Tech Trivia: Tales From The Trench


A User running Windows 98 is unable to connect to a share. When she tries the error is returned, Computer or Filename cannot be found. The shared drive even shows up in a browse list through Network Neighborhood yet when you click on it, the same error is returned. Other users do not report a problem. How do you fix this while minimizing down time?

  1. Upgrade to Windows 2000 or XP, then reconnect to the broken share
  2. From a Command Prompt, type net use \\servername\share to connect to the shared resource
  3. Open TCP/IP Properties, Click the Advanced button, select the DNS tab and manually enter the correct IP Address of the DNS Server
  4. Go to Start/Run, type winipcfg, click Release All then Renew All.


d.) is the correct answer. But why? What is happening under the hood that is preventing this PC from mapping a network drive? Why does releasing and renewing the IP Address, even when it gets back the same address, work? What does the local IP address of the workstation have to do with connecting to a network share? Why does the error state that the Server or Filename cannot be found when the problem is with the local PCs IP Address?

Bummer isn't it? You found a solution to this one... Didn't know about winipcfg. There seems to be a bug in the networking software that marks the IP connection as bad under certain circumstances. I usually have the user(s) reboot and it goes away. My understanding is that M$ can't reliably reproduce the circumstance so they contend that they can't fix it. That problem has been with us since at least 1997, probably longer. I haven't kept up with this one, I kind of forgot about it.

Another interesting thing is that it seems to have something to do with M$'s server part of the software. The problem doesn't seem to ever manifest itself while doing a samba share. Since we don't know what causes the problem in the first place, we can't say that samba is a fix for it. It would seem to be a client problem if what you say below is fixes the problem.

-R

Actually thanks go to Andrew L'Amoureux from P&J Computers for his help with this issue. He pointed to Microsoft Knowledge Base Article 278558 which contained the solution. While none of the symptoms mentioned in the article were reported, it did note the following as a cause: "...The client computer sends invalid encrypted password information to the server if the session that has been established between them is reset more than once. A session on the server can automatically time out..." This sounded like a possibilty. The article mentioned a Hotfix you could download if you called Microsoft. It also mentioned a work around. I decided to try that first.

  1. Click Start/Run, type winipcfg. The IP Configuration dialog box opens.
  2. In the drop down box, make sure your Ethernet card is selected (default is set to PPP) then click the Release All and Renew All buttons to renew the DHCP lease. Click OK to save the changes and close the box.
That's it. Simple. The User was then able to connect to the share and run her application.

According to Microsoft, this essentially resets the entire network stack. Of course, why one needs to set the entire network stack due to an issue that only affects one network share is not answered (after all, if it was an encryption issue why wouldn't all shares be affected?) Still, the important thing is that the issue was resolved in a timely manner. As Düg Fresh likes to say, "how often precedes why..."

Also, rebooting did not resolve this problem.


©Copyright 020030731 Fresh Ink