NetBIOS types

[Christopher R. Hertel]

> > > http://support.microsoft.com/support/kb/articles/Q163/4/09.ASP
> > > Just for the "completenes" of the trhead, which also points 
> > to another
> > > useful article on __MSBROWSE__ et.al.
> > > perhaps a pointer to this info would be useful in the samba docs?
> > > Anders
> > 
> > 
> > And Microsoft says:
> > 
> > +The NetBIOS naming convention allows for 16 characters in a NetBIOS 
> > +name. Microsoft, however, limits NetBIOS names to 15 characters and 
> > +uses the 16th character as a NetBIOS suffix.
> > 
> > This is just plain wrong, because NetBIOS names have been 
> > this way since 
> > 1984, when the very first papers on the PC Network Program by 
> > IBM were 
> > released.
> 
> I guess Chris H might have a few comments here ? 

Absolutely.  ;)

I have seen various documents that talk about NetBIOS names, including
some old IBM docs and books which predate the document the one Richard
quotes.  Some IBM documents talk about using the 16th byte as a special
character.  Others do not.  The RFCs do not mention this at all, though
the RFC encoding scheme doesn't disallow it either.  So, to say it's "just
plain wrong" is likely a bit of an overstatement.  This is probably a
practice that evolved over time until it became "standard". 

Regarding the 0x1B and 0x1C names...  This is much more complicated than 
has been discussed.

0x1B names:

  The 0x1B name is *both* a Domain Master Browser name *and* a Primary
  Domain Controller name--from Microsoft's point of view.  Microsoft does
  not separate these services or allow a DMB to exist without a PDC.  The 
  ability to create a DMB without a PDC is a Samba enhancement (and a good
  one, too). 

  Forutnately, Microsoft doesn't use the 0x1B name to find the PDC.  
  Instead, they use a kludge on top of the already kludgy 0x1C name
  kludge.

0x1C names:

  These are group names.  Several Domain Controllers (one PDC and many 
  BDCs) can register the same 0x1C name.

  Unfortunately, group names are not stored correctly in the WINS server 
  (or in Samba's nmbd, since we copy MS behavior).  The RFCs state that 
  the NBNS (aka. WINS) should store a complete list of the IP addresses 
  for which a group name has been registered.  Instead, WINS stores the 
  limited broadcast address: 255.255.255.255.  This is useless and causes
  lots of trouble, as Microsoft eventually discovered.

  With Windows/NT (not sure if this appeared in 3.51 or 4) Microsoft 
  decided that 0x1C group names were "special".  For these "special" 
  names, they implemented something closer to RFC behavior.  Instead of
  storing all of the IPs associated with an 0x1C name, they store the 
  most recent 25 IPs.  If there are 25 IPs in the list, and another DC
  registers (or refreshes and isn't in the list), the bottom IP address
  (the oldest one) is pushed off the list to make room for the newer
  entry.  If the entry is already in the list then it is moved to the top.
  Basic queue management.

  ...except... The WINS server needs to do one more bizarre thing.  It 
  must also keep track of the matching 0x1B name (which is a unique name). 
  For example, for the group name "GOOBER<1C>" the WINS server must also 
  find the unique name "GOOBER<1B>".  The IP address of "GOOBER<1B>" will 
  also have a "GOOBER<1C>" entry, and that entry *must* be the first 
  entry in the list.

  ...and that is how the PDC is located.  The first entry in the IP list 
  for the 0x1C name is the IP of the PDC.

With NT, only 0x1C group names were "special".  W2K also allows for 
"special" group names with suffix byte values of 0x00, 0x20, and (I 
think) 0x03.

This is soooo ugly.

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