Environment
Novell Client for Windows 2000/XP/2003 4.91 Support Pack
2
Novell Client for Windows 2000/XP/2003 4.91 Support Pack
1
Novell Client for Windows 2000/XP/2003 4.91
Novell Client for Windows 2000/XP/2003 4.90 Support Pack
2
Novell Client for Windows 2000/XP/2003 4.90 Support Pack
1a
Novell Client for Windows 2000/XP/2003 pre-4.90
Situation
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.
Resolution
Look on the client workstation and see if you have any sort of client firewall installed, such as the Microsoft Windows Firewall, or a third-party firewall. To fix the problem, you need to disable the firewall that is installed on the workstation and try logging in again.
TROUBLESHOOTING:
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.
Status
Top IssueAdditional Information
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.