SV: [jcifs] BFS vs DFS
torgny.johansson at kommun.ljungby.se
Mon Jul 30 16:22:23 EST 2001
For example after doing nothing for atleast 5 minutes I get this error when
listing a share:
jul 30 08:14:08.158 - SmbFile exception
java.net.NoRouteToHostException: Ingen kommunikation med värddatorn
at java.net.PlainSocketImpl.socketConnect(Native Method)
listShare failed: java.lang.NullPointerException
"Ingen kommunikation med vräddatorn" is Swedish and mean "No communication
I don't know if this tells you anything about what's wrong.
> -----Ursprungligt meddelande-----
> Från: jcifs-admin at lists.samba.org
> [mailto:jcifs-admin at lists.samba.org]För Michael B. Allen
> Skickat: den 28 juli 2001 03:18
> Till: Christopher R. Hertel
> Kopia: Torgny Johansson; jcifs at samba.org
> Ämne: Re: [jcifs] BFS vs DFS
> On Fri, Jul 27, 2001 at 10:28:55AM -0500, Christopher R. Hertel wrote:
> > On Fri, Jul 27, 2001 at 07:47:45AM +0200, Torgny Johansson wrote:
> > :
> > > What's taking time is sometimes when there are no shares on a
> pc or if the
> > > pc can't be found.
> > Hmmm... I can imagine that there would be a timeout problem
> when a server
> > cannot be found, but I'm surprised that no shares would cause a delay.
> Yes, this is strange. The name is coming from the browse list but
> querying WINS should immediately return false in which case the thread
> should immediatly move on. But if hosts are going up and down like yoyos
> then WINS and the browse list may not be up to date. Actually, if WINS
> returns false the I believe the client will try to broadcast which I
> think takes about 6 seconds to time out but of course the name must have
> come from somewhere in the first place. SMB and WINS systems are highly
> dynamic so you really have to start looking at traces to see what's
> happening. Querying for a list of shares should return immediately though.
> > > Also, the LAN I'm crawling is on many different subnets. I've
> set the wins,
> > > but I have to set the baddr to the same adress as the wins to
> be able to
> > > list all online pcs.
> > That's odd.
> I think the reason you must set the broadcast address is because you
> (I know I'm respondin to Chris but I'm addressing Torgny) have many
> machines that do not register with WINS. You will natrually not see these
> machines unless you broadcast for them and they happen to be on your
> local network segment. This would confirm suspicious timeouts mentioned
> above and might screw up jCIFS. Having some clients that register with
> WINS and others that just broadcast is a bad idea -- unfortunately this
> is all to common on University networks.
> > > Otherwise my crawler can't list any workgroups.
> > Huh? That doesn't make sense. You need to use broadcast name
> > to find the workgroups.
> > Mike, what do you think is happening here?
> The default value for baddr is 255.255.255.255. This should be fine
> unless you have multiple interfaces in which cast I think you will the
> exception described in the FAQ. I beleieve there are other ways to screw
> up the broadcast address. It might be the local machine, the network,
> or elsewhere. It may be necessary to set baddr just to communicate via
> broadcast at all. If you don't you may not be able to find local master
> browsers in which case you wouldn't be able to list any workgroups.
> > > I suppose it was this you guys talked about in an earlier
> discussion and this
> > > was being dealt with in the 0.6 ver, right?
> > I'm not sure what's happening here. It doesn't sync with my
> > of the workings of this stuff. By setting the baddr to the same address
> > as the NBNS you are, essentially, forcing P mode. I don't know how you
> Mmm, well I suppose if you set baddr to the WINS IP then the code that
> was meant for broadcasting will go to the WINS server and might actually
> get an answer. But if WINS is like 192.168.1.23 then baddr might very
> well be 192.168.1.255. Are you using the *exact same* IP for baddr and
> wins Torgny?
> About what we were talking about before Torgny, jCIFS cannot get a server
> list for workgroups that are entirely on a different subnets than the
> client. It's as simple as that.
More information about the jcifs