在某台PC上，当UDP数据包大小小于12字节时，UDP数据包将被丢弃。我该如何找出原因？
我遇到了一个以前从未听说过的问题。
我正在制作一个在线游戏，它在某个角色动作中使用 UDP 数据包。在我开发了udp模块之后，它似乎工作得很好。虽然我们的大多数团队成员都没有问题，但是一个人，也就是我的老板，告诉我那个模块出了问题。
我调查了这个问题，最后我发现了这样一个事实：在他的电脑上，如果 udp 数据包大小小于 12，则该数据包永远不会被传递到其他主机。
以下是一些附加信息：
- 1~11 字节的 udp 数据包被丢弃，12 字节和超过 12 字节的数据包正常。
- 操作系统：Microsoft Windows Vista Business
- 网卡：Attansic L1 千兆位以太网 10/100/1000Base-T 控制器
- WSASendTo 返回 TRUE。
- 环回 udp 数据包工作正常。
您如何看待这个问题？您认为...是什么导致了这个问题？ 为了事业我下一步应该做什么？
附言。我不想填充，这会使所有数据包的长度达到 12 个字节。
i've stuck in a problem that is never heard about before.
i'm making an online game which uses UDP packets in a certain character action. after i developed the udp module, it seems to work fine. though most of our team members have no problem, but a man, who is my boss, told me something is wrong for that module.
i have investigated the problem, and finally i found the fact that... on his PC, if udp packet size is less than 12, the packet is never have been delivered to the other host.
the following is some additional information:
- 1~11 bytes udp packets are dropped, 12 bytes and over 12 bytes packets are OK.
- O/S: Microsoft Windows Vista Business
- NIC: Attansic L1 Gigabit Ethernet 10/100/1000Base-T Controller
- WSASendTo returns TRUE.
- loopback udp packet works fine.
how do you think of this problem? and what do you think... what causes this problem?
what should i do for the next step for the cause?
PS. i don't want to padding which makes length of all the packets up to 12 bytes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
只是为了得到一个不明显的答案：也许该卡上的 UDP 校验和卸载被破坏，即数据包已发送，但被接收器丢弃？
您可以使用 Wireshark 查看收到的数据包来检查这一点。
Just to get one of the non-obvious answers in: maybe UDP checksum offload is broken on that card, i.e. the packets are sent, but dropped by the receiver?
You can check for this by looking at the received packets using Wireshark.
如果您已经检查过防火墙、防病毒、网络防火墙、网络入侵。阅读此内容
对于 UDP 数据包 ethernet_header(14 字节) + IPv4_header(最小 20 字节) + UDP_header (8 字节) = 42 字节
现在，由于它小于 Linux 上的 64 字节或 60，网络驱动程序将在发送数据包之前用 (64-42 = 22) 零填充数据包，使其达到 60 字节。
这是 UDP 数据包的最小长度。
理论上你可以发送0个数据字节的数据包，但还没有尝试过。
至于你的问题，一定是操作系统问题。检查网络的驱动程序手册或咨询制造商。因为这不应该发生。
参考：http://www.freesoft.org/CIE/Course/Section4/8.htm
参考：http://en.wikipedia.org/wiki/User_Datagram_Protocol
IF you already checked firewall, antivirus, network firewall, network intrusion. read this
For a UDP packet ethernet_header(14 bytes) + IPv4_header(20 bytes min) + UDP_header (8 bytes) = 42 bytes
Now since its less than the 64 bytes or 60 on linux, network driver will pad the packet with (64-42 = 22 ) zeros to make it 60 bytes before it send out the packet.
that's the minimum length for a UDP packet.
theoretically you can send 0 data bytes packet, but haven't tried it yet.
as for your issue it must be an OS issue . check your network's driver's manual or check with manufacturer. because this isn't suuposed to happen.
REF:http://www.freesoft.org/CIE/Course/Section4/8.htm
REF:http://en.wikipedia.org/wiki/User_Datagram_Protocol
在他的 PC 和目标 PC 上运行 Wireshark。
日志是否显示 udp 数据包离开他的机器？是否显示它已到达目标 PC？
他的 PC 和目的地之间有什么样的路由器硬件或交换机？您可以将它们拆下并用交叉电缆将两者连接起来吗？ （或者用笔记本电脑替换目的地，并使用交叉电缆将其链接到他的 PC？）
您是否删除或至少列出了他的计算机上的所有防病毒和防火墙产品以及安装 Winsock LSP 的任何产品？
是所有 12 字节或更少的数据包都被丢弃还是只是一些数据包被丢弃，您能否生成具有随机内容的数据包并查看是否是内容中的某些内容（而不仅仅是大小）导致了问题。
Run Wireshark on his PC AND on the destination PC.
Does the log show the udp packet leaving his machine? Does it show it arriving on the destination PC?
What kind of router hardware or switches are between his PC and the destination? Can you remove them and link the two with a cross over cable? (or replace the destination with a laptop and link that to his PC with a cross over cable?)
Have you removed or at least listed all anti virus and firewall products on his machine and anything that installs a Winsock LSP ?
Do ALL 12 byte or less packets get dropped or just some, can you generate packets with random content and see if it's something in the content, rather than just the size, that's causing the issue.
假设您的问题是从他的 PC 发送：首先，在有问题的 PC 上运行数据包嗅探器，看看它是否到达 NIC。如果成功，则 NIC 或 NIC 驱动程序可能有问题。
接下来，检查是否有任何正在运行的防火墙软件。尝试禁用它，看看会发生什么。
如果这不起作用，请使用
netsh Winsock Catalog Reset。如果这不起作用，我就会被难住了:)
最后，您可能会发现其他有同样问题的客户；无论如何，你可能想考虑一下这个解决方法。尝试在连接上发送一些小型 UDP 数据包，如果它们始终无法通过，请启用填充解决方法。对于探测数据包通过的主机，您不需要将它们填充。
Assuming your problem is with sending from his PC: First, run a packet sniffer on the problematic PC to see if it arrives at the NIC. If it makes it there, there may be a problem in the NIC or NIC driver.
Next, check for any running firewall software. Try disabling it and see what happens.
If that doesn't work, clear out any Winsock Layered Service Providers with
netsh winsock catalog reset.If that doesn't work, I'm stumped :)
Finally, you're probably going to find other customers with the same problem; you might want to think about that workaround anyway. Try sending a few small-size UDP packets on connect, and if they consistently fail to go through, enable a padding workaround. For hosts where the probe packets make it through, you don't need to pad them out.
纯粹的猜想：RTP是一种在UDP上发送的非常常见的数据包，它定义了12字节标头。我想知道网络软件的某个层是否假设任何较小的东西都是格式错误的 RTP 数据包并将其丢弃？
Pure conjecture: RTP, which is a very common packet to send on UDP, defines a 12 byte header. I wonder if some layer of network software is assuming that anything smaller is a malformed RTP packet and throwing it away?
这让我在两个 IoT 相关项目中遇到了麻烦，在这些项目中，在从边缘设备到服务器的路由过程中，小于 12 字节的小型 UDP 有效负载会被丢弃，反之亦然。
本文建议 Win 和 Linux 操作系统主机上的路由原因与网络接口有关，并且该问题已得到修复。如果您有权访问资源网络设置（在 Azure 容器实例上我无权访问），您还可以修改 NIC 属性以禁用校验和卸载。
参考号
https://github.com/microsoft/WSL/issues/8610
我们发现了填充在这两种情况下，将 UDP 数据包调整为 12 字节都可以缓解该问题。
解决方案：
更新以添加我们从使用 Azure 容器实例迁移到使用带有 Windows VM 后端池并运行的 Azure 负载均衡器VM 上的 Windows 服务。对 ACI 资源进行了更多工作，以从 Azure Dev Ops 启动并运行部署管道，但效果很好，不再需要填充 ACK。 VM 在 Windows Server 2022 数据中心版本上运行以供参考。
This has tripped me up on two IoT related projects where small UDP payloads less than 12 bytes are dropped during the routing from edge device to server and vice versa from certain types of Azure resources.
This article here suggests the route cause on Win and Linux OS hosts is related to the network interface and the issue has been patched. If you have access to the resource network settings (on an Azure Container Instance I dont) you can also amend the NIC properties to disable checksum offload.
Ref
https://github.com/microsoft/WSL/issues/8610
We found padding UDP packets to 12 bytes in both cases mitigated the issue.
Solutions:
Update to add we migrated from using an Azure Container Instance to using a Azure Load Balancer with Windows VM backend pools and running a windows service on the VM. Took a bit more work over a ACI resources to get the deployment pipeline up and running from Azure Dev Ops but works a treat and no longer need to pad the ACKs. VMs are running on Windows Server 2022 data centre edition for ref.