libsmbclient and smb_opendir: problem with workgroup

Christopher R. Hertel crh at
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 duckman<00>
Looking up status of
        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):
> ( is me, is duckman)
>   1   0.000000 ->   TCP 43978 > 445 [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=1050967277 TSER=0 WS=0
>   2   0.000189 ->   TCP 445 > 43978 [RST, ACK] Seq=0 Ack=0 Win=0 Len=0
>   3   0.010709 ->   TCP 43979 > 139 [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=1050967288 TSER=0 WS=0
>   4   0.010865 ->   TCP 139 > 43979 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=4150813149 TSER=1050967288 WS=0
>   5   0.010879 ->   TCP 43979 > 139 [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=1050967288 TSER=4150813149
>   6   0.021730 ->   NBSS Session request, to DUCKMAN<20> from PANDORA<00>
>   7   0.222636 ->   NBSS [TCP Retransmission] Session request, to DUCKMAN<20> from PANDORA<00>
>   8   0.624573 ->   NBSS [TCP Retransmission] Session request, to DUCKMAN<20> from PANDORA<00>
>   9   1.428451 ->   NBSS [TCP Retransmission] Session request, to DUCKMAN<20> from PANDORA<00>
>  10   3.036219 ->   NBSS [TCP Retransmission] Session request, to DUCKMAN<20> from PANDORA<00>
> (...) (some noise)
> later on:
>  31  20.040670 ->   NBSS Session request, to *SMBSERVER<20> from PANDORA<00>
>  32  20.241592 ->   NBSS [TCP Retransmission] Session request, to *SMBSERVER<20> from PANDORA<00>
>  33  20.643528 ->   NBSS [TCP Retransmission] Session request, to *SMBSERVER<20> from PANDORA<00>
>  34  21.447423 ->   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

My guesses, based on all of this, are:

1) The DNS being out of sync with the NetBIOS namespace is your first 
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 --     -)-----   Christopher R. Hertel
jCIFS Team --   -)-----   ubiqx development, uninq.
ubiqx Team --     -)-----   crh at
OnLineBook --    -)-----   crh at

More information about the samba-technical mailing list