应用程序未收到分段的UDP数据包 [英] Fragmented UDP packets not received by application

问题描述

非常奇怪的行为...

Very strange behavior...

我有3台机器:

 -----------     ------------     -----------
 | A (x86) |-----| B (x86)  |-----| C (arm) |
 | sender  |     | receiver |     | sender  |
 -----------     ------------     -----------

• A和B是Linux(Ubuntu 12.04)机器，内核3.2；
• C是一个Android(ICS)计算机，内核3.0.8;
• 所有均通过RJ45电缆连接；
• 连接正常，网络设置正确；
• A and B are Linux (Ubuntu 12.04) machines, kernel 3.2;
• C is an android (ICS) machine, kernel 3.0.8;
• All are connected via RJ45 cables;
• Connections are OK, network is set up correctly;

问题是::当机器C(ARM-android)发送有效载荷大小超过1472字节(分段前的最大有效载荷)的UDP数据包时，机器B上的服务器应用程序将永远无法执行收到，关于...:

Issue is: when machine C (ARM-android) sends a UDP packet which payload size is over 1472 bytes (maximum payload before packet gets fragmented), server application on machine B is never able to receive it, ... regarding that:

• 源/目标IP地址正确:如果将有效负载大小设置为小于或等于1472，我可以接收所有发送的数据报；
• 在机器B(接收方)上，如果我使用Wireshark转储网络流量，则可以看到每个片段，然后从Wireshark的角度重新组装消息=>，一切都很好！
• 将每个片段头以及重新组合的消息与从机器A发送的相同消息(总是收到OK)时可以转储的消息进行比较，一切似乎都很完美(只有区别是IP地址和校验和，因为UDP标头校验和包含帐户IP地址字段).
• 没有MTU问题，数据包按预期分段.
• 机器之间没有路由器/交换机
• ifconfig不会显示数据包丢失，溢出或任何其他经典错误！
• ...这太奇怪了！

我花了一些时间在Internet上，但从未找到过类似的话题.每次人们对UDP遇到麻烦时，要么是他们的MTU发现不正确，要么是他们在测试过程中处理不当，或者他们不能将消息转储到接收方主机上，...在这里不是这种情况！

I've spent some time on Internet, but never found any topic like this one. Each time people has troubles with UDP, either their MTU discovery was not correct, or they did some mishandling in the testing procedure, or they could not dump message on receiver host, ... this is not the case here!!

可以肯定的是，我知道问题出在发送方(机器C)上，但是也许可以更容易地在接收方启用一些日志(在内核级别?)以了解UDP数据报为什么消失了?有什么建议吗?我可以在/proc/sys/net中检入特定文件，还是应该启用的内核选项?

For sure, I know issue is on sender end (machine C), but maybe is could be easier to enable some logs (at kernel level?) on receiver end to understand why UDP datagram disappears!? Any advice? Are there specific files I could check in /proc/sys/net, or kernel options I should enable?

非常感谢.

推荐答案

如果您的计算机确实按照图示连接，即它们未连接到交换机/集线器，则必须在其上有两个NIC B因此它们将具有不同的地址，因此您用于从A发送给B的地址与从C发送给B的地址不同.即

If your machines are indeed connected as depicted, i.e. they are not connected to switch/hub, then you must have two NICs on B therefore they will have different addresses so the address you use to send to B from A will not be the same as sending to B from C. i.e.

您发送的地址可能不正确吗?尽管这不能解释较小的数据报如何通过-您确定它们通过吗?

Could the address you are sending to be wrong? Though that would not explain how smaller datagrams get through - are you sure they are?

注意:这些地址将必须手动分配，因为您没有连接到DHCP，此外，这些地址将必须与A和C位于同一子网中.您的所有地址(A，BA，BC和C)都是在同一个子网中? B上的套接字绑定并侦听到哪个address:port? B收到数据报后是否继续接收?请提供一些代码.

Note: Theses addresses would have to be assigned manually as you are not connected to DHCP, furthermore these addresses will need to be in the same subnet as A and C. Are all your addresses (A, BA, BC and C) in the same subnet? What address:port is the socket on B bound to and listening on? Does B continue to receive after receiving a datagram? Please provdie some code..

或，即使您的计算机连接到交换机/集线器，还是从C发送的数据报上设置的不分段"位，这可以解释为什么丢弃较大的而不是不发送较小的.

OR, even if your machines are connected to a switch/hub,, is the "Don't fragment" bit set on datagrams sent from C which would explain why larger ones are dropped but not smaller ones.

这篇关于应用程序未收到分段的UDP数据包的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！