The use of NetBIOS, (otherwise known as NetBEUI, NetBIOS Frames Protocol, NBF) is not a popular choice. Many networks use some form of encapsulation with the most popular being TCP/IP. It is important to understand that the various encapsulation implementations are designed to emulate the use of NetBIOS "on the wire"; the goal is to allow higher level protocols (such as SMB or CIFS) or applications to make use of the NetBIOS protocol irrespective of whether it is running "on the wire" or encapsulated. Thus in order to fully understand implementations that use encapsulation, it is necessary to understand "NetBIOS on the wire". It is not clear whether there is only one protocol or several protocols involved in NetBIOS networking. The original implementation for the PC Network certainly seemed to have the following protocols: Name Management protocol (NMP), Diagnostic and Monitoring Protocol (DMP), User Datagram Protocol (UDP) and Session Management Protocol (SMP). The distinction is less clear with NetBIOS on Token-Ring and other Implementations; the official IBM documentation IBM LAN Technical Reference IEEE 802.2 and NetBIOS Application Program Interfaces simply describes a collection of 22 frame formats, see . Given that at least network layer and session layer functions are involved, the various packets used will be discussed in terms of the original protocols for convenience, even if the distinctions are somewhat arbitrary. Frame name Command code ADD_NAME_QUERY 0x01 ADD_GROUP_NAME 0x00 ADD_NAME_RESPONSE 0x0D NAME_IN_CONFLICT 0x02 NAME_QUERY 0x0A NAME_RECOGNISED 0x0E DATAGRAM 0x08 DATAGRAM_BROADCAST 0x09 STATUS_QUERY 0x03 STATUS_RESPONSE 0x0F TERMINATE_TRACE 0x07 TERMINATE_TRACE local and remote 0x13 SESSION_ALIVE 0x1F SESSION_CONFIRM 0x17 SESSION_END 0x18 SESSION_INITIALIZE 0x19 DATA_ACK 0x14 DATA_FIRST_MIDDLE 0x15 DATA_ONLY_LAST 0x16 NO_RECEIVE 0x1A RECEIVE_OUTSTANDING 0x1B RECEIVE_CONTINUE 0x1C NetBIOS systems communicate in one of two manners; the protocols are often described as Session layer protocols because most of the communications occur over sessions established between two nodes on the network. The other form of communication does not involve sessions and uses a simple datagram transmission mechanism for simple communications between systems on a network. Non-session frames are used for functions such as name management or other functions that simply require a datagram delivery service. In general when one system needs to communicate with another it will contact that system and a session will be established between the two nodes; the session will be maintained as long as either node needs to communicate until one of the nodes closes the session. Sessions are established using an exchange of packets. The station wishing to establish the session sends an Open request that should be responded to with an Open acknowledgment. The station initiating the session will then send a Session request which will elicit either a Session accept or Session reject. Data is transmitted using an established session through the sending system sending data packets which are responded to with either acknowledgment packets (ACK) or negative acknowledgment packets (NACK) prompting re-transmission. Sessions are closed by the system that received data sending a close request that should be responded to by the system that initiated the session sending a close response. This is followed by the system that received data sending a packet indicating that the session is closed. Obviously in order to communicate, systems need an address scheme and this is described in .

To communicate, each node (computer, printer, router etc) needs to be uniquely identified on a network. Within the TCP/IP suite of protocols, under the IPv4 address scheme, a 32 bit address identifies each node and the network it is connected to. In IPX/SPX networks, a 48 bit address identifies a node on a network and a 32 bit address identifies each network. In NetBIOS networks names are used by each node. NetBIOS names are 16 bytes (128 bits) long (padded if necessary) and there are very few restraints on the byte values that can be used. Non-alphanumeric characters can be used in NetBIOS names, although some implementations may not support this and applications using NetBIOS may impose other constraints. Often an implementation will make use of the 16th byte, for example to indicate a particular service; thus the 16th byte may be used in a way which is broadly analogous to port numbers in TCP/IP. It is worth noting that SMB / CIFS names map directly on to NetBIOS names and in this case the 16th byte is particularly important for identifying various services. Microsoft has produced a Knowledge Base Article that lists the NetBIOS suffixes (i.e. the sixteenth byte) that Microsoft uses or supports. The Knowledge Base Article is Q163409 and can be found at http://support.microsoft.com/default.aspx?scid=kb;en-us;Q163409 Some examples of the 16th byte in Unique names are given below: 16th byte (in hex) Description 00 Workstation service 01 Messenger service 20 File server service 2B Lotus Notes Server Service NetBIOS names represent a flat name space; names are non-hierarchical with no provision for subdivision. Because there is no provision for identifying networks with the NetBIOS name scheme, protocols using this name scheme can not be routed. A NetBIOS name is often associated with one end of a session between two nodes. A station on the network can be known by several names (aliases) originally up to 12 (See BYTE Magazine November 1989 "Two tin cans and some string" Part 2 ) or 17 names (See BYTE Magazine January 1989 "Understanding NetBIOS" ) . Modern implementations allow very many names to be used. Names can be unique names reserved for the station's exclusive use or group names shared with other stations.

