SNARAS Receives 651 RAS Error After Failed Connection Attempt

• Microsoft SNA Server, versions 2.0, 2.1, 2.11, and 2.11 Service Pack 1

SYMPTOMS

You may want to use the NETBIOS interface made available in SNARAS to employ Microsoft networking over your existing SNA network, which consists mainly of 9600 SDLC multidrop links. This would allow you to use Systems Management Server remote control facilities and manage your computers running Windows NT Server through the Windows NT Administrative Utilities and the SNA Administrator UI.

However, implementing SNARAS over slow SDLC links on WAN networks can result in the following errors. When the SNARAS connection is dialed using the remote access client phonebook, after 10 seconds or so the following error message appears:

   Error 629
   Port was disconnected by remote machine.

   Error 651
   Your modem or other connecting device has reported an error.

CAUSE

The very low network bandwidth being used is insufficient to host the complex protocols employed to achieve Microsoft networking. The low bandwidth is further eroded as peer entities in all the protocol stacks being used time out request and initiate their retransmission routines.

The problem ultimately is the low bandwidth of the end-to-end connection, which can be as low as 120 KBps as a result of a mixture of low speed SDLC links between FEPs and other SNA traffic over the same links. SNARAS provides a guaranteed delivery, but RAS "believes" that it is not guaranteed and this level of bandwidth is too low for RAS to use.

RESOLUTION

Upgrade slow links to links that can adequately handle NetBIOS/Server Message Block (SMB) traffic.

MORE INFORMATION

Within the SNARAS components connection timeouts can be seen by employing the checked versions of Snaras.dll and Rassna.dll to produce internal tracing, as demonstrated below:

RASSNA.DLL internal tracing

SNARAS.DLL internal tracing

However, these failures occur as a result of an underlying network failure which can be seen if RAS PPP logging is enabled. The logs will show PPP packets get received a very long time after they are sent, causing PPP LCP to come down and re-negotiate. So LCP goes up and down for a long time until it disconnects. This is called a cross connection.

Although there are Microsoft Knowledge Base articles that describe how to tune timing parameters in the network protocols right up to SMB layer, Microsoft network architecture is not designed to work over networks offering such low bandwidth.