My client Windows XP boxes are failing to register with my WINS server (running nmbd from Samba). I'm puzzled how to figure out what I'm doing wrong.
Background: I'm setting up BackupPC to back up my Windows clients using rsync. I've installed cwRsync to the clients. BackupPC uses nmblookup to find the client's IP address given its Windows NETBIOS name.
I'm distributing the WINS server address via DHCP and see it on the client using "ipconfig /all". I can run tcpdump on the server (filtering for this client and the NETBIOS port) and see the register/response sequence at UDP 137:
MULTIHOMED REGISTRATION; REQUEST; UNICAST REGISTRATION; POSITIVE; RESPONSE; UNICAST REGISTRATION; REQUEST; UNICAST REGISTRATION; POSITIVE; RESPONSE; UNICAST
If I signal the nmbd process with SIGHUP to make it dump its table to nmbd.log, I don't see client in the list. I do see the server and my Windows Active Directory server's records in the list, but no clients.
nmblookup finds the client by broadcast (the client responds with the record) but nmblookup -U 127.0.0.1 says there's no record of it. (A query for the server's own record finds it, so I know the WINS service is at least working to that degree.)
So why is nmbd not remembering client records?
On Sat, 2011-09-03 at 17:51 -0700, Kenneth Porter wrote:
My client Windows XP boxes are failing to register with my WINS server (running nmbd from Samba). I'm puzzled how to figure out what I'm doing wrong.
Background: I'm setting up BackupPC to back up my Windows clients using rsync. I've installed cwRsync to the clients. BackupPC uses nmblookup to find the client's IP address given its Windows NETBIOS name.
I'm distributing the WINS server address via DHCP and see it on the client using "ipconfig /all". I can run tcpdump on the server (filtering for this client and the NETBIOS port) and see the register/response sequence at UDP 137:
MULTIHOMED REGISTRATION; REQUEST; UNICAST REGISTRATION; POSITIVE; RESPONSE; UNICAST REGISTRATION; REQUEST; UNICAST REGISTRATION; POSITIVE; RESPONSE; UNICAST
If I signal the nmbd process with SIGHUP to make it dump its table to nmbd.log, I don't see client in the list. I do see the server and my Windows Active Directory server's records in the list, but no clients.
nmblookup finds the client by broadcast (the client responds with the record) but nmblookup -U 127.0.0.1 says there's no record of it. (A query for the server's own record finds it, so I know the WINS service is at least working to that degree.)
So why is nmbd not remembering client records?
---- do you have 'wins support = yes' in your smb.conf on the system that is supposed to be the wins server?
Is this system running backuppc a different computer? If so, does it have 'wins server = $IP.Address.Of.WINS_Server' ? in smb.conf?
Do all WinXP systems use the ip address for this system as the wins server?
Are they all on the same network/subnet?
What is the 'os level' of this wins server? Is it higher than 32? (I'd probably make it > 64)
Did you examine the wins.tdb by using tdbdump?
Are you aware that elections take 15 minutes? If you actually restart the nmbd process on your samba based wins server, you need to wait to get a browsing list.
Craig
--On Tuesday, September 06, 2011 6:50 AM -0700 Craig White craigwhite@azapple.com wrote:
do you have 'wins support = yes' in your smb.conf on the system that is supposed to be the wins server?
Yes.
Is this system running backuppc a different computer? If so, does it have 'wins server = $IP.Address.Of.WINS_Server' ? in smb.conf?
Same computer is running BackupPC.
Do all WinXP systems use the ip address for this system as the wins server?
Are they all on the same network/subnet?
Yes. Same host is also the DHCP server for the subnet and provides the WINS value to all clients, and I can see it set on the XP client.
What is the 'os level' of this wins server? Is it higher than 32? (I'd probably make it > 64)
That setting I wasn't aware of. I'll change that.
Did you examine the wins.tdb by using tdbdump?
That might be an issue. I can't find a wins.tdb in /var/lib/samba.
Are you aware that elections take 15 minutes? If you actually restart the nmbd process on your samba based wins server, you need to wait to get a browsing list.
Oddly, when I restart samba, I see in nmbd.log:
[2011/09/06 11:00:24, 4] nmbd/nmbd_winsserver.c:wins_write_database(2353) wins_write_database: Dump of WINS name list.
And a long list of client names. But "nmblookup -U 127.0.0.1 [clientname]" tells me that name isn't found, for any of the clients seen in the list.
Could this be workgroup-related? I have both an AD domain and a workgroup on the subnet, plus customer and vendor machines with their own workgroups.
--On Tuesday, September 06, 2011 12:09 PM -0700 Kenneth Porter shiva@sewingwitch.com wrote:
That might be an issue. I can't find a wins.tdb in /var/lib/samba.
Found it in /var/cache/samba. It has the record I want, but nmblookup unicast fails. nmblookup broadcast works, but that gets it from the workstation, not the WINS server, and the point of WINS is to get rid of the broadcast traffic.
--On Tuesday, September 06, 2011 12:25 PM -0700 Kenneth Porter shiva@sewingwitch.com wrote:
Found it in /var/cache/samba. It has the record I want, but nmblookup unicast fails. nmblookup broadcast works, but that gets it from the workstation, not the WINS server, and the point of WINS is to get rid of the broadcast traffic.
Found it! When studying the man page for nmblookup I spotted the requirement that I need to provide -R with -U to force recursion.
Here's the -U option:
Do a unicast query to the specified address or host unicast address. This option (along with the -R option) is needed to query a WINS server.
Here's the entry for the -R option:
Set the recursion desired bit in the packet to do a recursive lookup. This is used when sending a name query to a machine running a WINS server and the user wishes to query the names in the WINS server. If this bit is unset the normal (broadcast responding) NetBIOS processing code on a machine is used instead. See RFC1001, RFC1002 for details.
So why would you use -U without -R? Seems an odd and error-prone command design.
On Sep 6, 2011, at 11:25 AM, Kenneth Porter wrote:
--On Tuesday, September 06, 2011 12:09 PM -0700 Kenneth Porter shiva@sewingwitch.com wrote:
That might be an issue. I can't find a wins.tdb in /var/lib/samba.
Found it in /var/cache/samba. It has the record I want, but nmblookup unicast fails. nmblookup broadcast works, but that gets it from the workstation, not the WINS server, and the point of WINS is to get rid of the broadcast traffic.
---- No - WINS doesn't get rid of broadcast traffic... it's just a set of rules and behaviors for broadcasting and resolving the names of the computers on the local subnet.
Craig
On Sep 6, 2011, at 11:09 AM, Kenneth Porter wrote:
--On Tuesday, September 06, 2011 6:50 AM -0700 Craig White craigwhite@azapple.com wrote:
Are you aware that elections take 15 minutes? If you actually restart the nmbd process on your samba based wins server, you need to wait to get a browsing list.
Oddly, when I restart samba, I see in nmbd.log:
[2011/09/06 11:00:24, 4] nmbd/nmbd_winsserver.c:wins_write_database(2353) wins_write_database: Dump of WINS name list.
And a long list of client names. But "nmblookup -U 127.0.0.1 [clientname]" tells me that name isn't found, for any of the clients seen in the list.
Could this be workgroup-related? I have both an AD domain and a workgroup on the subnet, plus customer and vendor machines with their own workgroups.
---- Having various domains and workgroups on the same subnet could impact the 'elections' of WINS master browsers - in fact, an AD server is pretty much intent on winning elections so it may never work as expected.
Still - you always have to keep in mind that it really does take 15 minutes if you restart nmbd service on Linux/samba server.
Craig
-
Craig White -
Craig White -
Kenneth Porter