Group Names are NetBIOS names that several stations can use. Each Group Name must be unique and in many situations must be distinct from any unique (node) names. These names allow stations to be grouped together to facilitate management and browsing of the network. Stations can send broadcast messages to all stations that share a particular group name. Within SMB / CIFS environments, collections of systems such as workgroups or domains map on to NetBIOS Group names.

One name is the permanent node name, which is the physical adapter card's name; this is usually derived from the Media Access Control (MAC) address of the card i.e. the hardware address and consists of 10 bytes of zeros followed by the 6 bytes of the MAC address. This special permanent node name is often called "NETBIOS_NAME_1". It is because one of the names incorporates the physical MAC address (and because there is only one network) that there is often no name resolution protocol (analogous to the Address Resolution Protocol ARP in TCP/IP networks). When NetBIOS is encapsulated within other protocols such as IPX/SPX or TCP/IP there is a mechanism for mapping NetBIOS names to the address schemes of the encapsulating protocol. See Encapsulation.

The Name Management Protocol (NMP) allows systems to create unique symbolic names that are visible on the network. NMP has some similarities with the AppleTalk Name Binding Protocol: The Name Management Protocol broadcasts a system's intention to use a new name and if no other system objects, the name is registered. NetBIOS broadcasts a name claim packet several times and if no other station contests the name claim the name is added to the local name table. Typically the packets are sent at half second intervals six times, although in principal these parameters can be tuned. Often a node will require three seconds to check each name it is using. The original Name Management Protocol is described in in the section . In the NetBIOS Frames Protocol on 802.2 networks there are four non-session level Name Management Frames. As described in there are two kinds of names: unique names and group names. The "ADD NAME QUERY" frame (0x01) is used by a node to verify that the name it wishes to add is unique within the network. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x01 identifying it as an "ADD NAME QUERY" frame. Five reserved octets are followed by a two byte response correlator, transmitted byte reversed, created by the sender and used to correlate any responses to the query. The next sixteen octets, used for the destination name in other frames, are reserved in this case. The following sixteen octets for the source name are used to identify the name to be added. The "ADD GROUP NAME" frame (0x00) is used by a node to verify that the group name does not exist as a unique name within the network. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x00 identifying it as an "ADD GROUP NAME QUERY" frame. Five reserved octets are followed by a two byte response correlator, transmitted byte reversed, created by the sender and used to correlate any responses to the query. The next sixteen octets, used for the destination name in other frames, are reserved in this case. The following sixteen octets for the source name are used to identify the group name to be added. The "ADD NAME RESPONSE" frame (0x0D) is used in response to one of the above query frames to inform the node wishing to add the name that the name is already in use. The "ADD NAME RESPONSE" frame (0x0D) is used in response to one of the above query frames to inform the node wishing to add the name that the name is already in use. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x0D identifying it as an "ADD NAME RESPONSE" frame. The next octet, the "DATA1" octet is set to 1 or 0; 0 = "add name not in process", 1 = "add name in process". The next two bytes, known as "DATA2", constitutes a define word set to 0 or 1; 0 = "unique name, 1 = "group name"; this is transmitted byte reversed. The next two bytes constitute a correlator, transmitted byte reversed, used to correlate the response with the original query. Two reserved octets are followed by sixteen octets holding the name to be added and a further sixteen octets which again hold the name to be added. The "NAME IN CONFLICT" frame (0x02) is used to indicate a problem with names on the network; it is sent if more than one adapter has the same unique name registered or a name is registered as both a unique name and a group name. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x02 identifying it as an "NAME IN CONFLICT" frame. Seven reserved octets are followed by sixteen octets representing the name in conflict. The final sixteen octets represent the special "NAME NUMBER 1" of the node sending the frame. The "ADD NAME QUERY" frame (0x01) is used by a node to verify that the name it wishes to add is unique within the network. Management frame Management frame Management frame Management frame Field Name Length ADD GROUP NAME QUERY ADD NAME QUERY ADD NAME RESPONSE NAME IN CONFLICT Length 2 0x2C 0x2C 0x2C 0x2C 0x00 0x00 0x00 0x00 Deliminator 2 0xFF 0xFF 0xFF 0xFF 0xEF 0xEF 0xEF 0xEF Command 1 0x00 0x01 0x0D 0x02 Data 1 1 Reserved Reserved 0 or 1 Reserved Data 2 2 Reserved Reserved 0 or 1 Reserved Reserved Reserved 0 Reserved XMIT Cor 2 Reserved Reserved nn Reserved Reserved Reserved nn Reserved RSP Cor 2 nn nn Reserved Reserved nn nn Reserved Reserved Destination Name 16 Reserved Reserved Name to be added Name in conflict Source Name 16 Group name to add Name to add Name to be added NAME NUMBER 1 In the NetBIOS Frames Protocol on 802.2 networks there are two frames used for managing names in session establishment. Although not part of name management, these frames are included here for convenience. The "NAME QUERY" frame (0x0A) is used to find a name on the network or to request a remote node to establish a session. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x0A identifying it as an "NAME QUERY" frame. Following the "DATA1" field which is reserved, the two octets of the "DATA2" field are 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. The "DATA2" field is transmitted byte reversed. Two reserved octets are followed by a two byte response correlator, transmitted byte reversed. Sixteen octets identify the name being called. The final sixteen octets identify the name of the node making the call. The "NAME RECOGNISED" frame (0x0E) is used in response to a NAME QUERY frame to indicate that a session can be established with the name or to provide the location of the name. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x0E identifying it as an "NAME RECOGNISED" frame. Following the "DATA1" field which is reserved, the two bytes of the "DATA2" field are set to "ttss" where "tt" is set to 0x00 to indicate a unique recognized name or 0x01 to indicate a unique recognized group name. the type of name being called, 00 for a unique name and 01 for a group "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, 0x01 to 0xFE are used as a number which will identify this session. The "DATA2" field is transmitted byte reversed. A two byte transmit correlator is used to correlate the response with the NAME QUERY frame. This is followed by a two byte response correlator used with SESSION INITIALIZE frames; these fields are transmitted byte reversed. Sixteen octets identify the name of the node making the NAME QUERY call. The final sixteen octets identify the name being queried. Management frame Management frame Field Name Length NAME QUERY NAME RECOGNISED Length 2 0x2C 0x2C 0x00 0x00 Deliminator 2 0xFF 0xFF 0xEF 0xEF Command 1 0x0A 0x0E Data 1 1 Reserved Reserved Data 2 2 X ss X ss X tt X tt XMIT Cor 2 Reserved nn Reserved nn RSP Cor 2 nn nn nn nn Destination Name 16 Name of receiver Name of receiver Source Name 16 Name of sender Name of sender

