The TCP Window Scale Log Event

Last modified on 15 Nov, 2022. Revision 8
Up to date for
cOS Core 14.00.06
Supported since
cOS Core 9.30.x
Status OK
Peter Nilsson


I’m getting “TCP window scale” log events, what is the cause of this?


Unfortunately there is no simple answer to this question and in order to give a more detailed answer to what this is we have to go deeper in explaining the function itself.


TCP window scale is used to extend the range of the announced receive window. TCP window scale is an option that is negotiated between the client and the server.

Example of successful negotiation

Example of failed negotiation

Possible issues

Hosts stop sending the option after a few retransmission’s

Log entry: “Mismatching TCP window scale”

This log is triggered when not all SYNs in one direction are identical with respect to TCP window scale options. Usually caused by the workaround to stop sending the option after a few retransmission’s. The log tells what the previous decision regarding window scale was (old), what the new packet claims (new) and what the new decision is (effective).


old=8, new=not_used, effective=not_used.

In this case the host has previously announced that it is going to use 8 as window scale but we have now received a re-transmitted SYN from the host without any window scale options. The value of effective indicates that the Firewall will act as if all SYNs from that host (on this particular connection) did not include any window scale option.

This log is not necessarily a sign of problems; the Firewall might still be able to make the right decisions so that it can apply the same scaling as the hosts. If the Firewall makes the wrong decision then that should result in “TCP sequence number too high” logs and reduced throughput on the connection. This log is vital information when investigating such logs.

Can this cause connection failures/delays?

If the systems are unable to establish any TCP connection at all then this is likely not the cause; the log is just a sign that the client (or server) is trying to use the fall-back to not use window scaling to see if the use of the window scale option is the reason it can’t connect. The real problem is likely something else, for instance, routing, or somewhere outside the Firewall.

If there is a significant delay in establishing the connection but the connection eventually gets established the there might be some other device in the network (or even the server) that can’t handle window scaling resulting in that the first SYNs with window scaling are dropped. This can be fixed by configuring the clients to not use window scaling or configuring the Firewall to strip the window scale option.

Configuring the Firewall to strip the window scale option can always be used to decide whether the Firewall’s handling of window scaling is the cause to the problem or not (this is done with the TCP advanced setting WSOPT). If stripping the window scale does not help then it is not the Firewall’s handling of window scaling that causes the problem.

Related articles

QoS / Traffic Shaping: Will cOS Core alter DiffServ tagging?
6 Feb, 2023 core trafficshaping pipes tcp