Unable to map drives to a NetWare server - Workstation firewall issues

LOGIN-LGNWNT32.DLL -430: The following drive mapping operation could not be completed. The error code was 8819.

LOGIN-LGNWNT32.DLL -430: The following drive mapping operation could not be completed. The error code was 8804.

LOGIN-LGNWNT32.DLL -923: An unexpected error has occurred: 15 (8801).

LOGIN-LGNWNT32.DLL -923: An unexpected error has occurred: 9 (8801).

Various client error codes (0x88XX) are being returned in the login screen.

If you logout and loging again, sometimes all of the drive mappings show up.

If you initially login, the drive mappings do not occur. But if you re-login again, then all of the drive mappings occur.

To troubleshoot the problem, you need to take a LAN trace of the workstation trying to login. Make sure in your login script that you have the following at the top of your login script (and have your login script results not close when finished):

MAP DISPLAY ON

MAP ERRORS ON

Highlight the results from your login script results window and copy and paste it into a text document. Obtain the IP address of the server where the drive mappings failed with the 0x88XX error. If you are using Wireshark or Ethereal, you can create a display filter of all the communications between the two computers. The display filter is as follows:

ip.addr== and ip.addr==

What you want to look for in the LAN trace is the establishment of TCP communications between the two computers. Typically it will look like this: SYN | SYN ACK | ACK. If a half-open TCP connection exists on the server, you may see something like this: SYN | ACK | RST. Then you will see SYN | SYN ACK | ACK. If a workstation firewall is involved in a half-open TCP connection, you may see SYN | ACK | no response. SYN | ACK | no response. SYN | ACK | no response. At which point the drive mapping fails to occur. If you see the pattern of SYN | ACK | no response three times, then your firewall is not allowing the ACK to be passed up to the TCP/IP stack to be processed. By turning the firewall off, the IP stack will be able to properly handle the half-open connection.

If you want to use the firewall and not have these problems, then you need to configure your workstation firewall to allow for half-open TCP/IP connection information to be passed back up the IP stack. However, some firewalls are not configurable.

The problem stems on how these third party firewalls behave when they encounter a half-open TCP connection. RFC 793 refers to the TCP protocol and how it handles connection creation, maintenance, and shutdown/closure. It also discusses how to handle scenarios where the connection is half open.

In normal TCP/IP operation, when one computer communicates with another computer, it initiates that communication via the three way TCP handshake. The initiating computer sends a SYN request to the destination computer. The destination computer sends a SYN ACK back to the initiating computer. Then the initiating computer sends an ACK back to the destination computer. Once this is done the computers have a connection open to each other and they can continue to communicate.

Let's say the client workstation crashes or becomes disconnected. Or the connection tear down process was never completed correctly or packets were lost/dropped. The client may think it has properly disconnected, but the server still has data from the previous open TCP/IP connection with the client workstation. So the client workstation will start up and reuse one of the ports used to communicate with the server. This is known as a half-open connection. The client workstation will send a SYN request. Since the server still has previous connection data, the server sends an ACK back to the client instead of a SYN ACK. When the client receives the ACK instead of the SYN ACK, the TCP/IP stack on the workstation will send a RST (reset) back to the server and the connection will be reset. The client workstation will send a new SYN request, and the server will respond back with a SYN ACK instead of an ACK and everything proceeds as normal. This is all done under the covers as a part of the protocol. No errors are returned and everything works as expected.

Now install a firewall on your workstation, or use the firewall that is a part of the operating system. What firewalls do is they look for suspicious or malicious activity that is occurring on the wire. They can also block off certain ports so that applications cannot exploit those ports. If the firewall views something as suspicious, then it will drop the packet. Meaning, that packet that appears suspicious will never make it to the TCP/IP stack, thereby protecting the operating system from an "attack".

The firewalls generally have enough intelligence in them to know what a normal connection looks like. However, many of the firewalls view the response given for a half-open TCP connection as malicious activity and will not allow the packet to pass through to the TCP/IP stack. When the client workstation sends a SYN request to the server, and the server has previous connection information, the server will send an ACK back. However, since the packet is an ACK and not a SYN ACK, the firewall will not allow the ACK to pass back to the TCP/IP stack. The TCP/IP stack on a Windows workstation will try two more times to establish a connection (SYN), but it will continue to receive ACKs from the server, which are intercepted by the firewall and dropped.

As previously mentioned, RFC 793 has a section that deals with half-open TCP/IP connections. Starting on page 33 of RFC 793 there is a section titled "Half-Open Connections and Other Anomalies". Many firewalls view the behavior described on pages 33 - 35 of RFC 793 as potentially malicious and do not allow the ACK packets to make it back up to the TCP/IP stack. Therefore the firewalls do not conform to RFC 793 and can cause drive mapping problems or failures to occur. The occurrance of the drive failures will appear to be random.