The NetBIOS User Datagram Protocol (UDP) provides packet transmission from source to destination. UDP is an unreliable datagram delivery protocol. NetBIOS User Datagram Protocol is comparable with the Datagram Delivery Protocol (DDP) in AppleTalk, or IP in the TCP/IP suite of protocols, or IPX in Novell's IPX/SPX protocol suite. It is important to note that the NetBIOS User Datagram Protocol differs from datagram protocols in other protocol suites; the NetBIOS User Datagram Protocol is designed specifically to provide a datagram delivery service and not necessarily to provide a foundation for higher level protocols. Where as in other protocol suites the datagram protocol supports transport and session layer protocols running over the datagram protocol, here there is a separate Session Management Protocol which does not make use of the NetBIOS User Datagram Protocol. The relationship is illustrated in the . UDP packets are sent between Named systems (see above) or are broadcast from one Named system to all Names on the network. The original User Datagram Protocol is described in in the section .

The "DATAGRAM" frame (0x08) is used to send a datagram to a name. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x08 identifying it as an "DATAGRAM" frame. Seven reserved octets are followed by sixteen octets used to identify the destination name of the datagram. The following sixteen octets identify the source name sending the datagram. A variable number of octets contain the data or payload of the datagram. The "DATAGRAM BROADCAST" frame (0x09) is used to broadcast a datagram to all names on the network. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x09 identifying it as an "DATAGRAM" frame. Seven reserved octets are followed by a further sixteen octets which are also reserved rather than identifying the destination name as in the case of "DATAGRAM" frames. The following sixteen octets identify the source name sending the datagram. A variable number of octets contain the data or payload of the datagram. Data frame Data frame Field Name Length DATAGRAM DATAGRAM BROADCAST Length 2 0x2C 0x2C 0x00 0x00 Deliminator 2 0xFF 0xFF 0xEF 0xEF Command 1 0x08 0x09 Data 1 1 Reserved Reserved Data 2 2 Reserved Reserved Reserved Reserved XMIT Cor 2 Reserved Reserved Reserved Reserved RSP Cor 2 Reserved Reserved Reserved Reserved Destination Name 16 Name of receiver Reserved Source Name 16 Name of sender Name of sender Optional Datagram Datagram

