Subject: Re: Unable to fetch http://www.netbsd.org - MSS problem?
To: Robert Elz <kre@munnari.OZ.AU>
From: Andreas Priebe <email@example.com>
Date: 11/12/2003 16:03:03
Robert Elz wrote in an answer to my mail.
> | As you see my side announces MSS 1452 and if I understand Stevens correctly,
> | the other side (www.NetBSD.org) should not send segments greater than
> | this, but as you can see it send me 1500 Bytes packets, i.e. MSS=1460 -
> | right?
> No, it is sending 1448 byte (TCP) packets, see ...
> 19:51:20.614159 188.8.131.52.80 > 184.108.40.206.53248: . 1449:2897(1448)
> That (1448) is the number of TCP data bytes in the packet.
> This is because of ...
> ack 8 win 33580 <nop,nop,timestamp 3162162 6>
> those (TCP) options in the packet, they make the TCP header bigger than 20
> bytes (12 bytes bigger in this case). Those 12 are the difference between
> 1448 and the 1460 you calculated.
> 1448 < 1452 so this is all legal TCP. Nothing is directly broken here.
> If packets that big can't get to you, you may need to make the MSS even
I must admit, I had forgotten for TCP options (and how to extract the correct
number of TCP data from tcpdump).
But anyway: In a discussion on the NeBSD tech-net (?) list from Nov 2001:
Rick Byers stated:
> That is exactly why the RFCs define the MSS to be the maximum IP
> packet size minus 40. That way, the extra IP or TCP options count against
> the segment size to keep the total packet size bounded at a constant
This seems to be my impression from RFC 879 too:
> The definition of the MSS option can be stated:
> The maximum number of data octets that may be received by the
> sender of this TCP option in TCP segments with no TCP header
> options transmitted in IP datagrams with no IP header options.
Sorry for my ignorance, but still confused,