NetBIOS over TCP/IP
NetBIOS defines a software interface and a naming convention, not a protocol. Early versions of Microsoft networking products provided only the NetBIOS Extended User Interface (NetBEUI) protocol with a NetBIOS application-programming interface. NetBEUI is a small, fast protocol with no networking layer; thus, it is not routable and is not suitable for internetworks. NetBEUI relies on multicasts for name resolution and location of services. NetBIOS over TCP/IP provides the NetBIOS programming interface over the TCP/IP protocol, extending the reach of NetBIOS client and server programs to the WAN, and providing interoperability with various other operating systems.
The Workstation, Server, Browser, Messenger, and NetLogon services are all (direct) NetBT clients. They use TDI (described earlier in this paper) to communicate with NetBT. Windows Server 2003 also includes a NetBIOS emulator. The emulator takes standard NetBIOS requests from NetBIOS applications and translates them to equivalent TDI primitives.
Windows Server 2003 still uses NetBIOS over TCP/IP to communicate with prior versions of Windows NT and other clients, such as Windows 98. However, the Windows Server 2003 redirector and server components also support direct hosting to communicate with other computers capable of direct hosting. Direct hosting uses DNS for name resolution. No NetBIOS name resolution (WINS or broadcast) is used, and the protocol is simpler. Direct hosting uses TCP port 445, instead of the NetBIOS TCP port 139.
By default, both NetBIOS and direct hosting are enabled, and both are tried in parallel when a new connection is established. The first to succeed in connecting is used for any attempt. NetBIOS support can be disabled to force all traffic to use direct hosting.
To disable NetBIOS support
-
On the Start menu, point to Control Panel, and then double-click Network Connections. Right-click Local Area Connection (or the name of your LAN connection) and then click Properties.
-
Select Internet Protocol (TCP/IP) in the list of components, and click Properties.
-
Click Advanced.
-
On the WINS tab, select Disable NetBIOS over TCP/IP.
Applications and services that depend on NetBIOS no longer function after this is done, so it is important that you verify that any clients and applications no longer need NetBIOS support before you disable it. For example, computers that cannot direct host will be unable to browse, locate, or create file and print share connections to a Windows Server 2003 computer with NetBIOS disabled.
NetBIOS Names
The NetBIOS namespace is flat, meaning that all names within the name space must be unique. NetBIOS names are 16 characters in length. Resources are identified by NetBIOS names, which are registered dynamically when computers boot, services or applications start, or users log on. Names can be registered as unique (one owner) or as group (multiple owner) names. A NetBIOS Name Query is used to locate a resource by resolving the name to an IP address.
Microsoft networking components, such as Workstation and Server services, allow the first 15 characters of a NetBIOS name to be specified by the user or administrator, but reserve the sixteenth character of the NetBIOS name to indicate a resource type (0x00-0xFF). Many popular third-party software packages also use this character to identify and register their specific services. Table 3 lists some example NetBIOS names used by Microsoft components.
Table 3. Examples of NetBIOS names used by Windows components
Unique name
|
Service
|
computer_name[00h]
|
Workstation service
|
computer_name[03h]
|
Messenger service
|
computer_name[1Fh]
|
NetDDE service
|
computer_name[20h]
|
Server service
|
computer_name[BEh]
|
Network Monitor Agent
|
computer_name[BFh]
|
Network Monitor Application
|
user_name[03]
|
Messenger service
|
domain_name[1Dh]
|
Master Browser
|
domain_name[1Bh]
|
Domain Master Browser
|
domain_name[00h]
|
Domain name
|
domain_name[1Ch]
|
Domain controllers
|
domain_name[1Eh]
|
Browser service elections
|
\\--__MSBROWSE__[01h]
|
Master browser
|
To see which names a computer has registered over NetBT, type the following from a command prompt:
nbtstat -n
Windows Server 2003 allows you to re-register names with the WINS server after a computer has already been started. To do this, type the following from a command prompt:
nbtstat –RR
NetBIOS Name Registration and Resolution
Windows TCP/IP systems use several methods to locate NetBIOS resources:
-
NetBIOS name cache
-
NetBIOS name server
-
Broadcast NetBIOS Name Query Request messages
-
Static Lmhosts file
-
Local host name (optional, depends on EnableDns registry parameter)
-
Static Hosts file (optional, depends on EnableDns registry parameter)
-
DNS servers (optional, depends on EnableDns registry parameter)
NetBIOS name resolution order depends upon the node type and system configuration. The following node types are supported:
-
B-node uses broadcasts for name registration and resolution.
-
P-node uses a NetBIOS name server (such as WINS) for name registration and resolution.
-
M-node uses broadcasts for name registration. For name resolution, it tries broadcasts first, but switches to p-node if it receives no answer.
-
H-node uses a NetBIOS name server for both registration and resolution. However, if no name server can be located, it switches to b-node. It continues to poll for a name server and switches back to p-node when one becomes available.
-
Microsoft-enhanced uses the local Lmhosts file or WINS proxies plus Windows Sockets gethostbyname() calls (using standard DNS and/or local Hosts files) in addition to standard node types.
Microsoft ships a NetBIOS name server known as the Windows Internet Name Service (WINS). Most WINS clients are set up as H-nodes; that is, they first attempt to register and resolve names using WINS, and if that fails, they try local subnet broadcasts. Using a WINS server to locate resources is generally preferable to broadcasting for two reasons:
-
Routers do not usually forward broadcasts.
-
All computers on a subnet process broadcasts.
NetBIOS Name Registration and Resolution for Multihomed Computers
As previously described, NetBT binds to only one IP address per physical network interface. From the NetBT viewpoint, a computer is multihomed only if it has more than one NIC installed. When a name registration packet is sent from a multihomed machine, it is flagged as a multihomed name registration so that it does not conflict with the same name being registered by another interface in the same computer.
If a multihomed machine receives a broadcast name query, all NetBT-interface bindings receiving the query respond with their addresses, and by default the client chooses the first response and connects to the address supplied by it. This behavior can be controlled by the RandomAdapter registry parameter described in Appendix B.
When a directed name query is sent to a WINS server, the WINS server responds with a list of all IP addresses that were registered with WINS by the multihomed computer.
Choosing the best IP address to connect to on a multihomed computer is a client function. Currently, the following algorithm is employed, in the order listed:
-
If one of the IP addresses in the name query response list is on the same logical subnet as the calling binding of NetBT on the local computer, that address is selected. If more than one of the addresses meets the criteria, one is picked at random from those that match.
-
If one of the IP addresses in the list is on the same (classless) network as the calling binding of NetBT on the local computer, that address is selected. If more than one of the addresses meets the criteria, one is picked at random from those that match.
-
If one of the IP addresses in the list is on the same logical subnet as any binding of NetBT on the local computer, that address is selected. If more than one of the addresses meets the criteria, one is picked at random from those.
-
If none of the IP addresses in the list is on the same subnet as any binding of NetBT on the local computer, an address is selected at random from the list.
This algorithm provides a reasonably good way of balancing connections to a server across multiple NICs, and still favoring direct (same subnet) connections when they are available. When a list of IP addresses is returned, they are sorted into the best order, and NetBT attempts to ping each of the addresses in the list until one responds. NetBT then attempts a connection to that address. If no addresses respond, a connection attempt is made to the first address in the list anyway. This is tried in case there is a firewall or other device filtering ICMP traffic. Windows Server 2003 supports per interface NetBT name caching, and the nbtstat -c command displays the name cache on a per-interface basis.
NetBT Internet/DNS Enhancements and the SMB Device
It has always been possible to connect from one Windows-based computer to another using NetBT over the Internet. To do so, some means of name resolution had to be provided. Two common methods were to use the Lmhosts file or a WINS server. Several enhancements were introduced in Windows NT 4.0 and carried forward in Windows Server 2003 to eliminate these special configuration needs.
It is possible to connect to a NetBIOS over TCP/IP resource in the following ways:
-
Use the command net use \\ip address\share_name. This eliminates the need for NetBIOS name resolution configuration.
-
Use the command net use \\FQDN\share_name. This allows the use of a DNS to connect to a computer using its fully qualified domain name (FQDN).
Examples of using new functionality to map a drive to ftp.microsoft.com are shown here. The IP address listed here is subject to change.
-
net use f: \\ftp.microsoft.com\data
-
net use \\131.107.232.1\data
-
net view \\131.107.232.1
-
dir \\ftp.microsoft.com\bussys\winnt
In addition, various applications, such as the Event Viewer Select Computer option on the Log menu, allow you to enter an FQDN or IP address directly. In Windows Server 2003, it is also possible to use direct hosting to establish redirector or server connections between computers running Windows Server 2003 without the use of the NetBIOS namespace or mapping layer at all. By default, Windows attempts to make connections using both methods so that it can support connections to lower-level computers. However, in Windows XP and Windows Server 2003–only environments, you can disable NetBIOS completely for each network connection in Network Connections.
The interface in Windows Server 2003 that makes NetBIOS-less operation possible is termed the Server Message Block (SMB) device. It appears to the redirector and server as another interface, much as an individual network adapter/protocol stack combination does. At the TCP/IP stack however, the SMB device is bound to ADDR_ANY, and it uses the DNS namespace natively, like a Windows Sockets application. Calls placed on the SMB device will result in a standard DNS lookup to resolve the (DNS) name to an IP address, followed by a single outbound connection request (even on a multihomed computer) using the best source IP address and interface as determined by the route table. Additionally, there is no NetBIOS session setup on top of the TCP connection, as there is with traditional NetBIOS over TCP/IP. By default, the redirector places calls on both the NetBIOS device(s) and the SMB device, and the file server receives calls on both. The file server SMB device listens on TCP port 445 instead of the traditional NetBIOS over TCP port 139.
NetBIOS over TCP Sessions
NetBIOS sessions are established between two names. For example, when a Windows XP Professional-based workstation makes a file-sharing connection to a server using NetBIOS over TCP/IP, the following sequence of events takes place:
-
The NetBIOS name for the server is resolved to an IP address.
-
The next-hop address for the IP address of the server is resolved to a MAC address.
-
A TCP connection is established from the workstation to the server, using
port 139.
-
The workstation sends a NetBIOS Session Request to the server name over the TCP connection. If the server is listening on that name, it responds affirmatively, and a session is established.
When the NetBIOS session has been established, the workstation and server negotiate which level of the SMB protocol to use. Microsoft networking uses only one NetBIOS session between two names at any time. Any additional file or print sharing connections are multiplexed over the same NetBIOS session using identifiers within the SMB header.
NetBIOS keep-alives are used on each connection to verify that both the server and workstation are still able to maintain their session. Therefore, if a workstation is shut down ungracefully, the server eventually cleans up the connection and associated resources, and vice versa. NetBIOS keep-alives are controlled by the SessionKeepAlive registry parameter and default to once per hour.
If Lmhosts files are used and an entry is misspelled, it is possible to attempt to connect to a server using the correct IP address but an incorrect name. In this case, a TCP connection is still established to the server. However, the server rejects the NetBIOS session request (using the wrong name), because there is no listen posted on that name. An Error 51, “Remote computer not listening,” is returned.
NetBIOS Datagram Services
Datagrams are sent from one NetBIOS name to another over UDP port 138. The datagram service provides the ability to send a message to a unique name or to a group name. Group names may resolve to a list of IP addresses or a broadcast. For example, the command net send /d:mydomain test sends a datagram containing the text “test” to the group name mydomain[03]. The mydomain[03] name resolves to an IP subnet broadcast, so the datagram is sent with the following characteristics:
-
Destination MAC address: broadcast (0xFF-FF-FF-FF-FF-FF).
-
Source MAC address: The MAC address of the sending interface.
-
Destination IP address: The local subnet broadcast address.
-
Source IP address: The IP address of the local computer.
-
Destination name: mydomain[03] (the messenger service on the remote computers).
-
Source name: username[03] (the messenger service on the local computer).
All hosts on the subnet pick up the datagram and process it, at least to the UDP protocol. On hosts that are running a NetBIOS datagram service, UDP hands the datagram to NetBT on port 138. NetBT checks the destination name to see if any application has posted a datagram receive on it and if so, passes the datagram up. If no receive is posted, the datagram is discarded.
If support for NetBIOS is disabled in Windows Server 2003 (as described earlier in this section), NetBIOS datagram services are not available.
|
