Registration Response packets to a Netbios Name Query

Sat Sep 8 11:38:02 GMT 2001

[Another long reply, but I'm working all of this out in
my own head so writing it out is useful.]

Julie Holloway wrote:
:
> 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.

Quick question...something I don't understand here...
Are both NICs (and their respective subnets) on the same
physical (or virtual) wire?  Just trying to get a clear
picture in my head.

Anyway, what I *think* would happen is this (understand
that this is theory, as I do not have a config like this
to test--your empirical evidence has much more weight):

- Samba receives only one copy of the query.  There is
  only one situation in which this would not be true:
    + If both NICs were on the same wire and
    + the query were sent to the 255.255.255.255 address
      rather than the subnet broadcast address,
    then you could see two copies of the query, one on
    each NIC.

  In any other situation, the packet should only arrive
  via one interface.  (If they share the wire, both NICs
  might see the packet, but the interface software would
  only accept the packet on the matching subnet.)

- The name is, as you say, registered on both subnets.
  In a broadcast environment, each registration should
  be considered separate, as each broadcast domain is a
  separate "scope", meaning a separate NetBIOS vLAN.

- Samba gets the query (we'll assume one copy) and
  replies.  We *should* only reply once but (from your
  report) we may reply multiple times, once per
  registration.  Those replies are sent as Unicast UDP
  datagrams to the client.

  Samba rides above the TCP/IP protocol stack.  We send
  and receive message via the kernel mechanisms so all
  of the via the routing table, which will send the
  Unicast replies via whichever NIC is listed as the
  route to the client.

  You wrote:
  > So I don't understand how  Samba (even with extra
  > code) would be expected to NOT respond from both
  > interfaces.

  It may be a pronoun problem.  Samba might repsond
  *for* each interface, but not *from* each interface.
  The only way to be sure is to look at a packet trace.
:
> > 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 first response would be accepted by the client.  Any
further responses would cause the client to send the Name
Conflict message.  From the client's point of view it is
getting replies from multiple hosts, so it would tell the
second, third, etc. host that the name is in conflict.

This is where things get a little wierd, though...

In response to a broadcast query, Samba should only be
sending one reply.  I do not know if that reply would
list all of the IPs to which the name is registered.  I
think we should be able to send just the one reply with
just the one relevant IP address.  If we are sending
multiple replies then I'd need to know why.  Most of all,
I need to see what this looks like on the wire to really
get it figured out.  As you can see from all the
theorizing I'm doing there's just too much wild guessing
without actuall packets to look at.

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

Windows caches name query responses (nbtstat -c, I
think).  It may be that this is an artifact of a cached
mapping.

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

I have no idea if we are or are not.  Handling of
multi-homed hosts is annoying at best.  Again, I'd want
to see what's on the wire.

> I have a setup with a multihomed NT4 server, and it
> behaves EXACTLY like the Samba 2.2.1 code.  It sends
> 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.

I'd be interested in seeing the results.  It is possible
that the vmware virtual hub is showing you the packets
twice...  I usually have good results with vmware, but
it's always good to remove any unneeded variables.

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

Well, the workings of Multi-homed in WINS is also a bit
wierd...

Anyway, the way I understand multi-homed hosts in the
broadcast environment is that each connection is viewed
as a separate NBT scope.  The right way to respond to a
query would be to send a single response which should
contain only the IP address of the receiving interface.
That should be possible.  If we're not doing that (and
particularly if Windows does do that) then I want to know
about it.  :)

Thanks.  This is interesting!

Chris -)-----

-- 
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org