libsmbclient and smb_opendir: problem with workgroup

[Derrell.Lipman at UnwiredUniverse.com]

"Christopher R. Hertel" <crh at ubiqx.mn.org> writes:

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

Currently, the code tries the broadcast queries for __MSBROWSE__, and has a
comment stating that if this fails, we should "try our other methods" (but the
latter is not yet implemented).  I don't know of a way to determine which mode
is in use (is there one?) so it seems that doing the broadcast queries for
__MSBROWSE__ followed by the *<1B> query would be the correct order.  Do you
concur?

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

I'm currently hot and heavy into some unrelated work.  I'll get back to this
and make whatever appropriate changes we decide on in a few weeks.  In the mean
time, who else should buy in on whatever we're going to do?  Richard Sharpe
has been involved in accepting my changes regarding this (his name is all over
libsmbclient so I think/thought he was the right person to be talking to.  I'd
like to get his take on this.  Who else?

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

Argh.  That timeout stuff in the code has problems.  The extra pipe that's
created in lib/select.c in implementing the timeout (and presumably
eliminating a race condition) does not seem to be reliable; i.e. it still
blocks indefinitely on occasion, requiring a kill.  I'd sure rather not add
more uses of sys_select() if at all possible...  In principle, a timeout might
be a reasonable thing to consider.

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

All right.  Again, though, before I go and change a working (but
unsatisfactory, you're telling me) implementation, I'd like to pow-wow with
all of the various powers that be so we all come to consensus.

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

Oops.  That was probably what I _meant_ to use, rather than dot.  Sigh.  Well
if it's going away, I needn't worry about it, and if the consensus is that the
current mechanism should stay, I can convert the dot to an asterisk.

> I threw some ideas at you above.  Let me know what you think about them.  

All seem reasonable (especially since it appears to be what I'm already doing
when the mb=.all option is specified).  Doing that by default is fine with me.
I'd just need to add the P mode stuff.

Let's figure out the "right" way to handle browsing in libsmbclient, and I'll
plan on working on it in something like 3-4 weeks (providing I don't get hung
up on something urgent that delays me).

Cheers,

Derrell