nmbd & netbios name -> many addreses

[Peter Polkinghorne]

First brief summary of problem:

Under Samba 1.9.18p10 with a server acting as a WINS server - any Samba 
servers that register which are multihomed get multiple addresses registered 
for their netbios names.  This in turn causes Nt 4.0 sp3 clients to receive 
multiple addresses which they are unhappy about - confirmed with nmblookup -R 
to the WINS server.  However resolving via DNS (dns proxy = yes) yields only 1 
address.

The Samba systems are running under Solaris 2.5.1

What I have done now is upgrade WINS server nmbd to 2.0.3 and a multihomed 
server nmbd as well (the smbd remain as 1.9.18p10).  The problem remains - 
multihomed servers registered via WINS yield multiple addresses to nmblookup 
and fail on NT 4.0 sp3 clients.

Here is a sample from the wins.dat file:

"KUDOS#00" 921670223 134.83.96.20 134.83.16.25 44R
"KUDOS#03" 921670223 134.83.96.20 134.83.16.25 44R
"KUDOS#20" 921670223 134.83.96.20 134.83.16.25 44R

Now what is the solution:

a) WINS clients (ie kudos in this case) only register 1 address

b) WINS servers only give out 1 address (perhaps using DNS like approach of 
giving same subnet as requester if exists)

c) NT clients accepting multiple address gracefully (the optimistic solution 
:-))

The other thing I have not been ale to test is what a multihomed NT box does - 
we do not have any.

Finally I am very surprised no one else has encountered this?



> On Sat, 6 Mar 1999, Peter Polkinghorne wrote:
> > > That is, that your Samba 1.9.18p10 server is acting as a WINS (NBNS)
> > > server and as the Domain Master Browser, right?  That rev of Samba 
> > > doesn't have the Domain Control functionality active, so I assume you're 
> > > using it as a DMB.
> > >
> > Yes - Domain Master Browser - too much of this terminology is getting the 
> > keywords in the right order :-(.
> >  
> > > 
> > > I don't recall any changes between 1.9.18 and 2.0 that would have fixed
> > > this, but I often miss these things.  The big change in nmbd (from my
> > > perspective) was that the namelists were converted from linked lists to
> > > splay trees, for speed.  Before 1.9.18 I didn't have my hands in, so I
> > > don't know what might have happened in between. 
> > >
[SNIP]
> uh... actually... that means... ok.  it's a bit complicated to explain in
> a short email, check against 2.0 and let the list know your findings:
> there may be a bug here.
>