Bug 498 - WINS server reports wrong address (ignores interfaces/bind interfaces)
WINS server reports wrong address (ignores interfaces/bind interfaces)
Status: RESOLVED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: nmbd
3.0.11
All Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-09-23 12:24 UTC by Joe Frisbie
Modified: 2009-07-02 05:17 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joe Frisbie 2003-09-23 12:24:14 UTC
On a linux machine with the following interfaces configured:




dev     address       netmask        broadcast


eth0    18.62.0.212   255.255.0.0    18.62.255.255 


eth0:0  10.36.70.103  255.255.255.0  10.36.70.255


eth0:1  10.36.70.10   255.255.255.0  10.36.70.255


eth0:2  10.36.70.20   255.255.255.0  10.36.70.255


eth0:3  10.36.70.30   255.255.255.0  10.36.70.255




And with an smb.conf of:




[global]


  ##Names


  workgroup = SENS


  server string = File Server


  netbios name = files-0




  ## Security


#  hosts allow = 10.36.70.


  encrypt passwords = yes


  security = user




  ## Nework


  socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192


  interfaces = 10.36.70.30/24 127.0.0.1


  bind interfaces only = yes




  ## WinDNS


  wins support = yes


  name resolve order = wins




[test]


  path = /tmp


  read only = no


  guest ok = yes






One would expect that 10.36.70.30 would be reported for address


of files-0. In fact, "nmblookup -R -U 10.36.70.30 files-0" yeilds:




added interface ip=10.36.70.30 bcast=10.36.70.255 nmask=255.255.255.0


added interface ip=127.0.0.1 bcast=127.255.255.255 nmask=255.0.0.0


querying files-0 on 10.36.70.30


Got a positive name query response from 10.36.70.30 ( 10.36.70.30 10.36.70.20 
10.36.70.10 10.36.70.103 18.62.0.212 )


10.36.70.30 files-0<00>


10.36.70.20 files-0<00>


10.36.70.10 files-0<00>


10.36.70.103 files-0<00>


18.62.0.212 files-0<00>




Although, 10.36.70.30 is listed first, it (almost?) never gets chosen. When


one of the other addresses is used, no connection can be made because 


smbd (?) is listening only on 10.36.70.30. This makes it effectively 


impossible to use the Samba WINS server functionality restricted to only


one network address.
Comment 1 Joe Frisbie 2003-09-24 05:24:49 UTC
Umm, deleting /var/cache/samba/wins.dat fixed the problem. I guess


this a cache that was stale. Perhaps a mention in the documentation


would help.
Comment 2 SATOH Fumiyasu 2004-02-24 01:51:39 UTC
Add Cc to track this bug.
Comment 3 SATOH Fumiyasu 2004-02-24 02:00:58 UTC
I can reproduce a similar problem. If the interfaces parameter has loopback
interface (interface name (e.g. "lo" on Linux), 127.0.0.1 or 127.0.0.1/8)
and another interface, nmbd registers a strange IP address.

smb.conf
--------
[global]
interfaces = 127.0.0.1/8 192.168.200.1/24

test command-line
-----------------
$ nmblookup -U 127.0.0.1 '*'
querying * on 127.0.0.1
192.168.200.1 *<00>
12.209.40.64 *<00>


Comment 4 Gerald (Jerry) Carter 2005-02-07 09:12:19 UTC
originally against 3.0.0rc4
Comment 5 jdppm7 2006-11-15 14:55:26 UTC
Here's why deleting the wins.dat file works in some instances:

The original smb.conf did NOT have the correct interfaces/bind interfaces only directives. SAMBA created the wins.dat file, including the entries for this server, its workgroup, etc. The directives were added but, upon restart, SAMBA did not do any sanity checks to make sure that its own entries in wins.dat were indeed correct.
Comment 6 SATOH Fumiyasu 2007-02-21 10:35:20 UTC
This bug can be reproducable with Samba 3.0.24 on Debian unstable (Linux kernel 2.6.18.5), but not on Solaris 10.
Comment 7 SATOH Fumiyasu 2007-11-19 19:27:21 UTC
I think this bug was fixed by:

http://gitweb.samba.org/?p=samba.git;a=commit;h=62a1c825b2cd702cc439c5f07fa36386b2260052

I've confirmed with Samba 3.0.24 + the above changes.
Comment 8 Matthias Dieter Wallnöfer 2009-07-02 05:17:19 UTC
If it seems that it has been fixed then mark it as "FIXED".