使用tcpdump监视流量时缺少UDP片段 [英] Missing UDP fragments when monitoring traffic with tcpdump

问题描述

我在本地局域网上，只有8台连接的计算机使用netgear 24端口千兆交换机，网络负载确实很低，并且所有涉及的节点(运行slackware 11)上的发送/接收缓冲区都设置为16mb.我还在每个节点上运行tcpdump来监视流量.

I'm on a local LAN with only 8 connected computers using a netgear 24 port gigabit switch, network load is really low and send/receive buffers on all involved nodes(running slackware 11) have been set to 16mb. I'm also running tcpdump on each node to monitor the traffic.

发送节点发送一个10044byte的大UDP数据包，该数据包通常(3/4倍)不会在接收方应用程序中终止，在这些情况下，我注意到(使用tcpdump)前x个片段丢失了， tcpdump仅捕获最后3个(所有偏移> 0并按顺序排列).因此，碎片化的UDP程序包无法重组，很可能会被丢弃.

A sending node sends a 10044byte large UDP packet which more often than not (3/4 times) does not end up in the receiving side application, in these cases I notice(using tcpdump) that the first x fragments are missing and only the last 3 (all with offsets > 0 and in order) are caught by tcpdump. The fragmented UDP package can therefore not be reassembled and is most likely thrown away.

我发现丢失的碎片很奇怪，因为我还尝试了一个简单的负载测试，该测试突发了10000个大小相同的UDP消息，接收应用程序发送了响应，到目前为止所有测试都给出了100％的响应.

I find the missing fragments strange since I have also tried a simple load test bursting out 10000 UDP messages of the same size, the receiving application sends a response and all tests so far gives 100% responses back.

有任何线索或提示吗?

推荐答案

更新！

在恢复对上述软件的测试之后，我发现了一种可重复的错误再现方法.

After resuming the testing of the above mentioned software I found a repeatable way of recreating the error.

在发送应用程序空闲一段时间(约5分钟)后，使用发送Windows机器上的windump和接收计算机上的tcpdump，我尝试发送udp消息，但最终只有一个被windump捕获的片段和tcpdump，剩下的3个片段会丢失.再发送一次相同的消息可以正常工作，并且展位windump和tcpdump捕获所有4个片段，并且接收方的应用程序将获得该消息.该模式是可重复的.

Using windump on the sending windows machine, and tcpdump on the receiving machine, after having left the application idle for some time(~5 minutes), I tried sending the udp message but only end up with a single fragment caught by windump and tcpdump, the 3 remaining fragments are lost. Sending the same message one more time works fine and booth windump and tcpdump catches all 4 fragments and the application on the receiving side gets the message. The pattern is repeatable.

开始搜索并找到以下信息，但对我来说，仍然不是一个明确的答案.

Started searching and found the following information, but to me, still not a clear answer.

http://www .eggheadcafe.com/software/aspnet/32856705/first-udp-message-to-a-sp.aspx

重新检查日志，现在我注意到正在发送ARP请求/答复，这与上面链接中给出的想法之一相符.

Re examining the logs I now notice the ARP request/reply being sent, which matches one of the ideas given in the link above.

注意！我使用以下命令过滤发送方的windump:"dst host receivernode"

NOTE! I filter windump on the sending side using: "dst host receivernode"

从windump捕获:第一条失败的udp消息，长度应为4个片段

Capture from windump: first failed udp message, should be 4 fragments long

14:52:45.342266 arp who-has receivernode tell sendernode
14:52:45.342599 IP sendernode> receivernode : udp

从异常捕获中捕获:第二条udp消息，内容完全相同，所有4个片段都被捕获

Capture from windump: second udp message, exactly the same contents, all 4 fragments caught

14:52:54.132383 IP sendernode.10104 > receivernode .10113: UDP, length 6019
14:52:54.132397 IP sendernode> receivernode : udp
14:52:54.132406 IP sendernode> receivernode : udp
14:52:54.132414 IP sendernode> receivernode : udp
14:52:54.132422 IP sendernode> receivernode : udp
14:52:56.142421 arp reply sendernode is-at 00:11:11:XX:XX:fd (oui unknown)

谁对发生的事情有个好主意?请详细说明！

Anyone who has a good idea about whats happening? please elaborate!

这篇关于使用tcpdump监视流量时缺少UDP片段的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！