The NetBIOS Diagnostic and Monitoring Protocol (DMP) provides the facilities to obtain status information about local and remote nodes on the network. This protocol is broadly comparable with the basic functionality provided by the Simple Network Monitoring Protocol (SNMP) within the TCP/IP suite of protocols. The NetBIOS Diagnostic and Monitoring Protocol (DMP) provides the facilities to obtain information including: Number of "Frame Reject" (FRMR) frames received. Number of "Frame Reject" (FRMR) frames transmitted. Number of I-format "Logical link control Protocol Data Units" (LPDUs) received in error. Number of aborted transmissions. Etc. It is worth noting that this facility is part of the protocol and not an advantage of a given Operating System that happens to be using the protocol.

The "STATUS QUERY" frame (0x03) is used to request remote adapter status information. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x03 identifying it as an "STATUS QUERY" frame. 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. The "DATA2" field is transmitted byte reversed. Two reserved octets are followed by a two octet response correlator, transmitted byte reversed. Sixteen octets identifying the name of the receiver are followed by a further sixteen octets indicating the sending node's NAME NUMBER 1. The "STATUS RESPONSE" frame (0x0F) is used in response to request a status request frame. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x0F identifying it as an "STATUS RESPONSE" 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 x is set to 1 if the length of the status data exceeds the frame size; the second bit y 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. The "DATA2" field is transmitted byte reversed. A two octet transmit correlator, transmitted byte reversed, is followed by two reserved octets. Sixteen octets indicate the receiving node's NAME NUMBER 1 and are followed by a further sixteen octets indicating the sending node's name. The "TERMINATE TRACE" frame (0x07) is used to end a trace at a remote node. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x07 identifying it as an "TERMINATE TRACE" frame. All the remaining 39 octets are reserved. The "TERMINATE TRACE" frame (0x13) is used to end a local trace and a trace at a remote node. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x13 identifying it as an "TERMINATE TRACE" frame. All the remaining 39 octets are reserved. Special frame Special frame Special frame Special frame Field Name Length STATUS QUERY STATUS RESPONSE TERMINATE TRACE Terminate local & remote trace Length 2 0x2C 0x2C 0x2C 0x2C 0x00 0x00 0x00 0x00Deliminator 2 0xFF 0xFF 0xFF 0xFF 0xEF 0xEF 0xEF 0xEF Command 1 0x03 0x0F 0x07 0x13Data 1 1 nn nn Reserved ReservedData 2 2 Length of status buf bbbbbbbb Reserved Reserved Length of status buf xybbbbbb Reserved ReservedXMIT Cor 2 Reserved nnnn Reserved Reserved Reserved nnnn Reserved ReservedRSP Cor 2 nnnn Reserved Reserved Reserved nnnn Reserved Reserved ReservedDestination Name 16 Name of receiver Receiver's NAME NUMBER 1 Reserved ReservedSource Name 16 Sending node NAME NUMBER 1 Name of sender Reserved Reserved

The NetBIOS Session Management Protocol (SMP) manages sessions between Named processes on the network. NetBIOS Sessions support full duplex operation. One Named process calls another Name on the network which answers. The Session continues until one or both systems hang up. The original NetBIOS Session Management Protocol is described in Appendix: NetBIOS protocols in IBM PC Network in NetBIOS Session Management Protocol in IBM PC Networks.

