summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1002.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1002.txt')
-rw-r--r--doc/rfc/rfc1002.txt5012
1 files changed, 5012 insertions, 0 deletions
diff --git a/doc/rfc/rfc1002.txt b/doc/rfc/rfc1002.txt
new file mode 100644
index 0000000..6e53173
--- /dev/null
+++ b/doc/rfc/rfc1002.txt
@@ -0,0 +1,5012 @@
+
+Network Working Group
+Request for Comments: 1002 March, 1987
+
+
+
+
+ PROTOCOL STANDARD FOR A NetBIOS SERVICE
+ ON A TCP/UDP TRANSPORT:
+ DETAILED SPECIFICATIONS
+
+
+
+
+ ABSTRACT
+
+This RFC defines a proposed standard protocol to support NetBIOS
+services in a TCP/IP environment. Both local network and internet
+operation are supported. Various node types are defined to accommodate
+local and internet topologies and to allow operation with or without the
+use of IP broadcast.
+
+This RFC gives the detailed specifications of the NetBIOS-over-TCP
+packets, protocols, and defined constants and variables. A more general
+overview is found in a companion RFC, "Protocol Standard For a NetBIOS
+Service on a TCP/UDP Transport: Concepts and Methods".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 1]
+
+RFC 1002 March 1987
+
+
+ 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
+
+
+
+NetBIOS Working Group [Page 2]
+
+RFC 1002 March 1987
+
+
+ 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 85
+
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 3]
+
+RFC 1002 March 1987
+
+
+ PROTOCOL STANDARD FOR A NetBIOS SERVICE
+ ON A TCP/UDP TRANSPORT:
+ DETAILED SPECIFICATIONS
+
+
+1. STATUS OF THIS MEMO
+
+ This RFC specifies a proposed standard for the DARPA Internet
+ community. Since this topic is new to the Internet community,
+ discussions and suggestions are specifically requested.
+
+ Please send written comments to:
+
+ Karl Auerbach
+ Epilogue Technology Corporation
+ P.O. Box 5432
+ Redwood City, CA 94063
+
+ Please send online comments to:
+
+ Avnish Aggarwal
+ Internet: mtxinu!excelan!avnish@ucbvax.berkeley.edu
+ Usenet: ucbvax!mtxinu!excelan!avnish
+
+ Distribution of this memorandum is unlimited.
+
+2. ACKNOWLEDGEMENTS
+
+ This RFC has been developed under the auspices of the Internet
+ Activities Board.
+
+ The following individuals have contributed to the development of
+ 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 Wu
+
+ The system proposed by this RFC does not reflect any existing
+ Netbios-over-TCP implementation. However, the design
+ incorporates considerable knowledge obtained from prior
+ implementations. Special thanks goes to the following
+ organizations which have provided this invaluable information:
+
+ CMC/Syros Excelan Sytek Ungermann-Bass
+
+
+
+
+NetBIOS Working Group [Page 4]
+
+RFC 1002 March 1987
+
+
+3. INTRODUCTION
+
+ This RFC contains the detailed packet formats and protocol
+ specifications for NetBIOS-over-TCP. This RFC is a companion to
+ RFC 1001, "Protocol Standard For a NetBIOS Service on a TCP/UDP
+ Transport: Concepts and Methods" [1].
+
+4. PACKET DESCRIPTIONS
+
+ Bit and byte ordering are defined by the most recent version of
+ "Assigned Numbers" [2].
+
+4.1. NAME FORMAT
+
+ The NetBIOS name representation in all NetBIOS packets (for NAME,
+ SESSION, and DATAGRAM services) is defined in the Domain Name
+ Service RFC 883[3] as "compressed" name messages. This format is
+ called "second-level encoding" in the section entitled
+ "Representation of NetBIOS Names" in the Concepts and Methods
+ document.
+
+ For ease of description, the first two paragraphs from page 31,
+ the section titled "Domain name representation and compression",
+ of RFC 883 are replicated here:
+
+ 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.
+
+ The following is the uncompressed representation of the NetBIOS name
+ "FRED ", which is the 4 ASCII characters, F, R, E, D, followed by 12
+ space characters (0x20). This name has the SCOPE_ID: "NETBIOS.COM"
+
+ EGFCEFEECACACACACACACACACACACACA.NETBIOS.COM
+
+ This uncompressed representation of names is called "first-level
+ encoding" in the section entitled "Representation of NetBIOS Names"
+ in the Concepts and Methods document.
+
+ The following is a pictographic representation of the compressed
+ representation of the previous uncompressed Domain Name
+ representation.
+
+
+
+NetBIOS Working Group [Page 5]
+
+RFC 1002 March 1987
+
+
+ 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) | 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 representation is the number of bytes in the label. For
+ the above example, the first 0x20 is the number of bytes in the
+ left-most label, EGFCEFEECACACACACACACACACACACACA, of the domain
+ name. The bytes following the label length count are the characters
+ of the label. The following labels are in sequence after the first
+ label, which is the encoded NetBIOS name, until a zero (0x00) length
+ count. The zero length count represents the root label, which is
+ always null.
+
+ A label length count is actually a 6-bit field in the label length
+ field. The most significant 2 bits of the field, bits 7 and 6, are
+ flags allowing an escape from the above compressed representation.
+ If bits 7 and 6 are both set (11), the following 14 bits are an
+ offset pointer into the full message to the actual label string from
+ another domain name that belongs in this name. This label pointer
+ allows for a further compression of a domain name in a packet.
+
+ NetBIOS implementations can only use label string pointers in Name
+ Service packets. They cannot be used in Session or Datagram Service
+ packets.
+
+
+
+
+NetBIOS Working Group [Page 6]
+
+RFC 1002 March 1987
+
+
+ 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)].
+
+ Note that the first octet of a compressed name must contain one of
+ the following bit patterns. (An "x" indicates a bit whose value may
+ be either 0 or 1.):
+
+ 00100000 - Netbios name, length must be 32 (decimal)
+ 11xxxxxx - Label string pointer
+ 10xxxxxx - Reserved
+ 01xxxxxx - Reserved
+
+4.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 are compatible with the existing DNS packet formats,
+ however, additional types and codes have been added to work with
+ NetBIOS.
+
+ If Name Service packets are sent over a TCP connection they are
+ preceded by a 16 bit unsigned integer representing 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 /
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+NetBIOS Working Group [Page 7]
+
+RFC 1002 March 1987
+
+
+4.2.1.1. HEADER
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Field Description
+
+ NAME_TRN_ID Transaction ID for Name Service Transaction.
+ Requestor places a unique value for each active
+ transaction. Responder puts NAME_TRN_ID value
+ from request packet in response packet.
+
+ OPCODE Packet type code, see table below.
+
+ NM_FLAGS Flags for operation, see table below.
+
+ RCODE Result codes of request. Table of RCODE values
+ for each response packet below.
+
+ QDCOUNT Unsigned 16 bit integer specifying the number of
+ entries in the question section of a Name
+
+ Service packet. Always zero (0) for responses.
+ Must be non-zero for all NetBIOS Name requests.
+
+ ANCOUNT Unsigned 16 bit integer specifying the number of
+ resource records in the answer section of a Name
+ Service packet.
+
+ NSCOUNT Unsigned 16 bit integer specifying the number of
+ resource records in the authority section of a
+ Name Service packet.
+
+ ARCOUNT Unsigned 16 bit integer specifying the number of
+ resource records in the additional records
+ section of a Name Service packet.
+
+ The OPCODE field is defined as:
+
+ 0 1 2 3 4
+ +---+---+---+---+---+
+ | R | OPCODE |
+ +---+---+---+---+---+
+
+
+
+
+NetBIOS Working Group [Page 8]
+
+RFC 1002 March 1987
+
+
+ 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.
+
+ The NM_FLAGS field is defined as:
+
+
+ 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.
+
+
+
+NetBIOS Working Group [Page 9]
+
+RFC 1002 March 1987
+
+
+ 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.
+
+4.2.1.2. QUESTION SECTION
+
+ 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:
+
+
+
+
+NetBIOS Working Group [Page 10]
+
+RFC 1002 March 1987
+
+
+ Symbol Value Description:
+
+ IN 0x0001 Internet class
+
+4.2.1.3. RESOURCE RECORD
+
+ 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
+
+
+
+NetBIOS Working Group [Page 11]
+
+RFC 1002 March 1987
+
+
+ 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 class
+
+ NB_FLAGS field of the RESOURCE RECORD RDATA field for RR_TYPE of
+ "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.
+
+ The NB_ADDRESS field of the RESOURCE RECORD RDATA field for
+ RR_TYPE of "NB" is the IP address of the name's owner.
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 12]
+
+RFC 1002 March 1987
+
+
+4.2.2. NAME REGISTRATION REQUEST
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 13]
+
+RFC 1002 March 1987
+
+
+4.2.3. NAME OVERWRITE REQUEST & DEMAND
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 14]
+
+RFC 1002 March 1987
+
+
+4.2.4. NAME REFRESH REQUEST
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 15]
+
+RFC 1002 March 1987
+
+
+4.2.5. POSITIVE NAME REGISTRATION 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 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
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+NetBIOS Working Group [Page 16]
+
+RFC 1002 March 1987
+
+
+ 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
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 17]
+
+RFC 1002 March 1987
+
+
+4.2.8. NAME CONFLICT DEMAND
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 18]
+
+RFC 1002 March 1987
+
+
+4.2.9. NAME RELEASE REQUEST & DEMAND
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 19]
+
+RFC 1002 March 1987
+
+
+4.2.10. POSITIVE NAME RELEASE 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 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
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+NetBIOS Working Group [Page 20]
+
+RFC 1002 March 1987
+
+
+ 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.
+
+4.2.12. NAME QUERY REQUEST
+
+ 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) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 21]
+
+RFC 1002 March 1987
+
+
+4.2.13. POSITIVE NAME QUERY 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 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 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) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 22]
+
+RFC 1002 March 1987
+
+
+4.2.14. NEGATIVE NAME QUERY 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NAME_TRN_ID |1| 0x0 |1|0|1|?|0 0|0| RCODE |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0x0000 | 0x0000 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0x0000 | 0x0000 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ / RR_NAME /
+ / /
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NULL (0x000A) | IN (0x0001) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0x00000000 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0x0000 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ 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.
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 23]
+
+RFC 1002 March 1987
+
+
+4.2.15. REDIRECT NAME QUERY 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ An end node responding to a NAME QUERY REQUEST always responds
+ with the AA and RA bits set for both the NEGATIVE and POSITIVE
+ NAME QUERY RESPONSE packets. An end node never sends a REDIRECT
+ NAME QUERY RESPONSE packet.
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 24]
+
+RFC 1002 March 1987
+
+
+ When the requestor receives the REDIRECT NAME QUERY RESPONSE it
+ must reiterate the NAME QUERY REQUEST to the NBNS specified by
+ the NSD_IP_ADDR field of the A type RESOURCE RECORD in the
+ ADDITIONAL section of the response packet. This is an optional
+ packet for the NBNS.
+
+ The NSD_NAME and the RR_NAME in the ADDITIONAL section of the
+ response packet are the same name. Space can be optimized if
+ label string pointers are used in the RR_NAME which point to the
+ labels in the NSD_NAME.
+
+ The RR_NAME in the AUTHORITY section is the name of the domain
+ the NBNS called by NSD_NAME has authority over.
+
+4.2.16. WAIT FOR ACKNOWLEDGEMENT (WACK) 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 25]
+
+RFC 1002 March 1987
+
+
+ The NAME_TRN_ID of the WACK RESPONSE packet is the same
+ NAME_TRN_ID of the request that the NBNS is telling the requestor
+ to wait longer to complete. The RR_NAME is the name from the
+ request, if any. If no name is available from the request then
+ it is a null name, single byte of zero.
+
+ The TTL field of the ResourceRecord is the new time to wait, in
+ seconds, for the request to complete. The RDATA field contains
+ the OPCODE and NM_FLAGS of the request.
+
+ A TTL value of 0 means that the NBNS can not estimate the time it
+ may take to complete a response.
+
+4.2.17. NODE STATUS REQUEST
+
+ 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) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 26]
+
+RFC 1002 March 1987
+
+
+4.2.18. 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 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 represents an active
+ name in the same NetBIOS scope as the requesting name in the
+ local name table of the responder. RR_NAME is the requesting
+ name.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 27]
+
+RFC 1002 March 1987
+
+
+ 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.
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 28]
+
+RFC 1002 March 1987
+
+
+ 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 are sent over a TCP connection.
+
+ All session packets are of the following general structure:
+
+ 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) /
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The TYPE, FLAGS, and LENGTH fields are present in every session
+ packet.
+
+
+
+
+NetBIOS Working Group [Page 29]
+
+RFC 1002 March 1987
+
+
+ The LENGTH field is the number of bytes following the LENGTH
+ field. In other words, LENGTH is the combined size of the
+ TRAILER field(s). For example, the POSITIVE SESSION RESPONSE
+ packet always has a LENGTH field value of zero (0000) while the
+ RETARGET SESSION RESPONSE always has a LENGTH field value of six
+ (0006).
+
+ One of the bits of the FLAGS field acts as an additional, high-
+ order bit for the LENGTH field. Thus the cumulative size of the
+ trailer field(s) may range from 0 to 128K bytes.
+
+ Session Packet Types (in hexidecimal):
+
+ 00 - SESSION MESSAGE
+ 81 - SESSION REQUEST
+ 82 - POSITIVE SESSION RESPONSE
+ 83 - NEGATIVE SESSION RESPONSE
+ 84 - RETARGET SESSION RESPONSE
+ 85 - SESSION KEEP ALIVE
+
+ Bit 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)
+
+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 /
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+NetBIOS Working Group [Page 30]
+
+RFC 1002 March 1987
+
+
+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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+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 |
+ +-+-+-+-+-+-+-+-+
+
+ NEGATIVE SESSION RESPONSE packet error code values (in
+ hexidecimal):
+
+ 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 error
+
+4.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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 31]
+
+RFC 1002 March 1987
+
+
+4.3.6. SESSION MESSAGE 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ / /
+ / USER_DATA /
+ / /
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4.3.7. SESSION KEEP ALIVE 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4.4. DATAGRAM SERVICE PACKETS
+
+4.4.1. NetBIOS DATAGRAM HEADER
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ 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 RESPONSE
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 32]
+
+RFC 1002 March 1987
+
+
+ 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
+
+ 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 /
+ / /
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+NetBIOS Working Group [Page 33]
+
+RFC 1002 March 1987
+
+
+ 4.4.3. DATAGRAM ERROR 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MSG_TYPE | FLAGS | DGM_ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | SOURCE_IP |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | SOURCE_PORT | ERROR_CODE |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ ERROR_CODE values (in hexidecimal):
+
+ 82 - DESTINATION NAME NOT PRESENT
+ 83 - INVALID SOURCE NAME FORMAT
+ 84 - INVALID DESTINATION NAME FORMAT
+
+4.4.4. DATAGRAM QUERY REQUEST
+
+ 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
+
+ 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 /
+ / /
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+NetBIOS Working Group [Page 34]
+
+RFC 1002 March 1987
+
+
+5. PROTOCOL DESCRIPTIONS
+
+5.1. NAME SERVICE PROTOCOLS
+
+ A REQUEST packet is always sent to the well known UDP port -
+ NAME_SERVICE_UDP_PORT. The destination address is normally
+ either the IP broadcast address or the address of the NBNS - the
+ address of the NBNS server it set up at initialization time. In
+ rare cases, a request packet will be sent to an end node, e.g. a
+ NAME QUERY REQUEST sent to "challenge" a node.
+
+ A RESPONSE packet is always sent to the source UDP port and
+ source IP address of the request packet.
+
+ A DEMAND packet must always be sent to the well known UDP port -
+ NAME_SERVICE_UDP_PORT. There is no restriction on the target IP
+ address.
+
+ 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
+
+ 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
+ */
+
+
+
+
+NetBIOS Working Group [Page 35]
+
+RFC 1002 March 1987
+
+
+ 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;
+
+
+
+NetBIOS Working Group [Page 36]
+
+RFC 1002 March 1987
+
+
+ END /* case */;
+ END /* got response */
+ END /* procedure */
+
+5.1.1.2. B-NODE ADD_GROUP NAME
+
+ 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 ...
+ */
+
+
+ END
+
+5.1.1.3. B-NODE FIND_NAME
+
+ 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;
+
+
+
+
+NetBIOS Working Group [Page 37]
+
+RFC 1002 March 1987
+
+
+ /*
+ * 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 */
+
+5.1.1.4. B NODE NAME RELEASE
+
+ PROCEDURE delete_name (name)
+ BEGIN
+
+ REPEAT
+
+ /*
+ * build packet
+ */
+
+
+
+NetBIOS Working Group [Page 38]
+
+RFC 1002 March 1987
+
+
+ ...
+
+ /*
+ * 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
+
+ Following processing is done when broadcast or unicast packets
+ are received at the NAME_SERVICE_UDP_PORT.
+
+ 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;
+
+
+
+NetBIOS Working Group [Page 39]
+
+RFC 1002 March 1987
+
+
+ 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.
+
+
+
+NetBIOS Working Group [Page 40]
+
+RFC 1002 March 1987
+
+
+ */
+
+ 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
+ END
+
+
+
+
+NetBIOS Working Group [Page 41]
+
+RFC 1002 March 1987
+
+
+5.1.2. P-NODE ACTIVITY
+
+ All packets sent or received by P nodes are unicast UDP packets.
+ A P node sends name service requests to the NBNS node that is
+ specified in the P-node configuration.
+
+5.1.2.1. P-NODE ADD_NAME
+
+ 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
+
+
+
+NetBIOS Working Group [Page 42]
+
+RFC 1002 March 1987
+
+
+ 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);
+
+
+
+
+NetBIOS Working Group [Page 43]
+
+RFC 1002 March 1987
+
+
+ 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 ...
+ */
+
+
+
+NetBIOS Working Group [Page 44]
+
+RFC 1002 March 1987
+
+
+ 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
+
+
+
+NetBIOS Working Group [Page 45]
+
+RFC 1002 March 1987
+
+
+ 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)
+
+
+
+
+NetBIOS Working Group [Page 46]
+
+RFC 1002 March 1987
+
+
+ /*
+ * 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
+
+
+
+NetBIOS Working Group [Page 47]
+
+RFC 1002 March 1987
+
+
+ /*
+ * 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
+ /*
+
+
+
+NetBIOS Working Group [Page 48]
+
+RFC 1002 March 1987
+
+
+ * 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);
+
+
+
+NetBIOS Working Group [Page 49]
+
+RFC 1002 March 1987
+
+
+ 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
+
+ M nodes behavior is similar to that of P nodes with the addition
+ of some B node-like broadcast actions. M node name service
+ proceeds in two steps:
+
+ 1.Use broadcast UDP based name service. Depending on the
+ operation, goto step 2.
+
+ 2.Use directed UDP name service.
+
+ The following code for M nodes is exactly the same as for a P
+ node, with the exception that broadcast operations are done
+ before P type operation is attempted.
+
+ 5.1.3.1. M-NODE ADD NAME
+
+ PROCEDURE add_name(newname)
+
+ /*
+ * Host initiated processing for a M node
+ */
+
+ BEGIN
+
+ /*
+ * check if name exists on the
+ * broadcast area
+ */
+
+
+
+NetBIOS Working Group [Page 50]
+
+RFC 1002 March 1987
+
+
+ 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.
+ */
+
+
+
+
+NetBIOS Working Group [Page 51]
+
+RFC 1002 March 1987
+
+
+ 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
+
+
+
+NetBIOS Working Group [Page 52]
+
+RFC 1002 March 1987
+
+
+ */
+
+ 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:
+
+
+
+
+NetBIOS Working Group [Page 53]
+
+RFC 1002 March 1987
+
+
+ /*
+ * 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
+
+ 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
+
+
+
+NetBIOS Working Group [Page 54]
+
+RFC 1002 March 1987
+
+
+ * group name claim is being made.
+ */
+
+ ...
+ G = GROUP;
+ ...
+
+ /*
+ * send packet
+ */
+ ...
+
+
+ END
+
+5.1.3.3. M-NODE FIND NAME
+
+ 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
+
+
+
+NetBIOS Working Group [Page 55]
+
+RFC 1002 March 1987
+
+
+ /*
+ * 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
+
+ PROCEDURE delete_name (name)
+
+ /*
+
+
+
+NetBIOS Working Group [Page 56]
+
+RFC 1002 March 1987
+
+
+ * 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
+ */
+
+
+
+NetBIOS Working Group [Page 57]
+
+RFC 1002 March 1987
+
+
+ return failure;
+ END /* case */
+ END /* procedure */
+
+5.1.3.5. M-NODE INCOMING PACKET PROCESSING
+
+ Processing initiated by reception of packets at a M node
+
+ 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
+ */
+
+
+
+NetBIOS Working Group [Page 58]
+
+RFC 1002 March 1987
+
+
+ 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 */
+
+
+
+
+NetBIOS Working Group [Page 59]
+
+RFC 1002 March 1987
+
+
+5.1.3.6. M-NODE TIMER INITIATED PROCESSING
+
+ Processing initiated by timer expiration:
+
+ 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 */
+
+5.1.4. NBNS ACTIVITY
+
+ A NBNS node will receive directed packets from P and M nodes.
+ Reply packets are always sent as directed packets to the source
+ IP address and UDP port number. Received broadcast packets must
+ be ignored.
+
+
+
+
+
+
+NetBIOS Working Group [Page 60]
+
+RFC 1002 March 1987
+
+
+5.1.4.1. NBNS INCOMING PACKET PROCESSING
+
+ 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
+ */
+
+
+
+NetBIOS Working Group [Page 61]
+
+RFC 1002 March 1987
+
+
+ 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
+
+
+
+NetBIOS Working Group [Page 62]
+
+RFC 1002 March 1987
+
+
+ * 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;
+
+
+
+NetBIOS Working Group [Page 63]
+
+RFC 1002 March 1987
+
+
+ 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 */
+
+
+
+NetBIOS Working Group [Page 64]
+
+RFC 1002 March 1987
+
+
+ /*
+ * 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;
+
+
+
+NetBIOS Working Group [Page 65]
+
+RFC 1002 March 1987
+
+
+ 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
+
+ A NS node uses timers to flush out entries from the data base.
+ Each entry in the data base is removed when its timer expires.
+ This time value is a multiple of the refresh TTL established when
+ the name was 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;
+ END
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 66]
+
+RFC 1002 March 1987
+
+
+5.2. SESSION SERVICE PROTOCOLS
+
+ The following are variables and should be configurable by the
+ NetBIOS user. The default values of these variables is found in
+ "Defined Constants and Variables" in the Detailed
+ Specification.):
+
+ - SSN_RETRY_COUNT - The maximum number TCP connection attempts
+ allowable per a single NetBIOS call request.
+
+ - SSN_CLOSE_TIMEOUT is the time period to wait when closing the
+ NetBIOS session before killing the TCP connection if session
+ sends are outstanding.
+
+ The following are Defined Constants for the NetBIOS Session
+ Service. (See "Defined Constants and Variables" in the Detailed
+ Specification for the value of these constants):
+
+ - SSN_SRVC_TCP_PORT - is the globally well-known TCP port
+ allocated for the NetBIOS Session Service. The service accepts
+ TCP connections on this port to establish NetBIOS Sessions.
+ The TCP connection established to this port by the caller is
+ initially used for the exchange of NetBIOS control information.
+ The actual NetBIOS data connection may also pass through this
+ port or, through the retargetting facility, through another
+ port.
+
+5.2.1. SESSION ESTABLISHMENT PROTOCOLS
+
+5.2.1.1. USER REQUEST PROCESSING
+
+ 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);
+
+
+
+
+NetBIOS Working Group [Page 67]
+
+RFC 1002 March 1987
+
+
+ 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;
+
+
+
+NetBIOS Working Group [Page 68]
+
+RFC 1002 March 1987
+
+
+ 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
+
+
+
+NetBIOS Working Group [Page 69]
+
+RFC 1002 March 1987
+
+
+ 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 */
+
+
+
+NetBIOS Working Group [Page 70]
+
+RFC 1002 March 1987
+
+
+5.2.1.2. RECEIVED PACKET PROCESSING
+
+ These are packets received on a TCP connection before a session
+ has been established. The listen routines attached to a NetBIOS
+ user process need not implement the RETARGET response section.
+ The user process version, separate from a shared Session Service,
+ need only accept (POSITIVE SESSION RESPONSE) or reject (NEGATIVE
+ SESSION RESPONSE) a session request.
+
+ 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 */
+
+
+
+NetBIOS Working Group [Page 71]
+
+RFC 1002 March 1987
+
+
+ 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
+
+ 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;
+ END
+
+ 5.2.2.2. RECEIVED PACKET PROCESSING
+
+ These are packets received after a session has been established.
+
+ 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;
+
+
+
+NetBIOS Working Group [Page 72]
+
+RFC 1002 March 1987
+
+
+ END /* session message */
+
+ SESSION KEEP ALIVE:
+ discard packet;
+
+ END /* case */
+ END /* procedure */
+
+5.2.2.3. PROCESSING INITIATED BY TIMER
+
+ 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
+
+ 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
+
+ PROCEDURE close_indication()
+ /*
+ * initiated by a TCP indication of a close request from
+ * the remote connection partner.
+
+
+
+NetBIOS Working Group [Page 73]
+
+RFC 1002 March 1987
+
+
+ */
+ BEGIN
+ close gracefully TCP connection;
+
+ close NetBIOS session;
+
+ inform user session closed by remote partner;
+ END /* procedure */
+
+5.3. NetBIOS DATAGRAM SERVICE PROTOCOLS
+
+ The following are GLOBAL variables and should be NetBIOS user
+ configurable:
+
+ - SCOPE_ID: the non-leaf section of the domain name preceded by a
+ '.' which represents the domain of the NetBIOS scope for the
+ NetBIOS name. The following protocol description only supports
+ single scope operation.
+
+ - MAX_DATAGRAM_LENGTH: the maximum length of an IP datagram. The
+ minimal maximum length defined in for IP is 576 bytes. This
+ value is used when determining whether to fragment a NetBIOS
+ datagram. Implementations are expected to be capable of
+ receiving unfragmented NetBIOS datagrams up to their maximum
+ size.
+
+ - BROADCAST_ADDRESS: the IP address B-nodes use to send datagrams
+ with group name destinations and broadcast datagrams. The
+ default is the IP broadcast address for a single IP network.
+
+
+ The following are Defined Constants for the NetBIOS Datagram
+ Service:
+
+ - DGM_SRVC_UDP_PORT: the globally well-known UDP port allocated
+ where the NetBIOS Datagram Service receives UDP packets. See
+ section 6, "Defined Constants", for its value.
+
+5.3.1. B NODE TRANSMISSION OF NetBIOS DATAGRAMS
+
+ 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;
+
+
+
+NetBIOS Working Group [Page 74]
+
+RFC 1002 March 1987
+
+
+ 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
+ */
+
+
+
+NetBIOS Working Group [Page 75]
+
+RFC 1002 March 1987
+
+
+ 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
+
+ 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
+
+
+
+NetBIOS Working Group [Page 76]
+
+RFC 1002 March 1987
+
+
+ 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;
+
+
+
+NetBIOS Working Group [Page 77]
+
+RFC 1002 March 1987
+
+
+ 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
+
+ The following algorithm discards out of order NetBIOS Datagram
+ fragments. An implementation which reassembles out of order
+ NetBIOS Datagram fragments conforms to this specification. The
+ fragment discard timer is initialized to the value FRAGMENT_TO.
+ This value should be user configurable. The default value is
+ given in Section 6, "Defined Constants and Variables".
+
+ 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;
+
+
+
+NetBIOS Working Group [Page 78]
+
+RFC 1002 March 1987
+
+
+ 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 */
+ /*
+
+
+
+NetBIOS Working Group [Page 79]
+
+RFC 1002 March 1987
+
+
+ * 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 */
+ END
+
+5.3.4. PROTOCOLS FOR THE NBDD
+
+ The key to NetBIOS Datagram forwarding service is the packet
+ delivered to the destination end node must have the same NetBIOS
+ header as if the source end node sent the packet directly to the
+ destination end node. Consequently, the NBDD does not reassemble
+ NetBIOS Datagrams. It forwards the UDP packet as is.
+
+
+
+NetBIOS Working Group [Page 80]
+
+RFC 1002 March 1987
+
+
+ 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:
+
+
+
+NetBIOS Working Group [Page 81]
+
+RFC 1002 March 1987
+
+
+ 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 */
+
+
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 82]
+
+RFC 1002 March 1987
+
+
+6. DEFINED CONSTANTS AND VARIABLES
+
+ 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:
+
+ REFRESH_TIMER Negotiated with NBNS for each name.
+
+ CONFLICT_TIMER 1 second
+ Implementations may chose a longer
+ value.
+
+
+ NAME_SERVICE_TCP_PORT 137 (decimal)
+
+
+
+NetBIOS Working Group [Page 83]
+
+RFC 1002 March 1987
+
+
+ NAME_SERVICE_UDP_PORT 137 (decimal)
+
+ INFINITE_TTL 0
+
+
+ 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:
+
+ DGM_SRVC_UDP_PORT 138 (decimal)
+
+ FRAGMENT_TO 2 seconds (default)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 84]
+
+RFC 1002 March 1987
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 85]