NetBIOS

Introduction

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'.

Protocol Stack

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.

Frame Format

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:

Command
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 Services

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.

Naming Service

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
- 0 - add name not in process
- 1 - add name in process
The 'Data2' field can have the following values:
- 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.

Diagnostic Services

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 by mistake.

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.

Datagram Services

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 are unused.
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.

Session Services

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 structure:

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.
Reserved
Error Code - codes returned for the Error Classes e.g. for the SUCCESS Error Class possible Error Codes include:
- BUFFERED (0x54) - The Message was buffered
- LOGGED (0x55) - The Message was logged
- DISPLAYED (0x56) - The Message was displayed
and for the ERRSRV Error Class, possible Error Codes include:
- ERRerror (0x01) - Non-specific error code
- ERRbadpw (0x02) - Bad password
- ERRbadtype (0x03) - Reserved
Flags
Flags 2
Reserved
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
Data

The following table lists a number of SMB commands that you could see in the Command field:

Core Commands
Field Name	smb_com	Description
SMBmkdir	0x00	Create directory
SMBrmdir	0x01	Delete directory
SMBopen	0x02	Open file
SMBcreate	0x03	Create file
SMBclose	0x04	Close file
SMBflush	0x05	Commit all files
SMBunlink	0x06	Delete file
SMBmv	0x07	Rename file
SMBgetatr	0x08	Get file attribute
SMBsetatr	0x09	Set file attribute
SMBread	0x0a	Read byte block
SMBwrite	0x0b	Write byte block
SMBlock	0x0c	Lock byte block
SMBunlock	0x0d	Unlock byte block
SMBmknew	0x0f	Create new file
SMBchkpth	0x10	Check directory
SMBexit	0x11	End of process
SMBlseek	0x12	LSEEK
SMBtcon	0x70	Start connection
SMBtdis	0x71	End connection
SMBnegprot	0x72	Verify dialect
SMBbskattr	0x80	Get disk attributes
SMBsearch	0x81	Search multiple files
SMBsplopen	0xc0	Create spool file
SMBsplwr	0xc1	Spool byte block
SMBsplclose	0xc2	Close spool file
SMBsplretq	0xc3	Return print queue
SMBsends	0xd0	Send message
SMBsendb	0xd1	Send broadcast
SMBfwdname	0xd2	Forward user name
SMBcancelf	0xd3	Cancel forward
SMBgetmac	0xd4	Get machine name
SMBsendstrt	0xd5	Start multi-block message
SMBsendend	0xd6	End multi-block message
SMBsendtxt	0xd7	Multi-block message text
Never valid	0xfe	Invalid
Implementation-dependant	0xff	Implementation-dependant
Core plus commands
SMBlockreadr	0x13	Lock then read data
SMBwriteunlock	0x14	Write then unlock data
SMBreadBraw	0x1a	Read block raw
SMBwriteBraw	0x1d	Write block raw
LANMAN 1.0 SMB commands
SMBreadBmpx	0x1b	Read block multiplexed
SMBreadBs	0x1c	Read block (secondary response)
SMBwriteBmpx	0x1e	Write block multiplexed
SMBwriteBs	0x1f	Write block (secondary response)
SMBwriteC	0x20	Write complete response
SMBsetattrE	0x22	Set file attributes expanded
SMBgetattrE	0x23	Get file attributes expanded
SMBlockingX	0x24	Lock/unlock byte ranges and X
SMBtrans	0x25	Transaction (name, bytes in/out)
SMBtranss	0x26	Transaction (secondary request/response)
SMBioctl	0x27	Passes the IOCTL to the server
SMBioctls	0x28	IOCTL (secondary request/response)
SMBcopy	0x29	Copy
SMBmove	0x2a	Move
SMBecho	0x2b	Echo
SMBwriteclose	0x2c	Write and Close
SMBopenX	0x2d	Open and X
SMBreadX	0x2e	Read and X
SMBwriteX	0x2f	Write and X
SMBsesssetup	0x73	Session Set Up and X (including User Logon)
SMBtconX	0x75	Tree connect and X
SMBffirst	0x82	Find first
SMBfunique	0x83	Find unique
SMBfclose	0x84	Find close
SMBinvalid	0xfe	Invalid command

Browser Service

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:

Opcode	Description
1	HostAnnouncement
2	AnnouncementRequest
8	RequestElection
9	GetBackupListReq
10	GetBackupListResp
11	BecomeBackup
12	DomainAnnouncment
13	MasterAnnouncement
15	LocalMasterAnnouncement

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 speed).

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 RFC 883 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. RFC 1002 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 RFC 1002.

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 follows:

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.

NetBIOS Nodes

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 RFC 1001 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.

WINS

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.

References

NetBIOS over PPP is described in RFC 2097 NetBIOS Frames Control Protocol (NBFCP).

Encapsulation of IP over NetBIOS is described in RFC 1088.

SAMBA can be found at https://www.samba.org.

Home

Disclaimer