wxp SP2 host responds to "nmblookup HOST" but not "nmblookup *"

[Christopher R. Hertel]

On Tue, Dec 28, 2004 at 11:55:28AM -0800, David Wuertele wrote:
> >> Executive summary: Is there some other method to enumerate all SMB
> >> hosts on a LAN than a wildcard NBT node status query to the
> >> broadcast address?
> 
> Christopher> This bug in XP breaks that rather nicely, doesn't it?
> 
> Yes, do we smell a conspiracy?

I was sitting behind a Senior VP from Microsoft at a conference once,
while his company was being roasted alive by a really good presentation
that simply told it like it was.  I remember the guy from Microsoft
repeating that old saying about never attributing to malice that which can 
be explained as incompetence.  :)

> Christopher> You might try the following:
> Christopher> - Turn off the Broadcast bit and see what happens.
> 
> Do you mean this line?
> 
> 	set_socket_options(sock,"SO_BROADCAST");

No, I mean the broadcast bit in the NBT Name Query.

> Christopher> - Try the "*SMBSERVER" name.  *Some* systems will respond
> Christopher>   to this (though they probably shouldn't).
> 
>   # nmblookup '*SMBSERVER'
>   creating lame upcase table
>   creating lame lowcase table
>   querying *SMBSERVER on 192.168.0.255
>   querying *SMBSERVER on 127.255.255.255
>   name_query failed to find name *SMBSERVER
>   # 
>
> They don't.

I tried it on my home net.  There's an older appliance (running an updated 
version of an ancient Samba release) that does respond the *SMBSERVER.

> Christopher> What node type is 192.168.0.15?  Is it a 'B'?
> 
> I think it is an 'M', but I don't have access to it to find out.

The information is contained in the response message, but I don't know 
if nmblookup can/will print it.  You might have to peek with ethereal.

I use my own tool called nbtquery which does print out the node type (B, 
M, H, P).

> Christopher> Is it running XP-SP2?
> 
> Nope, W2K
> 
> Christopher> What happens when you query for BOGUSWORKGROUP<1e> ?
> 
>   # nmblookup 'BOGUSWORKGROUP<1e>'
>   creating lame upcase table
>   creating lame lowcase table
>   querying BOGUSWORKGROUP<1e> on 192.168.0.255
>   192.168.0.15 BOGUSWORKGROUP<1e><00>
>   192.168.0.7 BOGUSWORKGROUP<1e><00>
>   # 
> 
> Yep, as expected, both hosts show up.  That suggests a workaround, so
> long as I can discover at least the LMBs.

You can find all local LMBs by querying for the MSBROWSE name (that 
*should* work even with XP-SP2...but test it).

> Christopher> 1) Do the broadcast name query.
> Christopher>    --or--
> Christopher>    Query for the MSBROWSE name.
> Christopher> 2) Query all of the nodes returned for their workgroup name
> Christopher>    (do a Node Status query and look for <1E> or <00> group names).
> Christopher> 3) Query for all of the workgroup names returned.
> Christopher> Nasty, eh?
> 
> Quite... I can implement this, but do you really think that this is
> how Microsoft does it?

I don't know of a reason that MS would search for all NBT nodes.  Instead, 
they'd use the Browse Service.

Your goal is to list all shares.  In theory, the nodes offering shares
would "advertise" their services via the Browse Service (assuming an 
NBT-only network...we're not talking about port 445-stuff).

So, the "right" way to find all shares would be:

Find all workgroups
  - Done by finding your LMB and asking the Browse Service to provide a 
    list of know workgroups.
For each workgroup
  - Query the LMB/DMB for the workgroup for the list of member servers
    For each server
    - Query the server for its share list.

One problem with the above approach (which may not be a problem at all) is
that it extends across subnet boundaries.

Another problem with the above approach is that it's flakey.  The Browse 
Service is highly dynamic and tends to lose information, or keep track of 
old information longer than it should.  If you want your scan to be 
robust, you'll augment the collection of the workgroup and server list 
gathering by using the name service as you've already described.

Hope that helps.

Chris -)-----

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org