[jcifs] Master Browsing Caching

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	Matthew Tippett [SMTP:matthew.tippett at sympatico.ca]
> Sent:	Friday, October 25, 2002 12:15 AM
> To:	Allen, Michael B (RSCH)
> Cc:	jcifs at lists.samba.org
> Subject:	Re: [jcifs] Master Browsing Caching
> 
>  >> 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
> 
	This is a bug in 0.7.0b5. It should try your supplied creds and if that fails it
	should try domain "", username "", and password null which will almost
	invariably work. I'm on a LAN with 300 domains and all the machines
	deliberately disable GUEST. 0.6.6 works and so will 0.7.0b6.

> 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.
> 
	This is not true. Names are cached for 30 seconds.

>   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.
> 
	Then make cachePolicy = 5.

>  >> 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,
> 
	Bug previously described? Try 0.6.6.

>  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*.
> 
	Both. I *know* they're the same object so they are 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.
> 
	The MSBROWSE_NAME is never read off the wire. If it were then a logical
	comparison would certainly fail.

>   (As an even further side note, the Sun
> Java Coding Conventions warn against using '==' for strings).
> 
	Obviously in certain instances it will simply not work. But in this case all
	instances of the MSBROWSE string come from the static member of
	NbtAddress and therefore we might as well be comparing 1 == 1.

> 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
>