[jcifs] Master Browsing Caching
matthew.tippett at sympatico.ca
Fri Oct 25 14:46:17 EST 2002
Looks like I triggered a meaty thread :)
>> That is pretty interesting considering you have to connect to IPC$
>> to retrieve the browse list.
> Some systems require a valid username/password in order to access any
> share, including IPC$. I'm not sure that this is the problem, though.
> I imagine that it would be hard to read the browse list from a system
> that required encrypted auth...if you don't have the credentials.
Which is the problem, at the protocol level (ethereal :), it is
connecting with ?\GUEST and no password, and in one case the PDC is
saying 'bugger off, that user has expired - hence no credentials', and
the other one is detecting that the SMB server uses plain text passwords
and forcing the user to turn on plaintext pasword support.
I agree that these are not technically jCIFS problem, but my whole
problem lies in that if *ONE* domain is poorly configured (I was
*fortunate* to have 2/5 that are not configured properly), then if the
dice fall such that that domain responds first with the __MSBROWSE__
resolution, then the SmbFile('smb://') will fail completely.
A happier medium might be to grab leave the NameServiceClient thread
continue listening for responses *JUST* in case there are more than one
DMB's on the network and the one that responds first will not allow us
to connect? My preferred approach would be to interogate all DMBs and
collate their individual world views.
> I agree with the "Why?". What does caching do that prevents you from
> getting all of the local __MSBROWSE__ IPs?
I am attempting to operate purely at the SmbFile("smb://") level as per
the documentation. I understand I can go down to the network and
resolve all of them seperately, but from a jCIFS consumers point of
view, the SmbFile("smb://"); interface appears on the surface to do what
is needed... but doesn't in my fringe condition.
The previous email about how the lifecycle of the names are different is
One final point would be that is it right to cache *only one* of the
addresses of a name where there are known to be multiple? IMHO that
could quite easily leave a jCIFS session getting a one-sided view of the
network, considering the whole NetBIOS naming approach hinges on systems
chatting over the wire and listening to other people (as mentioned below).
> If it sounds as if I'm waffling, I am. Mike is right from the practical
> point of view. I would say, though, that it would be worth-while to have
> a mechanism for doing a group name query and retrieving from that a list
> of IPs. That is lower-level functionality that can be very useful for
> folks doing special-purpose work like this.
That is probably the crux of the issue, the code as is handles the 95%
of cases where the network is configured 95% correctly. Even if I can't
convince the current jCIFS developers that there is a better way, I will
somehow work out how to graft the functionality in.
As a technologist and a pragmatist, I understand what is happening from
a technology point of view, but from a pragmatic view, the
SmbFile("smb://") interface is a jCIFS only implementation (I understand
about the ietf draft, but how man implementations use the URL format,
and what is their approach), and currently doesn't fully follow the
intent behind the documentation.
Quoting the SmbFile documentation :
the smb:// URL lists all available workgroups on a netbios LAN. Again,
in this context many methods are not valid and return default
values(e.g. isHidden and renameTo will always return false).
I don't see any provisos on that such as
' only if the jCIFS client has baseline authentication suitable for the
master browser that responds; if there is more than one DMB on the
network, the DOMAIN list will be retrieved from that server only (if
Which of course would *VERY* quickly shut me up and force me to
implement the functionally that I wanted by using direct NetBIOS calls :).
> What I don't know (yet) is:
> 1) Do the DMBs do anything to coordinate cross-NTDomain browse lists?
> 2) What happens to a node on a subnet that doesn't have a member of
> workgroup FOO when the user tries to look at the server list for
> On that last question, I know that the easy thing to do is look for a
> DMB for workgroup FOO (assuming one exists). I don't know what Windows
> does, though.
I tend to liken NetBIOS naming as to a whole pile of egotistic children
at school shouting at each other trying to work out who is going to put
together a list of people attending class that day for the teacher. As
you can imagine, it is a miracle if it works at all :).
Looking forwards to the replies :)
More information about the jcifs