libsmbclient and smb_opendir: problem with workgroup

Christopher R. Hertel crh at ubiqx.mn.org
Mon Jun 14 17:24:24 GMT 2004


On Mon, Jun 14, 2004 at 01:40:33PM -0300, Andreas wrote:
> On Mon, Jun 14, 2004 at 10:54:37AM -0500, Christopher R. Hertel wrote:
> > Okay, that's weird.
> > 
> > nmbd is obviously running and I assume that you can get to shares on the 
> > server, so smbd must be running...
> 
> No, I can't (not with a simple smbclient command, at least). That DUCKMAN 
> server is hosed somehow. But that's not the point.

Hmmm?  Not sure what you mean.

We know that nmbd is running on DUCKMAN because of this:

$ nmblookup -S duckman
querying duckman on 10.0.7.255
10.0.4.149 duckman<00>
Looking up status of 10.0.4.149
        DUCKMAN         <00> -         B <ACTIVE>
        DUCKMAN         <03> -         B <ACTIVE>
        DUCKMAN         <20> -         B <ACTIVE>
        ..__MSBROWSE__. <01> - <GROUP> B <ACTIVE>
        MYGROUP         <00> - <GROUP> B <ACTIVE>
        MYGROUP         <1d> -         B <ACTIVE>
        MYGROUP         <1e> - <GROUP> B <ACTIVE>

        MAC Address = 00-00-00-00-00-00

You would not have gotten a response if nmbd were not running.  The above 
list is sent by nmbd.

In contrast, the 'smbclient -L' query is sent to the smbd daemon running
on the server--not nmbd.  If smbd is not running, then you won't get a
reply (which would explain the problem you reported).

> > Try one more thing for me:  'nslookup DUCKMAN'
> 
> It resolves to duckman.distro.conectiva, which doesn't exist anymore (a side
> effect of "search distro.conectiva conectiva" in /etc/resolv.conf). The
> "duckman.distro.conectiva" name exist in DNS, but that IP is no longer used.

Bingo.  I get my 3 points.  :)

By default, samba will try to resolve names via the DNS before anything 
else.  So it's quite possible that the 'smbclient -L' query is being sent 
to the *wrong IP address*.

Change you smb.conf so that WINS and Broadcast lookups are attempted 
first.  The best order is probably: "wins bcast lmhosts host".

This is a insessant whine of mine, and most of the team disagree with me 
so you can take it with a grain of salt, but...

The DNS namespace and the NBT namespace are *separate and distinct*.  It 
is mere convenience that DNS and NetBIOS names are often the same on a 
given host.  Assuming that the DNS and NetBIOS names are the same has its 
dangers, as we've seen here.

> "duckman.conectiva", which is the domain I'm in (.conectiva), doesn't exist in
> DNS. This machine was moved from the "distro.conectiva" domain to the ".conectiva"
> domain but doesn't have the "duckman.conectiva" ip registered yet.
> 
> > I think I see the problem.  I've just done some testing and I think I get 
> > three points for this one (if I'm right).
> > 
> > Does the DNS entry match the NetBIOS lookup?  Same IPs?
> 
> No
> To try to circunvent this, I added an entry for duckman in /etc/samba/lmhosts.
> But again, my problem is not with duckman in particular, I just saw some weird
> behaviour with network browsing apps due to duckman which I think could mean
> something else is broken.

See above.

> > I was able to produce a similar problem at my end.  Turns out that the DNS 
> > entry doesn't match.  When I use nmblookup for the name "FOO" I get one 
> > IP, but when I do a DNS lookup I get a different IP.
> 
> Correct
> 
> > Try this as well:  'smbclient -R "bcast wins" -N -L DUCKMAN"'
> 
> Still doesn't work. The duckman machine is found allright, it just won't
> answer (which, I stress again, is not my particular problem, but probably related
> to why network browsing is hosed here if I'm on the MYGROUP group: the other groups
> don't show up).

Is smbd running on DUCKMAN?  If not, nmbd may still go ahead and register 
the Browse Service names and win elections, but without smbd there won't 
be anything to "server" the browse list.

If you can't run smbd on that server, set 'local master = false' in the 
smbd so that it doesn't become the local master browser.

> I'm still owing people a full packet trace, I'm working on that (trying to clean
> out some noise such as cups announcements, dhcp and other stuff). But here is a snippet of the text
> output part from tethereal regarding the above command (I now removed the duckman entry from lmhosts):
> (10.0.2.177 is me, 10.0.4.149 is duckman)
> 
>   1   0.000000   10.0.2.177 -> 10.0.4.149   TCP 43978 > 445 [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=1050967277 TSER=0 WS=0
>   2   0.000189   10.0.4.149 -> 10.0.2.177   TCP 445 > 43978 [RST, ACK] Seq=0 Ack=0 Win=0 Len=0
>   3   0.010709   10.0.2.177 -> 10.0.4.149   TCP 43979 > 139 [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=1050967288 TSER=0 WS=0
>   4   0.010865   10.0.4.149 -> 10.0.2.177   TCP 139 > 43979 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=4150813149 TSER=1050967288 WS=0
>   5   0.010879   10.0.2.177 -> 10.0.4.149   TCP 43979 > 139 [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=1050967288 TSER=4150813149
>   6   0.021730   10.0.2.177 -> 10.0.4.149   NBSS Session request, to DUCKMAN<20> from PANDORA<00>
>   7   0.222636   10.0.2.177 -> 10.0.4.149   NBSS [TCP Retransmission] Session request, to DUCKMAN<20> from PANDORA<00>
>   8   0.624573   10.0.2.177 -> 10.0.4.149   NBSS [TCP Retransmission] Session request, to DUCKMAN<20> from PANDORA<00>
>   9   1.428451   10.0.2.177 -> 10.0.4.149   NBSS [TCP Retransmission] Session request, to DUCKMAN<20> from PANDORA<00>
>  10   3.036219   10.0.2.177 -> 10.0.4.149   NBSS [TCP Retransmission] Session request, to DUCKMAN<20> from PANDORA<00>
> (...) (some noise)
> later on:
>  31  20.040670   10.0.2.177 -> 10.0.4.149   NBSS Session request, to *SMBSERVER<20> from PANDORA<00>
>  32  20.241592   10.0.2.177 -> 10.0.4.149   NBSS [TCP Retransmission] Session request, to *SMBSERVER<20> from PANDORA<00>
>  33  20.643528   10.0.2.177 -> 10.0.4.149   NBSS [TCP Retransmission] Session request, to *SMBSERVER<20> from PANDORA<00>
>  34  21.447423   10.0.2.177 -> 10.0.4.149   NBSS [TCP Retransmission] Session request, to *SMBSERVER<20> from PANDORA<00>
> 
> I'll try a packet capture now of opendir("smb://") with workgroup=MYGROUP and workgroup=SOMEGARBAGE.

Notice that the NetBIOS Session Service request keeps getting resent?  
Something *appears* to be listening on port 139 since the TCP connection
was accepted.  The problem is that DUCKMAN is not accepting the Session
Request.

My guesses, based on all of this, are:

1) The DNS being out of sync with the NetBIOS namespace is your first 
   problem.
2) smbd not running is your second problem.

These are guesses, so correct me if any of my assumptions are wrong.

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


More information about the samba-technical mailing list