Hi,

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 204.152.184.116.80 > 62.80.20.1.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 
> 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:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=fa.onn29ov.tjoegt%40ifi.uio.no&rnum=2&prev=/groups%3Fq%3Dtcp%2Bmss%2Boptions%26ie%3DUTF-8%26oe%3DUTF-8%26hl%3Den%26btnG%3DGoogle%2BSearch )

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,

Andreas