NetBIOS revisit
NetBIOS is an acronym for Network Basic Input/Output System and was originally developed by IBM and Sytek as an Application Programming Interface (API) for client software to access LAN resources. It does not in itself support a routing mechanism so applications communicating on a wide area network (WAN) must use another "transport mechanism" (such as Transmission Control Protocol).
NetBIOS provides two communication modes: session or datagram. Session mode lets two computers establish a connection for a "conversation," allows larger messages to be handled, and provides error detection and recovery. Datagram mode is "connectionless" (each message is sent independently), messages must be smaller, and the application is responsible for error detection and recovery. Datagram mode also supports the broadcast of a message to every computer on the LAN.
All communication in these environments are presented to NetBIOS in a format called Network Control Blocks (NCB) which, among other things, specifies a message location and the name of a destination.
NetBIOS Names
To communicate, each node (computer, printer, router etc) needs to be uniquely identified on a network. NetBIOS names are used to identify resources on a network. There are two types of names in a NetBIOS enviroment: Unique and Group. When communicating with a specific process on a computer, NetBIOS applications typically use unique names. When communicating with multiple computers at a time, NetBIOS applications use group names.
Each NetBIOS node maintains a table of all names currently owned by that node. Applications use these names to start and end sessions. You can configure a single machine with multiple applications, each of which has a unique NetBIOS name. Each PC that supports an application also has a NetBIOS station name that is user defined or that NetBIOS derives by internal means. NetBIOS names is a flat namespace. There is no hierarchy or capability to qualify the names.
A NetBIOS name is 16 bytes long. The exact NetBIOS name used by the Server service is the 15-byte computer name plus a sixteenth byte of 0x20. You configure the computer name on the Computer Name tab of the System item in Control Panel. If the computer name is not 15 bytes long, Windows pads it with spaces up to 15 bytes long. Computer names longer than 15 bytes are truncated. Other network services also use the computer name to build their NetBIOS names, so the sixteenth byte typically identifies a specific service. Other services that use NetBIOS include the Client for Microsoft Networks component (also known as the Workstation service in the Services snap-in) and the Messenger service (not to be confused with Windows Messenger). The Workstation service, also known as the redirector, uses the 15-byte computer name plus a sixteenth byte of 0x00. The Messenger service uses the 15-byte computer name plus a sixteenth byte of 0x03.
NetBIOS does not allow for duplicate computer names on a network. Before a PC that uses NetBIOS can fully function on a network, that PC must register their NetBIOS name. A client is considered to be registered when it can successfully advertise itself without any other client claiming it has the same name. The steps of the registration process are as follows:
1. Upon boot up, the client broadcasts itself and its NetBIOS information anywhere from 6 to 10 to ensure every other client on the network receives the information.
2. If another client on the network already has the name, that NetBIOS client issues its own broadcast to indicate that the name is in use. The client who is trying to register the already in use name, stop all attempts to register that name.
3. If no other client on the network objects to the name registration, the client will finish the registration process.
NetBIOS Sessions
Sessions allow for a larger message to be sent and handle error detection and correction. The NetBIOS session service provides a connection-oriented, reliable, full-duplex message service to a user process. NetBIOS requires one process to be the client and the other to be the server. The server application issued a Listen command whereas the client application issues a Call command. The Listen command references a name in its NetBIOS name table (or WINS server), and also the remote name an application must use to qualify as a session partner.
If the receiver (listener) is not already listening, the Call will be unsuccessful. If the call is successful, each application receives notification of session establishment with the session-id. The Send and Receive commands then transfer data. At the end of a session, either application can issue a Hang-Up command. There is no real flow control for the session service because it is assumed a LAN is fast enough to carry the required traffic.
NetBIOS over TCP/IP (NetBT) sends the NetBIOS protocol over the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP).
NetBT traffic includes the following:
- NetBIOS session traffic over TCP port 139
- NetBIOS name management traffic over UDP port 137
- NetBIOS datagram traffic over UDP port 138
Segmenting NetBIOS Names with the NetBIOS Scope ID
The NetBIOS scope ID is a character string that is appended to the NetBIOS name and that isolates a set of NetBT nodes. Without scopes, a unique NetBIOS name must be unique across all the NetBIOS resources on the network. With the NetBIOS scope ID, a unique NetBIOS name must be unique only within a specific NetBIOS scope ID. NetBIOS resources within a scope are isolated from all NetBIOS resources outside the scope. The NetBIOS scope ID on two hosts must match, or the two hosts will not be able to communicate with each other using NetBT.
NetBIOS Datagrams
The other form of communication does not involve sessions and uses a simple datagram transmission mechanism for simple communications between systems on a network. Non-session frames are used for functions such as name management or other functions that simply require a datagram delivery service.
Datagrams can be sent to a specific name, sent to all members of a group, or broadcast to the entire LAN. As with other datagram services, the NetBIOS datagrams are connectionless and unreliable. The Send_Datagram command requires the caller to specify the name of the destination. If the destination is a group name, then every member of the group receives the datagram. The caller of the Receive_Datagram command must specify the local name for which it wants to receive datagrams. The Receive_Datagram command also returns the name of the sender, in addition to the actual datagram data. If NetBIOS receives a datagram, but there are no Receive_Datagram commands pending, then the datagram is discarded.
The Send_Broadcast_Datagram command sends the message to every NetBIOS system on the local network. When a broadcast datagram is received by a NetBIOS node, every process that has issued a Receive_Broadcast_Datagram command receives the datagram. If none of these commands are outstanding when the broadcast datagram is received, the datagram is discarded.
NetBIOS Name Resolution
NetBIOS name resolution is the process of successfully mapping a NetBIOS name to an IP address so that connections can be established with TCP/IP. Basically there are three ways to resolve NetBIOS names to their corresponding IP addresses:
- Broadcast-based name resolution
- LMHosts filename resolution
- WINS name resolution
Broadcast-Based Name Resolution (B-Node name resolution)
Broadcast-Based Name Resolution occurs when a computer announces to all the other machines on its network segment that it needs the address of a particular computer. However, only the machine specified in the broadcast responds to the request.
This method works well in a LAN environment but does not work in networks that extend beyond the LAN, because routers block broadcasts by design. In that case, computers must perform NetBIOS name resolution using either LMHosts or a WINS server.
LMHosts Files Name Resolution
Windows systems can also resolve NetBIOS names to IP addresses using the LMHosts file. An LMHosts file associates NetBIOS names to IP addresses. The IP address is listed in the left column of the file with the corresponding computer name to the right separated by at least one space; comments can be put in the file by placing them after a # character. LMHosts requires a static mapping of IP addresses to NetBIOS names.
The following is an example of what a basic LMHosts file looks like:
192.59.66.205 marketserv #file server for marketing department
192.59.66.206 marketapp #application server for marketing
192.59.66.207 bobscomputer #bob's workstation
Recently resolved NetBIOS names are stored in the NetBIOS name cache. Whenever a user attempts to locate a specific computer, the system always consults the NetBIOS name cache before searching the LMHosts file. If no match is found, the entries within the LMHosts file can then be scanned for the requested name.
Maintaining static files such as hosts and LMHosts is tedious as these files are located on each individual computer, and therefore are not centralized. The LMHosts file addresses this problem by using the keyword #INCLUDE followed by an entry for the path to LMHosts files on other machines. With this keyword, the local LMHosts file can include the location of a server-based LMHosts file for use by the local machine. This enables edits to be performed on the server-based LMHosts file, but the changes are accessible from the user's computer.
If there is more than one #INCLUDE entry, they need to be placed between the keywords #BEGIN ALTERNATE and #END ALTERNATE.
Windows Internet Name Service (WINS) Name Resolution
Windows Internet Name Service (WINS) is Microsoft's implementation of NetBIOS Name Service (NBNS), a name server and service for NetBIOS computer names. The WINS server receives and responds to NetBIOS name resolution requests.
WINS maintains a database of registered NetBIOS names for a variety of objects, including users, computers, services running on those computers, and workgroups. Client computer registers its name and IP address with the WINS server dynamically when it starts up.
When a WINS client computer boots after being configured to use WINS, the following process occurs:
Service startup - As the computer boots, various services are started, some of which need to be made known to other computers.
Registration request - To be known to other computers on the network, the service must register itself. A WINS client computer packages the NetBIOS name and the computer's IP address inside a name registration request, and the registration request is sent to the WINS server. Upon receiving the registration request, WINS checks its database to see whether the name is already registered.
If the name does not exist, WINS adds the NetBIOS name and IP address pair to its database and sends a name registration response indicating the name was successfully registered. If the requested NetBIOS name already exists in the WINS database, WINS challenges the computer currently registered by sending a message to the registered IP address. If the currently registered computer responds, a negative acknowledgement is sent to the computer attempting to register the name. If the computer being challenged doesn't respond, WINS allows the registration to occur and overwrites the previous registration.
Lease - Assuming the computer is successful in registering its NetBIOS names and services with WINS, these names are considered leased. In essence, the computer is allowed to use the NetBIOS name for a specified period of time - for instance six days - sbut the client can renew the lease before it expires. The client typically renews the lease at 50% of the total lease time or in this case every three days.
During the WINS registration process, the 16th character is appended to the name by the WINS server based on what type of service the computer is trying to register before it is placed in the database. Between computer names, workgroup names, and a number of services, it is not unusual for a single computer to have 5 to 10 registration entries in the WINS database.
NetBIOS provides two communication modes: session or datagram. Session mode lets two computers establish a connection for a "conversation," allows larger messages to be handled, and provides error detection and recovery. Datagram mode is "connectionless" (each message is sent independently), messages must be smaller, and the application is responsible for error detection and recovery. Datagram mode also supports the broadcast of a message to every computer on the LAN.
All communication in these environments are presented to NetBIOS in a format called Network Control Blocks (NCB) which, among other things, specifies a message location and the name of a destination.
NetBIOS Names
To communicate, each node (computer, printer, router etc) needs to be uniquely identified on a network. NetBIOS names are used to identify resources on a network. There are two types of names in a NetBIOS enviroment: Unique and Group. When communicating with a specific process on a computer, NetBIOS applications typically use unique names. When communicating with multiple computers at a time, NetBIOS applications use group names.
Each NetBIOS node maintains a table of all names currently owned by that node. Applications use these names to start and end sessions. You can configure a single machine with multiple applications, each of which has a unique NetBIOS name. Each PC that supports an application also has a NetBIOS station name that is user defined or that NetBIOS derives by internal means. NetBIOS names is a flat namespace. There is no hierarchy or capability to qualify the names.
A NetBIOS name is 16 bytes long. The exact NetBIOS name used by the Server service is the 15-byte computer name plus a sixteenth byte of 0x20. You configure the computer name on the Computer Name tab of the System item in Control Panel. If the computer name is not 15 bytes long, Windows pads it with spaces up to 15 bytes long. Computer names longer than 15 bytes are truncated. Other network services also use the computer name to build their NetBIOS names, so the sixteenth byte typically identifies a specific service. Other services that use NetBIOS include the Client for Microsoft Networks component (also known as the Workstation service in the Services snap-in) and the Messenger service (not to be confused with Windows Messenger). The Workstation service, also known as the redirector, uses the 15-byte computer name plus a sixteenth byte of 0x00. The Messenger service uses the 15-byte computer name plus a sixteenth byte of 0x03.
NetBIOS does not allow for duplicate computer names on a network. Before a PC that uses NetBIOS can fully function on a network, that PC must register their NetBIOS name. A client is considered to be registered when it can successfully advertise itself without any other client claiming it has the same name. The steps of the registration process are as follows:
1. Upon boot up, the client broadcasts itself and its NetBIOS information anywhere from 6 to 10 to ensure every other client on the network receives the information.
2. If another client on the network already has the name, that NetBIOS client issues its own broadcast to indicate that the name is in use. The client who is trying to register the already in use name, stop all attempts to register that name.
3. If no other client on the network objects to the name registration, the client will finish the registration process.
NetBIOS Sessions
Sessions allow for a larger message to be sent and handle error detection and correction. The NetBIOS session service provides a connection-oriented, reliable, full-duplex message service to a user process. NetBIOS requires one process to be the client and the other to be the server. The server application issued a Listen command whereas the client application issues a Call command. The Listen command references a name in its NetBIOS name table (or WINS server), and also the remote name an application must use to qualify as a session partner.
If the receiver (listener) is not already listening, the Call will be unsuccessful. If the call is successful, each application receives notification of session establishment with the session-id. The Send and Receive commands then transfer data. At the end of a session, either application can issue a Hang-Up command. There is no real flow control for the session service because it is assumed a LAN is fast enough to carry the required traffic.
NetBIOS over TCP/IP (NetBT) sends the NetBIOS protocol over the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP).
NetBT traffic includes the following:
- NetBIOS session traffic over TCP port 139
- NetBIOS name management traffic over UDP port 137
- NetBIOS datagram traffic over UDP port 138
Segmenting NetBIOS Names with the NetBIOS Scope ID
The NetBIOS scope ID is a character string that is appended to the NetBIOS name and that isolates a set of NetBT nodes. Without scopes, a unique NetBIOS name must be unique across all the NetBIOS resources on the network. With the NetBIOS scope ID, a unique NetBIOS name must be unique only within a specific NetBIOS scope ID. NetBIOS resources within a scope are isolated from all NetBIOS resources outside the scope. The NetBIOS scope ID on two hosts must match, or the two hosts will not be able to communicate with each other using NetBT.
NetBIOS Datagrams
The other form of communication does not involve sessions and uses a simple datagram transmission mechanism for simple communications between systems on a network. Non-session frames are used for functions such as name management or other functions that simply require a datagram delivery service.
Datagrams can be sent to a specific name, sent to all members of a group, or broadcast to the entire LAN. As with other datagram services, the NetBIOS datagrams are connectionless and unreliable. The Send_Datagram command requires the caller to specify the name of the destination. If the destination is a group name, then every member of the group receives the datagram. The caller of the Receive_Datagram command must specify the local name for which it wants to receive datagrams. The Receive_Datagram command also returns the name of the sender, in addition to the actual datagram data. If NetBIOS receives a datagram, but there are no Receive_Datagram commands pending, then the datagram is discarded.
The Send_Broadcast_Datagram command sends the message to every NetBIOS system on the local network. When a broadcast datagram is received by a NetBIOS node, every process that has issued a Receive_Broadcast_Datagram command receives the datagram. If none of these commands are outstanding when the broadcast datagram is received, the datagram is discarded.
NetBIOS Name Resolution
NetBIOS name resolution is the process of successfully mapping a NetBIOS name to an IP address so that connections can be established with TCP/IP. Basically there are three ways to resolve NetBIOS names to their corresponding IP addresses:
- Broadcast-based name resolution
- LMHosts filename resolution
- WINS name resolution
Broadcast-Based Name Resolution (B-Node name resolution)
Broadcast-Based Name Resolution occurs when a computer announces to all the other machines on its network segment that it needs the address of a particular computer. However, only the machine specified in the broadcast responds to the request.
This method works well in a LAN environment but does not work in networks that extend beyond the LAN, because routers block broadcasts by design. In that case, computers must perform NetBIOS name resolution using either LMHosts or a WINS server.
LMHosts Files Name Resolution
Windows systems can also resolve NetBIOS names to IP addresses using the LMHosts file. An LMHosts file associates NetBIOS names to IP addresses. The IP address is listed in the left column of the file with the corresponding computer name to the right separated by at least one space; comments can be put in the file by placing them after a # character. LMHosts requires a static mapping of IP addresses to NetBIOS names.
The following is an example of what a basic LMHosts file looks like:
192.59.66.205 marketserv #file server for marketing department
192.59.66.206 marketapp #application server for marketing
192.59.66.207 bobscomputer #bob's workstation
Recently resolved NetBIOS names are stored in the NetBIOS name cache. Whenever a user attempts to locate a specific computer, the system always consults the NetBIOS name cache before searching the LMHosts file. If no match is found, the entries within the LMHosts file can then be scanned for the requested name.
Maintaining static files such as hosts and LMHosts is tedious as these files are located on each individual computer, and therefore are not centralized. The LMHosts file addresses this problem by using the keyword #INCLUDE followed by an entry for the path to LMHosts files on other machines. With this keyword, the local LMHosts file can include the location of a server-based LMHosts file for use by the local machine. This enables edits to be performed on the server-based LMHosts file, but the changes are accessible from the user's computer.
If there is more than one #INCLUDE entry, they need to be placed between the keywords #BEGIN ALTERNATE and #END ALTERNATE.
Windows Internet Name Service (WINS) Name Resolution
Windows Internet Name Service (WINS) is Microsoft's implementation of NetBIOS Name Service (NBNS), a name server and service for NetBIOS computer names. The WINS server receives and responds to NetBIOS name resolution requests.
WINS maintains a database of registered NetBIOS names for a variety of objects, including users, computers, services running on those computers, and workgroups. Client computer registers its name and IP address with the WINS server dynamically when it starts up.
When a WINS client computer boots after being configured to use WINS, the following process occurs:
Service startup - As the computer boots, various services are started, some of which need to be made known to other computers.
Registration request - To be known to other computers on the network, the service must register itself. A WINS client computer packages the NetBIOS name and the computer's IP address inside a name registration request, and the registration request is sent to the WINS server. Upon receiving the registration request, WINS checks its database to see whether the name is already registered.
If the name does not exist, WINS adds the NetBIOS name and IP address pair to its database and sends a name registration response indicating the name was successfully registered. If the requested NetBIOS name already exists in the WINS database, WINS challenges the computer currently registered by sending a message to the registered IP address. If the currently registered computer responds, a negative acknowledgement is sent to the computer attempting to register the name. If the computer being challenged doesn't respond, WINS allows the registration to occur and overwrites the previous registration.
Lease - Assuming the computer is successful in registering its NetBIOS names and services with WINS, these names are considered leased. In essence, the computer is allowed to use the NetBIOS name for a specified period of time - for instance six days - sbut the client can renew the lease before it expires. The client typically renews the lease at 50% of the total lease time or in this case every three days.
During the WINS registration process, the 16th character is appended to the name by the WINS server based on what type of service the computer is trying to register before it is placed in the database. Between computer names, workgroup names, and a number of services, it is not unusual for a single computer to have 5 to 10 registration entries in the WINS database.
Comments
Post a Comment