TCP接收数据包，但忽略它们(TCP receives packets, but it ignores them)

我有一个非常奇怪的网络问题。实际的网络配置非常复杂，因为我使用Openstack和Docker来构建虚拟网络。然而，这个问题并不存在，因为我正在捕获主机的接口，并以正确的方式看到所有数据包......但由于某些原因，我不知道，似乎TCP忽略了它们，尽管它们有已收到：它不会为它们发送ACK，也不会将数据发送给应用程序。

在我的试验中，我从主机（192.168.4.100）向服务器码头（IP 192.168.4.3）发送了一个HTML页面的HTTP GET请求。

我在Wireshark的192.168.4.100上看到的是：

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

这实际上是一个大问题，因为GET请求和最后一次ACK之间大约有40秒，这与应用程序（本例中为telnet）获取数据的时刻一致。

我检查了所有的校验和，他们是正确的...

所以我实际上不知道为什么会发生这种情况，该怎么办！我尝试过使用不同的操作系统作为主机（Windows 8手机，MAC OSX，Ubuntu 14.04，...），但没有任何变化。如果我从虚拟网络的另一个泊坞窗发送相同的请求，一切正常。

任何想法可能是什么问题？

谢谢！

PS在这里你可以看到截图的截图：

更新

我认为有趣的一件事是我做了类似的捕获，但是当HTTP请求从192.168.4.3发送到192.168.4.100时。在192.168.4.100接口上再次捕获捕获，并且似乎192.168.4.100再次忽略它接收到的数据包（例如，查看三次握手）。我发现没有理由再次。

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.

最满意答案

我设法解决了我的问题。我在这里发布解决方案，如果有人遇到同样的问题，这个解决方案很有用

问题是我禁用了Docker连接的虚拟网桥上的TSO（tcp-segmentation-offload）：

ethtool -K IFACE_NAME tso off

它仅关闭TSO，而校验和卸载保持打开状态。很明显，这会产生一些问题，尽管Wireshark向我展示了TCP校验和是确定的，但事实上并非如此。所以主机由于错误的TCP校验和而忽略了数据包。

要关闭TSO和校验和，我只是使用了这个命令：

ethtool --offload IFACE_NAME rx off tx off

现在一切正常。

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.

更多推荐