[jcifs] 0x1B names.

[Christopher R. Hertel]

James Nord wrote:
:
> >...or so I'm told.  I'd like to see this in a capture, if anyone has
> > one.
> >
> We have a MS Wins Server (NT 4), so I can capture one.
> 
> How would I stimulate one to be captured??

Grin.

I am looking for the output from Ethereal, TCPdump, or NetMon.  These are
packet capture programs that you can run to "see" the communications
across your network.  Vital tools for working on CIFS.

Anyway, on a network that has one or more Domains (meaning one or more
Primary Domain Controlers) I would like to see a packet capture that shows
interaction with the NT WINS server.  Here's what I am looking for:

  In various documentation, I have seen references that suggest that WINS
  behaves 'differently' when handling NetBIOS names with a suffix value
  of 0x1B.  The 0x1B suffix is registered by the Domain Master Browser,
  and takes the form:  <domain>#1B.  That is, if the NT Domain name is
  VELCROW, the full NetBIOS name would be (in C terms):

     "VELCROW        \x1b"

  Anyway, if I understand correctly, the WINS server will collect these
  names and do two odd things with them.

  1) The WINS name server itself typically ignores wildcard queries (which
     are defined in RFC1001/1002).  A node (even the node that the WINS
     server runs on) should answer these if it is running NBT.  (NetBIOS
     over TCP/IP Transport).  In theory, a node can be a WINS server
     without being a file server or a client.

     The wierd thing is that WINS *will* respond to a *special* wildcard
     query for the name "*              \x1b".

     What I don't know is what the query name actually looks like.  In a
     standard wildcard query the entire 15 bytes following the "*" is
     filled with nuls (0x00).  I don't know if the 0x1B wildcard query is
     padded with nuls or with spaces (spaces are the standard padding
     character).

     I'm also not sure what the reply looks like (though I have a good
     guess).  So, I'd like to see a packet capture of a "*<1B>" query
     exchnage.

  2) The other wierd thing that WINS does with 0x1B names is that it
     looks for matching 0x1C group names.  0x1C names are registered by
     all Domain Controllers in a network--both primary and backup DCs.
     WINS keeps a list of all of the IPs (well, up to 25 IPs) associated
     with a given 0x1C name.  These names are "group" names and are also
     handled a bit oddly...but that's another long story.

     Anyway, WINS always makes sure that the IP associated with the 0x1B
     name is always the *first* entry in the list of IPs associated with
     the 0x1C name.  So, if:

         VELCROW<1B> maps to 10.1.2.3

     and if

         10.1.1.1, 10.2.3.178, and 10.1.2.3 have all registered the group
         name VELCROW<1C>

     then the IP list for VELCROW<1C> might look like this:

         10.1.2.3      <<--- Always first
         10.1.1.1
         10.2.3.178

     On an NT system, the Domain Master Browser is always the *same* node
     as the Primary Domain Controller, so the 0x1B name represents both
     the PDC and the DMB.  The 0x1C name is a list of DCs for the given
     NT Domain, and the PDC is always listed first.

If that didn't make any sense, don't worry about it.  It *doesn't*
actually make any sense.  It's just the way Microsoft did it.

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