libsmbclient and smb_opendir: problem with workgroup
Christopher R. Hertel
crh at ubiqx.mn.org
Mon Jun 14 15:32:46 GMT 2004
On Sun, Jun 13, 2004 at 04:16:21PM -0400, Derrell.Lipman at UnwiredUniverse.com wrote:
> Broken is a bit harsh. URI syntax, particularly what comes after the
> question mark, is generally extensible.
Not in this case. I wrote the SMB URI draft and have been working with
the IETF on it. The draft includes a limited but specified set of context
variables designed to match NBT semantics.
Sorry, I don't mean to be overly pedantic, but if extensions are added
then they will break existing and future SMB URI implementations. The
'MB' keyword you have introduced is not part of the specification so if
someone were to type that in to, say, a Macintosh (which supports the SMB
URI via MacOS X or Thursby's Dave) it would generate an error.
Because of the NBT transport, the SMB URI cannot be fully free from
context. NBT itself is very sensitive to certain context information,
such as the local broadcast namespace and the NBNS it uses for name
resolution. It was fairly easy, however, to exlude workgroup context from
the URI (except in one annoying case, mentioned below).
There is usually no need, in the URI, to specify a default workgroup.
You don't need one for "smb://" (unless you're in P mode) but a client
implementation *may* choose to make use of default workgroup information
if that seems the best course. That's what libsmbclient seems to be doing
(though I agree with you that it may not be the best choice).
> That not withstanding, the majority of my past work has been in working
> with standards, and I'd love to find a way to provide the same
> functionality with no required extentions.
I believe that you are right, that the best way to collect the top-level
workgroup list is to query all of the __MSBROWSE__ nodes on the local LAN.
In B mode: Send the __MSBROWSE__ query, and then do a NetServerEnum2 for
all of the workgroup names on all of the LMBs you've found.
(...but don't report any errors unless *all* of the LMBs fail
to provide a list.)
In P mode: Send the *<1B> query. If that fails, then try the default
workgroup name query (workgroup<1B>). If that also fails
(perhaps because there is no default workgroup defined) then
you report an error. Note: an implementation may choose to
keep track of "known good" workgroup names. If, for example,
the user enters "smb://mydomain" and the underlying system
resolves that as an NT Domain name (a workgroup name...same
thing), then the client may keep track of it as a place to
find workgroup information.
M and H modes are just combinations of the above, though short-cuts might
be taken. For instance, in M mode there'd be no reason to check the NBNS
for names if a list is returned locally.
> > The SMB URI syntax purposfully avoids making any assumption about client
> > configuration, including the default workgroup. This is done in order to
> > avoid sensitivity to a particular context. The URI string "smb://" means
> > "all available workgroups". How that is interpreted is up to the
> > implementation writer.
> It sounds like you are saying that the current implementation is wrong if it
> doesn't show "all available workgroups" with a URI sting of only "smb://".
No, not quite. The browse service is flakey, so the term "available" here
means "available with a reasonable amount of effort". The problem lies in
the browse service itself and the URI format is not going to try to fix
> As you have stated earlier, though, it can be "time consuming" to do
"Properly" is probably too strong a word for the browse service.
> I left the default as the way it had been doing it (first master browser
> found) because I didn't want to change the behavior of existing applications.
The SMB URI and its implementation in libsmbclient are sufficiently new
(it's still a draft, after all) that such changes can and probably should
> For my own purposes, I'd have no problem with always requesting the browse
> list from all discovered master browsers since I'm much more concerned with
> getting a complete list than with how long it takes. (In practice, unless
> there are many workgroups, the added time isn't huge, but it is slightly
A timeout might be a reasonable thing to consider.
> > You have some good ideas about how to gather a workgroup list. There's no
> > reason to add a non-spec syntax.
> I'm with you. You wrote the book (wonderful) on this stuff, so you're the
> expert. :-) What are your suggestions?
I wrote it with lots of input from lots of people. The expertise really
comes from the community as a whole.
> Other than extending the syntax, the alternate method that comes to mind is
> an additional function call, e.g.
I think the functions you provided are a good idea, but only if we really
need that backward compatibility. I'm not sure that we do. I think that
gathering more information from more sources will help rather than hinder.
Those functions can certainly be added later if I'm wrong.
> Note that this does not allow the additional syntax I had added (mb=NAME) to
> request the browse list from a specific master browser. BTW, that's the
> reason that I used mb=.any and mb=.all leaving any name not beginning with a
> dot as the name of the master browser to query. Since dot is the one (and I
> think only) character that a name may not begin with, this seemed a reasonable
Actually, there's no restriction in NBT regarding the dot character. It's
the asterisk ('*') that is restricted. Names beginning with an asterisk
may not be registered. That's why Microsoft can use the "*SMBSERVER" name
as the generic Server Service alias. It's never registered, so all
servers can answer to it.
> > The underlying problems here are in the behavior of the protocol. There
> > is no perfect fix. The Browse Service is sloppy, but it does (eventually)
> > sort itself out.
> That's all I'm trying to do. My problem is in the "but it does (eventually)
> sort itself out" part. I can't wait the 12+ minutes for that to happen. I
> suspected, and the email to which I replied seemed to confirm, that I'm not
> alone. :-)
> > We know how it all works, so we should be able to tweak the code to produce
> > reasonable results.
> Great. Do you prefer my above-listed alternate approach?
> Is there a relatively simple way to get this working in P mode as well?
I threw some ideas at you above. Let me know what you think about them.
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
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
More information about the samba-technical