UDP datagrams have no sequence numbers, so sending a big amount of data can result in fragmented datagrams. For example, netcat can be easily used on Linux to produce UDP fragments:
$ dd if=/dev/zero count=10 | nc 192.168.0.1 1234
With tcpdump, we can observe the presence of the datagram id, the increasing fragment offset, and the “More fragments” flag:
# tcpdump -i eth0 -vvv udp and not port 53
00:41:35.449822 IP (tos 0x0, ttl 63, id 33788, offset 0, flags [+], proto UDP (17), length 1444)
192.168.0.2.38920 > 192.168.0.1.1234: UDP, bad length 5120 > 1416
00:41:35.449947 IP (tos 0x0, ttl 63, id 33788, offset 1424, flags [+], proto UDP (17), length 1444)
192.168.0.2 > 192.168.0.1: udp
00:41:35.449976 IP (tos 0x0, ttl 63, id 33788, offset 2848, flags [+], proto UDP (17), length 1444)
192.168.0.2 > 192.168.0.1: udp
00:41:35.450000 IP (tos 0x0, ttl 63, id 33788, offset 4272, flags [none], proto UDP (17), length 876)
192.168.0.2 > 192.168.0.1: udp
Some notes:
- This does not require any listener on the destination node.
- It produces different results (no fragments, it seems) if source and destination are the same machine, e.g. targetting
localhost
. Probably because my lo
interface has a MTU of 65536.
- TCP datagrams are not fragmented by netcat, the sequence number is used to reassemble the data chunks at the destination node.
I did not have a chance to try the Windows equivalent, but it is likely that it produces fragments as well. Given that the question was asked ten years ago anyway, the “Windows” restriction might not really matter anymore.