SNA Client Sessions Hang until SNA Server is Restarted (175321)

RESOLUTION

Windows NT 3.51

The Windows NT 3.51 fix should have the following time stamp:

10/29/97	04:23p	58,192	Dlc.sys	Intel
10/29/97	04:21p	100,752	Dlc.sys	Alpha
10/29/97	04:20p	88,016	Dlc.sys	MIPS

Windows NT 4.0

To resolve this problem, obtain the latest service pack for Windows NT 4.0 or Windows NT Server 4.0, Terminal Server Edition. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

152734 How to Obtain the Latest Windows NT 4.0 Service Pack

STATUS

Microsoft has confirmed this to be a problem in Windows NT version 3.51. A supported fix is now available, but has not been fully regression tested and should be applied only to systems experiencing this specific problem. Unless you are severely impacted by this specific problem, Microsoft recommends that you wait for the next service pack that contains this fix. Contact Microsoft Technical Support for more information.

Microsoft has confirmed that this is a problem in Windows NT 4.0 and Windows NT Server 4.0, Terminal Server Edition. This problem was first corrected in Windows NT 4.0 Service Pack 4.0 and Windows NT Server 4.0, Terminal Server Edition Service Pack 4.

MORE INFORMATION

This problem has been observed when using SNA Server on top of Windows NT 4.0 Service Pack 3 Dlc.sys driver, although it may occur with previous Windows NT 4.0 service pack levels and also with Windows NT 3.51. If the SNA Server is stopped and restarted, the 802.2 connection stays in a Pending state and does not reactivate. The only way to recover the 802.2 connection is to restart the server running both Windows NT and SNA Server.

SNA Server 802.2 link service Level 2 traces will show that the link service has several outstanding calls to the Windows NT Dlc.sys TRANSMIT.I.FRAME function that never complete. A network monitor LAN trace shows that Windows NT stops sending any DLC I-frames to the remote SNA system, although I-frames continue to be accepted from the remote system. The problem starts to occur after Windows NT DLC receives a REJ response to a retransmitted I-frame. The following network monitor trace illustrates the problem:

 Src Addr  Dst Addr  Description
 --------  --------  -----------

 SNASRV    HOST      I DSAP=0x04 SSAP=0x04 C N(S) = 0x0B, N(R) = 0x10
 SNASRV    HOST      I DSAP=0x04 SSAP=0x04 C N(S) = 0x0C, N(R) = 0x10 POLL
 HOST      SNASRV    RR DSAP=0x04 SSAP=0x05 R N(R) = 0x0B FINAL
 SNASRV    HOST      I DSAP=0x04 SSAP=0x04 C N(S) = 0x0B, N(R) = 0x10 POLL
 HOST      SNASRV    I DSAP=0x04 SSAP=0x04 C N(S) = 0x10, N(R) = 0x0B
 HOST      SNASRV    I DSAP=0x04 SSAP=0x04 C N(S) = 0x11, N(R) = 0x0B
 SNASRV    HOST      RR DSAP=0x04 SSAP=0x05 R N(R) = 0x11
 HOST      SNASRV    I DSAP=0x04 SSAP=0x04 C N(S) = 0x12, N(R) = 0x0B
 HOST      SNASRV    RR DSAP=0x04 SSAP=0x05 R N(R) = 0x0C
 SNASRV    HOST      RR DSAP=0x04 SSAP=0x05 R N(R) = 0x13
 HOST      SNASRV    RR DSAP=0x04 SSAP=0x05 R N(R) = 0x0D FINAL
 HOST      SNASRV    REJ DSAP=0x04 SSAP=0x05 R N(R) = 0x0D FINAL
 HOST      SNASRV    I DSAP=0x04 SSAP=0x04 C N(S) = 0x13, N(R) = 0x0D
 HOST      SNASRV    I DSAP=0x04 SSAP=0x04 C N(S) = 0x14, N(R) = 0x0D
 SNASRV    HOST      RR DSAP=0x04 SSAP=0x05 R N(R) = 0x15
 HOST      SNASRV    I DSAP=0x04 SSAP=0x04 C N(S) = 0x15, N(R) = 0x0D
 SNASRV    HOST      RR DSAP=0x04 SSAP=0x05 R N(R) = 0x16
 SNASRV    HOST      RR DSAP=0x04 SSAP=0x04 C N(R) = 0x16 POLL

In the above trace, Windows NT (SNASRV) sends I-frames 0x0B and 0x0C, setting the POLL bit after sending I-frame 0x0C. The host does not ack these I-frames, causing Windows NT (SNASRV) to resend I-frame 0x0B in line 4 above. The host eventually acks the I-frame 0x0C, but it then REJects the resend of I-frame 0x0B. After Windows NT DLC receives the host REJ (to the retransmitted I-frame 0x0B), Windows NT DLC never sends any more I-frames to the host. As this occurs, the SNA Server 802.2 link service's calls to TRANSMIT.I.FRAME stop responding (hang) and never complete.