This is our old Q&A Site. Please post any new questions and answers at

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:

Wireshark logs.

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
Querying active state...
TCP Global Parameters
Receive-Side Scaling State : enabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : none
ECN Capability : disabled
RFC 1323 Timestamps : disabled
** The above autotuninglevel setting is the result of Windows Scaling heuristics
overriding any local/policy configuration on at least one profile.

Thanks, Max.

asked 15 Mar '12, 23:16

mgalemin's gravatar image

accept rate: 0%

edited 16 Jun '12, 19:45

cmaynard's gravatar image

cmaynard ♦♦

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.

permanent link

answered 16 Mar '12, 23:28

Jim%20Aragon's gravatar image

Jim Aragon
accept rate: 24%

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.

(17 Mar '12, 00:21) mgalemin

(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.

permanent link

answered 17 Mar '12, 01:26

SYN-bit's gravatar image

SYN-bit ♦♦
accept rate: 20%

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.

permanent link

answered 16 Mar '12, 00:55

Jasper's gravatar image

Jasper ♦♦
accept rate: 18%

Hi Jasper,

Thanks for your reply. Basically RFC 879 says:

  • TCP provides an option that may be used at the time a connection is
  • established (only) to indicate the maximum size TCP segment that can
  • be accepted on that connection. This Maximum Segment Size (MSS)
  • announcement (often mistakenly called a negotiation) is sent from the
  • data receiver to the data sender and says "I can accept TCP segments
  • up to size X". The size (X) may be larger or smaller than the
  • default. The MSS can be used completely independently in each
  • direction of data flow. The result may be quite different maximum
  • sizes in the two directions.

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:

  1. Run test server program with particular MSS parameter, for example:

./tcpsrv --port=51234 --mss=128

  1. Establish raw TCP connection from putty;

  2. Send 1200 bytes of data.

Wireshark logs.

(16 Mar '12, 18:24) mgalemin
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 15 Mar '12, 23:16

question was seen: 18,896 times

last updated: 16 Jun '12, 19:45

p​o​w​e​r​e​d by O​S​Q​A