
Windows corrupting UDP datagrams - gkfasdfasdf
http://blog.geeky-boy.com/2015/10/windows-corrupting-udp-datagrams.html
======
detaro
I honestly think the theory of the NIC messing up one of the offloaded tasks
is a likely one, if I remember other strange errors that have happened in this
context. To bad that he doesn't have access to the machine to do more thorough
tests.

~~~
IvyMike
My money's also on a NIC checksum/segmentation offloading bug. Even though it
apparently isn't controllable via the exposed parameters, the card does have
these features. "TCP/UDP checksum and segmentation offload (IPv4 and IPv6)" on
the spec sheet [https://www-ssl.intel.com/content/dam/doc/product-
brief/8257...](https://www-ssl.intel.com/content/dam/doc/product-
brief/82579-gbe-controller-brief.pdf)

------
tiernano
should this not be "Windows corrupting UDP Datagrams in some (possibly lower
chance) cases"? The list of circumstances for the bug to occur (from the
article):

1\. UDP protocol. (Duh!) 2\. Multicast sends. (Does not happen with unicast
UDP.) 3\. A process on the same machine must be joined to the same multicast
group as being sent. 4\. Window's IP MTU size set to smaller than the default
1500 (I tested 1300).

5\. Sending datagrams large enough to require fragmentation by the reduced
MTU, but still small enough _not_ to require fragmentation with a 1500-byte
MTU.

~~~
IvyMike
> should this not be "Windows corrupting UDP Datagrams in some (possibly lower
> chance) cases"?

I mean, I guess, but I kinda assumed as much, since if Windows was corrupting
UDP at any significant frequency certainly it would have been noticed by now.

~~~
jandrese
It is a fairly unusual situation, but yeah, I would expect someone else to
have seen this by now.

I might have to try this myself to see if I can replicate it.

------
golem_de
I don't know why you set the MTU to a lower value... What I do know, is that
I've set it to 65535; my machine now transmits 64KB instead of just 1.5KB (per
packet)... Can you imagine what would happen if I set this to
UInt32.MaxValue...?

~~~
JoeAltmaier
Its generally a terrible idea to increase UDP MTU. There's no reliable
reassembly in UDP. If you miss a single packet (out of say 1000) then all are
simply discarded silently.

In fact, some versions of Linux didn't do UDP reassembly properly until a year
ago (was a topic here on HN). Reordered UDP wasn't dealt with properly if I
recall.

There are routers that drop UDP for any reason or no reason. And so on. So UDP
is the red-headed stepchild of protocols, with little testing going on and
lots of issues.

I recommend putting a protocol on top of _any_ UDP transfer you code, and
never increasing the MTU.

~~~
golem_de
Man, you know, it's just a packet, not 1.500, but 65.535 bytes. There could be
4.294.967.295 bytes!!! :-)

For basically everything TCP is used. UDP is just used by DNS and they usually
weight 100 - 200 bytes.

Look into your wireshark!

~~~
JoeAltmaier
The UDP packet, and what goes out on the wire, are different things. IP-over-
Ethernet for instance does not send out data in units larger than 1500 bytes;
often smaller over WiFi. So UDP packets larger than 1500 bytes will be divided
up, and reassembled on the receive end.

