Registration Response packets to a Netbios Name Query

Christopher R. Hertel crh at nts.umn.edu
Thu Sep 6 08:50:20 GMT 2001


> 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. 

  - 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.

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.

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.

> 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.

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




More information about the samba-technical mailing list