Weird WINS registration in 1.9.18alpha14

[Eloy A. Paris]

Hi,

I've found something that I don't know if could be a problem with the
WINS code in 1.9.18alpha14.

I have a remote Samba server connected via a permanent PPP link to our
main Samba server. The remote host is connected to an Ethernet which
has all private IP addresses. The address of the PPP interface is
valid. The remote Samba server workgroup is RAV-WH and the main
(local) server workgroup is RAV. Both servers are Domain Masters for
their workgroups.

When I have

interfaces = 172.16.0.10/255.255.0.0 130.151.17.193/255.255.255.128

wins.dat in the main Samba server (which is the WINS server, of
course) has:

SKYNET#20 883925953 172.16.0.10 130.151.17.193 44R
SKYNET#03 883925953 172.16.0.10 130.151.17.193 44R
SKYNET#00 883925953 172.16.0.10 130.151.17.193 44R
RAV-WH#00 883925953 255.255.255.255 c4R
RAV-WH#1e 883925953 255.255.255.255 c4R
RAV-WH#1b 883925954 172.16.0.10 130.151.17.193 44R

That is what I would expect.

However, when I have:

interfaces = 130.151.17.193/255.255.255.128 172.16.0.10/255.255.0.0

wins.dat contains:

SKYNET#20 883926142 130.151.17.193 44R
SKYNET#03 883926142 130.151.17.193 44R
SKYNET#00 883926142 130.151.17.193 44R
RAV-WH#00 883926147 255.255.255.255 c4R
RAV-WH#1e 883926147 255.255.255.255 c4R
RAV-WH#1b 883926143 130.151.17.193 44R

You see? The address 172.16.0.10 is missing. Why?

In the remote server I see these messages in nmbd's log file:

register_name_timeout_response: WINS server at address 130.151.17.154
is not responding.

In the local server (WINS server) I see these in nmbd's log file:

read socket failed. ERRNO=No route to host

It looks to me like the WINS server is trying to reply to the WINS
registration to the address 172.16.0.10 and since there is no route
to that address because that's a hidden address, both the client and
the server can't talk to each other. That might explain the error
message, but why in the first case of the "interfaces = xxx", the name
registration works fine?

I know my network setup is a little complicated and weird and that it
could be me doing things wrong but I can't explain this behavior.

-----------------------------------------------------------------

Also, I want to re-confirm a problem I reported a week ago here:
sometimes nmbd can't be killed with a kill -TERM signal because there
are two nmbd processes and none of them has forked the other. It looks
like a problem is the signal handler.

The news I have for today is that I found a way of reproducing the
problem: if the WINS client is stopped (killall -TERM nmbd) and then
the WINS server is stopped (killall -TERM nmbd) everything is fine. I
see that after stopping the client the WINS entries for it have been
removed.

However, if the WINS server is stopped before stopping the client, two
nmbd processes stay running in the server and they have to be killed
with killall -KILL nmbd.

I heard the Samba team is already working on this so please ignore
this if you already know what's going on.

Happy 1998!

E.-

P.S. I am leaving for a two week vacation tomorrow so I won't be able
to help to track this down at this time.

-- 

Eloy A. Paris
Information Technology Department
Rockwell Automation de Venezuela
Telephone: +58-2-9432311 Fax: +58-2-9431645