Group Name Query: Summary

[Christopher R. Hertel]

The thread on Microsoft's CIFS list has piddled out, so I thought I would 
summarize...

When a client sends a NetBIOS Name Query to a NBNS server (eg., WINS) the 
server sends a reply containing a single IP address: 255.255.255.255.

- This is not to spec.  Several people thought that this response was 
  documented in the RFCs, but it's not.  Paul Leach commented "I believe
  1001/1002 in general to be overspecified."  (His message is really quite
  clever & funny.  Worth reading the thread if only for this.)

- Microsoft supports two different reply formats in this case.  In 
  general, the response packet will list only 255.255.255.255.  If, 
  however, the name is of type 0x1C then WINS will respond with as
  described in the RFCs.  Note, though, that WINS restricts the number of 
  group name entries that it stores so that it will never exceed the UDP
  packet size in a response.  This ensures that it will not have to open
  a TCP connection to complete the query. 

  Though MS have reduced complexity by avoiding the TCP connection 
  described in the RFCs they've also added complexity by requiring two
  different behaviors and by restricting the number of entries per group.

- Samba, of course, follows suit (though I have not checked to see that 
  Samba limits the group name entries--I think it does).

According to 1001/1002 the NBNS server should respond with an array of
IPs, one for each registered group member.  Further, if the array is too
large for a UDP packet, the response should have the Truncation bit set. 
The client, then, has the option of repeating the query via TCP.  Yes,
really. 

The purpose of all this is to allow a client to get a list of the members
of a group.  I would have to agree with Paul, though, that it's a bit
awkward and probably not necessary.  On a "real" NetBIOS LAN, there would
be no such mechanism.  Instead, one would broadcast a name query and all
owners would reply.  On a NetBIOS LAN emulated over IP, the equivalent 
operation would involve both a broadcast *and* a name query sent via the 
Datagram service.

The Datagram service is a sigificant part of the NetBIOS LAN emulation
scheme defined by the RFCs.  You *can not* perform NetBIOS Multicast
operations over a routed IP network without this service.  (Well I suppose
you could send directed broadcasts to each subnet served by the NBNS
server--assuming you can generate *that* list and that directed broadcasts
are allowed by the routers.)

The Datagram service is supposed to recieve messages which are then
forwarded to all owners of that name.  That, of course, requires that the
Datagram service is able to get a list of all registered owners of a group
name from the NBNS server.  Typically, this is done by combining the
Datagram server with the NBNS server (eg., Samba's nmbd).

Problem:  If the number of group entries stored by the NBNS server is
limted to the number that will fit in a UDP packet then, once again,
NetBIOS multicast over IP is broken.  The solution is to store the group
name entries in a stack.  Those with the longest TTL would be at the top. 
If a group name query arrives for a type 0x1C name, take the reply list
from the top. 

Chris -)-----

-- 
             -- I have a shoehorn, the kind with teeth. --
                                  ---
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services