libsmbclient and smb_opendir: problem with workgroup

[Christopher R. Hertel]

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 
that.  :)

> As you have stated earlier, though, it can be "time consuming" to do
> "properly".

"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 
be made.

> 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
> noticeable.)

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

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.  

Thanks!

Chris -)-----

-- 
"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