[jcifs] jcifs problem and wins resolution

[Christopher R. Hertel]

On Thu, Sep 26, 2002 at 05:23:13AM -0700, Joe Bentley wrote:
:
> I've noticed the same problem too.  It's because you are executing your code
> on the PDC and a host cannot broadcast to it self.  
> 
> The problem can also be reproduced doing following:
>   jcifs.Config.setProperty("jcifs.netbios.baddr", "127.0.0.1");

Ah.  Brilliant.  Yes, that makes sense.

> If you move your code off the DCs, it should work, providing that the baddr
> includes at least one DC.  Yeah I know it's a lame work around.  Let me know
> if you find a better answer.

No, I think you're right that the loopback interface should be included by 
default.  Hmmm...  I'm wondering what problems that would cause.

> That reminds me, the global jcifs.Config.setProperty("jcifs.netbios.baddr")
> design doesn't work for me.  I need to be able to pass a broadcast address
> into the SmbFile("smb://") call to locally override the jcifs.netbios.baddr
> setting.  My jCIFS code is sitting on a gateway machine where I need to
> broadcast to separate networks that may have over-lapping domain names.
> Currently a single-threaded synchronized block is required to protect the
> global baddr value before a broadcast call.

Hmmm... This gets back to the issue of adding the loopback address...
(Okay, an odd statement... stick with me a moment.)

You could bind an instance of jCIFS to a specific interface.  Say, for 
example, that you had a dual-homed machine with

  - eth0:192.168.0.12
  - eth1:10.0.1.12
and
  - lo0:127.0.0.1

Next, suppose you are an LMB for a workgoup on the 192.168.0.0/24 subnet, 
but you are not running *any* NBT services on eth1 (the 10.0.1.0/24 
subnet).

So, now you try binding jCIFS to eth1 to do a query for "SMB://".  jCIFS 
doesn't know that you are only running LMB services on eth1.  It doesn't 
know that it shouldn't query for MSBROWSE on lo0.  Ouch.

The only solutions of which I'm aware are to either explicitly
[add|remove] the local loopback interface to the search list, or to build
the NBT layer as a complete and stand-alone layer (as Microsoft does) so
that such queries could be resolved internally.

The difficulty with the latter is that jCIFS cannot know that the layer
exists or how to talk to it unless it is consistent across all platforms.  
You could, for instance, probably write VisualC++ code that would use the
NBT layer in the W2K kernel.  jCIFS is not in a position to access that
layer.

NBT was designed as a protocol stack layer, with the intention that it 
would be part of the system itself.  Samba also has difficulties handling 
this sort of issue, but it's easier in Windows simply because the NBT 
layer is in the kernel.

Chris -)-----

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