[jcifs] Issue listing "smb://"

Thu Jul 15 02:01:29 GMT 2004

On Wed, Jul 14, 2004 at 08:05:41PM -0400, Eric Glass wrote:
> > 
> > But I don't think a domain controller is necessarily an authority for
> > browser protocol information. What reasons do we have to believe that you
> > did not just "lucked out" in getting a machine that happend to have useful
> > information? What does Windows NT or Windows 98 do? I would rather stick
> > to observed behavior if we have a choice.
> > 
> 
> Here's an article with some good description:
> 
> 
> http://www.microsoft.com/technet/prodtechnol/winntas/deploy/prodspecs/ntbrowse.mspx
> 
> 
> All this master/backup/domain master browser stuff is quite
> convoluted;

It's all written up in my book.  I go into detail to explain how it works
and what Samba does to augment the process.  You can skip over the section
that talks about the actual packets and mailslots and named pipes and
such.

Also, there are a lot of special Samba fixes to the Browse Service.  Samba 
plays a few very interesting games.

> but the relevant stuff would seem to be:
> 
> * The master browser (one on each subnet) has the browse list,
> containing all servers in the domain and the list of all domains.

The *local" master browser.  Yes and no.

First, keep in mind that an NT Domain is the *same thing* as a workgroup 
(for our purposes, anyway...the difference is that an NT Domain has a 
domain controller for authentication purposes).

Okay, so... The Local Master Browser has a list of all of the workgroups 
it knows about.  It finds out about these when other LMBs for other 
workgroups announce themselves on the local wire.  It also finds out about 
other workgroups (NT Domains) when it exchanges information with its own 
DMB.  The DMB also keeps a list of known workgroups.  This is how word 
spreads.

The LMB also has a list of all member servers (servers that are members of 
the same workgroup) on the local LAN.  Again, it gets this list because 
the local servers announce themselves periodically.  Also, if there is a 
DMB the LMB will sync the server list with the DMB.

There are timers for all of these steps, all outlined in my book.  The 
upshot is that propogation of the browse list (particularly when something 
is removed from the list) takes time.

The *combined list* is called the Browse List.

> * Backup browsers call the master browser every 15 minutes to get a
> copy of the browse list and list of domains.

...if there are any backup browsers.  Backup browsers happen in one of two 
ways:
  1) The LMB knows (because of the election process) which other 
     "potential browser" nodes are on the local wire.  It can send a 
     message to one or more of these other nodes appointing that node to 
     be a backup.
  2) A node that loses an election may decide on its own to become a 
     backup.  It does this by flipping a single bit in its announcement 
     packet.

Note that Samba runs in "stealth" backup browser mode.  It listens for the
announcements and keeps its own browse list even if it's not a backup
browser or LMB.  It doesn't bother to announce itself as a backup, 
however.

> * The browser service running on the PDC is the "domain master
> browser"; it has a bias in elections to ensure it becomes the master
> browser for its subnet.

Yes.

Note that Samba can run as DMB even if it's not PDC.  There's no reason 
not to run this way, but Microsoft has tied DMB and PDC functionality 
together so you can't have a Windows DMB unless it's the PDC.

The opposite is not true.  If you *do* have a PDC it *must* be the DMB.
Even in Samba.

The roles are cumulative...
The PDC must be the DMB.
The DMB must be the LMB for its local LAN.
The LMB is also a backup browser.
A backup browser is also a potential browser.
Potential browsers participate in LMB elections.

> So (in theory) the PDC for the domain specified in
> "jcifs.smb.client.domain" would always be the master browser for its
> subnet; and as such, would hold the browse list and list of all
> domains.  I think ;)

Only if the list has converged.

A lot depends on the query.  If you query for domain<1C> then you're 
asking for a list of DCs.  There may be many, but only one can be PDC.  
The rest must be BDCs.  If the BDCs are on separate subnets then there's a 
good chance that they'll be the LMBs for their subnet, since DCs have 
advantages in browser elections.

A domain<1C> query to a WINS server is weird because it almost works the
way it's supposed to.  According to the RFCs, when you query for a group
name you should get back a list of IPs--one for each registered group
member.  WINS fails at this, and typically sends back one IP:
255.255.255.255.  That's bad.  For <1C> group names, however, WINS will 
send back a really-truely list of member IPs.  Up to 25 IPs, and the first 
one is the IP of the PDC.

> Assuming this is correct, there would be the additional question of
> whether it is preferable to broadcast for the local master browser to
> get the list and fallback to contacting the PDC for
> jcifs.smb.client.domain, or to contact the PDC first (and broadcast as
> the fallback behavior, or if no jcifs.smb.client.domain is specified).

The following assumes that you're not running in 'P' mode.  If in 'P' mode
all business is done directly with the DMB.

Typical behavior is to query the local LAN first, then look for a DMB.

If there is a default workgroup name given, then the correct mechanism
would be to query for domain<1D> and use the workgroup's own LMB first. If
there is no default workgroup name (o jcifs.smb.client.domain is
specified) try __MSBROWSE__ and ask any LMB.  If there's no LMB for any
workgroup on the local wire--or if in 'P' mode, then:

If there's a default domain name given, try contacting domain<1B>.  If 
that fails, or if there's no default workgroup/domain name given, then 
query the NBNS for *<1B>.  This last is a desparate move.  *If* the NBNS 
is a Samba server, you'll get back a list of IPs for all known DMBs for 
all known domains/workgroups.  Query one or more of those for the browse 
list.

Whew!

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