libsmbclient and smb_opendir: problem with workgroup

[Christopher R. Hertel]

On Mon, Jun 14, 2004 at 02:38:40PM -0400, Derrell.Lipman at UnwiredUniverse.com wrote:
:
> 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 mode is determined by two things:  If there is no NBNS (WINS server)  
address defined then the node is in B mode.  If the NBNS IP is defined,
then it all depends on the RESOLVE ORDER parameter.

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

He is.  He's the one behind libsmbclient and the proposal for an SMB URI 
was originally his idea.

> I'd like to get his take on this.  Who else?

I don't know, really.  Most of the Team are up at the battlefront leaving 
folks like me (who love fussy details like this) to clean up.  :)

:
> > A timeout might be a reasonable thing to consider.
> 
> Argh.  That timeout stuff in the code has problems.  

Then we're probably best off trying to figure out and fix the 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.

There should, generally, only be need of one, and I tend to write to
poll() rather than select() when possible.  I'll have to take a look when 
I get some time.

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

Fair enough.

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

My gut tells me that there is no "right" way, but that's because of
browsing, not libsmbclient.  Still, there are better ways and I'd really 
like to see us polish this.

Oh...  The original problem that started this thread was really two 
things:

1) The DNS had the wrong IP address for the node.  DNS name resolution is, 
   by default, the first form tried by Samba (and libsmbclient).  My own 
   opinion (others on the Team disagree) is that DNS should be tried as a 
   last resort only.  In any case, the upshot was that the LMB was not 
   being found because it was resolving to the wrong IP address.

2) The above problem was fixed by changing the resolve order in smb.conf, 
   and then a new problem was discovered.  The LMB node is running some 
   sort of firewall software (or something) that's preventing connections
   to smbd.  As a result, even though the correct node is being contacted,
   the query cannot be completed.

Fun, eh?

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