Subject: Re: Unable to fetch - MSS problem?
To: Robert Elz <kre@munnari.OZ.AU>
From: Andreas Priebe <>
List: current-users
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 ( 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 > . 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 
> smaller.

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
 > (MSS+40).

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,