libsmbclient and smb_opendir: problem with workgroup

[Christopher R. Hertel]

On Sat, Jun 12, 2004 at 10:00:35PM -0400, Derrell.Lipman at UnwiredUniverse.com wrote:
> Andreas <andreas at conectiva.com.br> writes:
> 
> > I have a machine in the MYGROUP workgroup that is misbehaving:
> >
> > [andreas at pandora source]$ smbclient -L duckman -N
> > session request to DUCKMAN failed (Call timed out: server did not respond after 20000 milliseconds)
> > (...)
> >
> > It does exist:
> > [andreas at pandora source]$ nmblookup duckman
> > querying duckman on 10.0.7.255
> > 10.0.4.149 duckman<00>
> >
> > I don't have shell access to see what is wrong, but that is not the point.
> > The problem is that this missbehaviour is causing network browsing to fail
> > as a whole.
> >
> > On my client machine I have "workgroup=MYGROUP" and this causes
> > smbc_opendir("smb://") to return -1. If, however, I use
> > "workgroup=SOMEGARBAGE" (SOMEGARBAGE doesn't exist), then smbc_opendir()
> > works. Now, as I understand it, the "smb://" url is supposed to be used to
> > list all workgroups in the network, why should my own workgroup matter?  Or
> > does this "search" need to have some workgroup, even if it is an
> > non-existing one?
> 
> If the master browser of the first workgroup found has not been up and running
> for at least 12 minutes (that's the master browser running for 12 minutes, not
> the machine) then it's possible that the list of other workgroups and their
> master browsers has not been acquired by the found master browser.  In that
> case, your request to that master browser will indicate that there's nothing
> to be seen.  

The list may take even longer to converge if there are foreign workgroups
on remote subnets.  Those workgroups must announce themselves to one
another on that subnet (12 minutes max, ave. 6 minutes), and then the LMBs
must communicate with their DMB.  Then the LMBs on your local subnet must
communicate with their DMB to suck down the expanded list.

> IIRC, if you specify a workgroup, then that workgroup's master
> browser will be given your request, whereas if you give SOMEGARBAGE as the
> workgroup, it will discover workgroups and use the first one discovered, which
> would explain why your request works in one case but not the other (although
> if it happened to find the master browser for MYGROUP first and that master
> browser doesn't have the other browse lists, it wouldn't work even though you
> specified SOMEGARBAGE).

Hang on...  I *think* what you're saying is this:
- If the LMB for the default workgroup cannot be found, libsmbclient will 
  query for the __MSBROWSE__ name and then query each respondent in turn 
  for its workgroup list.

Is that right?

Note that doing so won't work in P mode.  In P mode, you might *try* 
querying the NBNS for *<1B> and hope there's a Samba NBNS on the other 
end.  If that fails, then the only option you have is to query for the DMB 
for your workgroup.

In B, M, or H mode you can query for the __MSBROWSE__ name.  Sending the 
NetServerEnum() request to each responding node could be time consuming, 
especially if the list is long (which is unlikely...geez that would be a 
messy network).

> smbclient has not been modified to use the new feature that I added to
> libsmbclient a number of months ago, which solves this problem.  The new
> feature allows smbc_opendir("smb://?mb=.all") to look at all master browsers
> that can be discovered, rather than only the first one found, in order to
> discover all workgroups on the network.

Ouch!  There is no "mb" key in the SMB URI draft (and I won't be adding
one), and there is no definition for ".all".  The syntax above is broken 
and shouldn't be in that code.  The better approach is to do a bit of 
thinking within the code to ensure that smbc_opendir( "smb://" ) returns 
a useful workgroup list.

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.

You have some good ideas about how to gather a workgroup list.  There's no 
reason to add a non-spec syntax.

> For backwards compatibility,
> smbc_opendir("smb://") operates as it always did, requesting the browse list
> only from the first master browser found.

This could be extended without having to add non-spec syntax.  Again, the 
URI draft doesn't say that the default workgroup should be used.  How the 
list of workgroups is obtained is completely up to the client 
implementation.

> See the comment above the function
> smbc_parse_path() in the 3.0 or CVS HEAD tree, for the complete URI syntax now
> supported by smbc_opendir().

smbc_opendir() should be supporting the draft spec syntax.

> I haven't looked at the smbclient source code,
> but the change to it to solve your problem might be as simple as changing
> "smb://" to the new "smb://?mb=.all".

Please don't do that.  Let's work on getting the library to produce a 
useful list using the correct syntax.  This is a problem that should be 
fixed by fixing the code.

> Note that all of this should apply only if the master browser for MYGROUP has
> been running for less than 12 minutes.  If it's been running for longer than
> that, then the browse lists "should" have already been exchanged among the
> various master browsers (in which case you can ignore this entire message. :-)

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.  We know how it all works, so we should be able to tweak 
the code to produce reasonable results.

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