In the NetBIOS Frames Protocol on 802.2 networks there are two frames used for managing names in session establishment. Details of these frames are given in "Name Management Frames in NetBIOS on 802.2 networks" Management frame Management frameField Name Length NAME QUERY NAME RECOGNISEDLength 2 0x2C 0x2C 0x00 0x00Deliminator 2 0xFF 0xFF 0xEF 0xEF Command 1 0x0A 0x0EData 1 1 Reserved Reserved Data 2 2 X ss X ss X tt X tt XMIT Cor 2 Reserved nn Reserved nn RSP Cor 2 nn nn nn nn Destination Name 16 Name of receiver Name of receiver Source Name 16 Name of sender Name of sender

The "SESSION ALIVE" frame (0x1F) is send as the result of an inactivity timer expiring. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x1F identifying it as an "SESSION ALIVE" frame. All the remaining 39 octets are reserved. The "SESSION CONFIRM" frame (0x17) is used to request remote adapter status information. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. these fields are followed by the one octet command frame which has a value of 0x17 identifying it as an "SESSION CONFIRM" frame. The "DATA1" octet is an 8 bit binary string; the first bit "y" is set to 0 for versions of NetBIOS prior to version 2.20 and to 1 for higher versions. After 6 bits always set to 0, the last bit "x" is set to 0 for NetBIOS version 1.xx and set to 1 for version 2.00 or above (In practice this will now always be set to 1). The two bytes of the "DATA2" field are used to indicate the length of the user's receive buffer. The "DATA2" field is transmitted byte reversed. Two octets used for a transmission correlator are followed by a two octet response correlator; these fields are transmitted byte reversed. A single octet is used for the remote session number and is followed by an octet for the local session number. The "SESSION END" frame (0x18) is used to request remote adapter status information. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x18 identifying it as an "SESSION END" frame. The "DATA1" octet is reserved. The two bytes of the "DATA2" field are used to indicate the reason for termination. 0x00 indicates a normal session end, 0x01 indicates an abnormal end. The "DATA2" field is transmitted byte reversed. Four reserved octets are followed by a single octet used for the remote session number. The final octet is for the local session number. The "SESSION INITIALIZE" frame (0x19) is used to request remote adapter status information. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x19 identifying it as an "SESSION INITIALIZE" frame. The "DATA1" octet is an 8 bit binary string; the first bit "z" is set to 0 for versions of NetBIOS prior to version 2.20 and to 1 for higher versions (In practice this will now always be set to 1). Three reserved bits "rrr", always set to 0 are followed by 3 bits "xxx" used to indicate the largest frame value as seen by the MAC layer; the last bit "z" 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. The "DATA2" field is transmitted byte reversed. A single octet is used for the remote session number and is followed by an octet for the local session number. Session frame Session frame Session frame Session frame Field Name Length SESSION ALIVE SESSION CONFIRM Session End SESSION INITIALIZE Length 2 0x0E 0x0E 0x0E 0x0E 0x00 0x00 0x00 0x00 Deliminator 2 0xFF 0xFF 0xFF 0xFF 0xEF 0xEF 0xEF 0xEF Command 1 0x1F 0x17 0x18 0x19Data1 1 Reserved B yrrrrrrx Reserved zrrrxxxy Data2 2 Reserved Max data rec size Termination indicator Max data receive size Reserved Max data rec size Termination indicator Max data receive size XMIT Cor 2 Reserved nnnn Reserved nnnn Reserved nnnn Reserved nnnn RSP Cor 2 Reserved nnnn Sess init xmit Reserved nnnn Reserved Remote session num Remote session num Remote session num Destination Num 1 Reserved Remote session num Remote session num Remote session num Source Num 1 Reserved Local session num Local session num Local session num

