Registration Response packets to a Netbios Name Query

Sat Sep 8 07:43:02 GMT 2001

--- "Christopher R. Hertel" <crh at nts.umn.edu> wrote:
> > Samba folks,
> > I have a multihomed Samba server (2.2.1).  When it
> > recieves a Netbios Query, both NICs respond.  The
> > Windows 98 client sends a Registration Response to
> the
> > second NBT name query response saying "Name
> conflict".
> > Microsoft is telling me that Samba should release
> its
> > name associated with this address.  The NT4 Server
> > does not release its name in the same scenario. 
> > Looking at the code, I see that Samba is not setup
> for
> > "unsolicited" responses.  There would be no
> response
> > record for this packet, and indeed Samba is not
> able
> > to process it.  
> > I am wondering if a) Does what Microsoft says
> makes
> > sense?  anb b) Does anyone have any suggestions on
> how
> > to implement this?
> 
> I am just going over exactly this type of problem. 
> Multi-homed systems
> are a bit of a pain, as they were not covered in the
> RFCs at all. 
> Microsoft added a special OpCode to perform
> Multi-home name registration
> with a WINS server.
> 
> So... let's go over the details...
> 
> > I have a multihomed Samba server (2.2.1).  When it
> > recieves a Netbios Query, both NICs respond.
> 
> Hmmm...  I think I know why, and I think we could
> fix it, but it would
> require a lot of work.  I *think*:
> 
>   - ...that you are sending a broadcast query.  With
> an IP broadcast,
>     there is no way for a Unix system to know from
> which interface the
>     message was received.  Samba cannot easily tell
> where the broadcast
>     came from, so it responds on all ports. 

The WIN98 does send a broadcast query.  The query is
recieved over both NICs.  But since we are a
multihomed server, the name is actually registered on
both subnets.  What I mean is that a subnet record has
been created for both interfaces, and the server name
has been added to both subnets.  So I don't understand
how  Samba (even with extra code) would be expected to
NOT respond from both interfaces.

> 
>   - We could look at the source of the query and
> only respond with the
>     name as registered on that interface, and only
> to that interface.
> 
> > The Windows 98 client sends a Registration
> Response to the second NBT 
> > name query response saying "Name conflict". 
> Microsoft is telling me 
> > that Samba should release its name associated with
> this address.
> 
> Well, sort of.  If the name were really in conflict
> it should be marked 
> as "in conflict" and not used.  In this case,
> however, the name is not 
> really in conflict.

You mean marked as in conflict and not used by either
interface???  But again, we are multihomed......

> 
> The problem is that we are sending multiple query
> responses.  When we
> receive a standard name query (not a query sent to
> an NBNS) we should only
> respond on that interface with the name as
> registered on that interface.  
> By sending multiple replies, we create the illusion
> of multiple systems 
> claiming the same name.
> 
> The question is, how much trouble does this cause? 
> In theory, the W/9x 
> box will recieve the local LAN response first (in
> *theory*, that is).  If 
> it does, it will send the Name Conflict message to
> the other interface, 
> and Samba will ignore it.  The W/9x box will then
> talk to the interface 
> on the local subnet.  If magic happens and the
> non-local interface's 
> response gets to the W/9x box first, then the W/9x
> box will (generally) 
> wind up talking to the non-local interface.  This
> latter situation might 
> be a problem for browsing, but that's about it.

The trouble that we are seeing is that once every 3 to
4 times, the Win98 client does not do what its suppose
to do.  If we are doing nbtstats, it does not send a
unicast NBT name query to the "first" interface it
hears from, and when using Network Neighborhood, it
can't always find the server.
Microsoft started out saying they think this is a bug
with their code, but now they are coming back trying
to say that its Samba not doing something it should.

> 
> Still, it would be a bug in Samba and something that
> will want fixing.
> 
> > The NT4 Server does not release its name in the
> same scenario.
> 
> Does the NT4 Server also send multiple query
> replies?  Just curious.  It 
> shouldn't.

I have a setup with a multihomed NT4 server, and it
behaves EXACTLY like the Samba 2.2.1 code.  It send
two responses to the NBT name query and it does not
release any names after the name response.

But I'm using vmware.  We are going to recreate this
using real hardware tomorrow.

> 
> > Looking at the code, I see that Samba is not setup
> for
> > "unsolicited" responses.  There would be no
> response
> > record for this packet, and indeed Samba is not
> able
> > to process it.  
> 
> Which packet, the Name Conflict?
> "Unsolicited" responses are those for which no
> Transaction ID is still
> open. It's quite possible that we close the
> transaction after sending the
> query response.  To be pedantic, what we should do
> is wait <timeout>
> milliseconds to see if a Name Conflict arrives, but
> then we'd have to 
> deal with the Name Conflict.  It may not be
> worth-while to do so.
> 
> > I am wondering if a) Does what Microsoft says
> makes sense?
> 
> As described above, yes.  See RFC1001, Section
> 15.1.3.5.  That's where it
> is. 
> 
> > and b) Does anyone have any suggestions on how to
> implement this?
> 
> In Samba or in your own code?
> 
> The RFCs talk about a Conflict Timer.  Basically,
> after responding to a 
> query the node should keep the Transaction ID open
> for <Conflict Timer> 
> milliseconds to see if a Name Conflict message
> arrives.  If so, it should 
> mark the name as 'in conflict' and not use it again
> (existing connections 
> are unchanged).  The problem is, how do you inform
> the application that 
> is *using* the name that its name has been revoked,
> and how should it 
> handle the situation?  No one knows.
> 
> The other thing is that the Name Conflict should
> never happen.  This 
> particular conflict is happening because Samba is
> responding out of 
> multiple interfaces when it should only be
> responding out of one.
> 
> Hope that helps.

It does help, and thanks Chris.  I guess the big
mystery to me still is how does a multihomed server
suppose to work in a broadcast scenario.  With a Wins,
its easy, you register multihomed and its done.  But
in a broadcast, how do you register mulithomed??  The
NT4 does not send a list of ip addresses in its name
registration broadcasts.....  
> 
> Chris -)-----
> 
> -- 
> Christopher R. Hertel -)-----                  
> University of Minnesota
> crh at nts.umn.edu              Networking and
> Telecommunications Services
> 
>     Ideals are like stars; you will not succeed in
> touching them
>     with your hands...you choose them as your
> guides, and following
>     them you will reach your destiny.  --Carl
Schultz

=====
Julie Holloway
113 Trailing Oak
Cary, NC  27513
(919) 467 - 1470

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com