Article View: comp.doc
Article #214RFC1002 - NetBIOS detailed spec - part 2 of 3
From: Brian Kantor
Date: Sat, 20 Feb 1988 04:43
Date: Sat, 20 Feb 1988 04:43
1750 lines
58144 bytes
58144 bytes
---
| 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:
---
Technical Details
Message-ID:
<22@ucsd.EDU>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!uunet!lll-winken!lll-lcc!mordor!sri-spam!ames!ucsd!brianShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!lll-winken!lll-lcc!mordor!sri-spam!ames!ucsd!brian From: brian@ucsd.EDU (Brian Kantor) Newsgroups: comp.doc Subject: RFC1002 - NetBIOS detailed spec - part 2 of 3 Message-ID: <22@ucsd.EDU> Date: 20 Feb 88 04:43:28 GMT Distribution: na Organization: UCSD wombat breeding society Lines: 1749 Approved: brian@cyberpunk.ucsd.edu