All geek questions in one place

TCP accepts packets, but ignores them

I have a really weird network problem. The actual network configuration is quite complicated because I use Openstack and Docker to create a virtual network. However, the problem does not exist, because I grab my host interface and I see the whole packet in the right direction ... But for some reason I don’t know, it seems that TCP is ignoring them, although they have been received: it does not send an ACK for them and does not send data to the application.

In my tests, I sent an HTTP GET request for an html page to the server pier (IP 192.168.4.3) from the host (192.168.4.100).

What I see, capture 192.168.4.100 with Wireshark:

192.168.4.100 -> SYN -> 192.168.4.3 192.168.4.3 -> SYN, ACK -> 192.168.4.100 192.168.4.100 -> ACK -> 192.168.4.3 192.168.4.100 -> GET / HTTP/1.1 -> 192.168.4.3 192.168.4.3 -> ACK -> 192.168.4.100 192.168.4.3 -> Fragment 1 of HTTP 200 OK response -> 192.168.4.100 192.168.4.3 -> Fragment 2 of HTTP 200 OK response -> 192.168.4.100 192.168.4.3 -> Fragment 3 of HTTP 200 OK response (PSH) -> 192.168.4.100 192.168.4.3 -> Retransmission of Fragment 3 of HTTP 200 OK response (PSH) -> 192.168.4.100 192.168.4.3 -> Retransmission of Fragment 1 of HTTP 200 OK response -> 192.168.4.100 192.168.4.3 -> Retransmission of Fragment 1 of HTTP 200 OK response -> 192.168.4.100 192.168.4.3 -> Retransmission of Fragment 1 of HTTP 200 OK response -> 192.168.4.100 192.168.4.3 -> Retransmission of Fragment 1 of HTTP 200 OK response -> 192.168.4.100 192.168.4.3 -> Retransmission of Fragment 1 of HTTP 200 OK response -> 192.168.4.100 192.168.4.3 -> Retransmission of Fragment 1 of HTTP 200 OK response -> 192.168.4.100 192.168.4.100 -> ACK of Fragment 1 -> 192.168.4.3 192.168.4.3 -> Retransmission of Fragment 2 of HTTP 200 OK response -> 192.168.4.100 192.168.4.3 -> Retransmission of Fragment 3 of HTTP 200 OK response (PSH) -> 192.168.4.100 192.168.4.3 -> Retransmission of Fragment 2 of HTTP 200 OK response -> 192.168.4.100 192.168.4.3 -> Retransmission of Fragment 2 of HTTP 200 OK response -> 192.168.4.100 192.168.4.3 -> Retransmission of Fragment 2 of HTTP 200 OK response -> 192.168.4.100 192.168.4.3 -> Retransmission of Fragment 2 of HTTP 200 OK response -> 192.168.4.100 192.168.4.3 -> Retransmission of Fragment 2 of HTTP 200 OK response -> 192.168.4.100 192.168.4.3 -> Retransmission of Fragment 2 of HTTP 200 OK response -> 192.168.4.100 192.168.4.100 -> ACK of Fragment 2 -> 192.168.4.3 192.168.4.3 -> Retransmission of Fragment 3 of HTTP 200 OK response (PSH) -> 192.168.4.100 192.168.4.3 -> Retransmission of Fragment 3 of HTTP 200 OK response (PSH) -> 192.168.4.100 192.168.4.3 -> Retransmission of Fragment 3 of HTTP 200 OK response (PSH) -> 192.168.4.100 192.168.4.3 -> Retransmission of Fragment 3 of HTTP 200 OK response (PSH) -> 192.168.4.100 192.168.4.3 -> Retransmission of Fragment 3 of HTTP 200 OK response (PSH) -> 192.168.4.100 192.168.4.3 -> Retransmission of Fragment 3 of HTTP 200 OK response (PSH) -> 192.168.4.100 192.168.4.100 -> ACK of Fragment 3 -> 192.168.4.3

This is actually a big problem, since there is about 40 seconds between the GET request and the last ACK, which coincides with the moment the application (telnet in this case) receives data.

I checked the entire checksum and they are correct ...

So, I really don’t know why this is happening and what to do! I tried using different OS as hosts (Windows 8 mobile phone, MAC OSX, Ubuntu 14.04, ...), but nothing changes. If I send the same request from another docker of the virtual network, everything works fine.

Any idea on what might be the problem?

Thanks!

PS here you can see the screenshot:

enter image description here

Update

I think it’s interesting that I did a similar capture, but when the HTTP request is sent from 192.168.4.3 to 192.168.4.100. Shooting is again performed on the 192.168.4.100 interface, and again it seems that 192.168.4.100 is ignoring the packets it receives (look, for example, at a three-way handshake). And I did not find a reason for this again.

enter image description here

+5
source share
1 answer

I managed to solve my problem. I am posting a solution here that might be useful if someone has the same problem.

The problem was that I disabled TSO (tcp-segmentation-offload) on the virtual bridge, to which my dockers are attached using the command:

 ethtool -K IFACE_NAME tso off

It disables only the TSO, while the control upload remains on. Obviously, this is creating some kind of problem, and although Wireshark showed me that the TCP checksum is fine, in fact it is not. Thus, the host ignored the packet due to a poor TCP checksum.

To disable TSO and checksums, I simply used the command:

 ethtool --offload IFACE_NAME rx off tx off

And now everything works.

+1
source

Source: https://habr.com/ru/post/1206093/

More articles:


All Articles