[jcifs] Master Browsing Caching

Matthew Tippett 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 
also important.

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 
possible).'

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
>    FOO?
> 
> 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 :)

Matt




More information about the jcifs mailing list