smbc_opendir() returns -1 but sets errno to 0

[Christopher R. Hertel]

On Wed, Nov 26, 2003 at 03:16:09PM +0100, Stephan Kulow wrote:
> On Wednesday 26 November 2003 01:51, Christopher R. Hertel wrote:
> > >  When receiving the responses, it therefore had access to
> > > the IP address from which the response originated.  Would it be an
> > > appropriate modification to libsmbclient, to cache the IP address
> > > from these responses, in order to behave in a more expected fashion?
> > 
> > Well... no, not really.  If there is a new election and some other node
> > becomes LMB then the cache would be invalid.  The real question is:  Why did
> > a query for smb://WORKGROUP_NAME/ return the IP address of something other
> > than a browser for the WORKGROUP_NAME workgroup?  Another question: Is it
> > possible that the workgroup browse list was, in fact, empty?  That can
> > happen fairly easily.
> > 
> > Ethereal... Your best friend.
> > 
> The issue is quite clear and I once discussed this problem already with Richard:
> The LMB is resolved through netbios and from the result only the host name is
> taken and then resolved over DNS - which can (as you say) result in a different
> IP.

...but that doesn't make sense.  If the code is looking up a workgroup
name to find the LMB, then sending a query for workgroup<1D> returns the
IP address of the LMB.  That's all you need.

To go through the steps you describe, the client would need to send a Node 
Status Query, scan through the list to find the <20> name to derive the 
machine base name, then send a DNS query for that name (no DNS domain), 
and then get the IP again.  ...or, perhaps do a reverse lookup to get the 
DNS name (which isn't useful).

I don't understand why the code would do that.

> And when then the server behind the IP doesn't want the connection, then
> libsmbclient is confused and returns this strange -1, errno = 0 case (which
> resulted in the nice konqueror error "Unknown error: success" for quite 
> some time :)

Then there's most definitely a bug that needs to be fixed.

> libsmbclient needs to be changed to not resolve the name _again_ when it found
> out the master browser. Just noone got to that so far. And yes, that's an invalid
> network setup, but there are tons of reports for that - just one example:
> http://bugs.kde.org/show_bug.cgi?id=58831

No, it doesn't sound like an invalid network setup.  It sounds as though 
there's something wrong in the client's workgroup resolution.  I need an 
Ethereal capture of this.  Anyone got one?

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