Bug ID 700889: Software syncookies without TCP TS improperly include TCP options that are not encoded

Last Modified: May 14, 2019

Bug Tracker

Affected Product:  See more info
BIG-IP LTM(all modules)

Known Affected Versions:
11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.6.1, 11.6.1 HF1, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3,,, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3,,,,,, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0,,,,,,,

Fixed In:

Opened: Jan 05, 2018
Severity: 3-Major
Related AskF5 Article:


When sending a software syncookie and there is no TCP timestamp option, tmm sends back TCP options like window scaling (WS), sackOK, etc. The values for these options are encoded in the timestamp field which is not sent. When the final ACK of the 3WHS arrives (without a timestamp), there is no way to know that the BIG-IP system negotiated the use of SACK, WS and other options that were encoded in the timestamp. This will leave the client believing that options are enabled and the BIG-IP believing that they are not.


In one known case, the client was Windows 7 which apparently disables timestamps by default. Users might experience poor connection performance because the client believed it was using WS, and that the BIG-IP system would scale up the advertised window. However, the BIG-IP system does not using WS in this case, and used the window size from the TCP header directly, causing the BIG-IP system to send small packets (believing it had filled the window) and wait for a response.


TCP timestamps are disabled by the client, or in the TCP profile.


Specifically prevent the WS issue by lowering the send_buffer_size and receive_window_size to less than or equal to 65535.

Fix Information

Added dependency between the window scale option and the timestamp option in a SYN/ACK response.

Behavior Change