how to discover the WINS server without using DHCP?

Christopher R. Hertel crh at
Fri Oct 17 03:08:01 GMT 2003

David Wuertele wrote:
> My customer manually sets his windows boxes with his WINS server
> address --- he doesn't use DHCP to distribute that information.
> I have a product that needs to talk to his WINS server, but I don't
> want to require that he hardcode his WINS server address on my box.
> Is there a way to discover a WINS server automatically, without using
> For example, I could:
> 1.  do a broadcast ping to get a list of all hosts on the subnet
> 2.  foreach host on the subnet, try to access port 137
> 3.  foreach host with an open port 137, talk magic words
> 4.  the host that replies in WINS-server speak must be the One True
>     WINS server for his network
> Obviously this couldn't find a WINS server on a different subnet, but
> could it succeed if the WINS server was on the same subnet?  What are
> the magic words I need to use in step 3?
> Is there any way to automatically discover the location of the WINS
> server if it is on a different subnet?

This is a classic bootstrapping pidgeon-and-egg problem type thingy.

I'll start off by saying no, I don't think there's a good way to do this. 
Particularly not across subnet boundaries.  Not using the protocol.

If you're on a system that runs Samba, then you could try finding and
reading the smb.conf file.  On a Windows system, you'd have to try digging
into the registry to find the WINS server IPs.  It's probably do-able.  I
wouldn't know how to do it.

The best bet, on a Windows system, is to ignore the protocol and just talk
to the NetBIOS API directly.  You can register names, listen for messages,
send name queries, whatever you need all via that API.  The further benefit
is that you are doing things within the system, rather than 'outside of the
box'.  That'll make WINS happier.

As for trying to find the WINS server using the protocol itself... there are
some things you could try.  I don't think any of them are reliable, however,
so you would need to do a lot of testing.

Thing 1:  There are two bits in the name query called "Recursion Desired"
          "Recursion Available".  In theory, queries with the "Recursion
          Desired" bit set should bypass a node's local name table and only
          be resolved by the NBNS.  In theory.  Also, in theory, only the
          NBNS should be setting the Recursion Available bit in responses.
          You'll have to test to find out how true this is on various

Thing 2:  Samba's implementation of the WINS server will respond to a
          special query.  You can send a query for "*<1B>" (that's a star,
          followed by either space or nul padding, with a suffix value of
          0x1B).  *IF* there is a Domain Master Browser somewhere on your
          network and *IF* you find a Samba WINS server, then the server
          will respond to this query with a list of IPs (one per DMB).
          Not the most helpful, but only a Samba NBNS (WINS server) will
          respond to this.

Thing 3:  Send a unicast query for workgroup<00> (and Recursion Desired
          If the node responds with its own IP address then it's not an
          If it replies with (and Recursion Available set)
          then it's an NBNS.

As you noted, none of these help you find an NBNS that's off the local LAN.
Also, none of these guarantee that the node is the *right* NBNS.  It's
possible that two separate namespaces are being supported using two NBNSs.

I can think of a few other tricks, but they're even more outlandish.

Details on the workings of NBT (including the workings of the NBNS) are

You may find something that I've already forgotten about.

Good luck (have fun).

Chris -)-----

"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team --     -)-----   Christopher R. Hertel
jCIFS Team --   -)-----   ubiqx development, uninq.
ubiqx Team --     -)-----   crh at
OnLineBook --    -)-----   crh at

More information about the samba-technical mailing list