RFC 1002
Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications
RFC 1002: PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: DETAILED SPECIFICATIONS ✨
Network Working Group 🌸 Request for Comments: 1002 🎀 Date: March 1987 🦋 Status: proposed standard 💖
🙈 Heads up bestie: this part of the document doesn't list the authors, or say what it obsoletes or updates. So I'm not making any of that up!
ABSTRACT 💅
okay so this RFC defines a proposed standard protocol that brings NetBIOS services to a TCP/IP environment, and it's giving versatile 🧚. It works on a local network and across internets. It also defines different node types so it can fit local and internet setups, and it can run with or without IP broadcast. Iconic. 👑
This RFC gives the detailed specs for the NetBIOS-over-TCP packets, the protocols, and the defined constants and variables. If you want the bigger-picture overview, go check out the companion RFC, "Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods." 📖✨
TABLE OF CONTENTS 🗂️
1. STATUS OF THIS MEMO 4
2. ACKNOWLEDGEMENTS 4
3. INTRODUCTION 5
4. PACKET DESCRIPTIONS 5
4.1 NAME FORMAT 5
4.2 NAME SERVICE PACKETS 7
4.2.1 GENERAL FORMAT OF NAME SERVICE PACKETS 7
4.2.1.1 HEADER 8
4.2.1.2 QUESTION SECTION 10
4.2.1.3 RESOURCE RECORD 11
4.2.2 NAME REGISTRATION REQUEST 13
4.2.3 NAME OVERWRITE REQUEST & DEMAND 14
4.2.4 NAME REFRESH REQUEST 15
4.2.5 POSITIVE NAME REGISTRATION RESPONSE 16
4.2.6 NEGATIVE NAME REGISTRATION RESPONSE 16
4.2.7 END-NODE CHALLENGE REGISTRATION RESPONSE 17
4.2.8 NAME CONFLICT DEMAND 18
4.2.9 NAME RELEASE REQUEST & DEMAND 19
4.2.10 POSITIVE NAME RELEASE RESPONSE 20
4.2.11 NEGATIVE NAME RELEASE RESPONSE 20
4.2.12 NAME QUERY REQUEST 21
4.2.13 POSITIVE NAME QUERY RESPONSE 22
4.2.14 NEGATIVE NAME QUERY RESPONSE 23
4.2.15 REDIRECT NAME QUERY RESPONSE 24
4.2.16 WAIT FOR ACKNOWLEDGEMENT (WACK) RESPONSE 25
4.2.17 NODE STATUS REQUEST 26
4.2.18 NODE STATUS RESPONSE 27
4.3 SESSION SERVICE PACKETS 29
4.3.1 GENERAL FORMAT OF SESSION PACKETS 29
4.3.2 SESSION REQUEST PACKET 30
4.3.3 POSITIVE SESSION RESPONSE PACKET 31
4.3.4 NEGATIVE SESSION RESPONSE PACKET 31
4.3.5 SESSION RETARGET RESPONSE PACKET 31
4.3.6 SESSION MESSAGE PACKET 32
4.3.7 SESSION KEEP ALIVE PACKET 32
4.4 DATAGRAM SERVICE PACKETS 32
4.4.1 NetBIOS DATAGRAM HEADER 32
4.4.2 DIRECT_UNIQUE, DIRECT_GROUP, & BROADCAST DATAGRAM 33
4.4.3 DATAGRAM ERROR PACKET 34
4.4.4 DATAGRAM QUERY REQUEST 34
4.4.5 DATAGRAM POSITIVE AND NEGATIVE QUERY RESPONSE 34
5. PROTOCOL DESCRIPTIONS 35
5.1 NAME SERVICE PROTOCOLS 35
5.1.1 B-NODE ACTIVITY 35
5.1.1.1 B-NODE ADD NAME 35
5.1.1.2 B-NODE ADD_GROUP NAME 37
5.1.1.3 B-NODE FIND_NAME 37
5.1.1.4 B NODE NAME RELEASE 38
5.1.1.5 B-NODE INCOMING PACKET PROCESSING 39
5.1.2 P-NODE ACTIVITY 42
5.1.2.1 P-NODE ADD_NAME 42
5.1.2.2 P-NODE ADD GROUP NAME 45
5.1.2.3 P-NODE FIND NAME 45
5.1.2.4 P-NODE DELETE_NAME 46
5.1.2.5 P-NODE INCOMING PACKET PROCESSING 47
5.1.2.6 P-NODE TIMER INITIATED PROCESSING 49
5.1.3 M-NODE ACTIVITY 50
5.1.3.1 M-NODE ADD NAME 50
5.1.3.2 M-NODE ADD GROUP NAME 54
5.1.3.3 M-NODE FIND NAME 55
5.1.3.4 M-NODE DELETE NAME 56
5.1.3.5 M-NODE INCOMING PACKET PROCESSING 58
5.1.3.6 M-NODE TIMER INITIATED PROCESSING 60
5.1.4 NBNS ACTIVITY 60
5.1.4.1 NBNS INCOMING PACKET PROCESSING 61
5.1.4.2 NBNS TIMER INITIATED PROCESSING 66
5.2 SESSION SERVICE PROTOCOLS 67
5.2.1 SESSION ESTABLISHMENT PROTOCOLS 67
5.2.1.1 USER REQUEST PROCESSING 67
5.2.1.2 RECEIVED PACKET PROCESSING 71
5.2.2 SESSION DATA TRANSFER PROTOCOLS 72
5.2.2.1 USER REQUEST PROCESSING 72
5.2.2.2 RECEIVED PACKET PROCESSING 72
5.2.2.3 PROCESSING INITIATED BY TIMER 73
5.2.3 SESSION TERMINATION PROTOCOLS 73
5.2.3.1 USER REQUEST PROCESSING 73
5.2.3.2 RECEPTION INDICATION PROCESSING 73
5.3 NetBIOS DATAGRAM SERVICE PROTOCOLS 74
5.3.1 B NODE TRANSMISSION OF NetBIOS DATAGRAMS 74
5.3.2 P AND M NODE TRANSMISSION OF NetBIOS DATAGRAMS 76
5.3.3 RECEPTION OF NetBIOS DATAGRAMS BY ALL NODES 78
5.3.4 PROTOCOLS FOR THE NBDD 80
6. DEFINED CONSTANTS AND VARIABLES 83
REFERENCES 851. STATUS OF THIS MEMO 💅
okay so this RFC specifies a proposed standard for the DARPA Internet community. Since this topic is brand new to the Internet community, they're specifically asking for discussions and suggestions. Bestie, speak up! 🗣️✨
If you want to send written comments, mail them to:
Karl Auerbach
Epilogue Technology Corporation
P.O. Box 5432
Redwood City, CA 94063And if you'd rather go online, send your comments to:
Avnish Aggarwal
Internet: mtxinu!excelan!avnish@ucbvax.berkeley.edu
Usenet: ucbvax!mtxinu!excelan!avnishDistribution of this memorandum is unlimited. 🦋
2. ACKNOWLEDGEMENTS 🫶
This RFC was developed under the auspices of the Internet Activities Board. Literally the big leagues. 👑
These individuals helped build this RFC:
Avnish Aggarwal Arvind Agrawal Lorenzo Aguilar
Geoffrey Arnold Karl Auerbach K. Ramesh Babu
Keith Ball Amatzia Ben-Artzi Vint Cerf
Richard Cherry David Crocker Steve Deering
Greg Ennis Steve Holmgren Jay Israel
David Kaufman Lee LaBarre James Lau
Dan Lynch Gaylord Miyata David Stevens
Steve Thomas Ishan WuNgl, the design doesn't match any existing Netbios-over-TCP implementation. 🙈 But it still pulls in a lot of knowledge from earlier implementations, and the special thanks go to these organizations for sharing that invaluable info: 💜
CMC/Syros Excelan Sytek Ungermann-Bass3. INTRODUCTION 🎀
This RFC has the detailed packet formats and protocol specs for NetBIOS-over-TCP. It's the companion to RFC 1001, "Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods" [1]. So the two are a matching set, periodt. 💖
4. PACKET DESCRIPTIONS 🧚
Bit and byte ordering are defined by the most recent version of "Assigned Numbers" [2]. So check that doc for the ordering rules, it's the source of truth! 🌈
to be continued... part 2 is coming, bestie 💅✨
4.1. NAME FORMAT 💅
Okay bestie, every NetBIOS name in every packet (NAME, SESSION, and DATAGRAM services) gets written in the "compressed" name style from DNS RFC 883[3] 🫶 The Concepts and Methods doc calls this "second-level encoding" in its "Representation of NetBIOS Names" section ✨
Since this stuff is a lot, we're copying the first two paragraphs from page 31 of RFC 883 (the "Domain name representation and compression" section) so you can see the source 🎀
Domain names messages are expressed in terms of a sequence
of labels. Each label is represented as a one octet length
field followed by that number of octets. Since every domain
name ends with the null label of the root, a compressed
domain name is terminated by a length byte of zero. The
high order two bits of the length field must be zero, and
the remaining six bits of the length field limit the label
to 63 octets or less.
To simplify implementations, the total length of label
octets and label length octets that make up a domain name is
restricted to 255 octets or less.Next up is the uncompressed version of the name "FRED ". That's the 4 ASCII characters F, R, E, D, followed by 12 space characters (0x20) 🌸 This name has the SCOPE_ID: "NETBIOS.COM" 💜
EGFCEFEECACACACACACACACACACACACA.NETBIOS.COMThis uncompressed style is called "first-level encoding" in the "Representation of NetBIOS Names" section of the Concepts and Methods document 🦋
Here's a pictographic look at the compressed version of that same uncompressed domain name 👑
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x20 | E (0x45) | G (0x47) | F (0x46) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C (0x43) | E (0x45) | F (0x46) | E (0x45) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| E (0x45) | C (0x43) | A (0x41) | C (0x43) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A (0x41) | C (0x43) | A (0x41) | C (0x43) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A (0x41) | C (0x43) | A (0x41) | C (0x43) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A (0x41) | C (0x43) | A (0x41) | C (0x43) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A (0x41) | C (0x43) | A (0x41) | C (0x43) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A (0X41) | 0x07 | N (0x4E) | E (0x45) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T (0x54) | B (0x42) | I (0x49) | O (0x4F) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S (0x53) | 0x03 | C (0x43) | O (0x4F) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M (0x4D) | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Each section of a domain name is called a label [7 (page 31)] 🧚 A label can be a maximum of 63 bytes. The first byte of a label in compressed form is the number of bytes in that label. In the example above, the first 0x20 is the byte count for the left-most label, EGFCEFEECACACACACACACACACACACACA, of the domain name. The bytes after the length count are the characters of the label. The labels that follow are in sequence after that first label (the encoded NetBIOS name), until you hit a zero (0x00) length count. That zero count is the root label, which is always null 🍓
A label length count is really a 6-bit field inside the label length field. The two most significant bits (bits 7 and 6) are flags that let you escape from the compressed format above. If bits 7 and 6 are both set (11), then the following 14 bits are an offset pointer into the full message, pointing to the actual label string from another domain name that belongs in this name. This label pointer lets a domain name get compressed even further inside a packet ✨
NetBIOS implementations can only use label string pointers in Name Service packets. They cannot be used in Session or Datagram Service packets.
The other two possible values for bits 7 and 6 (01 and 10) of a label length field are reserved for future use by RFC 883[2 (page 32)] 🙈
Also, the first octet of a compressed name must contain one of the following bit patterns. (An "x" marks a bit that can be either 0 or 1.):
00100000 - Netbios name, length must be 32 (decimal)
11xxxxxx - Label string pointer
10xxxxxx - Reserved
01xxxxxx - Reserved4.2. NAME SERVICE PACKETS 🦋
4.2.1. GENERAL FORMAT OF NAME SERVICE PACKETS ✨
The NetBIOS Name Service packets follow the packet structure defined in the Domain Name Service (DNS) RFC 883 [7 (pg 26-31)] 💖 The structures stay compatible with the existing DNS packet formats, but NetBIOS added extra types and codes so it can do its thing 💅
If Name Service packets get sent over a TCP connection, they're preceded by a 16 bit unsigned integer that tells you the length of the Name Service packet 🫶
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ ------ ------- +
| HEADER |
+ ------ ------- +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ QUESTION ENTRIES /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ ANSWER RESOURCE RECORDS /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ AUTHORITY RESOURCE RECORDS /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ ADDITIONAL RESOURCE RECORDS /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.2.1.1. HEADER 🎀
okay so the header is the very first thing in every Name Service packet and it's giving "read me first, bestie" 💅 here's the layout:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID | OPCODE | NM_FLAGS | RCODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QDCOUNT | ANCOUNT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSCOUNT | ARCOUNT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each field does:
NAME_TRN_IDis the transaction ID for the Name Service transaction. The requestor gives each active transaction its own unique value, and the responder copies theNAME_TRN_IDvalue from the request packet into the response packet. so the two always match up 🦋OPCODEis the packet type code. See the table below.NM_FLAGSholds the flags for the operation. See the table below.RCODEholds the result codes of the request. There's a table ofRCODEvalues for each response packet, shown below.QDCOUNTis an unsigned 16 bit integer giving the number of entries in the question section of a Name Service packet. It's always zero (0) for responses. It MUST be non-zero for all NetBIOS Name requests. 👑ANCOUNTis an unsigned 16 bit integer giving the number of resource records in the answer section of a Name Service packet.NSCOUNTis an unsigned 16 bit integer giving the number of resource records in the authority section of a Name Service packet.ARCOUNTis an unsigned 16 bit integer giving the number of resource records in the additional records section of a Name Service packet.
Now the OPCODE field, which is bits 0 through 4 of the packet's second 16 bit word, like a little bitfield 🌸
0 1 2 3 4
+---+---+---+---+---+
| R | OPCODE |
+---+---+---+---+---+
Symbol Bit(s) Description
OPCODE 1-4 Operation specifier:
0 = query
5 = registration
6 = release
7 = WACK
8 = refresh
R 0 RESPONSE flag:
if bit == 0 then request packet
if bit == 1 then response packet.So OPCODE is the operation (query, registration, release, WACK, or refresh), and the R bit tells you whether the packet is a request (0) or a response (1) 🫶
Next up is the NM_FLAGS field, which is bits 0 through 6 of that same word:
0 1 2 3 4 5 6
+---+---+---+---+---+---+---+
|AA |TC |RD |RA | 0 | 0 | B |
+---+---+---+---+---+---+---+
Symbol Bit(s) Description
B 6 Broadcast Flag.
= 1: packet was broadcast or multicast
= 0: unicast
RA 3 Recursion Available Flag.
Only valid in responses from a NetBIOS Name
Server -- MUST be zero in all other
responses.
If one (1) then the NBNS supports recursive
query, registration, and release.
If zero (0) then the end-node MUST iterate
for query and challenge for registration.
RD 2 Recursion Desired Flag.
MAY only be set on a request to a NetBIOS
Name Server.
The NBNS will copy its state into the
response packet.
If one (1) the NBNS will iterate on the
query, registration, or release.
TC 1 Truncation Flag.
Set if this message was truncated because the
datagram carrying it would be greater than
576 bytes in length. Use TCP to get the
information from the NetBIOS Name Server.
AA 0 Authoritative Answer flag.
MUST be zero (0) if R flag of OPCODE is zero
(0).
If R flag is one (1) then if AA is one (1)
then the node responding is an authority for
the domain name.
End nodes responding to queries always set
this bit in responses.Let's break the flags down, because there's a lot going on here 🧚
B(bit 6) is the Broadcast Flag. It's 1 if the packet was broadcast or multicast, and 0 if it was unicast. 📡RA(bit 3) is the Recursion Available Flag. It's only valid in responses from a NetBIOS Name Server, and it MUST be zero in all other responses.- If it's one (1), the NBNS supports recursive query, registration, and release.
- If it's zero (0), the end-node MUST iterate for query and challenge for registration.
RD(bit 2) is the Recursion Desired Flag. It MAY only be set on a request to a NetBIOS Name Server.- The NBNS copies its state into the response packet.
- If it's one (1), the NBNS will iterate on the query, registration, or release.
TC(bit 1) is the Truncation Flag. It gets set if the message was truncated because the datagram carrying it would be greater than 576 bytes in length. If that happens, use TCP to get the information from the NetBIOS Name Server. 🙈AA(bit 0) is the Authoritative Answer flag. It MUST be zero (0) if theRflag ofOPCODEis zero (0).- If the
Rflag is one (1) andAAis one (1), the responding node is an authority for the domain name. - End nodes responding to queries always set this bit in responses. ✨
- If the
4.2.1.2. QUESTION SECTION 💌
the question section is where the actual ask lives, so here's how it's laid out:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ QUESTION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QUESTION_TYPE | QUESTION_CLASS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Field Description
QUESTION_NAME The compressed name representation of the
NetBIOS name for the request.
QUESTION_TYPE The type of request. The values for this field
are specified for each request.
QUESTION_CLASS The class of the request. The values for this
field are specified for each request.
QUESTION_TYPE is defined as:
Symbol Value Description:
NB 0x0020 NetBIOS general Name Service Resource Record
NBSTAT 0x0021 NetBIOS NODE STATUS Resource Record (See NODE
STATUS REQUEST)
QUESTION_CLASS is defined as:
Symbol Value Description:
IN 0x0001 Internet classQUESTION_NAMEis the compressed name representation of the NetBIOS name for the request. 🍓QUESTION_TYPEis the type of request. Its values get specified for each request.NBis0x0020, the NetBIOS general Name Service Resource Record.NBSTATis0x0021, the NetBIOS NODE STATUS Resource Record (see NODE STATUS REQUEST).
QUESTION_CLASSis the class of the request. Its values get specified for each request.INis0x0001, the Internet class. 🌈
4.2.1.3. RESOURCE RECORD 🦄
resource records are the actual answers, and they come with a whole bunch of fields:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR_TYPE | RR_CLASS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDLENGTH | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
/ /
/ RDATA /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Field Description
RR_NAME The compressed name representation of the
NetBIOS name corresponding to this resource
record.
RR_TYPE Resource record type code
RR_CLASS Resource record class code
TTL The Time To Live of a the resource record's
name.
RDLENGTH Unsigned 16 bit integer that specifies the
number of bytes in the RDATA field.
RDATA RR_CLASS and RR_TYPE dependent field. Contains
the resource information for the NetBIOS name.
RESOURCE RECORD RR_TYPE field definitions:
Symbol Value Description:
A 0x0001 IP address Resource Record (See REDIRECT NAME
QUERY RESPONSE)
NS 0x0002 Name Server Resource Record (See REDIRECT
NAME QUERY RESPONSE)
NULL 0x000A NULL Resource Record (See WAIT FOR
ACKNOWLEDGEMENT RESPONSE)
NB 0x0020 NetBIOS general Name Service Resource Record
(See NB_FLAGS and NB_ADDRESS, below)
NBSTAT 0x0021 NetBIOS NODE STATUS Resource Record (See NODE
STATUS RESPONSE)
RESOURCE RECORD RR_CLASS field definitions:
Symbol Value Description:
IN 0x0001 Internet classHere's the rundown on each field:
RR_NAMEis the compressed name representation of the NetBIOS name this resource record corresponds to. 💖RR_TYPEis the resource record type code.RR_CLASSis the resource record class code.TTLis the Time To Live of the resource record's name. ⏰RDLENGTHis an unsigned 16 bit integer that specifies the number of bytes in theRDATAfield.RDATAis a field that depends onRR_CLASSandRR_TYPE. It contains the resource information for the NetBIOS name.
The RR_TYPE values are:
Ais0x0001, the IP address Resource Record (see REDIRECT NAME QUERY RESPONSE).NSis0x0002, the Name Server Resource Record (see REDIRECT NAME QUERY RESPONSE).NULLis0x000A, the NULL Resource Record (see WAIT FOR ACKNOWLEDGEMENT RESPONSE).NBis0x0020, the NetBIOS general Name Service Resource Record (seeNB_FLAGSandNB_ADDRESS, below). 🫧NBSTATis0x0021, the NetBIOS NODE STATUS Resource Record (see NODE STATUS RESPONSE).
The RR_CLASS value is:
INis0x0001, the Internet class. 🌸
The NB_FLAGS field sits inside the RDATA field when RR_TYPE is "NB":
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| G | ONT | RESERVED |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Symbol Bit(s) Description:
RESERVED 3-15 Reserved for future use. MUST be zero (0).
ONT 1,2 Owner Node Type:
00 = B node
01 = P node
10 = M node
11 = Reserved for future use
For registration requests this is the
claimant's type.
For responses this is the actual owner's
type.
G 0 Group Name Flag.
If one (1) then the RR_NAME is a GROUP
NetBIOS name.
If zero (0) then the RR_NAME is a UNIQUE
NetBIOS name.RESERVED(bits 3-15) is reserved for future use, and it MUST be zero (0). 🔒ONT(bits 1 and 2) is the Owner Node Type. It's00for a B node,01for a P node,10for an M node, and11is reserved for future use. For registration requests, it's the claimant's type. For responses, it's the actual owner's type. 👑G(bit 0) is the Group Name Flag. If it's one (1), theRR_NAMEis a GROUP NetBIOS name. If it's zero (0), theRR_NAMEis a UNIQUE NetBIOS name. 💜
And last but not least, the NB_ADDRESS field, which lives in the RDATA field when RR_TYPE is "NB", is the IP address of the name's owner. 🎀
4.2.2. NAME REGISTRATION REQUEST ✨
okay bestie, this is the packet a node sends when it wants to claim a name on the network 🦋 Here's the layout:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID |0| 0x5 |0|0|1|0|0 0|B| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ QUESTION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 | NB_FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+So here's the thing 💅 Since the RR_NAME is the same name as the QUESTION_NAME, the RR_NAME representation must use pointers to the QUESTION_NAME name's labels to guarantee the length of the datagram is less than the maximum 576 bytes. See section above on name formats and also page 31 and 32 of RFC 883, Domain Names - Implementation and Specification, for a complete description of compressed name label pointers. it's giving compression, it's giving efficiency 🌸
4.2.3. NAME OVERWRITE REQUEST & DEMAND 🎀
Same vibe as the registration request, just with a different opcode doing the talking 🧚 Here's how it looks:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID |0| 0x5 |0|0|0|0|0 0|B| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ QUESTION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 | NB_FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.2.4. NAME REFRESH REQUEST 🔄
Refreshing a name is basically saying "hey, still me, still here" 🫶 Here's the packet:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID |0| 0x9 |0|0|0|0|0 0|B| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ QUESTION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 | NB_FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.2.5. POSITIVE NAME REGISTRATION RESPONSE 🌈
This is the happy ending ⭐ The response when the registration goes through looks like this:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID |1| 0x5 |1|0|1|1|0 0|0| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 | NB_FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.2.6. NEGATIVE NAME REGISTRATION RESPONSE 🙈
Not every registration gets a gold star 💀 When it doesn't work out, this is the packet, and the RCODE field tells you why:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID |1| 0x5 |1|0|1|1|0 0|0| RCODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 | NB_FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+RCODE field values:
Symbol Value Description:
FMT_ERR 0x1 Format Error. Request was invalidly
formatted.
SRV_ERR 0x2 Server failure. Problem with NBNS, cannot
process name.
IMP_ERR 0x4 Unsupported request error. Allowable only
for challenging NBNS when gets an Update type
registration request.
RFS_ERR 0x5 Refused error. For policy reasons server
will not register this name from this host.
ACT_ERR 0x6 Active error. Name is owned by another node.
CFT_ERR 0x7 Name in conflict error. A UNIQUE name is
owned by more than one node.4.2.7. END-NODE CHALLENGE REGISTRATION RESPONSE ⚔️
The last one in this batch is the end-node challenge response 👑 Here's the layout:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID |1| 0x5 |1|0|1|0|0 0|0| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 | NB_FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.2.8. NAME CONFLICT DEMAND 💥
Okay so this one is basically a NEGATIVE NAME REGISTRATION RESPONSE wearing a different outfit 💅 Same layout, but the RCODE is set to CFT_ERR. Here's the full look 🎀
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID |1| 0x5 |1|0|1|1|0 0|0| 0x7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00000000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 |0|ONT|0| 0x000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00000000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This packet is identical to a NEGATIVE NAME REGISTRATION RESPONSE with RCODE = CFT_ERR. 🙈
4.2.9. NAME RELEASE REQUEST & DEMAND 🫶
Time to let go of a name 🦋 This is the packet for releasing one, and it's also used for the demand version.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID |0| 0x6 |0|0|0|0|0 0|B| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ QUESTION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00000000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 | NB_FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Since the RR_NAME is the same name as the QUESTION_NAME, the RR_NAME representation must use label string pointers to the QUESTION_NAME labels to guarantee the length of the datagram is less than the maximum 576 bytes. This is the same condition as with the NAME REGISTRATION REQUEST. 💜
4.2.10. POSITIVE NAME RELEASE RESPONSE 🌸
The happy ending ✨ This is the positive reply saying the name has been released.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID |1| 0x6 |1|0|0|0|0 0|0| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 | NB_FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.2.11. NEGATIVE NAME RELEASE RESPONSE 🥀
The not-so-happy version 😭 Same shape as the positive one, but with an RCODE field that tells you what went wrong.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID |1| 0x6 |1|0|0|0|0 0|0| RCODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 | NB_FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RCODE field values:
Symbol Value Description:
FMT_ERR 0x1 Format Error. Request was invalidly
formatted.
SRV_ERR 0x2 Server failure. Problem with NBNS, cannot
process name.
RFS_ERR 0x5 Refused error. For policy reasons server
will not release this name from this host.
ACT_ERR 0x6 Active error. Name is owned by another node.
Only that node may release it. A NetBIOS
Name Server can optionally allow a node to
release a name it does not own. This would
facilitate detection of inactive names for
nodes that went down silently.RCODE check, bestie 🚨FMT_ERR(0x1) means the request was messed up in formatting,SRV_ERR(0x2) means the server had a failure and couldn't handle the name,RFS_ERR(0x5) means the server refuses to release the name from this host for policy reasons, andACT_ERR(0x6) means the name belongs to a different node and only that node can release it. Also, a NetBIOS Name Server can optionally let a node release a name it doesn't own, which helps spot names from nodes that silently went down 👀
4.2.12. NAME QUERY REQUEST 🔍
Now we're asking the network who's who 💁♀️ This is the request that goes out with a QUESTION_NAME and asks for the answer.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID |0| 0x0 |0|0|1|0|0 0|B| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ QUESTION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.2.13. POSITIVE NAME QUERY RESPONSE 🎉
The payoff 🎁 This is the response that hands back the answer, with a list of ADDR_ENTRY records telling you who owns the name.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID |1| 0x0 |1|T|1|?|0 0|0| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDLENGTH | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ ADDR_ENTRY ARRAY /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The ADDR_ENTRY ARRAY is a sequence of zero or more ADDR_ENTRY records. Each ADDR_ENTRY record represents an owner of a name. For group names there may be multiple entries. However, the list may be incomplete due to packet size limitations. Bit 22, "T", will be set to indicate truncated data. 🧚
Each ADDR_ENTRY has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB_FLAGS | NB_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB_ADDRESS (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.2.14. NEGATIVE NAME QUERY RESPONSE 🙅♀️💖
Okay, so this is the "sorry bestie, nobody by that name lives here" packet 💅. Here's the layout:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID |1| 0x0 |1|0|1|?|0 0|0| RCODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NULL (0x000A) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00000000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The RCODE field can be one of these values, and each one tells the requestor what went sideways 👀:
Symbol Value Description
FMT_ERR 0x1 Format Error. Request was invalidly
formatted.
SRV_ERR 0x2 Server failure. Problem with NBNS, cannot
process name.
NAM_ERR 0x3 Name Error. The name requested does not
exist.
IMP_ERR 0x4 Unsupported request error. Allowable only
for challenging NBNS when gets an Update type
registration request.
RFS_ERR 0x5 Refused error. For policy reasons server
will not register this name from this host.4.2.15. REDIRECT NAME QUERY RESPONSE 🧚
This one is the "ask over there instead" packet 🦋. The layout looks like this:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID |1| 0x0 |0|0|1|0|0 0|0| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NS (0x0002) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDLENGTH | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
/ NSD_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A (0x0001) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0004 | NSD_IP_ADDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSD_IP_ADDR, continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Now the important tea ☕. An end node answering a NAME QUERY REQUEST always sets the AA and RA bits, and that goes for both the NEGATIVE and the POSITIVE NAME QUERY RESPONSE packets. An end node never sends a REDIRECT NAME QUERY RESPONSE packet, so that one is strictly NBNS business 🏢.
When the requestor gets a REDIRECT NAME QUERY RESPONSE, it must send the NAME QUERY REQUEST again to the NBNS named in the NSD_IP_ADDR field of the A type RESOURCE RECORD in the ADDITIONAL section of the response 🔁. This packet is optional for the NBNS to send 🫶.
The NSD_NAME and the RR_NAME in the ADDITIONAL section are the same name ✨. You can save some space by using label string pointers in the RR_NAME that point at the labels in the NSD_NAME, which is a very smart little trick 🧠.
The RR_NAME in the AUTHORITY section is the name of the domain that the NBNS called by NSD_NAME has authority over 👑.
4.2.16. WAIT FOR ACKNOWLEDGEMENT (WACK) RESPONSE ⏳
This is the "hold up, I'm still working on it" packet 💅, and it looks like this:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID |1| 0x7 |1|0|0|0|0 0|0| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NULL (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0002 | OPCODE | NM_FLAGS | 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The NAME_TRN_ID of a WACK RESPONSE is the same NAME_TRN_ID as the request the NBNS is asking the requestor to keep waiting on 🫧. The RR_NAME is the name from that request, if there is one. If the request doesn't carry a name, the RR_NAME is a null name, which is just a single byte of zero 0️⃣.
The TTL field of the ResourceRecord is the new amount of time to wait, in seconds, for the request to finish ⏰. The RDATA field holds the OPCODE and NM_FLAGS of the request 📦.
A TTL value of 0 means the NBNS can not estimate how long it may take to finish a response. Brutal, but honest 💀.
4.2.17. NODE STATUS REQUEST 🔍
Last one in this part! This is the "hey, who are you really?" packet 🕵️♀️, and here's the layout:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID |0| 0x0 |0|0|0|0|0 0|B| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ QUESTION_NAME /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NBSTAT (0x0021) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.2.18. NODE STATUS RESPONSE ✨
okay so the NODE STATUS RESPONSE is the reply to that status request and it's giving everything 💅 the RR_NAME is the requesting name, then comes NBSTAT and IN, a run of zeros, RDLENGTH, NUM_NAMES, the NODE_NAME ARRAY, and finally STATISTICS 🦋
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID |1| 0x0 |1|0|0|0|0 0|0| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NBSTAT (0x0021) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00000000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDLENGTH | NUM_NAMES | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
/ NODE_NAME ARRAY /
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
/ STATISTICS /
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The NODE_NAME ARRAY is an array of zero or more NUM_NAMES entries of NODE_NAME records. Each NODE_NAME entry stands for an active name that sits in the same NetBIOS scope as the requesting name, in the responder's local name table. And RR_NAME? That's just the requesting name, bestie 🎀
NODE_NAME Entry:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+--- ---+
| |
+--- NETBIOS FORMAT NAME ---+
| |
+--- ---+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The NAME_FLAGS field:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| G | ONT |DRG|CNF|ACT|PRM| RESERVED |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+The NAME_FLAGS field is defined as:
Symbol Bit(s) Description:
RESERVED 7-15 Reserved for future use. Must be zero (0).
PRM 6 Permanent Name Flag. If one (1) then entry
is for the permanent node name. Flag is zero
(0) for all other names.
ACT 5 Active Name Flag. All entries have this flag
set to one (1).
CNF 4 Conflict Flag. If one (1) then name on this
node is in conflict.
DRG 3 Deregister Flag. If one (1) then this name
is in the process of being deleted.
ONT 1,2 Owner Node Type:
00 = B node
01 = P node
10 = M node
11 = Reserved for future use
G 0 Group Name Flag.
If one (1) then the name is a GROUP NetBIOS
name.
If zero (0) then it is a UNIQUE NetBIOS name.Okay so NAME_FLAGS is a little 16-bit flag set, and it's so specific 🙈 PRM is the permanent node name bit, ACT is always one, CNF means the name is in conflict, DRG means it's getting deleted, ONT is the owner node type (B, P, or M, with 11 still reserved), and G tells you whether it's a GROUP or UNIQUE name. Everything from bit 7 up is reserved, and that reserved part is supposed to be zero, periodt 💀
STATISTICS Field of the NODE STATUS RESPONSE:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UNIT_ID (Unique unit ID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UNIT_ID,continued | JUMPERS | TEST_RESULT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VERSION_NUMBER | PERIOD_OF_STATISTICS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUMBER_OF_CRCs | NUMBER_ALIGNMENT_ERRORS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUMBER_OF_COLLISIONS | NUMBER_SEND_ABORTS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUMBER_GOOD_SENDS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUMBER_GOOD_RECEIVES |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUMBER_RETRANSMITS | NUMBER_NO_RESOURCE_CONDITIONS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUMBER_FREE_COMMAND_BLOCKS | TOTAL_NUMBER_COMMAND_BLOCKS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MAX_TOTAL_NUMBER_COMMAND_BLOCKS| NUMBER_PENDING_SESSIONS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX_NUMBER_PENDING_SESSIONS | MAX_TOTAL_SESSIONS_POSSIBLE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_DATA_PACKET_SIZE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.3. SESSION SERVICE PACKETS 💜
4.3.1. GENERAL FORMAT OF SESSION PACKETS 🧚
All session service messages travel over a TCP connection, so no shortcuts here 🌸
Every session packet has this general shape:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | FLAGS | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ TRAILER (Packet Type Dependent) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+TYPE, FLAGS, and LENGTH show up in every session packet, no exceptions. LENGTH counts the bytes that come after the LENGTH field, which is basically the combined size of the TRAILER field(s). For example, a POSITIVE SESSION RESPONSE always has a LENGTH of zero (0000), while a RETARGET SESSION RESPONSE always has a LENGTH of six (0006) 🦋
One bit in FLAGS works as an extra high-order bit for LENGTH, so the total trailer size can go anywhere from 0 to 128K bytes. Big energy 🔥
Session Packet Types (in hex):
00 - SESSION MESSAGE
81 - SESSION REQUEST
82 - POSITIVE SESSION RESPONSE
83 - NEGATIVE SESSION RESPONSE
84 - RETARGET SESSION RESPONSE
85 - SESSION KEEP ALIVEBit definitions of the FLAGS field:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | E |
+---+---+---+---+---+---+---+---+
Symbol Bit(s) Description
E 7 Length extension, used as an additional,
high-order bit on the LENGTH field.
RESERVED 0-6 Reserved, must be zero (0)Bit 7 is the E bit, the length extension that rides along on LENGTH. Bits 0 through 6 are reserved and have to be zero, so no sneaking stuff in there 🙅♀️
4.3.2. SESSION REQUEST PACKET 🎀
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | FLAGS | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ CALLED NAME /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ CALLING NAME /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This is the packet that knocks on the door 🚪 It carries the CALLED NAME (who you want) and the CALLING NAME (who's asking).
4.3.3. POSITIVE SESSION RESPONSE PACKET 🌈
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | FLAGS | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The yes-we-are-here answer! 🥳 It's just the header, and its LENGTH is zero (0000) because there's no trailer at all.
4.3.4. NEGATIVE SESSION RESPONSE PACKET 🙈
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | FLAGS | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERROR_CODE |
+-+-+-+-+-+-+-+-+The big no 😭 Here's what each error code means:
NEGATIVE SESSION RESPONSE packet error code values (in hex):
80 - Not listening on called name
81 - Not listening for calling name
82 - Called name not present
83 - Called name present, but insufficient resources
8F - Unspecified error4.3.5. SESSION RETARGET RESPONSE PACKET 🦋
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | FLAGS | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RETARGET_IP_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The redirect packet! ✨ It carries a RETARGET_IP_ADDRESS and a PORT, which is why its LENGTH is six (0006) 👑
4.3.6. SESSION MESSAGE PACKET ✨
okay the session message packet is up next, bestie 💖 here's the layout:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | FLAGS | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ /
/ USER_DATA /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.3.7. SESSION KEEP ALIVE PACKET 🦋
the keep alive packet is the tiniest little guy, and it's giving minimalism 🧚
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | FLAGS | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.4. DATAGRAM SERVICE PACKETS 🌸
4.4.1. NetBIOS DATAGRAM HEADER 💜
this is the header that every datagram packet wears, so pay attention, it's the main character 👑
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | DGM_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PACKET_OFFSET |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the MSG_TYPE values, in hex, are the datagram types you can get:
MSG_TYPE values (in hexidecimal):
10 - DIRECT_UNIQUE DATAGRAM
11 - DIRECT_GROUP DATAGRAM
12 - BROADCAST DATAGRAM
13 - DATAGRAM ERROR
14 - DATAGRAM QUERY REQUEST
15 - DATAGRAM POSITIVE QUERY RESPONSE
16 - DATAGRAM NEGATIVE QUERY RESPONSEand the FLAGS field has its bits laid out like this 🎀
Bit definitions of the FLAGS field:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | SNT | F | M |
+---+---+---+---+---+---+---+---+
Symbol Bit(s) Description
M 7 MORE flag, If set then more NetBIOS datagram
fragments follow.
F 6 FIRST packet flag, If set then this is first
(and possibly only) fragment of NetBIOS
datagram
SNT 4,5 Source End-Node type:
00 = B node
01 = P node
10 = M node
11 = NBDD
RESERVED 0-3 Reserved, must be zero (0)4.4.2. DIRECT_UNIQUE, DIRECT_GROUP, & BROADCAST DATAGRAM 🍓
the three direct and broadcast datagram types all share this exact layout, so you only have to learn it once 🫶
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | DGM_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PACKET_OFFSET | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ SOURCE_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ USER_DATA /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.4.3. DATAGRAM ERROR PACKET 🙈
when something goes sideways, this is the packet that tells you about it 💀
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | ERROR_CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and these are the ERROR_CODE values you might see:
ERROR_CODE values (in hexidecimal):
82 - DESTINATION NAME NOT PRESENT
83 - INVALID SOURCE NAME FORMAT
84 - INVALID DESTINATION NAME FORMAT4.4.4. DATAGRAM QUERY REQUEST 💅
the query request is basically asking "hey, who's there?" 🔥
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.4.5. DATAGRAM POSITIVE AND NEGATIVE QUERY RESPONSE 🧚
and the answer comes back in this shape, whether the news is good or not 🦋
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+5. PROTOCOL DESCRIPTIONS 👑
5.1. NAME SERVICE PROTOCOLS 💖
okay so the name service has some ground rules about where packets go, and they're lowkey important 🫶
a REQUEST packet always goes to the well known UDP port, NAME_SERVICE_UDP_PORT. usually the destination is either the IP broadcast address or the address of the NBNS, which is the NBNS server that got set up at initialization time. every once in a while, a request packet goes straight to an end node instead. like a NAME QUERY REQUEST sent to "challenge" a node, for example 🙈
a RESPONSE packet always goes back to the source UDP port and source IP address of the request packet. that's just manners 💅
a DEMAND packet must always be sent to the well known UDP port, NAME_SERVICE_UDP_PORT. there's no restriction on the target IP address for that one ✨
here are the terms used in this section:
tid- Transaction ID. This is a value composed from the requestor's IP address and a unique 16 bit value generated by the originator of the transaction.
5.1.1. B-NODE ACTIVITY 🌈
5.1.1.1. B-NODE ADD NAME 🔥
this is the host initiated process for a B node when it wants to add a name, and it's giving persistence 💪
PROCEDURE add_name(newname)
/*
* Host initiated processing for a B node
*/
BEGIN
REPEAT
/* build name service packet */
ONT = B_NODE; /* broadcast node */
G = UNIQUE; /* unique name */
TTL = 0;
broadcast NAME REGISTRATION REQUEST packet;
/*
* remote node(s) will send response packet
* if applicable
*/
pause(BCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet is received or
retransmit count has been exceeded
IF no response packet was received THEN
BEGIN /* no response */
/*
* build packet
*/
ONT = B_NODE; /* broadcast node */
G = UNIQUE; /* unique name */
TTL = 0;
/*
* Let other nodes known you have the name
*/
broadcast NAME UPDATE REQUEST packet;
/* name can be added to local name table */
return success;
END /* no response */
ELSE
BEGIN /* got response */
/*
* Match return transaction id
* against tid sent in request
*/
IF NOT response tid = request tid THEN
BEGIN
ignore response packet;
END
ELSE
CASE packet type OF
NEGATIVE NAME REGISTRATION RESPONSE:
return failure; /* name cannot be added */
POSITIVE NAME REGISTRATION RESPONSE:
END-NODE CHALLENGE NAME REGISTRATION RESPONSE:
/*
* B nodes should normally not get this
* response.
*/
ignore packet;
END /* case */;
END /* got response */
END /* procedure */5.1.1.2. B-NODE ADD_GROUP NAME 🎀
the group version is almost the same as the unique one, with one key difference: the group bit (G) must be set in the request packets. so it's basically a twin with a little plot twist 🍓
PROCEDURE add_group_name(newname)
/*
* Host initiated processing for a B node
*/
BEGIN
/*
* same as for a unique name with the
* exception that the group bit (G) must
* be set in the request packets.
*/
...
G = GROUP;
...
...
/*
* broadcast request ...
*/
END5.1.1.3. B-NODE FIND_NAME ✨
okay so this is the B node asking "hey, who has this name?" 🙋♀️ it's a host-initiated thing, and the B node just keeps yelling the query over the broadcast until someone answers or it gives up. no cap, it's giving persistence 💅
PROCEDURE find_name(name)
/*
* Host initiated processing for a B node
*/
BEGIN
REPEAT
/*
* build packet
*/
ONT = B;
TTL = 0;
G = DONT CARE;
broadcast NAME QUERY REQUEST packet;
/*
* a node might send response packet
*/
pause(BCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet received OR
max transmit threshold exceeded
IF no response packet received THEN
return failure;
ELSE
IF NOT response tid = request tid THEN
ignore packet;
ELSE
CASE packet type OF
POSITIVE NAME QUERY RESPONSE:
/*
* Start a timer to detect conflict.
*
* Be prepared to detect conflict if
* any more response packets are received.
*
*/
save response as authoritative response;
start_timer(CONFLICT_TIMER);
return success;
NEGATIVE NAME QUERY RESPONSE:
REDIRECT NAME QUERY RESPONSE:
/*
* B Node should normally not get either
* response.
*/
ignore response packet;
END /* case */
END /* procedure */The vibe here: if a positive answer comes back, the B node saves it as the authoritative one and starts a conflict timer 👀 bestie, it's watching for any extra responses just in case. Negative and redirect responses? B nodes basically shouldn't get those, so they just get ignored 🙈
5.1.1.4. B NODE NAME RELEASE 🦋
this is the "I'm done with this name, let it go" moment 🫶 the B node keeps broadcasting a release request, but nobody's replying, so there's no response to wait for. it just pauses and repeats until the retransmit count runs out.
PROCEDURE delete_name (name)
BEGIN
REPEAT
/*
* build packet
*/
...
/*
* send request
*/
broadcast NAME RELEASE REQUEST packet;
/*
* no response packet expected
*/
pause(BCAST_REQ_RETRY_TIMEOUT);
UNTIL retransmit count has been exceeded
END /* procedure */5.1.1.5. B-NODE INCOMING PACKET PROCESSING 🌈
okay this is the big one, the inbox for a B node 📬 it handles anything that shows up on the NAME_SERVICE_UDP_PORT, whether it came in as broadcast or unicast. the main thing to remember is that replies always head back to whoever sent the request (the source IP address and source UDP port of that request) 💖
PROCEDURE process_incoming_packet(packet)
/*
* Processing initiated by incoming packets for a B node
*/
BEGIN
/*
* Note: response packets are always sent
* to:
* source IP address of request packet
* source UDP port of request packet
*/
CASE packet type OF
NAME REGISTRATION REQUEST (UNIQUE):
IF name exists in local name table THEN
send NEGATIVE NAME REGISTRATION RESPONSE ;
NAME REGISTRATION REQUEST (GROUP):
IF name exists in local name table THEN
BEGIN
IF local entry is a unique name THEN
send NEGATIVE NAME REGISTRATION RESPONSE ;
END
NAME QUERY REQUEST:
IF name exists in local name table THEN
BEGIN
build response packet;
send POSITIVE NAME QUERY RESPONSE;
POSITIVE NAME QUERY RESPONSE:
IF name conflict timer is not active THEN
BEGIN
/*
* timer has expired already... ignore this
* packet
*/
return;
END
ELSE /* timer is active */
IF a response for this name has previously been
received THEN
BEGIN /* existing entry */
/*
* we sent out a request packet, and
* have already received (at least)
* one response
*
* Check if conflict exists.
* If so, send out a conflict packet.
*
* Note: detecting conflict does NOT
* affect any existing sessions.
*
*/
/*
* Check for name conflict.
* See "Name Conflict" in Concepts and Methods
*/
check saved authoritative response against
information in this response packet;
IF conflict detected THEN
BEGIN
unicast NAME CONFLICT DEMAND packet;
IF entry exists in cache THEN
BEGIN
remove entry from cache;
END
END
END /* existing entry */
ELSE
BEGIN
/*
* Note: If this was the first response
* to a name query, it would have been
* handled in the
* find_name() procedure.
*/
ignore packet;
END
NAME CONFLICT DEMAND:
IF name exists in local name table THEN
BEGIN
mark name as conflict detected;
/*
* a name in the state "conflict detected"
* does not "logically" exist on that node.
* No further session will be accepted on
* that name.
* No datagrams can be sent against that name.
* Such an entry will not be used for
* purposes of processing incoming request
* packets.
* The only valid user NetBIOS operation
* against such a name is DELETE NAME.
*/
END
NAME RELEASE REQUEST:
IF caching is being done THEN
BEGIN
remove entry from cache;
END
NAME UPDATE REQUEST:
IF caching is being done THEN
BEGIN
IF entry exists in cache already,
update cache;
ELSE IF name is "interesting" THEN
BEGIN
add entry to cache;
END
END
NODE STATUS REQUEST:
IF name exists in local name table THEN
BEGIN
/*
* send only those names that are
* in the same scope as the scope
* field in the request packet
*/
send NODE STATUS RESPONSE;
END
ENDThis part is a lot, so here's the tea ☕ a conflict is a serious situation 😭 if a name ends up in "conflict detected", it basically doesn't exist on that node anymore. no new sessions, no datagrams, and it won't be used for answering incoming requests. the only thing you can really do with it is DELETE NAME 💀
5.1.2. P-NODE ACTIVITY 🍓
so P nodes are the more old-school, straight-to-the-point ones 🧚 everything they send or receive is a unicast UDP packet, and their name service requests all go to the NBNS node listed in their P-node configuration. no broadcasting drama here, just one direct line 📞
5.1.2.1. P-NODE ADD_NAME 💜
this is a P node trying to claim a name, and it's giving careful, polite, very "may I please" energy 🥹 it sends a unique name registration request to the NBNS, then waits. if the NBNS sends a WACK, the P node waits for the time in that response's TTL field. if not, it just uses the regular retry timeout. and if the registration gets challenged by an end node, the P node challenges right back with a query and only claims the name if the owner stays quiet or says "nah, I don't own it anymore" 👑
PROCEDURE add_name(newname)
/*
* Host initiated processing for a P node
*/
BEGIN
REPEAT
/*
* build packet
*/
ONT = P;
G = UNIQUE;
...
/*
* send request
*/
unicast NAME REGISTRATION REQUEST packet;
/*
* NBNS will send response packet
*/
IF receive a WACK RESPONSE THEN
pause(time from TTL field of response);
ELSE
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet is received OR
retransmit count has been exceeded
IF no response packet was received THEN
BEGIN /* no response */
/*
* NBNS is down. Cannot claim name.
*/
return failure; /* name cannot be claimed */
END /* no response */
ELSE
BEGIN /* response */
IF NOT response tid = request tid THEN
BEGIN
/* Packet may belong to another transaction */
ignore response packet;
END
ELSE
CASE packet type OF
POSITIVE NAME REGISTRATION RESPONSE:
/*
* name can be added
*/
adjust refresh timeout value, TTL, for this name;
return success; /* name can be added */
NEGATIVE NAME REGISTRATION RESPONSE:
return failure; /* name cannot be added */
END-NODE CHALLENGE REGISTRATION REQUEST:
BEGIN /* end node challenge */
/*
* The response packet has in it the
* address of the presumed owner of the
* name. Challenge that owner.
* If owner either does not
* respond or indicates that he no longer
* owns the name, claim the name.
* Otherwise, the name cannot be claimed.
*
*/
REPEAT
/*
* build packet
*/
...
unicast NAME QUERY REQUEST packet to the
address contained in the END NODE
CHALLENGE RESPONSE packet;
/*
* remote node may send response packet
*/
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet is received or
retransmit count has been exceeded
IF no response packet is received OR
NEGATIVE NAME QUERY RESPONSE packet
received THEN
BEGIN /* update */
/*
* name can be claimed
*/
REPEAT
/*
* build packet
*/
...
unicast NAME UPDATE REQUEST to NBNS;
/*
* NBNS node will send response packet
*/
IF receive a WACK RESPONSE THEN
pause(time from TTL field of response);
ELSE
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet is received or
retransmit count has been exceeded
IF no response packet received THEN
BEGIN /* no response */
/*
* name could not be claimed
*/
return failure;
END /* no response */
ELSE
CASE packet type OF
POSITIVE NAME REGISTRATION RESPONSE:
/*
* add name
*/
return success;
NEGATIVE NAME REGISTRATION RESPONSE:
/*
* you lose ...
*/
return failure;
END /* case */
END /* update */
ELSE
/*
* received a positive response to the "challenge"
* Remote node still has name
*/
return failure;
END /* end node challenge */
END /* response */
END /* procedure */5.1.2.2. P-NODE ADD GROUP NAME
PROCEDURE add_group_name(newname)
/*
- Host initiated processing for a P node */
BEGIN /*
- same as for a unique name, except that the
- request packet must indicate that a
- group name claim is being made. */
... G = GROUP; ...
/*
- send packet */ ...
END
5.1.2.3. P-NODE FIND NAME
PROCEDURE find_name(name)
/*
- Host initiated processing for a P node */
BEGIN
REPEAT /*
- build packet */
ONT = P; G = DONT CARE;
unicast NAME QUERY REQUEST packet;
/*
- a NBNS node might send response packet */
IF receive a WACK RESPONSE THEN pause(time from TTL field of response); ELSE pause(UCAST_REQ_RETRY_TIMEOUT); UNTIL response packet received OR max transmit threshold exceeded
IF no response packet received THEN return failure; ELSE IF NOT response tid = request tid THEN ignore packet; ELSE CASE packet type OF POSITIVE NAME QUERY RESPONSE: return success;
REDIRECT NAME QUERY RESPONSE:
/*
- NBNS node wants this end node
- to use some other NBNS node
- to resolve the query. */
repeat query with NBNS address in the response packet; NEGATIVE NAME QUERY RESPONSE: return failure;
END /* case / END / procedure */
5.1.2.4. P-NODE DELETE_NAME
PROCEDURE delete_name (name) /*
- Host initiated processing for a P node */
BEGIN
REPEAT
/*
- build packet */ ...
/*
- send request */
unicast NAME RELEASE REQUEST packet; IF receive a WACK RESPONSE THEN pause(time from TTL field of response); ELSE pause(UCAST_REQ_RETRY_TIMEOUT); UNTIL retransmit count has been exceeded or response been received
IF response has been received THEN CASE packet type OF POSITIVE NAME RELEASE RESPONSE: return success; NEGATIVE NAME RELEASE RESPONSE:
/*
- NBNS does want node to delete this
- name !!! */
return failure; END /* case / END / procedure */
5.1.2.5. P-NODE INCOMING PACKET PROCESSING
Processing initiated by reception of packets at a P node
PROCEDURE process_incoming_packet(packet)
/*
- Processing initiated by incoming packets at a P node */
BEGIN
/*
- always ignore UDP broadcast packets */
IF packet was sent as a broadcast THEN BEGIN ignore packet; return; END CASE packet type of
NAME CONFLICT DEMAND: IF name exists in local name table THEN mark name as in conflict; return;
NAME QUERY REQUEST: IF name exists in local name table THEN BEGIN /* name exists */
/*
- build packet */ ...
/*
- send response to the IP address and port
- number from which the request was received. */
send POSITIVE NAME QUERY RESPONSE ; return; END /* exists / ELSE BEGIN / does not exist */
/*
- send response to the requestor */
send NEGATIVE NAME QUERY RESPONSE ; return; END /* does not exist / NODE STATUS REQUEST: /
- Name of "*" may be used for force node to
- divulge status for administrative purposes / IF name in local name table OR name = "" THEN BEGIN /*
- Build response packet and
- send to requestor node
- Send only those names that are
- in the same scope as the scope
- in the request packet. */
send NODE STATUS RESPONSE; END
NAME RELEASE REQUEST: /*
- This will be received if the NBNS wants to flush the
- name from the local name table, or from the local
- cache. */
IF name exists in the local name table THEN BEGIN delete name from local name table; inform user that name has been deleted; END ELSE IF name has been cached locally THEN BEGIN remove entry from cache: END
END /* case / END / procedure */
5.1.2.6. P-NODE TIMER INITIATED PROCESSING
Processing initiated by timer expiration.
PROCEDURE timer_expired() /*
- Processing initiated by the expiration of a timer on a P node / BEGIN /
- Send a NAME REFRESH REQUEST for each name which the
- TTL which has expired. */ REPEAT build NAME REFRESH REQUEST packet; REPEAT send packet to NBNS;
IF receive a WACK RESPONSE THEN pause(time from TTL field of response);
ELSE pause(UCAST_REQ_RETRY_TIMEOUT); UNTIL response packet is received or retransmit count has been exceeded
CASE packet type OF POSITIVE NAME REGISTRATION RESPONSE: /* successfully refreshed */ reset TTL timer for this name;
NEGATIVE NAME REGISTRATION RESPONSE: /*
- refused, can't keep name
- assume in conflict / mark name as in conflict; END / case */
UNTIL request sent for all names for which TTL has expired END /* procedure */
5.1.3. M-NODE ACTIVITY ✨
okay so M nodes are basically P nodes with a little B node flair mixed in 🦋 M node name service happens in two steps, and it's giving layered:
- Use broadcast UDP based name service. Depending on the operation, goto step 2.
- Use directed UDP name service.
The code for M nodes is literally the same as the P node code, except broadcast operations happen before the P type operation gets attempted. Bestie, it's the same energy with an extra warm-up 💅
5.1.3.1. M-NODE ADD NAME
this is where the M node tries to claim a name: broadcast first, then the name server, then the whole "who owns this?" drama if things get messy 🙈
PROCEDURE add_name(newname)
/*
* Host initiated processing for a M node
*/
BEGIN
/*
* check if name exists on the
* broadcast area
*/
REPEAT
/* build packet */
....
broadcast NAME REGISTRATION REQUEST packet;
pause(BCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet is received or
retransmit count has been exceeded
IF valid response received THEN
BEGIN
/* cannot claim name */
return failure;
END
/*
* No objections received within the
* broadcast area.
* Send request to name server.
*/
REPEAT
/*
* build packet
*/
ONT = M;
...
unicast NAME REGISTRATION REQUEST packet;
/*
* remote NBNS will send response packet
*/
IF receive a WACK RESPONSE THEN
pause(time from TTL field of response);
ELSE
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet is received or
retransmit count has been exceeded
IF no response packet was received THEN
BEGIN /* no response */
/*
* NBNS is down. Cannot claim name.
*/
return failure; /* name cannot be claimed */
END /* no response */
ELSE
BEGIN /* response */
IF NOT response tid = request tid THEN
BEGIN
ignore response packet;
END
ELSE
CASE packet type OF
POSITIVE NAME REGISTRATION RESPONSE:
/*
* name can be added
*/
adjust refresh timeout value, TTL;
return success; /* name can be added */
NEGATIVE NAME REGISTRATION RESPONSE:
return failure; /* name cannot be added */
END-NODE CHALLENGE REGISTRATION REQUEST:
BEGIN /* end node challenge */
/*
* The response packet has in it the
* address of the presumed owner of the
* name. Challenge that owner.
* If owner either does not
* respond or indicates that he no longer
* owns the name, claim the name.
* Otherwise, the name cannot be claimed.
*
*/
REPEAT
/*
* build packet
*/
...
/*
* send packet to address contained in the
* response packet
*/
unicast NAME QUERY REQUEST packet;
/*
* remote node may send response packet
*/
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet is received or
retransmit count has been exceeded
IF no response packet is received THEN
BEGIN /* no response */
/*
* name can be claimed
*/
REPEAT
/*
* build packet
*/
...
unicast NAME UPDATE REQUEST to NBNS;
/*
* NBNS node will send response packet
*/
IF receive a WACK RESPONSE THEN
pause(time from TTL field of response);
ELSE
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet is received or
retransmit count has been exceeded
IF no response packet received THEN
BEGIN /* no response */
/*
* name could not be claimed
*/
return failure;
END /* no response */
ELSE
CASE packet type OF
POSITIVE NAME REGISTRATION RESPONSE:
/*
* add name
*/
return success;
NEGATIVE NAME REGISTRATION RESPONSE:
/*
* you lose ...
*/
return failure;
END /* case */
END /* no response */
ELSE
IF NOT response tid = request tid THEN
BEGIN
ignore response packet;
END
/*
* received a response to the "challenge"
* packet
*/
CASE packet type OF
POSITIVE NAME QUERY:
/*
* remote node still has name.
*/
return failure;
NEGATIVE NAME QUERY:
/*
* remote node no longer has name
*/
return success;
END /* case */
END /* end node challenge */
END /* case */
END /* response */
END /* procedure */5.1.3.2. M-NODE ADD GROUP NAME
group names get their own little flag here. same vibe as a unique name, but the request has to say "hey, this is a group name claim" 🌈
PROCEDURE add_group_name(newname)
/*
* Host initiated processing for a P node
*/
BEGIN
/*
* same as for a unique name, except that the
* request packet must indicate that a
* group name claim is being made.
*/
...
G = GROUP;
...
/*
* send packet
*/
...
END5.1.3.3. M-NODE FIND NAME
this is the "does anyone have this name?" move. shout on the broadcast area first, and if nobody answers, ask the name server 👑
PROCEDURE find_name(name)
/*
* Host initiated processing for a M node
*/
BEGIN
/*
* check if any node on the broadcast
* area has the name
*/
REPEAT
/* build packet */
...
broadcast NAME QUERY REQUEST packet;
pause(BCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet received OR
max transmit threshold exceeded
IF valid response received THEN
BEGIN
save response as authoritative response;
start_timer(CONFLICT_TIMER);
return success;
END
/*
* no valid response on the b'cast segment.
* Try the name server.
*/
REPEAT
/*
* build packet
*/
ONT = M;
G = DONT CARE;
unicast NAME QUERY REQUEST packet to NBNS;
/*
* a NBNS node might send response packet
*/
IF receive a WACK RESPONSE THEN
pause(time from TTL field of response);
ELSE
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet received OR
max transmit threshold exceeded
IF no response packet received THEN
return failure;
ELSE
IF NOT response tid = request tid THEN
ignore packet;
ELSE
CASE packet type OF
POSITIVE NAME QUERY RESPONSE:
return success;
REDIRECT NAME QUERY RESPONSE:
/*
* NBNS node wants this end node
* to use some other NBNS node
* to resolve the query.
*/
repeat query with NBNS address
in the response packet;
NEGATIVE NAME QUERY RESPONSE:
return failure;
END /* case */
END /* procedure */5.1.3.4. M-NODE DELETE NAME
time to let go of a name 🦋 the name server gets the release first, and the broadcast cleanup only happens once it's confirmed
PROCEDURE delete_name (name)
/*
* Host initiated processing for a P node
*/
BEGIN
/*
* First, delete name on NBNS
*/
REPEAT
/*
* build packet
*/
...
/*
* send request
*/
unicast NAME RELEASE REQUEST packet to NBNS;
IF receive a WACK RESPONSE THEN
pause(time from TTL field of response);
ELSE
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL retransmit count has been exceeded
or response been received
IF response has been received THEN
CASE packet type OF
POSITIVE NAME RELEASE RESPONSE:
/*
* Deletion of name on b'cast segment is deferred
* until after NBNS has deleted the name
*/
REPEAT
/* build packet */
...
broadcast NAME RELEASE REQUEST;
pause(BCAST_REQ_RETRY_TIMEOUT);
UNTIL rexmt threshold exceeded
return success;
NEGATIVE NAME RELEASE RESPONSE:
/*
* NBNS does want node to delete this
* name
*/
return failure;
END /* case */
END /* procedure */5.1.3.5. M-NODE INCOMING PACKET PROCESSING ✨
Okay so this is the bit where an M node gets a packet and has to decide what to do with it 💅 Processing kicks off whenever a packet shows up at an M node, and the whole thing is basically one big CASE on the packet type 🫶
PROCEDURE process_incoming_packet(packet)
/*
* Processing initiated by incoming packets at a M node
*/
BEGIN
CASE packet type of
NAME CONFLICT DEMAND:
IF name exists in local name table THEN
mark name as in conflict;
return;
NAME QUERY REQUEST:
IF name exists in local name table THEN
BEGIN /* name exists */
/*
* build packet
*/
...
/*
* send response to the IP address and port
* number from which the request was received.
*/
send POSITIVE NAME QUERY RESPONSE ;
return;
END /* exists */
ELSE
BEGIN /* does not exist */
/*
* send response to the requestor
*/
IF request NOT broadcast THEN
/*
* Don't send negative responses to
* queries sent by B nodes
*/
send NEGATIVE NAME QUERY RESPONSE ;
return;
END /* does not exist */
NODE STATUS REQUEST:
BEGIN
/*
* Name of "*" may be used for force node to
* divulge status for administrative purposes
*/
IF name in local name table OR name = "*" THEN
/*
* Build response packet and
* send to requestor node
* Send only those names that are
* in the same scope as the scope
* in the request packet.
*/
send NODE STATUS RESPONSE;
END
NAME RELEASE REQUEST:
/*
* This will be received if the NBNS wants to flush the
* name from the local name table, or from the local
* cache.
*/
IF name exists in the local name table THEN
BEGIN
delete name from local name table;
inform user that name has been deleted;
END
ELSE
IF name has been cached locally THEN
BEGIN
remove entry from cache:
END
NAME REGISTRATION REQUEST (UNIQUE):
IF name exists in local name table THEN
send NEGATIVE NAME REGISTRATION RESPONSE ;
NAME REGISTRATION REQUEST (GROUP):
IF name exists in local name table THEN
BEGIN
IF local entry is a unique name THEN
send NEGATIVE NAME REGISTRATION RESPONSE ;
END
END /* case */
END /* procedure */Here's the vibe: if someone asks about a name the M node already holds, it answers with a POSITIVE NAME QUERY RESPONSE, sent right back to the IP address and port that asked 🎀 If it doesn't have the name, it only sends a NEGATIVE NAME QUERY RESPONSE when the request is not a broadcast. B nodes don't get negative answers to their queries, which is kind of iconic for them 🙈
NODE STATUS REQUEST is a bit special 🧚 The name "*" is a wildcard that lets a force node spill its status for admin purposes, and the response only includes names in the same scope as the request.
NAME RELEASE REQUEST is the NBNS cleaning house 🧹 If the name is in the local name table it gets deleted and the user is told. If it's only in the cache, that entry is removed instead.
For registrations, a UNIQUE request for a name we already have gets a NEGATIVE NAME REGISTRATION RESPONSE, no drama. A GROUP request only gets rejected if the existing local entry is a unique name 💜
5.1.3.6. M-NODE TIMER INITIATED PROCESSING 🦋
Now the timer side of things ⏰ This happens when a timer on an M node expires, and the M node goes around refreshing every name whose TTL has run out 😭
PROCEDURE timer_expired()
/*
* Processing initiated by the expiration of a timer on a M node
*/
BEGIN
/*
* Send a NAME REFRESH REQUEST for each name which the
* TTL which has expired.
*/
REPEAT
build NAME REFRESH REQUEST packet;
REPEAT
send packet to NBNS;
IF receive a WACK RESPONSE THEN
pause(time from TTL field of response);
ELSE
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet is received or
retransmit count has been exceeded
CASE packet type OF
POSITIVE NAME REGISTRATION RESPONSE:
/* successfully refreshed */
reset TTL timer for this name;
NEGATIVE NAME REGISTRATION RESPONSE:
/*
* refused, can't keep name
* assume in conflict
*/
mark name as in conflict;
END /* case */
UNTIL request sent for all names for which TTL
has expired
END /* procedure */So for each expired name, it sends a NAME REFRESH REQUEST to the NBNS and keeps retrying. If a WACK RESPONSE comes back, it waits for the time given in that response's TTL field 🕰️ Otherwise it waits for UCAST_REQ_RETRY_TIMEOUT. It keeps going until either a response arrives or the retransmit count runs out 🌸
If the refresh succeeds, the TTL timer for that name just gets reset ✨ If the NBNS says no with a NEGATIVE NAME REGISTRATION RESPONSE, the M node can't keep the name, so it's marked as in conflict 💀 Rough, but that's the process 🫠
5.1.4. NBNS ACTIVITY 🌈
The NBNS is the one receiving the directed packets, and that means P and M nodes are the ones sending them 📬 Replies always go back as directed packets to the source IP address and UDP port number, and any broadcast packets it receives must be ignored 🚫
5.1.4.1. NBNS INCOMING PACKET PROCESSING ✨
okay so this is the NBNS (NS node) brain 🧠 when a packet comes in, and it's SO many branches. bestie, get comfy 🧸
PROCEDURE process_incoming_packet(packet)
/*
* Incoming packet processing on a NS node
*/
BEGIN
IF packet was sent as a broadcast THEN
BEGIN
discard packet;
return;
END
CASE packet type of
NAME REGISTRATION REQUEST (UNIQUE):
IF unique name exists in data base THEN
BEGIN /* unique name exists */
/*
* NBNS node may be a "passive"
* server in that it expects the
* end node to do the challenge
* server. Such a NBNS node is
* called a "non-secure" server.
* A "secure" server will do the
* challenging before it sends
* back a response packet.
*/
IF non-secure THEN
BEGIN
/*
* build response packet
*/
...
/*
* let end node do the challenge
*/
send END-NODE CHALLENGE NAME REGISTRATION
RESPONSE;
return;
END
ELSE
/*
* secure server - do the name
* challenge operation
*/
REPEAT
send NAME QUERY REQUEST;
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL response has been received or
retransmit count has been exceeded
IF no response was received THEN
BEGIN
/* node down */
update data base - remove entry;
update data base - add new entry;
send POSITIVE NAME REGISTRATION RESPONSE;
return;
END
ELSE
BEGIN /* challenged node replied */
/*
* challenged node replied with
* a response packet
*/
CASE packet type
POSITIVE NAME QUERY RESPONSE:
/*
* name still owned by the
* challenged node
*
* build packet and send response
*/
...
/*
* Note: The NBNS will need to
* keep track (based on transaction id) of
* the IP address and port number
* of the original requestor.
*/
send NEGATIVE NAME REGISTRATION RESPONSE;
return;
NEGATIVE NAME QUERY RESPONSE:
update data base - remove entry;
update data base - add new entry;
/*
* build response packet and send
* response
*/
send POSITIVE NAME REGISTRATION RESPONSE;
return;
END /* case */
END /* challenged node replied */
END /* unique name exists in data base */
ELSE
IF group name exists in data base THEN
BEGIN /* group names exists */
/*
* Members of a group name are NOT
* challenged.
* Make the assumption that
* at least some of the group members
* are still alive.
* Refresh mechanism will
* allow the NBNS to detect when all
* members of a group no longer use that
* name
*/
send NEGATIVE NAME REGISTRATION RESPONSE;
END /* group name exists */
ELSE
BEGIN /* name does not exist */
/*
* Name does not exist in data base
*
* This code applies to both non-secure
* and secure server.
*/
update data base - add new entry;
send POSITIVE NAME REGISTRATION RESPONSE;
return;
END
NAME QUERY REQUEST:
IF name exists in data base THEN
BEGIN
/*
* build response packet and send to
* requestor
*/
...
send POSITIVE NAME QUERY RESPONSE;
return;
ELSE
BEGIN
/*
* build response packet and send to
* requestor
*/
...
send NEGATIVE NAME QUERY RESPONSE;
return;
END
NAME REGISTRATION REQUEST (GROUP):
IF name exists in data base THEN
BEGIN
IF local entry is a unique name THEN
BEGIN /* local is unique */
IF non-secure THEN
BEGIN
send END-NODE CHALLENGE NAME
REGISTRATION RESPONSE;
return;
END
REPEAT
send NAME QUERY REQUEST;
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL response received or
retransmit count exceeded
IF no response received or
NEGATIVE NAME QUERY RESPONSE
received THEN
BEGIN
update data base - remove entry;
update data base - add new entry;
send POSITIVE NAME REGISTRATION RESPONSE;
return;
END
ELSE
BEGIN
/*
* name still being held
* by challenged node
*/
send NEGATIVE NAME REGISTRATION RESPONSE;
END
END /* local is unique */
ELSE
BEGIN /* local is group */
/*
* existing entry is a group name
*/
update data base - remove entry;
update data base - add new entry;
send POSITIVE NAME REGISTRATION RESPONSE;
return;
END /* local is group */
END /* names exists */
ELSE
BEGIN /* does not exist */
/* name does not exist in data base */
update data base - add new entry;
send POSITIVE NAME REGISTRATION RESPONSE;
return;
END /* does not exist */
NAME RELEASE REQUEST:
/*
* secure server may choose to disallow
* a node from deleting a name
*/
update data base - remove entry;
send POSITIVE NAME RELEASE RESPONSE;
return;
NAME UPDATE REQUEST:
/*
* End-node completed a successful challenge,
* no update database
*/
IF secure server THEN
send NEGATIVE NAME REGISTRATION RESPONSE;
ELSE
BEGIN /* new entry */
IF entry already exists THEN
update data base - remove entry;
update data base - add new entry;
send POSITIVE NAME REGISTRATION RESPONSE;
start_timer(TTL);
END
NAME REFRESH REQUEST:
check for consistency;
IF node not allowed to have name THEN
BEGIN
/*
* tell end node that it can't have name
*/
send NEGATIVE NAME REGISTRATION RESPONSE;
END
ELSE
BEGIN
/*
* send confirmation response to the
* end node.
*/
send POSITIVE NAME REGISTRATION;
start_timer(TTL);
END
return;
END /* case */
END /* procedure */5.1.4.2. NBNS TIMER INITIATED PROCESSING 🕰️
so a NS node uses timers to flush out old entries from the data base 🧹 every entry gets zapped the second its timer runs out. and that timer is a multiple of the refresh TTL that got set when the name was first registered 💅
PROCEDURE timer_expired()
/*
* processing initiated by expiration of TTL for a given name
*/
BEGIN
/*
* NBNS can (optionally) ensure
* that the node is actually down
* by sending a NODE STATUS REQUEST.
* If such a request is sent, and
* no response is received, it can
* be assumed that the node is down.
*/
remove entry from data base;
END5.2. SESSION SERVICE PROTOCOLS 🎀
okay now we're in the session service era 🦋 first up, a few variables that the NetBIOS user should be able to configure. the default values are over in "Defined Constants and Variables" in the Detailed Specification.):
SSN_RETRY_COUNT- the max number of TCP connection attempts allowed for a single NetBIOS call request 🔁SSN_CLOSE_TIMEOUTis how long to wait when closing the NetBIOS session before killing the TCP connection, but only if session sends are still outstanding ⏳
next, the Defined Constants for the NetBIOS Session Service 💜 (check "Defined Constants and Variables" in the Detailed Specification for their values, obvi):
SSN_SRVC_TCP_PORT- this is the globally well-known TCP port reserved for the NetBIOS Session Service 🌈 the service takes TCP connections on this port to set up NetBIOS Sessions. the caller's TCP connection to this port is first used to swap NetBIOS control info. the actual NetBIOS data connection may also go through this port or, via the retargetting facility, through another port 🧚
5.2.1. SESSION ESTABLISHMENT PROTOCOLS ✨
5.2.1.1. USER REQUEST PROCESSING
Okay, this is where the session setup gets real. Here's how a listener and a caller do their thing for B, P and M nodes 💅
PROCEDURE listen(listening name, caller name)
/*
* User initiated processing for B, P and M nodes
*
* This procedure assumes that an incoming session will be
* retargetted here by a session server.
*/
BEGIN
Do TCP listen; /* Returns TCP port used */
Register listen with Session Service, give names and
TCP port;
Wait for TCP connection to open; /* Incoming call */
Read SESSION REQUEST packet from connection
Process session request (see section on
processing initiated by the reception of session
service packets);
Inform Session Service that NetBIOS listen is complete;
IF session established THEN
return success and session information to user;
ELSE
return failure;
END /* procedure */
PROCEDURE call(calling name, called name)
/*
* user initiated processing for B, P and M nodes
*/
/*
* This algorithm assumes that the called name is a unique name.
* If the called name is a group name, the call() procedure
* needs to cycle through the members of the group
* until either (retry_count == SSN_RETRY_COUNT) or
* the list has been exhausted.
*/
BEGIN
retry_count = 0;
retarget = FALSE; /* TRUE: caller is being retargetted */
name_query = TRUE; /* TRUE: caller must begin again with */
/* name query. */
REPEAT
IF name_query THEN
BEGIN
do name discovery, returns IP address;
TCP port = SSN_SRVC_TCP_PORT;
IF name discovery fails THEN
return failure;
ELSE
name_query = FALSE;
END
/*
* now have IP address and TCP port of
* remote party.
*/
establish TCP connection with remote party, use an
ephemeral port as source TCP port;
IF connection refused THEN
BEGIN
IF retarget THEN
BEGIN
/* retry */
retarget = FALSE;
use original IP address and TCP port;
goto LOOP;
END
/* retry for just missed TCP listen */
pause(SESSION_RETRY_TIMER);
establish TCP connection, again use ephemeral
port as source TCP port;
IF connection refused OR
connection timed out THEN
return failure;
END
ELSE
IF connection timed out THEN
BEGIN
IF retarget THEN
BEGIN
/* retry */
retarget = FALSE;
use original IP address and TCP port;
goto LOOP;
END
ELSE
BEGIN
/*
* incorrect name discovery was done,
* try again
*/
inform name discovery process of
possible error;
name_query = TRUE;
goto LOOP;
END
END
/*
* TCP connection has been established
*/
wait for session response packet;
CASE packet type OF
POSITIVE SESSION RESPONSE:
return success and session established
information;
NEGATIVE SESSION RESPONSE:
BEGIN
CASE error OF
NOT LISTENING ON CALLED NAME:
NOT LISTENING FOR CALLING NAME:
BEGIN
kill TCP connection;
return failure;
END
CALLED NAME NOT PRESENT:
BEGIN
/*
* called name does not exist on
* remote node
*/
inform name discovery procedure
of possible error;
IF this is a P or M node THEN
BEGIN
/*
* Inform NetBIOS Name Server
* it has returned incorrect
* information.
*/
send NAME RELEASE REQUEST for called
name and IP address to
NetBIOS Name Server;
END
/* retry from beginning */
retarget = FALSE;
name_query = TRUE;
goto LOOP;
END /* called name not present */
END /* case */
END /* negative response */
RETARGET SESSION RESPONSE:
BEGIN
close TCP connection;
extract IP address and TCP port from
response;
retarget = TRUE;
END /* retarget response */
END /* case */
LOOP: retry_count = retry_count + 1;
UNTIL (retry_count > SSN_RETRY_COUNT);
return failure;
END /* procedure */5.2.1.2. RECEIVED PACKET PROCESSING
These are the packets that show up on a TCP connection before the session is officially a thing 🎀 The listen routines hanging off a NetBIOS user process don't need to handle the RETARGET response bit, okay? The user process version, when it's separate from a shared Session Service, only has to say yes (POSITIVE SESSION RESPONSE) or no (NEGATIVE SESSION RESPONSE) to a session request. Simple and iconic 🦋
PROCEDURE session_packet(packet)
/*
* processing initiated by receipt of a session service
* packet for a session in the session establishment phase.
* Assumes the TCP connection has been accepted.
*/
BEGIN
CASE packet type
SESSION REQUEST:
BEGIN
IF called name does not exist on node THEN
BEGIN
send NEGATIVE SESSION RESPONSE with CALLED
NAME NOT PRESENT error code;
close TCP connection;
END
Search for a listen with CALLING NAME for CALLED
NAME;
IF matching listen is found THEN
BEGIN
IF port of listener process is port TCP
connection is on THEN
BEGIN
send POSITIVE SESSION RESPONSE;
Hand off connection to client process
and/or inform user session is
established;
END
ELSE
BEGIN
send RETARGET SESSION RESPONSE with
listener's IP address and
TCP port;
close TCP connection;
END
END
ELSE
BEGIN
/* no matching listen pending */
send NEGATIVE SESSION RESPONSE with either
NOT LISTENING ON CALLED NAME or NOT
LISTENING FOR CALLING NAME error
code;
close TCP connection;
END
END /* session request */
END /* case */
END /* procedure */5.2.2. SESSION DATA TRANSFER PROTOCOLS
5.2.2.1. USER REQUEST PROCESSING
Time for the actual chatting part 💬✨
PROCEDURE send_message(user_message)
BEGIN
build SESSION MESSAGE header;
send SESSION MESSAGE header;
send user_message;
reset and restart keep-alive timer;
IF send fails THEN
BEGIN
/*
* TCP connection has failed */
*/
close NetBIOS session;
inform user that session is lost;
return failure;
END
ELSE
return success;
END5.2.2.2. RECEIVED PACKET PROCESSING
These are packets that arrive after the session is up and running 🌸
PROCEDURE session_packet(packet)
/*
* processing initiated by receipt of a session service
* packet for a session in the data transfer phase.
*/
BEGIN
CASE packet type OF
SESSION MESSAGE:
BEGIN
process message header;
read in user data;
reset and restart keep-alive timer;
deliver data to user;
END /* session message */
SESSION KEEP ALIVE:
discard packet;
END /* case */
END /* procedure */5.2.2.3. PROCESSING INITIATED BY TIMER
When the session keep-alive timer goes off, this is what happens 🧚
PROCEDURE session_ka_timer()
/*
* processing initiated when session keep alive timer expires
*/
BEGIN
send SESSION KEEP ALIVE, if configured;
IF send fails THEN
BEGIN
/* remote node, or path to it, is down */
abort TCP connection;
close NetBIOS session;
inform user that session is lost;
return;
END
END /* procedure */5.2.3. SESSION TERMINATION PROTOCOLS
5.2.3.1. USER REQUEST PROCESSING
Ending a session the polite way first, and then the not-so-polite way if it takes too long 🙈
PROCEDURE close_session()
/* initiated by a user request to close a session */
BEGIN
close gracefully the TCP connection;
WAIT for the connection to close or SSN_CLOSE_TIMEOUT
to expire;
IF time out expired THEN
abort TCP connection;
END /* procedure */5.2.3.2. RECEPTION INDICATION PROCESSING
Okay, so if the other side wants to close the session, here's how we handle it 💅
PROCEDURE close_indication()
/*
* initiated by a TCP indication of a close request from
* the remote connection partner.
*/
BEGIN
close gracefully TCP connection;
close NetBIOS session;
inform user session closed by remote partner;
END /* procedure */5.3. NetBIOS DATAGRAM SERVICE PROTOCOLS
Now for the datagram side of things, which is giving fast and loose vibes 🦋 These are the GLOBAL variables you're allowed to configure as a NetBIOS user:
- SCOPE_ID: this is the non-leaf part of a domain name, with a leading '.' in front of it. It's the domain for the NetBIOS scope of the NetBIOS name. The protocol description that follows only supports single scope operation, so keep that in mind 🌈
- MAX_DATAGRAM_LENGTH: this is the maximum length of an IP datagram. The minimal maximum length defined in for IP is 576 bytes. The value helps decide whether a NetBIOS datagram needs to be fragmented. Implementations are expected to be able to receive unfragmented NetBIOS datagrams up to their maximum size, which is very much a main character requirement ✨
- BROADCAST_ADDRESS: this is the IP address B-nodes use when they send datagrams to group name destinations and broadcast datagrams. By default it's the IP broadcast address for a single IP network 🍓
Here are the Defined Constants for the NetBIOS Datagram Service 💖
- DGM_SRVC_UDP_PORT: this is the globally well-known UDP port where the NetBIOS Datagram Service receives UDP packets. Check section 6, "Defined Constants", for its value 👑
5.3.1. B NODE TRANSMISSION OF NetBIOS DATAGRAMS ✨
okay so this is the B node sending side, and it's giving step by step energy 💅 first the node does name discovery on the destination name to get back a name type and an IP address. if that name is a group name, the node flips group to TRUE. then it builds the datagram service UDP packet, converting the source and destination NetBIOS names into half-ASCII, biased encoded names and tacking on the SCOPE_ID. 🦋
the source is this node's own IP and the DGM_SRVC_UDP_PORT, and the destination depends on whether it's a NetBIOS broadcast (then it's * plus the scope) or a regular name. after that it picks one of BROADCAST, DIRECT_UNIQUE, or DIRECT_GROUP, grabs a fresh transaction id for datagrams, and works out the length.
now the fun part: if the whole thing (with UDP and IP headers) is bigger than MAX_DATAGRAM_LENGTH, it gets split into two UDP packets. the first one carries the names plus whatever data fits, with MORE and FIRST set and OFFSET at 0. the second one copies the datagram header, carries the rest of the data, clears MORE and FIRST, and sets its OFFSET. if it fits in one packet, it's just the data with FIRST set, MORE cleared, and OFFSET at 0. ✨
finally, group or broadcast traffic goes to BROADCAST_ADDRESS, and everything else goes straight to the IP address that name discovery gave back. iconic routing 👑
PROCEDURE send_datagram(data, source, destination, broadcast)
/*
* user initiated processing on B node
*/
BEGIN
group = FALSE;
do name discovery on destination name, returns name type and
IP address;
IF name type is group name THEN
BEGIN
group = TRUE;
END
/*
* build datagram service UDP packet;
*/
convert source and destination NetBIOS names into
half-ASCII, biased encoded name;
SOURCE_NAME = cat(source, SCOPE_ID);
SOURCE_IP = this nodes IP address;
SOURCE_PORT = DGM_SRVC_UDP_PORT;
IF NetBIOS broadcast THEN
BEGIN
DESTINATION_NAME = cat("*", SCOPE_ID)
END
ELSE
BEGIN
DESTINATION_NAME = cat(destination, SCOPE_ID)
END
MSG_TYPE = select_one_from_set
{BROADCAST, DIRECT_UNIQUE, DIRECT_GROUP}
DGM_ID = next transaction id for Datagrams;
DGM_LENGTH = length of data + length of second level encoded
source and destination names;
IF (length of the NetBIOS Datagram, including UDP and
IP headers, > MAX_DATAGRAM_LENGTH) THEN
BEGIN
/*
* fragment NetBIOS datagram into 2 UDP packets
*/
Put names into 1st UDP packet and any data that fits
after names;
Set MORE and FIRST bits in 1st UDP packet's FLAGS;
OFFSET in 1st UDP = 0;
Replicate NetBIOS Datagram header from 1st UDP packet
into 2nd UDP packet;
Put rest of data in 2nd UDP packet;
Clear MORE and FIRST bits in 2nd UDP packet's FLAGS;
OFFSET in 2nd UDP = DGM_LENGTH - number of name and
data bytes in 1st UDP;
END
BEGIN
/*
* Only need one UDP packet
*/
USER_DATA = data;
Clear MORE bit and set FIRST bit in FLAGS;
OFFSET = 0;
END
IF (group == TRUE) OR (NetBIOS broadcast) THEN
BEGIN
send UDP packet(s) to BROADCAST_ADDRESS;
END
ELSE
BEGIN
send UDP packet(s) to IP address returned by name
discovery;
END
END /* procedure */5.3.2. P AND M NODE TRANSMISSION OF NetBIOS DATAGRAMS 🌸
same vibe as the B node, bestie, with one big difference: P and M nodes can't just blast out broadcasts and multicasts the way B nodes do 🙈 so for group or broadcast datagrams they first try a DATAGRAM QUERY REQUEST to the NBDD. sending that query is optional, and the node is allowed to send the datagram straight to the NBDD without asking, though the NBDD may just throw it away 💀
if the NBDD answers with a POSITIVE QUERY RESPONSE, the packets go to the NBDD Server IP address. if not, the node gets the list of destination nodes from the NBNS and sends the UDP packets to each one of them, one at a time. everything else (plain unique names) goes to the IP address from name discovery, just like on B nodes. the packet building and fragmenting part is literally identical, so you already know that bit 🫶
PROCEDURE send_datagram(data, source, destination, broadcast)
/*
* User initiated processing on P and M node.
*
* This processing is the same as for B nodes except for
* sending broadcast and multicast NetBIOS datagrams.
*/
BEGIN
group = FALSE;
do name discovery on destination name, returns name type
and IP address;
IF name type is group name THEN
BEGIN
group = TRUE;
END
/*
* build datagram service UDP packet;
*/
convert source and destination NetBIOS names into
half-ASCII, biased encoded name;
SOURCE_NAME = cat(source, SCOPE_ID);
SOURCE_IP = this nodes IP address;
SOURCE_PORT = DGM_SRVC_UDP_PORT;
IF NetBIOS broadcast THEN
BEGIN
DESTINATION_NAME = cat("*", SCOPE_ID)
END
ELSE
BEGIN
DESTINATION_NAME = cat(destination, SCOPE_ID)
END
MSG_TYPE = select_one_from_set
{BROADCAST, DIRECT_UNIQUE, DIRECT_GROUP}
DGM_ID = next transaction id for Datagrams;
DGM_LENGTH = length of data + length of second level encoded
source and destination names;
IF (length of the NetBIOS Datagram, including UDP and
IP headers, > MAX_DATAGRAM_LENGTH) THEN
BEGIN
/*
* fragment NetBIOS datagram into 2 UDP packets
*/
Put names into 1st UDP packet and any data that fits
after names;
Set MORE and FIRST bits in 1st UDP packet's FLAGS;
OFFSET in 1st UDP = 0;
Replicate NetBIOS Datagram header from 1st UDP packet
into 2nd UDP packet;
Put rest of data in 2nd UDP packet;
Clear MORE and FIRST bits in 2nd UDP packet's FLAGS;
OFFSET in 2nd UDP = DGM_LENGTH - number of name and
data bytes in 1st UDP;
END
BEGIN
/*
* Only need one UDP packet
*/
USER_DATA = data;
Clear MORE bit and set FIRST bit in FLAGS;
OFFSET = 0;
END
IF (group == TRUE) OR (NetBIOS broadcast) THEN
BEGIN
/*
* Sending of following query is optional.
* Node may send datagram to NBDD immediately
* but NBDD may discard the datagram.
*/
send DATAGRAM QUERY REQUEST to NBDD;
IF response is POSITIVE QUERY RESPONSE THEN
send UDP packet(s) to NBDD Server IP address;
ELSE
BEGIN
get list of destination nodes from NBNS;
FOR EACH node in list
BEGIN
send UDP packet(s) to this node's
IP address;
END
END
END
ELSE
BEGIN
send UDP packet(s) to IP address returned by name
discovery;
END /* procedure */5.3.3. RECEPTION OF NetBIOS DATAGRAMS BY ALL NODES 🦋
this is the receiving side, and it's for everyone: B, P, and M nodes all do the same thing here. the algorithm throws away NetBIOS Datagram fragments that show up out of order. an implementation that puts out-of-order fragments back together is still conforming to this spec, so you do you, queen 👑 each fragment discard timer starts at FRAGMENT_TO, and that value should be user configurable. the default is in Section 6, "Defined Constants and Variables", so go check it out 🧚
in the code, P nodes ignore broadcast packets right away. then it checks the packet type. for a DATAGRAM SERVICE packet, if FIRST is set and MORE is set, the node saves that first fragment and starts its discard timer. if FIRST is set and MORE isn't, it's just one packet. if FIRST isn't set, it's the second fragment, so the node looks for the first one by source IP address and DGM_ID. no match means the second fragment gets tossed 💀
after that, a * destination goes to every outstanding broadcast receive request. anything else gets checked against the local name table. if the name isn't there, the node sends a DATAGRAM ERROR packet back and drops the UDP packets. if it is there, the data gets copied to every pending receive operation whose source name matches the destination name. ✨
a DATAGRAM ERROR is basically the name service saying "oops, my bad," so the node tells its local name service the info was wrong. P and M nodes also send a NAME RELEASE REQUEST to the NetBIOS Name Server, because it might have handed out bad info too 🌈
PROCEDURE datagram_packet(packet)
/*
* processing initiated by datagram packet reception
* on B, P and M nodes
*/
BEGIN
/*
* if this node is a P node, ignore
* broadcast packets.
*/
IF this is a P node AND incoming packet is
a broadcast packet THEN
BEGIN
discard packet;
END
CASE packet type OF
DATAGRAM SERVICE:
BEGIN
IF FIRST bit in FLAGS is set THEN
BEGIN
IF MORE bit in FLAGS is set THEN
BEGIN
Save 1st UDP packet of the Datagram;
Set this Datagram's fragment discard
timer to FRAGMENT_TO;
return;
END
ELSE
Datagram is composed of a single
UDP packet;
END
ELSE
BEGIN
/* Have the second fragment of a Datagram */
Search for 1st fragment by source IP address
and DGM_ID;
IF found 1st fragment THEN
Process both UDP packets;
ELSE
BEGIN
discard 2nd fragment UDP packet;
return;
END
END
IF DESTINATION_NAME is '*' THEN
BEGIN
/* NetBIOS broadcast */
deliver USER_DATA from UDP packet(s) to all
outstanding receive broadcast
datagram requests;
return;
END
ELSE
BEGIN /* non-broadcast */
/* Datagram for Unique or Group Name */
IF DESTINATION_NAME is not present in the
local name table THEN
BEGIN
/* destination not present */
build DATAGRAM ERROR packet, clear
FIRST and MORE bit, put in
this nodes IP and PORT, set
ERROR_CODE;
send DATAGRAM ERROR packet to
source IP address and port
of UDP;
discard UDP packet(s);
return;
END
ELSE
BEGIN /* good */
/*
* Replicate received NetBIOS datagram for
* each recipient
*/
FOR EACH pending NetBIOS user's receive
datagram operation
BEGIN
IF source name of operation
matches destination name
of packet THEN
BEGIN
deliver USER_DATA from UDP
packet(s);
END
END /* for each */
return;
END /* good */
END /* non-broadcast */
END /* datagram service */
DATAGRAM ERROR:
BEGIN
/*
* name service returned incorrect information
*/
inform local name service that incorrect
information was provided;
IF this is a P or M node THEN
BEGIN
/*
* tell NetBIOS Name Server that it may
* have given incorrect information
*/
send NAME RELEASE REQUEST with name
and incorrect IP address to NetBIOS
Name Server;
END
END /* datagram error */
END /* case */
END5.3.4. PROTOCOLS FOR THE NBDD ✨
okay so the big secret to NetBIOS Datagram forwarding is that the packet that lands at the destination end node has to keep the exact same NetBIOS header it would've had if the source end node sent it straight there 🎀. That's why the NBDD doesn't reassemble NetBIOS Datagrams. It just forwards the UDP packet as is 💅
the datagram_packet procedure is the NBDD's whole playbook 🔥
PROCEDURE datagram_packet(packet)
/*
* processing initiated by a incoming datagram service
* packet on a NBDD node.
*/
BEGIN
CASE packet type OF
DATAGRAM SERVICE:
BEGIN
IF packet was sent as a directed
NetBIOS datagram THEN
BEGIN
/*
* provide group forwarding service
*
* Forward datagram to each member of the
* group. Can forward via:
* 1) get list of group members and send
* the DATAGRAM SERVICE packet unicast
* to each
* 2) use Group Multicast, if available
* 3) combination of 1) and 2)
*/
...
END
ELSE
BEGIN
/*
* provide broadcast forwarding service
*
* Forward datagram to every node in the
* NetBIOS scope. Can forward via:
* 1) get list of group members and send
* the DATAGRAM SERVICE packet unicast
* to each
* 2) use Group Multicast, if available
* 3) combination of 1) and 2)
*/
...
END
END /* datagram service */
DATAGRAM ERROR:
BEGIN
/*
* Should never receive these because Datagrams
* forwarded have source end node IP address and
* port in NetBIOS header.
*/
send DELETE NAME REQUEST with incorrect name and
IP address to NetBIOS Name Server;
END /* datagram error */
DATAGRAM QUERY REQUEST:
BEGIN
IF can send packet to DESTINATION_NAME THEN
BEGIN
/*
* NBDD is able to relay Datagrams for
* this name
*/
send POSITIVE DATAGRAM QUERY RESPONSE to
REQUEST source IP address and UDP port
with request's DGM_ID;
END
ELSE
BEGIN
/*
* NBDD is NOT able to relay Datagrams for
* this name
*/
send NEGATIVE DATAGRAM QUERY RESPONSE to
REQUEST source IP address and UDP port
with request's DGM_ID;
END
END /* datagram query request */
END /* case */
END /* procedure */so basically there are three cases 🧚. a datagram service packet gets forwarded to a group if it was sent as a directed NetBIOS datagram, and to every node in the NetBIOS scope otherwise. a datagram error should literally never show up 💀, because forwarded datagrams already carry the source end node's IP address and port in the NetBIOS header. if one does show up anyway, the NBDD sends a DELETE NAME REQUEST with the incorrect name and IP address to the NetBIOS Name Server. and a datagram query request gets a POSITIVE DATAGRAM QUERY RESPONSE if the NBDD can relay for that name, or a NEGATIVE one if it can't, both sent back to the request's source IP address and UDP port with the request's DGM_ID 🫶
6. DEFINED CONSTANTS AND VARIABLES 🌈
okay bestie, time for the cheat sheet 📝 these are the constants and variables, and every single value here is exactly as the spec has it.
GENERAL:
GENERAL:
SCOPE_ID The name of the NetBIOS scope.
This is expressed as a character
string meeting the requirements of
the domain name system and without
a leading or trailing "dot".
An implementation may elect to make
this a single global value for the
node or allow it to be specified
with each separate NetBIOS name
(thus permitting cross-scope
references.)
BROADCAST_ADDRESS An IP address composed of the
nodes's network and subnetwork
numbers with all remaining bits set
to one.
I.e. "Specific subnet" broadcast
addressing according to section 2.3
of RFC 950.
BCAST_REQ_RETRY_TIMEOUT 250 milliseconds.
An adaptive timer may be used.
BCAST_REQ_RETRY_COUNT 3
UCAST_REQ_RETRY_TIMEOUT 5 seconds
An adaptive timer may be used.
UCAST_REQ_RETRY_COUNT 3
MAX_DATAGRAM_LENGTH 576 bytes (default)NAME SERVICE:
NAME SERVICE:
REFRESH_TIMER Negotiated with NBNS for each name.
CONFLICT_TIMER 1 second
Implementations may chose a longer
value.
NAME_SERVICE_TCP_PORT 137 (decimal)
NAME_SERVICE_UDP_PORT 137 (decimal)
INFINITE_TTL 0SESSION SERVICE:
SESSION SERVICE:
SSN_SRVC_TCP_PORT 139 (decimal)
SSN_RETRY_COUNT 4 (default)
Re-configurable by user.
SSN_CLOSE_TIMEOUT 30 seconds (default)
Re-configurable by user.
SSN_KEEP_ALIVE_TIMEOUT 60 seconds, recommended, may be set to
a higher value.
(Session keep-alives are used only
if configured.)DATAGRAM SERVICE:
DATAGRAM SERVICE:
DGM_SRVC_UDP_PORT 138 (decimal)
FRAGMENT_TO 2 seconds (default)REFERENCES 📚
[1] "Protocol Standard For a NetBIOS Service on a TCP/UDP
Transport: Concepts and Methods", RFC 1001, March 1987.
[2] J. Reynolds, J. Postel, "Assigned Numbers", RFC 990, November
1986.
[3] P. Mockapetris, "Domain Names - Implementation and
Specification", RFC 883, November 1983.📦 where this page comes from
- ietf: rfc1002 1987-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms