Is it possible that Windows 7 ignores TCP MSS? Even if another side announces MSS 256 bytes TCP/IP stack on Windows 7 sends TCP segments with payload > 256 bytes. Please find pcap files and a simple server program for testing this issue by following the link below: The issue can be reproduced on Windows 7 PC only (32/64 bits), i.e. not on Windows XP/Linux machines. Chimney Offload State is disabled on my Windows 7 PC: F:>netsh interface tcp show global Thanks, Max. asked 15 Mar '12, 23:16  mgalemin edited 16 Jun '12, 19:45  cmaynard ♦♦ |
3 Answers:
Here's a link to an article called Why Doesn't Windows Server 2008 negotiate TCP MSS smaller than 536 bytes? Although it's about Windows Server 2008, I think it's the same thing you're encountering on Windows 7. The author's conclusion is that recent versions of Windows don't recognize MSS values smaller than 536 bytes because Microsoft has coded them to not accept an MTU value smaller than 576 bytes. Google did not turn up a lot of information about this, and some of it was confusing. Your original question was "Is it possible that Windows 7 ignores TCP MSS?" The answer seems to be "Yes, for values less than 536." Whether it's a violation of the TCP RFCs or not, you have confirmed it using Wireshark. If your device has to interact with Windows 7 computers, you have to accommodate this behavior. The embedded device you're working on may have a limited amount of RAM, but there is still a practical minimum. If you want your device to communicate with Windows systems, you will have to equip it with enough RAM to handle a 536-byte MSS. answered 16 Mar '12, 23:28  Jim Aragon |
(I converted your "answers" to "comments", please read the FAQ for details) From RFC 791 (Internet Protocol): "All hosts must be prepared to accept datagrams of up to 576 octets (whether they arrive whole or in fragments)." So the MTU size of a link may be smaller, in which case fragmentation at the IP layer will occur if bigger IP datagrams are sent. The way to minimize the RF occupation is therefor to not only lower the MSS, but also lower the MTU on both sides of the RF link. This will make sure that each individual IP datagram that is sent over the link will have a maximum size. Of course this would mean that Win7 packets that do not follow the low MSS will indeed be fragmented at the IP layer, just before being put on the RF link. And they will be re-assembled by the IP stack at the receiving end. answered 17 Mar '12, 01:26  SYN-bit ♦♦ Thanks for you answer, SYN-bit. However, from my understanding the problem is not in IP layer (which is L3 in OSI model) but rather in TCP layer (L4). IP layer doesn't know anything about TCP MSS and it's a TCP layer responsibility to handle maximum size of data segment to be passed to the IP layer. Changing default MTU with IP datagram fragmentation on gateway device is a reasonable workaround but unfortunately it's not an easy fix in our network configuration. In any case I'm very surprised that Windows Vista/2008/7 just silently ignores announced small MSS value. (17 Mar '12, 01:48) mgalemin Yes and no. Since the TCP layer knows the IP layer MUST be able to send 576 byte datagrams, it can deduct that (without extra IP or TCP options) it must be able to send 536 byte segments to the IP layer. Since you said it is the RF link occupation that is of concern, the packet size limitation is basically a L2 limitation, which should be enforced as close to L2 as possible. That's why I think you should fix it in the IP layer by reducing the MTU. That way, there will never be a packet bigger than what you set the limit too on the RF link. (17 Mar '12, 02:23) SYN-bit ♦♦ |
I think that Windows 7 probably ignores the MSS of 256 since IPv4 requires an MTU of at least 576 bytes, which would lead to a minimum MSS of 536. With IPv6 the minimum MTU is 1280, resulting in an even larger minimum MSS. answered 16 Mar '12, 00:55  Jasper ♦♦ Hi Jasper, Thanks for your reply. Basically RFC 879 says:
So for example if PC is connected to an embedded device with small amount of RAM device will anounce MSS with value smaller than the default one. This is basically my case as I have RF embedded controller with Lwip TCP/IP stack connected to the network through RF link. The question is why TCP/IP stack on both Linux and Windows XP operating systems handles MSS but TCP/IP stack on Windows 7 ignores TCP MSS parameter? From my prospective it's a kind of violation of TCP standard. Please find additional wireshark traces and a simple server program for testing this issue in the attachment. I captured wireshark logs on both server and client machines. Server always was Linux Ubuntu PC and client were Win 7, Win XP and Linux Ubuntu. Test case:
./tcpsrv --port=51234 --mss=128
(16 Mar '12, 18:24) mgalemin |
Hi Jim,
Thanks a lot for your comment, it confirms and explains the original issue.
Basically in my case the main problem is not a limited amount of RAM but rather a maximum size of a data packet which can be transmitted over the air. Embedded device is a Radio Frequency modem and for some configurations maximum data packet length should be limited to a particular value to minimise RF channel occupation time. But it seems that I can't use MSS smaller than 536 bytes on Windows 7 PC. Thanks again!
Cheers, Max.