https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5667
--- Comment #5 from Guy Harris <guy@xxxxxxxxxxxx> 2011-02-09 00:28:57 PST ---
As for why it picked 590 bytes, that's a good question. If "590 bytes" is the
size of the TCP payload, and if the IPv4 and TCP headers had no options, that's
a total of 590+20+20 = 630 bytes, but that's not an obvious MTU for any
networks I know of - the MTU for Ethernet is typically 1500 bytes (1500 bytes
of payload + 14 bytes of Ethernet header + 4 bytes of Ethernet CRC = 1518
bytes, which is the maximum Ethernet packet size including the CRC), and the
MTU for 802.11 is larger (although, in practice, packets are often bridged
between 802.11 and Ethernet, so the MTU is cut to the Ethernet MTU), and
framing such as PPPoE used on some home Internet links only reduce the MTU by a
small amount. If it's the size of the *total* payload, I'm not sure I know of
any network where 590 is the MTU.
Perhaps there's some link in between with the lower MTU, and it used Path MTU
Discovery to determine that the maximum segment size should be tuned to avoid
IP fragmentation on that link.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
