Windows 2000 TCP Does Not Pass Web Polygraph "msl_test" Test (261218)



The information in this article applies to:

  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Professional

This article was previously published under Q261218
IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows Registry

SYMPTOMS

Web Polygraph (http://polygraph.ircache.net/doc/msl_test.html) uses the Msl_test tool to verify the Maximum Segment Lifetime (MSL) value used by TCP. Windows 2000 does not pass the test with an incorrect value of 1 second reported.

Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.

CAUSE

According to Network Monitor traces, this behavior occurs because a SYN request sent from port 1054 to port 8080 causes an ACK response. The test assumes that the connection (1054, 8080) is in the TIME_WAIT state and therefore should not respond to a SYN request.

The current Windows 2000 behavior is:
  • No RST, SYN, or FIN (data segment or ACK) bit set:

    The segment is ignored, no ACK response is sent.
  • The FIN bit is set:

    If it is a duplicate FIN packet (the sequence number matches), an ACK response is sent and then 2MSL is restarted, otherwise the packet is ignored.
  • The RST bit is set:

    The connection is changed to the CLOSED state from the TIME_WAIT state and all the resources are released.
  • The SYN bit is set:

    The connection is changed to the CLOSED state from the TIME_WAIT state and all the resources are released. In addition, the connection is accepted normally (SYN.ACK is sent). This effectively i the 2*MSL period.

RESOLUTION

To resolve this problem, obtain the latest service pack for Windows 2000. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

260910 How to Obtain the Latest Windows 2000 Service Pack


STATUS

Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article.

This problem was first corrected in Windows 2000 Service Pack 1.

MORE INFORMATION

WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

This hotfix enables the following registry value that you can use to "tune" this behavior: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value: StrictTimeWaitSeqCheck
Value type: DWORD
Data:
  • 0 - (default) Windows 2000, Windows NT 4.0, Windows 95/98 behavior - There is no change in default behavior.
  • 1 - BSD style: New connections are accepted only if ISN is larger than rcvnext, otherwise SYN is ignored and the remote client eventually times out.
The connection in TIME WAIT takes approximately six more seconds to come out of the wait time than the default time. For additional information about how to install Windows 2000 and Windows 2000 hotfixes at the same time, click the article number below to view the article in the Microsoft Knowledge Base:

249149 Installing Microsoft Windows 2000 and Windows 2000 Hotfixes

The third-party products that are discussed in this article are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, regarding the performance or reliability of these products.

Modification Type:MajorLast Reviewed:11/20/2003
Keywords:kbbug kbfix kbQFE kbWin2000SP1Fix KB261218