Strategy for mapping the neighborhood

David Wuertele dave-gnus at bfnet.com
Wed Oct 29 23:30:38 GMT 2003


CH> Read up on the workings of the Name Service and the Browse
CH> Service.

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 :-)

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

CH> Second, when you say "Network Neighborhood" do you mean the browse
CH> list entries (that is, all servers announcing services) or the
CH> entire NBT scope?  (See, "scope" has some meaning here.)

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.

CH> P nodes do not participate in LMB elections and will not contact
CH> the LMB, because the LMB election is handled entirely in broadcast
CH> mode, and the LMB can only be located by sending a broadcast
CH> query.

But P nodes do contact the DMB, and that gets merged into all LMB
lists, 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

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

Can you think of a more straightforward way?

Me> b.  Find the NBNS via DHCP.

CH> This only works if the DHCP server is configured to hand out the
CH> NBNS IP address.  If it is, then you're set.  If not...  I know of
CH> no good way to find the NBNS other than checking the configuration
CH> of a client or two.

Right, since I don't have access to the clients, I'll just have to
live with what I can or can't get from DHCP.

Me> c.  Resolve all service names discovered in (a) by the NBNS found
Me> in (b).

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?

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.

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").

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.

CH> Note, however, that if both are needed your network is probably
CH> misconfigured (except in the case of the LMB names, which are a
CH> special case).  P nodes and B nodes are said to be in separate NBT
CH> scopes (because they cannot see one another).  Mixing B mode nodes
CH> with M, H, or P nodes can cause other problems on your network.

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.

Me> f.  ask each workstation service name resolved in (c)+(d)+(e) for
Me> its list of shares

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?

Thanks,
Dave




More information about the samba-technical mailing list