The "DATA ACK" frame (0x14) is sent in response to a DATA ONLY LAST frame (see below). The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x14 identifying it as an "DATA ACK" frame. Three reserved octets are followed by a two octet transmit correlator then a two octet receive correlator; these fields are transmitted byte reversed. A single octet is used for the remote session number and is followed by an octet for the local session number. The "DATA FIRST MIDDLE" frame (0x15) is used to transmit user messages across a session. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x15 identifying it as an "DATA FIRST MIDDLE" frame. The "DATA1" octet is an 8 bit binary string; the first four bits are reserved; the fifth bit "x" is set to 1 if an acknowledgment is included; this is followed by a reserved bit; the seventh bit "y" is set to 0 for versions of NetBIOS prior to version 2.20 and set to 1 for later versions (In practice this will now always be set to 1); the last bit "z" is set to 0 if a RECEIVE CONTINUE was not requested, otherwise it is set to 1. The next two octets are for DATA2 and is a re-synchronization indicator set to 0001 if it is the first DATA FIRST MIDDLE frame. The "DATA2" field is transmitted byte reversed. This is followed by a transmit correlator then a two octet receive correlator. A single octet is used for the remote session number and is followed by an octet for the local session number. Finally the user data follows. The "DATA ONLY LAST" frame (0x16) is used to transmit user messages across a session and is either the only frame or the last. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x16 identifying it as an "DATA ONLY LAST" frame. The "DATA1" octet is an 8 bit binary string; the first four bits are reserved; the fifth bit "x" is set to 1 if an acknowledgment is included; this is followed by the sixth "y" bit which indicates that an "acknowledge with data allowed" is permitted; the seventh bit "z" is a "no.ack" indicator and the final bit is reserved. The next two octets are for DATA2 and is a re-synchronization indicator set to 0001 if this frame is send following receipt of a RECEIVE OUTSTANDING. The "DATA2" field is transmitted byte reversed. This is followed by a transmit correlator then a two octet receive correlator; these fields are transmitted byte reversed. A single octet is used for the remote session number and is followed by an octet for the local session number. Finally the user data follows. The "NO RECEIVE" frame (0x1A) is transmitted in response to a "DATA ONLY LAST" frame or a "DATA FIRST MIDDLE" frame. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x1A identifying it as an "NO RECEIVE" frame. The "DATA1" octet is an 8 bit binary string; the first six bits are reserved; the seventh bit "x" is set to 0 for versions of NetBIOS prior to 2.20, otherwise it is set to 1 (In practice this will now always be set to 1); the eighth bit is reserved. The next two bytes are for DATA2 and gives the number of data bytes accepted. The "DATA2" field is transmitted byte reversed. Four reserved octets are followed by a single octet used for the remote session number; this is followed by an octet for the local session number. The "RECEIVE OUTSTANDING" frame (0x1B) is transmitted in response to a "NO RECEIVE" frame. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x1C identifying it as an "RECEIVE OUTSTANDING" frame. The "DATA1" octet is reserved. The next two octets are for DATA2 and gives the number of data bytes accepted. The "DATA2" field is transmitted byte reversed. Four reserved octets are followed by a single octet used for the remote session number; this is followed by an octet for the local session number. The "RECEIVE CONTINUE" frame (0x1C) is transmitted in response to a "DATA ONLY LAST" frame which had the RECEIVE CONTINUE bit set. The frame begins with a two byte length field with a value of 0x002C followed by the two byte frame deliminator field 0xEFFF; these fields are transmitted byte reversed. These fields are followed by the one octet command frame which has a value of 0x1C identifying it as an "RECEIVE CONTINUE" frame. Three reserved octets are followed by a two octet transmit correlator, transmitted byte reversed, which is followed by two more reserved octets. A single octet is used for the remote session number and is followed by an octet for the local session number. Data frame Data frame Data frame Data frame Data frame Data frame Field Name Length DATA ACK DATA FIRST MIDDLE DATA ONLY LAST NO RECEIVE RECEIVE OUT-STANDING RECEIVE CONTINUE Length 2 0x0E 0x0E 0x0E 0x0E 0x0E 0x0E 0x00 0x00 0x00 0x00 0x00 0x00 Deliminator 2 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xEF 0xEF 0xEF 0xEF 0xEF 0xEF Command 1 0x14 0x15 0x16 0x1A 0x1B 0x1CData1 1 Reserved Brrrxryz Brrrxryz Brrrrrrxr Reserved ReservedData2 2 Reserved Re-synch indicator Re-synch indicator Number of data bytes accepted Number of data bytes accepted Reserved Reserved Re-synch indicator Re-synch indicator Number of data bytes accepted Number of data bytes accepted ReservedXMIT Cor 2 nnnn nnnn nnnn Reserved Reserved nnnn nnnn nnnn nnnn Reserved Reserved nnnnRSP Cor 2 Reserved nnnn nnnn Reserved Reserved Reserved Reserved nnnn nnnn Reserved Reserved ReservedDest Num 1 Remote session num Remote session num Remote session num Remote session num Remote session num Remote session numSource Num 1 Local session num Local session num Local session num Local session num Local session num Local session numOptional data USER DATA Message from send USER DATA Message from send