In 1983, IBM's (and Sytek's) design goal of Network Basic Input/Output System (NetBIOS),
was to build a small and fast protocol that would allow for human-assigned names of devices,
such as 'MyComputer', that are easier to remember than a complex numbering scheme. NetBIOS is effectively IBMs
API for PCs to access LAN facilities. The size of network at the time was no more than 72 devices on broadband access.
Implementations of NetBIOS vary as there are no standards, however this document aspires to provide a framework
which can be used to place the various elements of the NetBIOS 'suite'.
The NetBIOS protocol stack could be represented by the following schematic:
NetBIOS Extended User Interface (NetBEUI)
NetBIOS, being effectively an interface rather than a protocol,
requires a network protocol to carry its sessions across a network. Traditionally, this need has been met
with NetBEUI. NetBEUI was designed by IBM in 1985 as the network protocol which completes the requirements to transport NetBIOS
using IBMs LAN Manager server. The invention of NetBEUI was prompted by the introduction of Token Ring in 1985 which could
accommodate up to 260 devices on one ring.
NetBEUI is NetBIOS operating over a LAN without a layer 3 carrier protocol.
It is, as it's name suggests, an extension of the NetBIOS API. NetBEUI uses OSI Layer 2 802.2 LLC2, which the Data Link
Layer connection-oriented protocol used for SNA traffic as well. NetBEUI is very fast but also very
bandwidth hungry since stations seeking each other broadcast their requests very frequently. NetBEUI has traditionally
been the default configuration for SMB devices because it is very easy to set up, however it is not scalable
because NetBEUI cannot be routed, being only an LLC2 protocol, it can only be bridged.
The version of NetBEUI that comes with modern Windows packages is version 3.0 (or 4.0) which is not strictly NetBEUI but rather
NetBIOS Frame Format (NBF) protocol which interfaces with Windows Transport Driver Interface (TDI) at the bottom
end and NetBIOS at the top end. NetBEUI 3.0/4.0 is backwardly compatible with older versions of NetBEUI.
NBF is more consistent than the older NetBIOS versions with regards to frame formats.
Nowadays, the Transport protocol used for NetBIOS is IP, or occasionally
IPX. Applications such as SAMBA actually require NetBIOS to run over IP although some versions of SAMBA can
run over IPX.
NetBIOS uses LLC Type 1 (Datagram services) and LLC Type 2 (Session services)
on a LAN. The following diagram illustrates the NetBIOS header (NBF) in LLC
where the Destination and Source SAP is F0.
The fields are described as follows:
- Length - a 2 byte field containing the NetBIOS frame length, normally 0x002C.
- Deliminator - a 2 byte field containing the value 0xEFFF.
- Command - a 1 byte field containing the command value (see below for the particular command values).
- Data1 - a 1 byte field used only by certain frames such as ADD_NAME_RESPONSE (see later).
- Data2 - a 2 byte field used only by certain frames such as NAME_QUERY and NAME_RECOGNISED (see later).
- Transmit Correlator - a 2 byte field used by certain response frames to correlate the response frame
with the query using a value returned in the response.
- Response Correlator - another 2 byte field used by certain frames to correlate the response frame
which has a value in the Transmit Correlator field.
- Destination Name - this ID is the destination NetBIOS name (or number).
- Source Name - this ID is the Source NetBIOS name (or number).
- Data - information passed by the user to NetBIOS.
Network Control Blocks (NCB)
All program commands are presented to NetBIOS in a format called Network Control Blocks (NCB).
These blocks are allocated in memory by the user program. NetBIOS supports Connection-oriented
(Virtual Circuit) communication and Connectionless communication using broadcasts and multicasts.
NetBIOS interfaces with the upper layer application via an interrupt (0x5C) which is called pointing to
a 64-byte data structure which is the NCB. The NCB sits in every NetBIOS frame after the
Source Name, however it cannot be decoded by an analyser.
The NCB has the following structure:
- Return Code - completion code for asynchronous command, or initiation code for an asynchronous command.
- Local Session - session number for the command
- Name Number - a unique number for the name being used
- Buffer Address - the address of the buffer for transmit and receive commands
- Buffer Length
- Call Name - the name of the other station that you are contacting, or from which you have received contact
- Name - the local name
- Receive Timeout (RTO) - the timeout for Receive commands (in 500ms)
- Send Timeout (STO) - the timeout for Send commands (in 500ms)
- POST address - the address of the POST routine which is called when asynchronous commands have completed
- LAN_A_Number - used to identify an adapter when there is more than one network adapter in a station
- Command Complete - completion code for aynchronous commands
- Reserved - reserved byte
NetBIOS supports the following services:
- Naming Service using Name Management Protocol (NMP), Names are necessary for identification and
can be specific to the node (Unique Name) or for a group of nodes (Group Name) and can be changed.
- Session Services using Session Management Protocol (SMP), provides a connection-oriented, reliable,
full-duplex message service to user process.
- Datagram Services using User Datagram Protocol (UDP), Datagrams can be sent to a specific name,
sent to all members of a group, or broadcast to the entire LAN.
- Diagnostic Services using Diagnostic and Monitoring Protocol (DMP) provides the ability to query the status of nodes on the network
(akin to IPs SNMP).
Sessions can occur between any NetBIOS nodes on a network, there is no hierarchy, NetBIOS is Peer-to-peer.
A NetBIOS name can contain up to 16 alphanumeric characters where the last character is often used to identify the application.
Each name must be unique within the network.
Before an application or device can use a name it must first be registered. For this registration process there are the following
frames using the format described above:
- ADD_NAME_QUERY - this command has a value of 0x01 and is used to add a unique name to the network.
- ADD_GROUP_QUERY - this command has a value of 0x00 and is used to add a group name to the network.
Any number of applications/devices can have this group name, the only check made is that it does not conflict
with an existing Unique name. Both this command and the previous one can be repeated a number of times (depending
on manufacturer) to make sure that every station receives it.
- ADD_NAME_RESPONSE - this command has a value of 0x0D and is sent by a station as a response
to the previous queries if the name is already being used. The 'Data1' field can have the following values
The 'Data2' field can have the following values:
- 0 - add name not in process
- 1 - add name in process
- 0 - Unique name
- 1 - Group name
- NAME_IN_CONFLICT - this command has a value of 0x02 and is sent if more than one station has the same Unique name
or there is a conflict between a Unique name and a Group name. The user receiving this message is not allowed to join the network.
The Source name is the special name of NAME NUMBER 1.
In order for Name Discovery to take place i.e. for the network adapter on the sending computer to find the network
adapter on the receiving adapter, for this there is a FIND_NAME command. In order to delete a name (i.e. opposite
of name registration) there is a DELETE_NAME command.
The status of remote and local nodes on a network can be found using the Diagnostic and Monitoring Protocol
(DMP). This information contains the number of Reject frames transmitted and received, the number
of aborted transmissions and the number of Logical Linl Control Protocol Data Units (LPDU) received
DMP has frames using the format described above:
- STATUS_QUERY - this command has a value of 0x03 and is used to obtain information on the remote
adapter. The Data1 octet is used to indicate the status of the request, 0x0 indicates a 1.x or 2.0 type request,
0x01 indicates a NetBIOS 2.1 request and values greater than 1 indicate a NetBIOS 2.1 request.
The two bytes of the Data2 field are used to indicate the length of the user's status buffer.
In the name fields Sixteen octets identifying the name of the receiver are followed by sixteen octets indicating
the sending node's NAME_NUMBER_1
- STATUS_RESPONSE - this command has a value of 0x0F and is used as a response to a request for
status frame. The Data1 octet is used to indicate the status of the response, 0x0 indicates a 1.x or 2.0
type response, and values greater than 0x0 indicate a NetBIOS 2.1 response. The two octets of the Data2 field
are regarded as a 16 bit string; the first bit is set to 1 if the length of the status data exceeds the frame
size; the second bit is set to 1 if the length exceeds the size of the user's buffer; the remaining 14 bits
indicate the length of the status data sent. Sixteen octets indicate the receiving node's NAME_NUMBER_1 and are
followed by a further sixteen octets indicating the sending node's name.
- TERMINATE_TRACE - this command has a value of 0x07 and is used to end a trace at a remote node.
- TERMINATE_LOCAL&REMOTE_TRACE - this command has a value of 0x13 and is used to end a trace
at the local and remote node.
NetBIOS User Datagram Protocol (UDP) is equivalent to IP in that it is used to transfer data from device to device
but NOT to carry upper layer protocols (as in IP/UDP). Datagrams are used when a response is not required
(as opposed to the Session service). Datagrams can be sent to just one application, to a Group of NetBIOS
applications, or to all applications.
NetBIOS datagrams are connectionless and unreliable and can only manage messages up to 512 bytes in length. The
Send_Datagram command requires the caller to specify the name of the destination.
If the destination application is a Unique name, then only that application can receive the datagram. If the destination is a group name, then
every member of the group can receive the datagram. The caller of the Receive_Datagram command must specify the local name for
which it wants to receive datagrams. The Receive_Datagram command also returns the name of the sender, in addition to the actual
datagram data. If NetBIOS receives a datagram, but there are no Receive_Datagram commands pending, then the datagram is discarded
i.e. the receiving application MUST first issue a Receive_Datagram command otherwise it will not be able to receive datagrams.
Similarly, the Send_Broadcast_Datagram command sends the message to every NetBIOS system on the local network. When a broadcast
datagram is received by a NetBIOS node, every process that has previously issued a Receive_Broadcast_Datagram command receives
the datagram. If none of these commands are outstanding when the broadcast datagram is received, the datagram is discarded
The following commands are used for UDP using the frame format described earlier:
- DATAGRAM - this command has a value of 0x08 and is used to send a datagram to a name. The Data and Correlation fields
- DATAGRAM_BROADCAST - this command has a value of 0x09 and is used to send a datagram to all names.
The Data and Correlation fields are unused.
Once legal names have been established
a Session occurs between two NetBIOS names (devices or applications). The Session service establishes and maintains the sessions
where session maintenance includes error-detection and control. Each session is numbered
and each frame must be acknowledged within a specified timeout so
there can be more that one session between one name and another.
NetBIOS session establishment requires cooperation between the two stations. One application
must have already issued a Listen command when another application issues a Call command. The Listen command references a name in
its NetBIOS name table, and also the remote name an application must use to qualify as a session partner. If the receiver
is not already listening, the Call will be unsuccessful. If the call is successful, each application receives
notification of session establishment with the session-id. The Send and Receive commands then transfer data. At the end
of a session, either application can issue a Hang-Up command. Messages up to 64KB can be sent.
Establishing a Session occurs in the following manner:
- The sending station sends a NAME_QUERY as a Spanning Tree Explorer (STE).
- The frame gathers RIF data as it traverses the network. In a Source-Routed Spanning Tree network
only one copy of the frame arrives at the destination, otherwise multiple copies arrive at the destination.
- If the NetBIOS interface recognises that one of its own applications is being requested then it
sends back a broadcast NAME_RECOGNIZED All Routes Explorer (ARE).
- The returning AREs gather RIF information on their way back to the originating station.
- The originating station receives multiple copies of the NAME_RECOGNIZED frame.
- The first NAME_RECOGNIZED frame received by the orginating station is taken and the RIF used
for the following Specifically Routed Frames (SRF) frames to the destination station.
- At this point a session is begun between the two stations and there is no need for NetBIOS names from now on.
The following details the two commands just discussed and uses the same NetBIOS frame format described earlier:
- NAME_QUERY - this command has a value of 0x0A.
The Data2 field is set to 'ttss' where 'tt' indicates the type of name being called,
00 for a Unique name and 01 for a Group name; 'ss' is used to indicate the session number
- NAME_RECOGNIZED - this command has a value of 0x0E.
The Data2 field is set to 'ttss' where 'tt'
indicates the type of name being called, 00 for a Unique name and 01 for a Group name; 'ss' is used to indicate the state
of the name: 0x00 is used when the station is not listening for this name, 0xFF is used when the station is listening for this name,
but can not establish a session, and 0x01 to 0xFE are used as a number which will identify this particular session.
Other Session services frames have a slightly different structure to the previous ones discussed. These frames have the following
The differences are that instead of the NetBIOS name fields for the Destination and Source frames, there are Destination Session (Remote)
and Source (Local) Session numbers since the names are no longer required once the Name Query has been successful, as discussed above.
This makes the NetBIOS frame shorter as the Session Number fields are now just one byte instead of the NetBIOS name fields
which were 16 bytes fields. The Length field therefore now has a value of 0x000E.
The following Session Services frames use this format:
- SESSION_ALIVE - this command has a value of 0x1F and is sent when an inactivity timer expires.
- SESSION_CONFIRM - this command has a value of 0x17 and is used to ask for the status
of the remote adapter. The Data1 octet is an 8 bit binary string; the first bit is set to 0 for versions of NetBIOS prior to
version 2.20 and set to 1 for higher versions. The next 6 bits are always set to 0,
the last bit is set to 0 for NetBIOS version 1.xx and
set to 1 for version 2.00 or above (Nowadays this is always 1). The two bytes of the Data2 field are used to
indicate the length of the user's receive buffer.
- SESSION_END - this command has a value of 0x18 and is again used to gain information about the remote adapter.
The two bytes of the Data2 field are used to indicate the reason for the termination where 0x00 indicates a normal session end,
and 0x01 indicates an abnormal end.
- SESSION_INITIALISE - this command has a value of 0x19 and is again used to gain information about the remote adapter.
The Data1 field is an 8 bit binary string; the first bit is set to 0 for versions of NetBIOS prior to version 2.20 and to 1 for
higher versions (Nowadays always 1). Three reserved bits that are always set to 0 are followed by 3 bits
used to indicate the largest frame value as seen by the MAC layer; the last bit is set to 0 for NetBIOS version 1.xx and set to 1 for
version 2.00 or above. The two octets of the Data2 field are used to indicate the length of the user's receive buffer.
- DATA_FIRST_MIDDLE - this command has a value of 0x15 and is used to transmit user messages across a session.
The Data1 octet is an 8 bit binary string; the first four bits are reserved; the fifth bit is set to 1 if an
acknowledgement is included; this is followed by a reserved bit; the seventh bit is set to 0 for versions of NetBIOS
prior to version 2.20 and set to 1 for later versions (nowadays always 1); the last bit is
set to 0 if a RECEIVE_CONTINUE was not requested, otherwise it is set to 1. Data2 is a
re-synchronisation indicator set to 0001 if it is the first DATA_FIRST_MIDDLE frame.
- DATA_ONLY_LAST - this command has a value of 0x16 and is used to transmit user messages across a session. It is
either the last frame in a sequence, or the only frame.
The Data1 octet is an 8 bit binary string; the first four bits are reserved; the fifth bit is set to 1 if an acknowledgement
is included; this is followed by the sixth bit which indicates that an 'Acknowledge With Data Allowed' is permitted; the
seventh bit is a 'no acknowledgement' indicator and the final bit is reserved. Data2 is a re-synchronisation
indicator set to 0001 if this frame is send following receipt of a RECEIVE_OUTSTANDING.
- DATA_ACK - this command has a value of 0x14 and is sent as a response to a DATA_ONLY_LAST frame.
- NO_RECEIVE - this command has a value of 0x1A and is sent in reply to DATA_ONLY_LAST frame or a DATA_FIRST_MIDDLE frame.
The Data1 octet is an 8 bit binary string; the first six bits are reserved; the seventh bit is set to 0 for versions of
NetBIOS prior to 2.20, otherwise it is set to 1 (nowadays always 1); the eighth bit is reserved.
Data2 gives the number of data bytes accepted.
- RECEIVE_OUTSTANDING - this command has a value of 0x1B and is sent in response to a NO_RECEIVE frame.
Data2 and gives the number of data bytes accepted.
- RECEIVE_CONTINUE - this command has a value of 0x1C and is sent in response to
DATA_ONLY_LAST frame which had the RECEIVE_CONTINUE bit set.
Server Message Blocks (SMB)
Windows networking uses an Application level protocol called the Server Message Blocks (SMB) protocol
(more recently re-labelled Common Internet File System (CIFS)
and is being proposed as an Internet standard by Microsoft and others).
SMB allows computers to control sessions i.e. share files, disks, COM ports, printers etc.
and is analagous to AppleTalk's Session Protocol or Filing Protocol or IPX's Netware Core Protocol.
These devices that use SMB are mainly Windows computers such as NT, Win95, Win98, Win2000 etc., however other computers
such as OS/2 LAN Server (Warp Connect - 1988), DOS stations using LAN Manager
(Microsoft - 1988) and Unix stations running SAMBA can also talk using SMB.
SMBs are the messages that LAN Manager clients and servers use to communicate with each other.
SMB clients and servers expect to see NetBIOS as the vehicle for carrying the SMB packets. NetBIOS was
designed by IBM and can run over NetBEUI (NBF), SNA, DECnet, IP (NBT) or IPX.
There are different versions of SMB called dialects and these include:
- Core Protocol - PC Networks 1.0
- Core Protocol plus Dialect - Microsoft Networks 1.03
- Extended Procotol - Microsoft networks 3.0
SMB uses 16-byte names which generally map to the NetBIOS names. Unique NetBIOS names map to SMB individual
system names whilst NetBIOS Group names map to Windows Workgroup or Domain names.
SMB frames use a NetBIOS DATAGRAM frame (command value of 0x08), DATAGRAM_BROADCAST frame (0x09),
the DATA_FIRST_MIDDLE frame (0x15) and the DATA_ONLY_LAST frame (0x16).
SMB Frame Format
The fields are as follows:
- Deliminator - has a value of 0xFF
- Identifier - the value of 0x53424D stands for SMB
- Command - see below for a list of SMB commands
- Error Class - common Error Classes include SUCCESS (0x00) and ERRSRV (0x02) for error.
- Error Code - codes returned for the Error Classes e.g. for the SUCCESS Error Class possible Error
and for the ERRSRV Error Class, possible Error Codes include:
- BUFFERED (0x54) - The Message was buffered
- LOGGED (0x55) - The Message was logged
- DISPLAYED (0x56) - The Message was displayed
- ERRerror (0x01) - Non-specific error code
- ERRbadpw (0x02) - Bad password
- ERRbadtype (0x03) - Reserved
- Flags 2
- Tree ID - Authenticated Resource Identifier
- Process ID - the Caller's Process Identifier
- Unauthenticated User ID
- Multiplex ID
- 16-bit Field Count - the number of 16-bit fields in the data
- 16-bit Byte Count - the numeber of bytes in the 16-bit fields
- 8-bit Field Count - the number of 8-bit fields in the data
- 8-bit Byte Count - the numeber of bytes in the 8-bit fields
The following table lists a number of SMB commands that you could see in the Command field:
|Commit all files
|Get file attribute
|Set file attribute
|Read byte block
|Write byte block
|Lock byte block
|Unlock byte block
|Create new file
|End of process
|Get disk attributes
|Search multiple files
|Create spool file
|Spool byte block
|Close spool file
|Return print queue
|Forward user name
|Get machine name
|Start multi-block message
|End multi-block message
|Multi-block message text
|Core plus commands
|Lock then read data
|Write then unlock data
|Read block raw
|Write block raw
|LANMAN 1.0 SMB commands
|Read block multiplexed
|Read block (secondary response)
|Write block multiplexed
|Write block (secondary response)
|Write complete response
|Set file attributes expanded
|Get file attributes expanded
|Lock/unlock byte ranges and X
|Transaction (name, bytes in/out)
|Transaction (secondary request/response)
|Passes the IOCTL to the server
|IOCTL (secondary request/response)
|Write and Close
|Open and X
|Read and X
|Write and X
|Session Set Up and X (including User Logon)
|Tree connect and X
The Browser Service is used to make systems available in the Network Neighbourhood Window in Windows environments
although it is also designed to operate with LAN Manager and OS/2.
The Browser Service registers SMB (NetBIOS) names dynamically and makes this dynamic list available to systems on the
network. The Browser Service runs over SMB (and is described as running over a 'mail slot' protocol over SMB).
The Browser Service is not be confused with an NBNS service such as WINS, they are two entirely separate services.
The Browser Service is more akin to IPX SAP or perhaps even Novell's Directory Service (NDS). The Browser
Service is there to ease the access to the Peer-to-Peer network that is characteristic of a Windows network.
The Browser service had it's history begin with LAN Manager 1.0 as a broadcasting system before
progressed into the Browser Service that we know now, without the broadcasting, with Windows for Workgroups.
The Browser service has matured in the NT environment to include Domains.
The latest incarnation is called the CIFS/E Browser Protocol.
The Servers are organised in logical groups according to which
group they belong to; these can be Workgroups or Domains and correspond to SMB / NetBIOS group names.
The Computer Browser Service is the way in which Windows displays a list of the resources available. This Browser list is maintained
centrally by a specific computer assigned to the task, this saves all computers having to compile the list and saves on network
bandwidth. The browser service can operate on any layer 3 protocol.
The roles of the computers are:
- Domain Master Browser - this is the PDC and distributes the master list to the master browsers on each subnet in a domain.
It is also the Master Browser for the subnet that it is on.
- Master Browser - collects the list of resources, shares it with the Domain Master Browser and the Backup Browser.
- Backup Browser - receives the browse list from the Master Browser and distributes the list to the Browser Clients when requested.
The Backup Browser periodically queries the Master Browser for the browse list.
- Potential Browser - could become a browser at a browser election but is not at the moment.
- Non-Browser - configured (using the registry) not to maintain a browse list nor ever to take part in a browser election.
Master Browsers talk to one another under TCP/IP and can be an NT Workstation.
The Browser Service operates thus:
- Computers running the server service announce (register) themselves to the Master Browser.
- The first time a client tries to find resources, it queries the Master Browser for a list of Backup Browsers in the domain subnet.
- The client requests a server list from any Backup Browser that responds.
- The Backup Browser responds with the list.
- A session is setup with the appropriate resource.
Client system will contact Browser servers for a list
of servers within a group or for lists of groups. Typically clients will keep a list of several Browsers
If a client system does not get a response from a Local Master Browser it can initiate an election. The
Browser systems and Potential Browser systems communicate to decide which machine will become the Browser.
There is only ever one Master Browser in a domain. The Election Packet is broadcast whenever a Master Browser is not available.
When a Browser receives the Election packet it compares the election criteria with its own, if its own criteria are higher, then
it sends its own election packet and so on until the one with the highest criteria is elected as the Master Browser. The criteria
include the following:
- Operating System
- Version number
- Alphabetical order of computer name
- Configured Role of the computer. The PDC overrides all.
A network resource is announced every 12 minutes. If the Master Browser does not hear an announcement for 3 x 12 = 36 minutes
then the resource is dropped. The Master Browser sends out the resource list to the Backup Browsers every 15 minutes. It is
conceivable that a resource could be down for 36 + 15 = 51 minutes before it is finally removed from the resource list and no
longer displayed in Explorer.
As mentioned earlier, the Browser service uses Mailslots where the mailslot frames are carried in
SMBtrans (Transact) packets (see the table above).
The opcode within the Transact SMB packet is Mailslot Write. Within the data portion of the Transact
packet is the mailslot frame. The Transact data itself begins with an opcode as shown below:
NetBIOS over IPX
Novell introduced an implementation of NetBIOS over IPX in 1986.
This used to be encoded in
a ROM on the NIC, however nowadays, in Token Ring networks, NetBIOS is loaded using the IBM
LAN Support Program disk.
Native NetBIOS carries out extensive broadcasting and is therefore very bandwidth intensive, it also
needs to be bridged or, if it is to be routed, then encapsulated in IP or IPX ready for
routing (often preferable because it is bandwidth hungry, the problem with is the reduction in
Netware can run a NetBIOS emulation which runs on top of Packet Exchange Protocol (PEP) which
is similar to SAP, and PEP processes NetBIOS calls before sending them to IPX. Programs written
to the NetBIOS interface can run in the Netware system communication being established by the
provision of a logical connection between two NetBIOS names. An IPX packet carrying NetBIOS
information is defined as packet type 0x14 (Decimal '20') and has a destination socket of 0x455.
NetBIOS can now be routed through IPX.
If a NetBIOS client wishes to connect to a NetBIOS application then it sends out just one NetBIOS
Name Propagation Packet (Type 0x14). Any routers on the way to the application will examine
the Transport Control Field (contains the number of routers traversed plus the Network Numbers
that contain information) and compare the network numbers with the network that it is on. If
no match is found the router adds it's own network number to the list in the packet, increments
the Transport Control Field and sends the packet to the directly connected networks not within the
Network Number fields. On reaching the application server, the server puts the name and address
into its cache and issues a connection number to the client and from now on the socket number
0x455 is used to indicate NetBIOS as the packet is routed according to normal IPX procedures.
NetBIOS Accept and NetBIOS Deliver parameters can be used to prevent unwanted Name Propagation
Packets (and thus subsequent NetBIOS traffic) from being accepted or forwarded (respectively),
thereby providing some bandwidth limitation of NetBIOS traffic.
NetBIOS over TCP/IP (NBT)
The NetBIOS name representation in all NetBIOS packets is defined in the Domain Name Service
as compressed name messages. This format is
called second-level encoding
The frame format is very similar to the DNS frame see DNS Frame
The frame format is repeated here for convenience:
The differences are that extra types and codes have been added for NetBIOS.
concentrates on the frame format used for NetBIOS.
- ID - Name Transaction ID, there is a unique name for each transaction, the receiver uses the same name used by the sender.
- QR - Query Response Flag, 0 for a Request, 1 for a Response.
- Opcode - has the following values (1 to 4 are used for DNS):
- 0 - query
- 5 - registration
- 6 - release
- 7 - WACK
- 8 - refresh
- AA - Authoritative Flag, 0 if QR flag is 0 i.e. NOT a Response. If QR is 1 AND the
AA flag is 1 then the responding node is an Authoritative server for the domain.
- TC - Truncation Flag, this is set if the content is greater than 576 bytes.
- RD - Recursive Desired Flag, which is set on a request to a NetBIOS Name Server. The NBNS will copy its state into the
response packet, if it is 1 the NBNS will iterate on the query, registration, or release.
- RA - Recursion Available, if this is 1, then the NBNS supports recursive query, registration, and release.
If this is 0 then the end-node must iterate for query and challenge for registration.
This is only used in responses from a NetBIOS Name Server.
- Z - unused in DNS but in NetBIOS this is
made up of two 0's and a Broadcast Flag, for which a 1 means that the packet was broadcast and a 0 means that it was Unicast.
- Rcode - Result (or Response) Code, which can have the following values:
- 0x0 - No error
- 0x1 - Format error, the server did not understand the query
- 0x2 - Server failure Problem with NBNS, cannot process name
- 0x3 - Name error, only the authoritative server would set this value
- 0x4 - Unsupported request error. Allowable only for challenging NBNS when gets an Update type registration request
- 0x5 - Refused. For policy reasons server will not register this name from this host
- 0x6 - Active error. Name is owned by another node.
- 0x7 - Name in conflict error. A UNIQUE name is owned by more than one node.
- QDcount - the number of entries in the question section of a Name. This is a Service packet. Always zero (0) for responses
and must be non-zero for all NetBIOS Name requests.
- ANcount - the number of resource records in the answer section of a Name Service packet.
- NScount - the number of resource records in the authority section of a Name Service packet.
- ARcount - the number of resource records in the additional records section of a Name Service packet.
- Qname - the compressed name representation of the NetBIOS name for the request.
- Qtype - the type of request e.g.
- NB - 0x0020 - NetBIOS general Name Service Resource Record
- NBSTAT - 0x0021 - NetBIOS NODE STATUS Resource Record
- Qclass - the class of the request, currently the value 0x0001 specifies an Internet Class.
- Name - The compressed name representation of the NetBIOS name corresponding to this resource record.
- Type - Resource Record Type e.g.
- A - 0x0001 - IP address Resource Record
- NS - 0x0002 - Name Server Resource Record
- NULL - 0x000A - NULL Resource Record
- NB - 0x0020 - NetBIOS general Name Service Resource Record. This puts its own fields into the Rdata portion,
the NB_ADDRESS field contains the IP address of the name's owner, the NB_FLAGS field has the following fields:
- G - Group Name flag (1 bit), set to 1 if the Resource Record Name is a Group Name otherwise it is 0.
- ONT - Owner Node Type (2 bits), e.g.
- 00 - B-node
- 01 - P-node
- 10 - M-node
- 11 - Reserved for future use (Microsoft use this for thie H-node)
- Reserved - all zeros (13 bits)
- NBSTAT - 0x0021 - NetBIOS NODE STATUS Resource Record
- Class - Resource Record Class e.g. 0x0001 for Internet Class.
- TTL - time to Live of the Resource Record's name.
- RDlength - the number of bytes in the RDATA field.
- Rdata - contains the resource information for the NetBIOS name including extra fields as detailed above.
Further breakdown of the Resource Record types and specifics regarding their field values can be found in
When running over TCP/IP, NetBIOS uses the following ports:
- 137 - UDP/TCP - nbname used for the Name Service, name broadcasts for building browsing lists.
- 138 - UDP - nbdatagram - used for the Datagram Service
- 139 - TCP - nbsession - used for the Session Service
NBT name resolution occurs by searching through these various methods in turn until a name match is found.
The default order used by Microsoft's networking clients, is as
- NBT searches its internal name cache;
- NBT queries the WINS server defined;
- a broadcast is issued;
- NBT searches the LMHOSTS file;
- NBT issues a DNS query for the NetBIOS name in question.
Each node maintains a small name cache that contains the most commonly used names. Ideally, you want to make sure that
the most commonly used names are in the name cache so that name query requests are minimised, however the cache (which
is adjustable) tends to be of limited size and so it can get flushed regularly in a large network where there is alot
of device browsing going on. This diminished the effect of the cache.
We have just mentioned host name to IP address mapping, however NetBIOS names can also refer to services.
One host may have a number of services such as a web server, an SNA gateway etc. in which case there would
be a number of names associated with the same IP address in the LMHOSTS file.
When a node needs to communicate with another node, it broadcasts to find the remote node. The remote node
responds to the broadcast with a direct unicast response. Once the two nodes have located each other, they can communicate
directly using unicast packets. The problem is that this design breaks down quickly in even minor networks, and is not very scalable.
In order to scale NetBIOS over IP networks a specificatio has been written in
and RFC 1002
Within the standards there are two types of servers defined:
- NetBIOS Name Server (NBNS) - a server where systems can register names, or completely manage names and addresses
and example of NBNS is WINS.
- NetBIOS Datagram Distribution Server (NBDD) -
Datagrams to be sent to individual nodes or broadcast, can be sent to the NBDD which will forward the datagram to the target node or nodes.
There are three types of NetBIOS End-nodes defined by the standards and a fourth one (H-node) added by Microsoft:
- B-node - Broadcast node that uses broadcasts to query nodes for the owner of a NetBIOS name.
- P-node - Point-to-point node that uses directed calls to communicate with a known NetBIOS name
server, such as a Windows Internet Name Service (WINS) server, for the IP address of a NetBIOS machine name.
P-nodes depend upon NBNS servers to register their name to IP address mappings and discover the names of other End-Nodes.
- M-node - Mixed node that uses broadcasted queries to find a node, and failing that, queries a known
P-node name server for the address i.e. a P-node with B-node characteristics. An M-node uses NBNS and NBDD servers.
- H-node - Hybrid node reverses the M-node standard so that a directed query is executed first, and failing that,
a broadcast is attempted. The H-node model is the default used by Microsoft's networking clients whenever a WINS server has been
selected in the client configuration.
The H-node is an addition to the first three that are defined in RFC 1001
and RFC 1002
. These node types apply only at the stage where
an IP address is being found for a known name. Once the IP address has been found, unicast transmission ensues.
In the IP environment WINS is most commonly used for dynamic mapping of IP to NetBIOS names. Detail on this
and the use of LMHOSTS files can be found in the document WINS
NetBIOS over PPP is described in RFC 2097 NetBIOS Frames Control
Encapsulation of IP over NetBIOS is described in RFC 1088
SAMBA can be found at https://www.samba.org