TCP receives packets, but it ignores them

Question

I have a really strange networking problem. The actual network configuration is quite complex, because I am using Openstack and Docker to build a virtual network. However, the problem is not there, because I am capturing on my host's interface and I see all the packet in the right way.... But for some reasons I do not know, it seems that TCP is ignoring them, though they have been received: it doesn't send ACK for them and it doesn't send the data to the application.

In my trials, I sent HTTP GET request for an html page to a server jetty (IP 192.168.4.3) from an host (192.168.4.100).

What I see capturing on 192.168.4.100 with Wireshark is:

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, because there are about 40 seconds between the GET request and the last ACK which coincides with the moment the application (telnet in this case) gets the data.

I have checked all the checksum and they are correct...

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

Any idea about what the problem could be?

Thanks!

PS here you can see a screenshot of the capture:

Update

One thing I think can be interesting is that I have made an analogous capture, but when a HTTP request is sent from 192.168.4.3 to 192.168.4.100. The capture is taken again on the 192.168.4.100 interface and it seems again that 192.168.4.100 ignores the packets it receives (look at the three way handshake for example). And I found no reason for this again.

Answer 1

I managed to solve my problem. I post here the solution which can be useful if someone has my same problem.

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

ethtool -K IFACE_NAME tso off

It turns off only TSO, whereas the checksumming offload remains on. Evidently, this creates some problem and though Wireshark showed me that TCP checksum was OK, actually it wasn't. So the host ignored the packet due to the bad TCP checksum.

To turn off TSO and checksumming too, I just used the command:

ethtool --offload IFACE_NAME rx off tx off

And now everything works.