Please forgive the lengthy message, but I'm hoping that by giving too much detail, I might avoid multiple posts.

We are using Client32 4.90 sp2 on Windows XP sp2 (firewall disabled) and randomly receive lgnwnt32 890 and 100 errors on logging in. We have probably 1500 machines with this client version, but the problem is local to one hardware platform (but this one platform is used in a manner that others are not).

The specific circumstance is that we are using Cisco 802.11a/b/g cards in Compaq laptops with LEAP authentication. The issue seems limited only to these laptops. We do have other laptops with Intel wireless and LEAP, but the issue does not occur on the other models.

What is concerning is that the LEAP authentication process (using pre-setup userid/passwords) occurs just after the login screen appears. Obviously if we try to login prior to the LEAP process finishing, we get a "tree or server not found" error - we've trained our users through that one.

What does happen is a randomly occuring -890 or -100 error in LGNWNT32 immediately after pressing OK on the login screen. Subsequent drive mappings to one specific server fail. The "bad" server is the preferred server in both the client profile, and the default server in the user object.

After a period of time, the server can be accessed without logging-out and back in again.

It would be very easy to troubleshoot with a packet trace during that login process, but I am having a great deal of difficulty getting a Linux box to authenticate using LEAP to use the wireless card to sniff what is happening to other machines (I do not think it is possible to use Ethereal on Windows to see traffic to/from other machines...?)

Anyhow, after a login with 890 errors, any attempts to map a drive or browse to the server's volume will fail. A packet trace shows the client ask another server for the network address, receive a response, and then make no attempt to access the "bad" server. In Windows, an error is then generated about being unable to access the specified server. Minutes later, the problem goes away.

My guess is that somehow the server's name or address is being placed in "bad cache" on the client - which we seem to be able to work around by changing the client32 settings.

But... It bugs me as to why this specific server would be placed in "bad cache". Here is some of the information we found out through troubleshooting from TIDs and this newsgroup.

SLPINFO /ALL on the client during a -890 error shows the SLP DA properly given out over dhcp, and in an UP status with the proper scope.

The "bad" server can be pinged by name or address.

We have updated the TCP/IP stack to the latest version available for NW5.1 on all of the servers in this building. Checked half/full duplex mismatches and switch interfaces for errors.

Display SLP SERVICES shows this "bad" server and associated services on other servers in the building, and on the SLP DA (in another segment).

The client uses IP and IPX, but removing IPX makes no difference in the problem.

Any ideas? (and thanks in advance)