libsmbclient: Browsing and a URI spec, updated.

[Christopher R. Hertel]

> 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 /
> VPNs.  
> 
> 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
> workgroup.

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.

Chris -)-----

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