[jcifs] 0x1B names.
Christopher R. Hertel
crh at ubiqx.mn.org
Mon Jul 30 13:20:11 EST 2001
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??
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):
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
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
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
10.1.1.1, 10.2.3.178, and 10.1.2.3 have all registered the group
then the IP list for VELCROW<1C> might look like this:
10.1.2.3 <<--- Always first
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.
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
More information about the jcifs