|
| |
|
NetBIOS Name Suffix Bytes
The table below classifies NetBIOS names according to their
base-names, the suffix byte, and their status as a unique or group
name. The list was gathered from sources scattered around the
Internet, old documentation, and hear-say. There are many references
out there, and a good deal of variation among them. As usual, what is
available is at times both contradictory and incomplete. As a result,
the information presented below should be viewed with suspicion. If
you have updates or comments which you can share freely, please send
them to [email protected].
|
...no warranty, expressed or implied...
-- relevant disclaimer
| |
|
| Name Format |
Suffix |
Group/Unique |
Service/Description |
|---|
|
machine
|
<00>
|
unique
|
Workstation Service
Known as the NetBIOS Computer Name or the Client
Service Name because it is typically sent as the
CALLING NAME (NBT source address) in NBT Session
requests. Some of the documentation indicates that the purpose of
the Workstation Service is to receive mailslot messages directed
at the node.
|
|
machine
|
<01>
|
unique
|
Messenger Service
Under some versions of Windows, this name is registered by
the Messenger Service and used as the CALLING NAME
(NBT source address) when creating an NBT session with the
Messenger Service on another node.
Not all implementations use this name as the
CALLING NAME when setting up a Messenger Service
session. Samba uses the machine<00> name, and
Windows2000 uses the machine<03> name.
|
|
machine
|
<03>
|
unique
|
Messenger Service
This name is registered by the Messenger Service, which
is used to exchange "WinPopup" messages. Like the Server
Service the Messenger Service speaks SMB protocol, but it uses a
different set of SMB messages and is a distinct service.
When creating an NBT session, the Messenger Service client
uses either the username<03> or
machine<03> name as the CALLED NAME
(NBT destination address) in the NBT SESSION REQUEST.
The choice, of course, depends upon whether the message is being
sent to a user or a node.
Some, but not all, implementations of the Messenger Service
client will also use the client's machine<03> name
as the CALLING NAME in the NBT SESSION
REQUEST.
See also machine<01> and
username<03>.
|
|
machine
|
<06>
|
unique
|
RAS Server Service
|
|
machine
|
<1F>
|
unique
|
NetDDE Service
|
|
machine
|
<20>
|
unique
|
File Server Service
This, of course, is the Server Service, which is the
primary recipient of SMB connections. SMB services may be offered
under any name, but this is the standard. Clients expect that the
Server Service name will have a suffix value of 0x20.
|
|
machine
|
<21>
|
unique
|
RAS Client Service
|
|
machine
|
<22>
|
unique
|
Microsoft Exchange
|
|
machine
|
<23>
|
unique
|
Microsoft Exchange
|
|
machine
|
<24>
|
unique
|
Microsoft Exchange
|
|
machine
|
<2B>
|
group
|
Lotus Notes Server Service
|
|
machine
|
<30>
|
unique
|
Modem Sharing Server Service
|
|
machine
|
<31>
|
unique
|
Modem Sharing Client Service
|
|
machine
|
<42>
|
unique
|
McAfee anti-virus.
Several sites list this suffix as being used by McAfee (or,
incorrectly, McCaffee) anti-virus software, but no further
documentation was found to support the claim. The information may
be out of date.
|
|
machine
|
<43>
|
unique
|
SMS Client Remote Control
|
|
machine
|
<44>
|
unique
|
SMS Administration Remote Control Tool
|
|
machine
|
<45>
|
unique
|
SMS Client Chat
|
|
machine
|
<46>
|
unique
|
SMS Client Remote Transfer
|
|
machine
|
<4C>
|
unique
|
DEC Pathworks TCP/IP Service for WindowsNT
|
|
machine
|
<52>
|
unique
|
DEC Pathworks TCP/IP Service for WindowsNT
|
|
machine
|
<6A>
|
unique
|
Microsoft Exchange
|
|
machine
|
<87>
|
unique
|
Microsoft Exchange
|
|
machine
|
<BE>
|
unique
|
Network Monitor Agent
Microsoft's Network Monitor (NetMon) is split into two pieces:
the "Agent", and the "Client Application".
The agent does the work of capturing packets, and the NetMon
client provides the user interface. The advantage of this
architecture is that agents and clients may run on separate
machines. A single NetMon client can, therefore, have access to
the capture services of multiple agents, scattered all around an
intranet (or, in theory, the Internet). Putting aside the obvious
security problems associated with having live capture agents on
networks, this can be a useful for testing and monitoring
purposes.
The Network Monitor Agent name is composed of the
machine name padded with the value 0xBE (rather than the
normal space padding) and ending with a suffix value of 0xBE.
Microsoft's nbtstat utility has a strange habit of
displaying this special padding character as a plus sign ('+').
|
|
machine
|
<BF>
|
unique
|
Network Monitor Client Application
The Network Monitor Client Application is the GUI front-end
that is used to control, filter, and display NetMon captures.
The Network Monitor Client name is composed of the
machine name padded with the value 0xBF (rather than the
normal space padding or the 0xBE value used by the agent) and
ending with a suffix value of 0xBF. Microsoft's nbtstat
utility still has a strange habit of displaying this special
padding character as a plus sign ('+').
The NetMon NetBIOS names may not be in use any longer. Newer
versions of NetMon (starting with 2.0?) appear to use a different
mechanism for communicating.
|
|
workgroup
|
<00>
|
group
|
LAN Manager Browse Service
This name is a remnant of an older Browse List distribution
mechanism. There are still references to the older system in
documents such as the Leach/Naik Internet Draft for Browsing
(draft-leach-cifs-browser-spec-00.txt), copies of which can be
found by searching the web.
|
workgroup
or
nt_domain
|
<1B>
|
unique
|
Domain Master Browser
This name identifies the Domain Master Browser (DMB).
A Samba server can behave as a DMB without also being a Primary
Domain Controller (PDC). The existence of a PDC promotes the
Workgroup to NT Domain status, in which case we write
nt_domain<1B> instead of workgroup<1B>.
If there is a PDC, it must provide the DMB service for the
NT Domain.
Domain Controllers (both Primary and Backup) register the
nt_domain<1C> Internet Group name. Registration of
the nt_domain<1B> name effectively distinguishes the
PDC from all of the other DCs in the domain. The NBNS will ensure
that the IP address of the (unique) <1B> name is the first
in the list of IP addresses
|
|
nt_domain
|
<1C>
|
Internet group
|
Domain Controller
Every domain controller in the NT Domain will register this
group name. The NBNS (WINS server) is expected to store all of
the IP addresses associated with the name, though it will report
at most 25 IP addresses in a NAME QUERY RESPONSE.
The first entry in the list should be the IP address of the
Primary Domain Controller (PDC). The rest of the IPs are
ordered most recent first. This is atypical handling for group
names under WINS. WINS (and, therefore, any NBNS which is
WINS-compatible) will usually report only the limited broadcast
address (255.255.255.255) when queried for a group name.
|
|
workgroup
|
<1D>
|
LAN unique
|
Local Master Browser
This name identifies the Local Master Browser (LMB, sometimes
called simply "Master Browser") for a subnet. WINS
servers (and any NBNS which is WINS-compatible) will accept
registration for <1D> unique names, but when queried will
always reply with a NEGATIVE NAME QUERY RESPONSE. As a
result, the LMB name is unique within its local subnet only.
|
|
workgroup
|
<1E>
|
group
|
Browser Election Service
Every node that is capable of acting as a browser registers
this group name so that it can listen for election announcements.
|
|
\x01\x02__MSBROWSE__\x02
|
<01>
|
group
|
Local Master Browser
This group name is registered by all Local Master Browsers
(LMBs). It allows LMBs on a local LAN to find one another in
order to exchange Browse Lists. This is how Browse Lists for
multiple Workgroups and/or NT Domains are combined.
|
|
username
|
<03>
|
unique
|
Messenger Service
This name is used in the same way as machine<03>
described above. A client opens an SMB connection to the
Messenger Service (just as would be done with the Server Service),
and uses SMB protocol to send the body of the message. The client
that displays these messages is known as "WinPopup", and
there are dozens of third-party implementations out there.
Some Microsoft documentation lists this name as a group name,
which would be nice. Unfortunately, in practice the name is a
unique name which means that a single user logged on to multiple
machines can only receive messages (sent to the username) on one
of those machines.
See also machine<01> and machine<03>.
|
|
internetgroup
|
<20>
|
Internet Group
|
User Defined
This name type was probably introduced with Windows2000.
Group names with a suffix byte value of 0x20 can be defined as
"Internet Group" names, which means that the NBNS must
report up to 25 IP addresses per name when queried. The 0x20
Internet Group names are used to identify groups of systems for
administrative purposes.
|
|
*
|
<00>
|
unspecified
|
Wildcard Name
The wildcard name is composed of an asterisk ('*')
followed by fifteen nuls (the last of which is the suffix byte).
This name is never registered, so it is neither a unique nor a
group name. The wildcard name may be used when sending NBT
NAME QUERY REQUEST and NODE STATUS REQUEST
messages.
|
|
*SMBSERVER
|
<20>
|
unspecified
|
File Server Service
This name is never registered (it begins with an asterisk and
is, therefore, an illegal name under NBT). Many implementations,
however, will accept it as a valid CALLED NAME in an NBT Session
Request message.
|
|
INet~Services
|
<1C>
|
[Internet] group
|
Internet Information Server
This name is registered by IIS servers, and handled as an
Internet Group name. Note that the name is in mixed UPPER/lower
case. It is, in fact, encoded that way, which is a little
awkward1.
|
|
IS~machine
|
<00>
|
unique
|
Internet Information Server
This name is formed by adding the prefix
"IS~" to the machine name, padding with nuls,
and using a suffix byte value of 0x00.
The handling of NetBIOS names by IIS is a little ...er...
unusual. Nul bytes are not supposed to be used as padding except
in the wildcard name. There is also a bug (verified in testing
against a set of Windows2000 systems running IIS) which causes the
suffix byte to be overwritten if the name is longer than 15
bytes2.
For example, adding "IS~" to the machine name
"AHOSETHIULLMAN" (13 bytes) would give
"IS~AHOSETHIULLMAN", which is 16 bytes long.
The correct thing to do is to truncate the string and register the
name "IS~AHOSETHIULLMA<00>". Instead, the
trailing 'N' in the machine name overwrites the suffix byte,
giving "IS~AHOSETHIULLMA<4E>". (The hex
value of 'N' is 0x4E.)
|
|
IRISMULTICAST
|
<2F>
|
group
|
Lotus Notes
|
|
IRISNAMESERVER
|
<33>
|
group
|
Lotus Notes
|
|
Forte_$ND800ZA
|
<20>
|
group
|
DCA IrmaLan Gateway Server Service
|
Special Handling of NetBIOS Names in WINS
The Windows Internet Name Service (WINS)
is Microsoft's implementation of the NetBIOS Name
Server (NBNS) described in the RFCs. WINS does not match the
RFC specifications, however, and its behavior is somewhat quirky.
Known quirks are listed below.
- Unique Names
Unique names are handled per the RFC specifications with two
exceptions: Multi-homed host names and the Domain Master Browser
name. Read on...
- Multi-homed Host Names
Multi-homed hosts register unique names by sending a special
MULTI-HOMED NAME REGISTRATION REQUEST packet to the NBNS.
The procedure is described in section 1.4.3.1.4 of this
book. WINS servers (and WINS-compatible NBNS implementations)
keep track of the list of IP addresses registered by a multi-homed
host, and will report up to 25 IP addresses when queried for the
multi-homed host name.
- Group Names
By default, in reply to a NAME QUERY REQUEST for a
group name, WINS will send the limited broadcast address:
255.255.255.255. This is clearly not what the RFC authors had in
mind.
- Internet Group, Special Group, and Domain Group Names
There are a few things to be said about these:
|
Thing 1:
|
The terms "Internet Group" and "Special Group"
are used interchangeably in much of the available documentation.
|
|
Thing 2:
|
Older references use the terms "Internet Group" and
"Special Group" when referring to group names with the
<1C> suffix. More recent sources add the term "Domain
Group" specifically for the nt_domain<1C>
names, and expand the use of the other terms to include groups
defined by adding a special static entry, with a suffix value of
<20>, to the WINS database3.
|
|
Thing 3:
|
Internet (aka. Special) and Domain Groups are defined by using
the #SG and #DOM keywords in the
LMHOSTS file, or via WINS configuration dialogs on
Windows systems.
|
As with multi-homed host entries, the WINS server should keep
track of as many IP addresses per name as it can handle. When
queried, the POSITIVE NAME QUERY RESPONSE should list at
most 25 IP addresses per Internet Group name.
- Local Master Browser
The LMB registers the workgroup<1D> unique name.
A WINS server will accept all such registrations, ignoring any
conflicts, and will reply with a NEGATIVE NAME QUERY
RESPONSE when queried for the name. This behavior forces M
and H nodes to search for the LMB on the local IP subnet. If
there is no LMB for the Workgroup on the local subnet, then the
client that sent the request may call for a browser election. P
nodes cannot talk to Local Master Browsers, so they communicate
directly with the Domain Master Browser (if there is one).
- Domain Master Browser
The DMB registers the unique nt_domain<1B> name.
The WINS server will ensure that the IP address associated with
the nt_domain<1B> name is always the first in the
list of IPs associated with the nt_domain<1C> Domain
Group name.
|
![<Previous]](images/prev.gif)
![[Contents]](images/contents.gif)
![[W3C Validated]](images/vh401.gif)
Copyright © 2002 Christopher R. Hertel