Data Network Resource
         Earn on the Web



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 protocol stack

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.

NetBIOS header

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:
  1. The sending station sends a NAME_QUERY as a Spanning Tree Explorer (STE).
  2. 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.
  3. 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).
  4. The returning AREs gather RIF information on their way back to the originating station.
  5. The originating station receives multiple copies of the NAME_RECOGNIZED frame.
  6. 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.
  7. 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:

Session services frame

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

SMB Frame

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:
  1. Computers running the server service announce (register) themselves to the Master Browser.
  2. The first time a client tries to find resources, it queries the Master Browser for a list of Backup Browsers in the domain subnet.
  3. The client requests a server list from any Backup Browser that responds.
  4. The Backup Browser responds with the list.
  5. 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.


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:

DNS header

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:
  1. NBT searches its internal name cache;
  2. NBT queries the WINS server defined;
  3. a broadcast is issued;
  4. NBT searches the LMHOSTS file;
  5. 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.


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 Protocol (NBFCP).

Encapsulation of IP over NetBIOS is described in RFC 1088.

SAMBA can be found at

Valid HTML 4.01 Transitional

Earn on the Web    

All rights reserved. All trademarks, logos, and copyrights are property of their respective owners.