1

Environment: I am writing a UDP client-server application. the path MTU between client and server is 1500 bytes (with only a wireless link between them, so this value is pretty much stable). My system set don't fragment bit by default, and on both client and server, SO_SENDBUF is 16384, and SO_RECVBUF = 87380.

Question: Client use sendto to send 8192 bytes to server at once.I use Wireshark to see how these 8192 bytes will be sent in mow many packets, and discover that each packet only holds 1023 bytes of UDP data max. But given path MTU = 1500, shouldn't I be able to send 1500-20(IP header)-8(UDP header) = 1472 bytes of data in each packet? When I do the same thing with TCP, the result is what I expected. Each TCP packet can hold up to 1448 bytes, which is 1500-20(IP header)-32(TCP header with timestamp option) My question is: why dosn't UDP put 1472 bytes in each packet, instead of 1023 bytes? Is it just minor implementation detail? Or did I overlook some system restrictions?

Remark: The same result ca be observed even when I do the experiment on the same machine (with 127.0.0.1 on loopback interface).

schwannden
  • 19
  • 1
  • 5
  • 2
    Clearly something is missing from your analysis. There is no way a 8192 byte payload could be fragmented with 1023 bytes in each fragment for the simple reason that fragmentation always happens on 8 byte boundaries. – kasperd Apr 04 '18 at 21:21

1 Answers1

-1

You are just deducting overhead for layers L4(UDP) and L3(IP). I'm guessing the overhead in the Ethernet frame (L2) with preamble, MAC addressing, type field and checksum would account for the rest?

http://www.doc.ic.ac.uk/~nd/surprise_97/journal/vol4/mhl/ether01.gif

ErikE
  • 4,746
  • 1
  • 20
  • 27
  • 1
    Because there are 1472-1023 = 449 bytes missing, I don't think that is the reason. Also, that's why I re-do my experiment on TCP. In TCP, there is no such problem. And I also think that the value of path MTU already exclude data-link layer header – schwannden Dec 07 '13 at 08:44
  • Yes that is a lot. I'm thinking maybe wireshark gets tricked by some offloading function, only I cannot readily conceive what that function would be (I have been tricked by wireshark before, just not by this). A good weekend mystery question to ponder btw. – ErikE Dec 07 '13 at 09:16
  • Is it conceivable something similar to this is happening? http://sandilands.info/sgordon/segmentation-offloading-with-wireshark-and-ethtool – ErikE Dec 07 '13 at 09:30
  • This answer is incorrect. The MTU is defined to include the IP header but not the MAC header or trailer. – kasperd Apr 04 '18 at 21:23