« iDVD suckage | Main | When 1 does not equal 1 »

Windows netbios name caching

I learned something new about Windows networking today, and am putting it here in JeffJournal so that I can find the information again someday when I need it.

I got a call from my church yesterday saying that they couldn’t print to a printer share that hangs off one of the machines on their LAN. I tried a few things with them via e-mail and then said, “I’ll come over tonight and have a look.”

The machine in question is named “volunteer”.

When I got there, the machine appeared to be working fine. It could access any network share (including the main file server), it could see internet web pages, could ping other machines on the network, etc. Other machines on the LAN could ping volunteer, too, so they could see each other via ethernet (not surprising, since there’s only one network switch).

But none of the other machines could access volunteer’s shares at all. If you tried to browse to \\volunteer, windows explorer would eventually timeout and say that the network path was invalid. I rebooted every machine on the network multiple times (including volunteer), all to no avail.

So — what the heck?

I thought to myself, “it’s almost like the name ‘volunteer’ is resolving incorrectly.” So on a hunch, I googled for “clear netbios cache” and found the magic windows command “nbtstat” (I had never heard of this command before). A few queries later I found that, lo and behold, our Samba-based WINS server (run by an outside vendor) was returning the wrong IP address for the name “volunteer”. I read a few Samba docs, and poked around on our Samba server and found the wins.dat file (cache file for nmbd, the Samba WINS server). Guess what I found in there?

"VOLUNTEER#00" 1169624518 64R
"VOLUNTEER#03" 1169824240 64R
"VOLUNTEER#20" 1169624518 64R

I’m not sure why, but every desktop machine seems to be listed 3 times in this file. But “volunteer” had 2 incorrect entries (.237) and one correct entry (.104)! Whoa!

So I killed nmbd on the Samba server, edited the wins.dat file to make all 3 entries be “.104”, retsarted nmbd, and bingo! Now every machine on the network can see \\volunteer and its shares.

I suspect that the volunteer machine actually did have the .237 IP address for a while (all the machines get their IP addresses via DHCP); I had just done some DHCP reallocation and consolidation that weekend (I found out that there were 3 DHCP servers running on my network — doh! One on my DSL modem, one on my linux server, and one on the Samba box — I was only aware of the one running on my linux server). So I disabled the DHCP servers on the DSL modem and my linux box, and let the vendor-run Samba box be the DHCP server (it was always the WINS server).

But anyhoo, that’s how I assume “volunteer” switched IP addresses. Why it didn’t also update the data in wins.dat properly, I don’t know. I don’t know what the fields in the wins.dat file mean; perhaps those old IP addresses would have eventually timed out…? ☹

FWIW, in the midst of figuring this all out, I killed the nmbd on the Samba server and then machines were able to find \\volunteer (after I cleared their netbios name caches via “nbtstat -R”) because the WINS server was no longer being used for resolution. Instead, the machine were falling back to broadcast-based resolution, which, while it will only work on a subnet, was sufficient for them to find each other (and get current information). Restarting the nmbd server forced the machines to again get the wrong address, so this led me to poke around and find nmbd’s cache file that had the stale information.

After the fact, I found some important facts:

  • WINS servers can be re-seeded from a workstation’s perception of what name resolutions are. So if there’s a “bad” workstation out there with stale info, it may poisoin the WINS server.
  • The “safe” way to get all the information syncronized and current is to turn off all workstations, stop nmbd, remove wins.dat, restart nmbd, and then restart the workstations.
  • My private wondering is that if you just kill the nmbd for a few hours and let all workstations resolve current information via broadcast (which kinda depends on all workstations try to reach each other and getting all the most recent information), and then turn on nmbd and let nmbd re-seed itself from the broadcasted data (either via workstations registering, a workstation re-syncing its whole table to the WINS server, or watching broadcast data). Didn’t get a chance to try this, though.


TrackBack URL for this entry:

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)


This page contains a single entry from the blog posted on January 23, 2007 7:33 AM.

The previous post in this blog was iDVD suckage.

The next post in this blog is When 1 does not equal 1.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.34