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

Christopher R. Hertel crh at ubiqx.mn.org
Tue Apr 1 16:34:48 EST 2003


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jcifs-gets-browselist.cap
Type: application/octet-stream
Size: 6751 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20030401/f56865e1/jcifs-gets-browselist.obj


More information about the jcifs mailing list