[jcifs] RE: Can't grab browse list using 0.7.3.

[Allen, Michael B (RSCH)]

I see the problem. I though the code was pretty sophisticated about devising
CalledNames but it was deficient when it came to handling workgroup
names. I have implemented the fix. I just want to add Eric's jcifs.http
package updates and I'll push out a new release.

> -----Original Message-----
> From:	Allen, Michael B (RSCH) [SMTP:Michael_B_Allen at ml.com]
> Sent:	Wednesday, April 02, 2003 6:53 PM
> To:	'Christopher R. Hertel'
> Cc:	jcifs at samba.org
> Subject:	[jcifs] RE: Can't grab browse list using 0.7.3.
> 
> Do you have OMEGA in your hosts file? Where is it getting that? What
> example/arguments are you using?
> 
> Mike
> 
> > -----Original Message-----
> > From:	Christopher R. Hertel [SMTP:crh at ubiqx.mn.org]
> > Sent:	Tuesday, April 01, 2003 1:35 AM
> > To:	Allen, Michael B (RSCH)
> > Cc:	jcifs at samba.org
> > Subject:	Can't grab browse list using 0.7.3.
> > 
> > Mike,
> > 
> > I've run across a little problem with 0.7.4.
> > 
> > I'm trying to grab the browse list (NetServeEnum2) using jCIFS.  The LMB
> > is currently a W98 box (OMEGA) and the workgroup name is UBIQX.
> > 
> > JCIFS succeeds in finding the W98 box (Omega) and tries to connect with
> > it.
> > 
> > - It tries the workgroup name as a server service name first
> >   (UBIQX#20--not sure why it does this but, of course, it fails).
> > 
> > - It tries *SMBSERVER#20 second (which won't work on a W9x box, because
> >   they don't support the *SMBSERVER name).
> > 
> > - Then it tries the workgroup name as a server name again (UBIQX#20).
> > 
> > It never tries connecting to OMEGA#20, so it always gets a CALLED NAME NOT
> > PRESENT error, which throws an exception:
> > 
> > Exception in thread "main" jcifs.smb.SmbException: Failed to establish 
> > session with UBIQX<1D>/192.168.101.16
> > 	at jcifs.smb.SmbTransport.send(SmbTransport.java:476)
> > 	at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:664)
> > 	at jcifs.smb.SmbTree.treeConnect(SmbTree.java:116)
> > 	at jcifs.smb.SmbFile.connect(SmbFile.java:514)
> > 	at jcifs.smb.SmbFile.connect0(SmbFile.java:484)
> > 	at jcifs.smb.SmbFile.list(SmbFile.java:1082)
> > 	at List.main(List.java:13)
> > 
> > I've attached a quick capture (which will probably be filtered out by the 
> > mailing list software so I'm sending directly in parallel).
> > 
> > Packets 1 through 23 show Samba's smbclient doing its thing.  Note that it
> > connects to OMEGA#20, which works (but then the way smbclient works you 
> > have to give it the correct CALLED NAME).  That part is just there to show 
> > that the browse system is working correctly.
> > 
> > Packets 24..49 show the following:
> > - jCIFS queries for UBIQX#1D and UBIQX#20.
> > - There's a positive response for UBIQX#1D.  No response for UBIQX#20, but 
> >   only one query is sent.  There really should be three queries sent when 
> >   resolving a name, since UDP is considered unreliable.
> > - We try to create a session with UBIQX#20.  If the name didn't 
> >   resolve, why do this?
> > - We try again using *SMBSERVER#20.  Windows9x doesn't like that name so 
> >   that fails too.
> > - An Node Status query is sent.  The results list OMEGA#20 as the only 
> >   type 20 name.
> > - We try UBIQX#20 again.
> > 
> > Ouch.
> > 
> > Annoyingly, this will all work against a Samba server, WindowsNT, or W2K.
> > Samba doesn't pay any attention to the CALLED NAME, and the NT family will 
> > accept *SMBSERVER#20.
> > 
> > There are two problems that I am seeing here.  The first is that we're
> > using the <workgroup>#20 name even though there wasn't a positive name
> > response for that name.  The second is that <workgroup>#20 is still being
> > used after the the Node Status query returns.  In both cases, it looks as
> > though something is stuck.
> > 
> > I'm also debating in my mind whether it makes sense to stop querying for
> > one name (eg. UBIQX#20) when the other name (UBIQX#1D) gets a response.  
> > In general, once you've gotten *any* response for this kind of query, you
> > have *the* response you wanted.  The only time it's a problem is in the 
> > case of the misconfigured network.  In that case, given that UDP is 
> > considered unreliable, you *could* get different results each time you 
> > try to resolve a URL like: smb://<name>/
> > 
> > I hate misconfigured networks.  Note, however, that WindowsXP doesn't 
> > register the <workgroup>#00 name, which makes this kind of 
> > misconfiguration easier to set up.
> > 
> > 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 << File: jcifs-gets-browselist.cap >> 
>