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