Troubleshooting Q&A - September 2, 2004
A Workaround for When Workgroup Networks Won't Work
Ten PCs some wireless, some not a network without a server and office workers who need to share info can add up to frustration. Here's our advice and a suggestion.
By Ron Pacchiano
Q. I am the owner/operator of a small real estate company in Florida. In addition to my many regular responsibilities, I am also the company's technology manager. Now I'm the first to admit that I don't know everything about computer networks, but I do know enough that I have been able to keep the office up and running for a couple of years now. Recently, however, I came across a rather strange problem and no one seems to be able to resolve.
Our office network is made up of 10 computers in a workgroup configuration. All of the computers are connected to a D-Link wireless router. Of these 10 computers, four are connected wirelessly. At least half of these machines have data on them that needs to be shared among the office staff. From any of the six PCs that are physically wired to the router, there is no problem accessing this data . All of the machines are visible in Network Neighborhood, but, for some reason, none of the wireless PCs can see or access any of the other workgroup PCs. In spite of the fact that both the wired and wireless PCs can ping each other and have access to the Internet.
A few weeks ago you did a Q&A column that addressed an issue similar to this one. In the article you suggested that enabling NetBIOS over TCP/IP should help relieve the problem. I tried that and the other methods you suggested in the article, but none of them worked for me.
The really weird thing about the situation is that if I take one of the wireless PCs and disable the wireless adapter, then connect it to the network using the integrated 10/100 Ethernet adapter, all of the computers in Network Neighborhood become accessible. As soon as I switch back to the wireless adapter alone, the connection disappears and I get a message that says something like "You might not have the rights to access this network resource."
I am at a lost to explain this. The wireless PCs are running a combination of Windows XP and Windows 2000 Professional. File and Print Sharing is enabled and NetBIOS over TCP/IP is enabled on both the wired and wireless interfaces. I've tired upgrading all of the drivers and each wireless PC is using a different type of wireless adapter. Two have an integrated wireless adapter, one is PC card-based and the other is using a wireless bridge. I even tried changing my wireless router with a regular router and an access point, but the network exhibited the same symptoms. Some people suggested that perhaps WEP was interfering with it, so I disabled it. No change. I even got so desperate that I tired changing the SSID name to match the workgroup name. That didn't work either. I tired contacting D-Link's technical support group, but proved to be useless.
So has of now I am not only disgusted, but officially out of ideas. Any advice you can offer that might help to resolve this situation would be appreciated. Thank you!
A. Believe it or not you're not alone in your wireless network difficulties. While researching your problem I did a search in Google's newsgroups and discovered that a lot of people were apparently having similar problems. Unfortunately, no one had posted a solution to the problem at least not a confirmed or reliable one. As you mentioned I saw many people who recommended disabling WPA (but not WEP) and some others suggested making a few Registry changes. None of which looked too promising.
I myself have run into this problem on one or two occasions and getting around it has always proved to be difficult. Personally, I feel that part of the problem stems from the fact that you're using a workgroup network configuration as opposed to a more reliable client/server setup.
As far as what could be the cause of the problem the only thing I could think of is that the wireless adapters aren't broadcasting the NetBIOS information. I'm not sure why that is, but all the symptoms seem to point to that conclusion. That said, the only thing I can suggest you try is creating a LMHOSTS file for each of the wireless PCs. As long as they can ping each other and TCP is configured correctly, the LMHOSTS file should be all you need to get past this problem. It doesn't necessarily explain the cause of your affliction, but at least I can say with confidence that in the past, this has worked for me.
An LMHOSTS file, for those of you not familiar with it, is a static table that resolves a host name to an IP address and assists with remote NetBIOS name resolution on computers that for one reason or another, cannot respond to NetBIOS name-query broadcasts. You can find a sample LMHOSTS file in the %SYSTEMROOT%\SYSTEM32\DRIVERS\ETC directory in Windows 2000 and Windows XP. The file is named LMHOSTS.SAM. After you make the appropriate changes to the file, it must be saved as LMHOSTS (without the SAM extension) before it can be used. This is important to note because sometimes Notepad will inadvertently place a TXT extension to the end of a document you've created. This would prevent the file from functioning properly.
The format of the LMHOST file is typically IP address, system name and the extension #PRE. Following any entry in the file with the characters #PRE will cause the entry to be preloaded into the name cache for faster resolution. An example of the contents of an LMHOSTS file would be:
192.168.1.110 TDS-SERVER #PRE 192.168.1.111 FRONT-DESK #PRE 192.168.1.112 ADMIN#PRE 192.168.1.113 TDS-CAMERA #PRE 192.168.1.114 TDS-WS#PRE 192.168.1.115 HELPDESK#PREBy running NBTSTAT -r (the r must be in lower case) from a command prompt, you can see if your name requests are being resolved by broadcast or WINS. An LMHOSTS lookup will appear as a broadcast. NBTSTAT -c will show the contents of the name cache that is loaded from the LMHOSTS file each time you boot.
The LMHOSTS.SAM sample file has much more information on the available extensions that can be used in the configuration. The file also contains information for other things like configuring it to point to a domain controller.
It is important to remember that since an LMHOSTS file contains a static computer name to IP address mapping, it may cause conflicts if you are also using DHCP to dynamically assign IP addresses on the same network. So I would recommend that you assign a static IP address to each system. At least until you upgrade to a client/server environment where the LMHOSTS file will no longer be needed. Although, some shops put the name and IP address of a domain controller in the LMHOSTS file of a dial-up machine to speed up authentication.
One last thing I would like to point out: At 10 workstations you're quickly approaching the limits of a practical workgroup. Some of the problems associated with the workgroup model are the fact that there is no centralized authentication system that maintains the user and PC accounts on the network. This means that the majority of the communication that takes place on the network is being controlled by one PC that somehow took it upon itself to be the network's Master Browser. As you have discovered, this can be problematic.
In a client/server environment, there are numerous ways for PCs to find each other. Inclusion in the Active Directory, NetBIOS broadcast, WINS servers and DNS servers. All of these help to prevent the problem you're currently experiencing. So until you upgrade I think the LMHOSTS file is your only recourse. I hope this helped.
|Home | Networking | Backgrounders | Internet Sharing | Security | HowTo | Troubleshooting | Reviews | News | About | Jobs | Tools | Forums|