Subject: interesting MSS handling issue

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 25 Apr 2000 12:34:28 -0700

Saw an interesting tcpdump between UnixWare 7 and Solaris 7, where the
UnixWare host was transmitting segments with 1460-byte payloads, even
though timestamp and a couple of noop options were in the TCP headers
(resulting in fragmentation). This did not occur with connections
between similar UnixWare hosts; in those cases the host sent 1448-byte
payloads (leaving room for timestamp and noops).

The only thing that shows up different between the UW-Sol and UW-UW
connections is that Solaris put the MSS option at the end of the option
list, while UW puts it at the beginning:

UW7 returns:
09:18:38.817464 btstche.bld.cqg.com.shell > bvt.bld.cqg.com.1017: S
13303670:13303670(0) ack 2674166220 win 24820 <mss 1460,nop,wscale
0,nop,nop,timestamp 5472284 21403787>

Solaris returns:
09:19:44.222169 bsldev.bld.cqg.com.shell > bvt.bld.cqg.com.1014: S
2501322619:2501322619(0) ack 2690620994 win 10136 <nop,nop,timestamp
1664310917 21410324,nop,wscale 0,mss 1460> (DF)

Possible explanation: UW is processing options linearly, so it is
starting with a default MSS, subtracting segment space for options like
SACK and timestamp as needed, and then sees MSS of 1460 which overrides
the adjustments.

Has this happened anywhere else? Has putting MSS at the end of the
option list triggered this sort of problem anywhere else, or has UW7
shown this problem with other platforms that put MSS somewhere other
than at the beginning.

-- 
Eric A. Hall                                            [email-masked]
+1-650-685-0557                                    http://www.ehsco.com