Strategy for mapping the neighborhood

Thu Oct 30 02:10:52 GMT 2003

David,

:
> Actually, I just got done reading your MOST EXCELLENT book at
> http://ubiqx.org/cifs.  I promise to buy a dead tree copy when I get
> my allowance :-)

Most kind.  :)

> CH> First, be careful using the term "scope" since that term already
> CH> has meaning in an NBT environment.
> 
> Yes, I should have disambiguated myself:  I was not refering to the
> ScopeID, but rather to the FIRST definition in your list of three
> definitions for the word scope:
> 
>  * the set of NetBIOS nodes that participate in an NBT virtual LAN
>  * an identifier used to distinguish one virtual LAN from another
>  * that which is included within the purpose of the RFC document

I do provide warnings, in the book, that I am wildly pedantic at times (but
hopefully only when I have at least half a clue).

> I chose words poorly again.  Instead of "Network Neighboorhood," what
> I should have said was: the union of all sets of NetBIOS nodes that
> participate in any NBT virtual LAN, such that each set has at least
> one host on my subnet.  Or, to put it another way: the union of scopes
> used by all NBT nodes on my subnet.

Okay, now you're trying to out-pedantic me.  ;)

Thanks, though.  Makes more sense to me now.  I assume that also means you
are looking for nodes in all Scope IDs.  Note that many implementations will
not respond to Node Status (NBSTAT) queries if the query does not contain
the same Scope ID.

:
> But P nodes do contact the DMB, and that gets merged into all LMB
> lists, right?

Yes, that's right.

> In any case, assuming that the LMB's don't know all the
> P hosts, one strategy to find P nodes would be to:
> 
>   a.  ICMP Echo to the subnet broadcast IP to find all NICs on the LAN
>   b.  attempt an NBSTAT to each NIC

Well, yeah...  It would need to be a unicast NBSTAT, I believe.

> This assumes:
> 
>   1.  servers actually respond to ICMP Echo (strict firewall rules may
>       gum that up)
>   2.  servers are actually listening on (or redirecting from) port 139
>       or 445

Ah.  Not 445.  That's the SMB-over-naked-TCP service port.  You won't find
nodes offering SMB over naked TCP by trying to look up NetBIOS names or use
the Browse Service (unless, of course, the server is also providing SMB over
NBT).

> Can you think of a more straightforward way?

Not really, no.  There's a lot of guesswork involved.

If you are really looking for shares (and not all NBT nodes in all scopes
that have participating members on your local LAN) then starting with the
Browse Service is probably your best shot.  You can find your local LMB
(within the same ScopeID scope) by doing a broadcast query for
workgroup<1D>.  You can find the DMB by querying the WINS server for
workgroup<1B>.  If the NBNS is a Samba server, you can also query for *<1B>
and get a list of known DMBs.

> CH> The list of service names is known as the Browse List.  It will
> CH> *only* contain the names of servers that are advertising their
> CH> services.
> 
> This is something I don't understand.  What is the definition of an
> advertised service?  If I'm using Samba, aren't all my services
> advertised?  What does a Windows user have to do to advertise or
> un-advertise their services?

In general, if the service is being offered via SMB over NBT it will be
advertised.  The server simply announces the services and the LMB picks them
up and keeps the local list.  If there is a DMB it should exchange
information with the DMB, thus building a larger list (covering more
subnets).

The flaw in the plan, of course, is that a Workgroup is LAN-limited unless
there is a DMB for the workgroup (aka. NT Domain).

Anyway, the servers advertise their services by broadcasting a special kind
of UDP-based NetBIOS Datagram message formatted as a SMB message containing
the parameters of a function call (you didn't want to know all that...I sure
don't).

The message is a HostAnnouncement Mailslot message.  It contains all sorts
of odd little bits of information about the server.  You can take a look at
the table in this section: 
http://www.ubiqx.org/cifs/Browsing.html#BRO.4.3.2

If the flag bits shown in that table are all clear, then the server is
asking the LMB to erase its entry from the Browse List.

> Me> d.  Find all B nodes on the subnet and discover their service
> Me> names.
> 
> CH> Are you looking for the browse list or the list of all NBT nodes
> CH> available?
> 
> The latter.

Hmmm...  Any reason?  I assume the eventual goal is a list of (open,
vulnerable) shares.  In theory (theory vs. practice being at odds in CIFS)
nodes not listed in the Browse List are not offering services.

> CH> These B nodes *should* have advertised their services with the
> CH> workgroup LMB on their subnet so this step *should* be redundant.
> 
> That's what I thought until I started playing around.  Some of the B
> nodes on my test subnet are not included in the browse lists.  I don't
> know why, but it seems to have something to do with not turning on the
> message service ("#03").

If that's true, then it won't just be B nodes.

Are you sure that these nodes are offering SMB services (the host<20> name)?

> Me> e.  For any service names not resolved in (c), attempt to resolve
> Me> on the subnet via broadcast
> 
> CH> 'c' and 'e' are the same thing.  You're just using the NBT Name
> CH> Service to resolve the names.  NBT can use either broadcast or
> CH> point-to-point (NBNS) resolution, or both.  (M and H modes).
> 
> Seems to me that 'c' and 'e' are different because 'c' resolves the
> set of P, M, and H nodes, while 'e' resolves the set of B nodes.

Well, to be pedanic [ ;) ] c resolves P, M, and H and e resolves B, M, and H
(as long as they're on the local subnet).

> I have customers who have mixed P/M/H and B modes on purpose for one
> reason or another, and I have to be able to find all modes of servers,
> whether they did it on purpose or not.

Ick.  Doing so breaks the virtual NetBIOS LAN and "hides" nodes from one
another.

> CH> Note that some systems will not allow you to access the list of shares
> CH> unless you have authenticated.  Ick.
> 
> OK.  Is that true even if the system has some shares readable by the
> guest account?

I don't know.  I imagine that if there's a valid guest account you should be
able to "log on" with those credentials in order to see the share list.

This is the basis for an interesting discussion I had once on the jCIFS
list.  There is a difference, it seems, between anonymous and guest access. 
Some implementations will try connecting as anonymous and then failover to
guest if the anonymous connection fails (or perhaps it was t'other way
'round).  I think that part of the problem is that you can disable either
one without disabling the other.

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