libsmbclient: Browsing and a URI spec, updated.
Christopher R. Hertel
crh at nts.umn.edu
Mon Jan 1 19:15:16 GMT 2001
> I have been following your discussion for the last few days with great interest
> and support the direction you are going. While I recognize that it does not
> impact _directly_ on the current task, I would like to raise a point that
> continues to hamper the use of samba for browsing support on (some) WAN /
> The current behaviour of samba nmbd is (according to the policy decision
> mentioned in the source code);
> 1) All group names (except names ending in 0x1C) are added as 255.255.255.255
> 2) All unique names ending in 0x1D are ignored with a positive response
Excellent points. However, this policy is set by Microsoft, not us.
On point #2:
The browsing system is based on broadcasts. Putting the Domain Master
Browser aside, the remainder of the system is entirely LAN-bound.
Within the LAN, there is *one* local master browser (though there may be
multiple backup browsers). There must be one LMB per workgroup per LAN.
If there are two LANs that each contain a workgroup with the same name,
then they each must have a unique <workgroup>#1D name registered. This
presents a problem, since this WINS server will not allow both LMBs to
register this name.
So, rather than stick with the intent of RFC1001/1002, MS broke
things. They told the WINS server to ignore registration of any
<workgroup>#1D names, but to send a positive response. Conversely,
WINS always sends a negative response to queries for <workgroup>#1D
names. Thus, B, M, and H-mode nodes will always find the <workgroup>#1D
name on the local IP subnet. Note that P-mode is broken under this
scheme. P-mode nodes cannot find the LMB.
Again this is Microsoft's design, not ours.
On point #1:
Once again, MS did it wrong on purpose.
RFC 1001/1002 say that the NBNS server should keep a complete list of
all IP addresses associated with a group name. It further states that
if the complete list cannot be sent in a UDP packet, the client may
negotiate the use of TCP on port 137.
Following Microsoft's lead, no one implements TCP support for the name
service. The worse mistake, though, was that when Microsoft introduced
WINS they chose to store only the broadcast address (FF.FF.FF.FF) for
group names. This became a problem when they introduced Domain
Controllers and chose to allow all DCs (both PDCs and BDSs to register
the <domain>#1C name.
Because of their decision to have WINS keep only the broadcast address
for group names, it became impossible for a client on a remote subnet
to *find* a domain controller. Thus, MS was forced to partially
implement RFC behavior in the special case of #1C names.
Yet again, this is Microsoft's design, not ours.
> One of the the results of this policy decision is that synchronized
> browse lists ( between samba servers accross a WAN ) contain only the
> broadcast address for any workgroups for which the samba server is NOT
> the master browser. Use of that broadcast address by a browsing client
> looking for a list of servers in the workgroup, will return a positive
> result only if that workgroup is local (unless special measures are
> taken to ensure the broadcast reaches the remote LAN).
Right. That is, you cannot access remote workgroups. You *can* access
remote ntdomains. This is, I'm afraid, normal.
This is only a problem if you can see remote workgroups but not access
them at all. You should not be able to see anything you cannot access.
I have not tested this out, but I can imagine how it might happen. I
have to think about this...
> Proposed solutions to this problem include (among others) the possibility
> that samba be made capable of being the master browser for more than one
I don't think that would really fix it.
> To the extent that a solution to this browsing problem can be addressed by
> the development of the samba client library, perhaps you could include this
> item in your design considerations.
Personally, I need a more detailed understanding of the problem itself.
That will take some time and testing on my part.
Thanks for raising a good point.
Christopher R. Hertel -)----- University of Minnesota
crh at nts.umn.edu Networking and Telecommunications Services
Ideals are like stars; you will not succeed in touching them
with your hands...you choose them as your guides, and following
them you will reach your destiny. --Carl Schultz
More information about the samba-technical