[jcifs] Issue listing "smb://"
Christopher R. Hertel
crh at ubiqx.mn.org
Thu Jul 15 01:37:46 GMT 2004
On Wed, Jul 14, 2004 at 06:44:51PM -0400, Michael B Allen wrote:
> Eric Glass said:
> > Mike,
> > Do you have any thoughts on this (i.e., does it seem to be a
> > reasonable approach)? I'm still not convinced that I'm not just doing
> > something wrong myself (although I've checked my broadcast address,
> > etc., and everything *seems* to be correct). But asking the
> > jcifs.smb.client.domain controller (if specified) for the list seems
> > like an appropriate fallback, since otherwise you would just get an
> > UnknownHostException listing "smb://".
> But I don't think a domain controller is necessarily an authority for
> browser protocol information.
Yes it is. *If* there is a DC then there must be a PDC. If there is a
PDC it *must* be the DMB. The roles are layered. The PDC must be the DMB
which must then be the LMB for its local LAN.
The next thing is this: If you query a WINS-compatible NBNS for the
domain<1C> name the list is returned such that the first entry is the PDC.
This is an obscure MS kludge. WINS watches for the domain<1B> name (the
*DMB* name) to be registered and then makes sure that the IP address
associated with domain<1B> is always the first in the domain<1C> list.
domain<1B> is the name of the DMB for domain 'domain'.
domain<1C>, of course, is a list of IPs for DCs. If there's only one DC
or if you pick the first IP from the list, you'll get the DMB.
> 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.
Windows, I believe, does this:
1) Put 'P' mode behavior aside. That's different.
2) Windows machines typically have a default workgroup set up. I don't
know if they can run without this. Anyway, they start by contacting
the LMB for their default workgroup on the local LAN.
There's another kludge here. If the client is in H mode it's supposed
to try P mode behavior first. That is, it's supposed to contact the
NBNS before trying a broadcast. For this reason (ugh) MS's WINS server
will *always deny knowledge of <1D> unique names*. Kludge city. That
forces the H node to try broadcast name resolution for domain<1D>
3) The client is supposed to ask the LMB for a list of local backup
browsers. In practice, not all clients do this and it doesn't matter
for small networks since the LMB will generally be the only one. (Yep,
the LMB is also a backup browser.)
4) The client should now contact the backup browser for any additional
browse list information it wants. It can get the list of domains
(workgroups) or servers within that domain from the assigned backup
5) There's one interesting exception to #4. If the client wants to list
the servers in a 'foreign' domain (that is, not its own domain), then
it has to find a [Local|Domain] Master Browser for that foreign domain.
I'm not sure what the standard practice is here. There's always a
chance that the foreign domain doesn't have any local representatives,
so there'll be no LMB on the local wire. In that case, the client
would need to go to the DMB, if there is one.
The test scenario for this would be awkward to set up without a couple
of networks and a router.
6) Really quickly... in P mode the client cannot send a broadcast query,
so it queries the WINS server for the domain<1B> name and does all
business directly with the DMB. That should be precedent enough for
what Eric is proposing.
"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
More information about the jcifs