[jcifs] Master Browsing Caching

Matthew Tippett matthew.tippett at sympatico.ca
Fri Oct 25 14:15:29 EST 2002


 >> I want to scan the network for all domains, in our network we have
 >> a number of 'interesting' master browsers.  Some won't let us
 >> connect to the IPC$ share
 >
 > That is pretty interesting considering you have to connect to IPC$ to
 > retrieve the browse list.
 >
 >> , others are set up to use plain text passwords.
 >
 > Also interesting considering retrieving the browse list usually uses
 > null credentials but if not you can set disablePlainTextPasswords =
 > false.

Of the five DOMAINS (don't ask) on our network, there is an NT DOMAIN
with a guest account that has expired (so the connection to the IPC$
fails with 'account expired'), and a Samba machine configured for
plaintext password (which results in a RuntimeException indicating that
the plaintext option must be enabled - I am not sure if a generic
exception is appropraite for that.)

 >> o The __MSBROWSE__ name should not be cached in NbtAddress
 >
 > Why?

Because if there are multiple matches for the name, then there is no
opportunity to locate another Master Browser.  The first Master Browser
that is found is the browser for the life of the cache.  With new
servers being able to cause an election since they may have a better
idea of the network hosts, it makes sense to me for the the __MSBROWSE__
name to be a special case and be resolved through the NbtAddress means
each time.

 > Set cachePolicy = -1.
 >
 > All jcifs properties are described on the Overview page of the API
 > documentation.

I understand that, but I don't agree that caching should be turned off
altogether, machine names change rarely, usernames (exposed in the
NetBIOS namespace) change more regularly and finally Master Browsers
change regularly as different servers of different OS levels come in and
out of existance.

 >> o Currently the NameServiceClient  waits on the first Name response
 >>  before continuing, if there is more than one response (if there
 >> are
 >
 > We're not going to do this. We do what NT does. You should be able to
 > collect domain names fine listing "smb://". Sure it *might* create a
 > more complete list if you have machines going up and down like yo-yos
 > but it's not behavior that is observed in any other clients I don't
 > really see the benefit.

I would disagree with this.  Although the behaviour of NT is one thing,
the statement in the documentation indicates that 'smb://' should return
a list of all domains visible on the network.  If through
misconfiguration the *first* Master Browser won't allow connection to
the IPC$ share, then we are left in a situation where we have nothing.
Given that most networks are configured more reliably than the one that
I am working with, I would disagree that we should fall back to a
partial solution.  I can tell you with absolute confidence, that the
smb:// behaviour is *very* unreliable on poorly configured networks.  I
have seen behaviour consistent with the 'NT does it this way' apprach
when you have a NT system that simply cannot browse.

My personal preference is that jcifs works to the documentation.
Creating a SmbFile("smb://") *should* do it's absolute best to return a
complete list of Domains if they are available.  The following Snippet
simply doesn't work reliably in a poorly configured network.

             try {
                 try {
                     domainFile = new SmbFile("smb://");
                 } catch (MalformedURLException e) {
                     System.out.println("MalformedURL "+e);
                 }
                 allDomains = domainFile.listFiles();
             } catch (RuntimeException e) {
                 System.out.println("RuntimeException "+e);
             } catch (SmbException e) {
                 System.out.println("SmbException "+e);
             }

 >> From my understanding of CIFS each WORKGROUP/DOMAIN has it's own
 >> Master Browser, even though the master browsers should have all
 >> DOMAINS in their browselist.
 >
 > This is not quite right. Each subnet has at least one master browser.
 > I don't know if there is a master browser for each workgroup. I don't
 > think so. Chris?

Why is it that the smbclient -L output has a table with WORKGROUP/MASTER?
eg:

	Workgroup            Master
	---------            -------
	WORKGROUP       MEEP
	TIPPETT              JUPITER

 >> As an aside, I have noticed that in NameServiceClient.java at line
 >> 367.
 >>
 >> name.name != NbtAddress.MASTER_BROWSER_NAME
 >
 > To query for a master browser you do:
 >
 > NbtAddress.getByName( NbtAddress.MASTER_BROWSER_NAME );
 >
 > in which case the same String object is always passed in and
 > therefore comparing object references is indeed the correct behavior.
 > In theory you could do getByName( "\u0001\u0002__MSBROWSE__\u0002" )
 > but I'd make sure you're wearing clean underwear before you try that!
 >
I agree that in this case it will work, but again I fall back to what is
the intent?  Do you want to confirm that the string in the name is the
same *object*, or do you want to confirm that the string is the name is
*equivalent*.  Although it isn't a real issue, I have found more than my
share of subtle bugs in other peoples code that came down to the
assumption that a string read from the wire can be compared with a
constant with the '==' operator.  (As an even further side note, the Sun
Java Coding Conventions warn against using '==' for strings).

Don't get me wrong however, jcifs is a great piece of work, but where a
feature isn't part of the protocol, but an artefact of the development
('smb://'), I don't feel that we should fall back to a poor (potentially
broken) approach when *ALL* Master Browsers do respond, we could
trivially pull together a complete list.  Contrasting what I have seen
of other application CIFS browsers, jCIFS is a lot better and does
actually discover most of the network.  I just want to push the
reliability of the scan beyond what is now to be able to be more robust
even in the face of poorly configured corporate and (more likely) home
machines.

Thanks for the lively response, hopefully this response has made my
rationale for the first posting a bit clearer.

Regards,

Matthew




More information about the jcifs mailing list