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