Share via


NetBIOS Over TCP/IP

The Windows 2000 implementation of NetBIOS over TCP/IP is referred to as NetBT . NetBT uses the following TCP and UDP ports:

  • UDP port 137 (name services)

  • UDP port 138 (datagram services)

  • TCP port 139 (session services)

NetBIOS over TCP/IP is specified by RFC 1001 and RFC 1002. The Netbt.sys driver is a kernel -mode component that supports the TDI interface. Services such as workstation and server use the TDI interface directly, while traditional NetBIOS applications have their calls mapped to TDI calls through the Netbios.sys driver. Using TDI to make calls to NetBT is a more difficult programming task, but can provide higher performance and freedom from historical NetBIOS limitations.

NetBIOS defines a software interface and a naming convention, not a protocol. 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 IP internetworks and providing interoperability with various other operating systems.

The Windows 2000 workstation service, server service, browser, messenger, and NetLogon services are all NetBT clients and use TDI to communicate with NetBT. Windows 2000 also includes a NetBIOS emulator. The emulator takes standard NetBIOS requests from NetBIOS applications and translates them to equivalent TDI functions.

Windows 2000 uses NetBIOS over TCP/IP to communicate with prior versions of Windows NT and other clients, such as Windows 95. However, the Windows 2000 redirector and server components now support direct hosting for communicating with other computers running Windows 2000. With direct hosting, NetBIOS is not used for name resolution. DNS is used for name resolution and the Microsoft networking communication is sent directly over TCP without a NetBIOS header. Direct hosting over TCP/IP uses TCP port 445 instead of the NetBIOS session 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 given attempt. NetBIOS over TCP/IP support can be disabled to force all traffic to use TCP/IP direct hosting.

To disable NetBIOS over TCP/IP support

  1. From the Network and Dial-up Connections icon in Control Panel , select Local Area Connection and right-click Properties .

  2. On the General tab, click Internet Protocol (TCP/IP) in the list of components, and click the Properties button.

  3. Click the Advanced button.

  4. Click the WINS tab. Click Disable NetBIOS over TCP/IP .

Applications and services that depend on NetBIOS over TCP/IP no longer function once NetBIOS over TCP/IP is disabled. Therefore, verify that any clients and applications no longer need NetBIOS over TCP/IP support before you disable it.

NetBIOS Names

The NetBIOS namespace is flat, meaning that all names within the namespace must be unique. NetBIOS names are 16 bytes long. Resources are identified by NetBIOS names, which are registered dynamically when services or applications start, or users log on. Names can be registered as unique names (one owner) or as group names (multiple owners). A NetBIOS Name Query is used to locate a resource by resolving the NetBIOS name to an IP address.

Microsoft networking components, such as the workstation and server services, allow the first 15 characters of a NetBIOS name to be specified by the user or administrator, but reserve the 16th character of the NetBIOS name to indicate a resource type (00-FF hex). Tables 2.2 and 2.3 have some example NetBIOS names used by Microsoft components:

Table 2.2 Unique NetBIOS Names Used by Microsoft Components

Unique Name

Service

<computer_name>[00] (space filled) 1

Workstation Service

<computer_name>[03] (space filled)

Messenger Service

<computer_name>[06] (space filled)

RAS Server Service

<computer_name>[1F] (space filled)

NetDDE Service

<computer_name>[20] (space filled)

Server Service

<computer_name>[21] (space filled)

RAS Client Service

<computer_name>[BE] (0xBE filled)

Network Monitor Agent

<computer_name>[BF] (0xBF filled)

Network Monitor Application

<user_name>[03] (space filled)

Messenger Service

<domain_name>[1D] (space filled)

Master Browser

<domain_name>[1B] (space filled)

Domain Master Browser

1 The number in brackets is a hexadecimal number. (space filled) means that if the computer or domain name is not 15 characters long, the name is filled with spaces up to 15 characters.

Table 2.3 Group NetBIOS Names Used by Microsoft Components

Group Name

Service

<domain_name>[00] (space filled)

Domain Name

<domain_name>[1C] (space filled)

Domain Controllers

<domain_name>[1E] (space filled)

Browser Service Elections

[01h][01h]__MSBROWSE__[01h][01h]

Master Browser

NBTStat Tool

The NBTStat tool is used to view and register NetBIOS names on a Windows 2000 computer. To see which NetBIOS names a computer has registered over NetBT, type the following from a command prompt:

nbtstat -n

Windows 2000 allows you to reregister NetBIOS names with the name server after a computer has already been started. To reregister NetBIOS names, type the following from a command prompt:

nbtstat –RR

NetBIOS Name Registration and Resolution

Windows 2000 TCP/IP systems use several methods to locate NetBIOS resources:

  • NetBIOS name cache.

  • NetBIOS name server.

  • IP subnet broadcasts.

  • Static Lmhosts file.

  • Static Hosts file (optional, depends on EnableDns registry entry (HKLM\SYSTEM\CurrentControlSet\Services\Netbt\Parameters)).

  • DNS servers (optional, depends on EnableDns registry entry).

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 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 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 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 includes 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 name server to locate resources is generally preferable to broadcasting for two reasons:

  • Broadcasts are not usually forwarded by routers.

  • Broadcast frames are processed by all computers on a subnet.

Figures 2.4 through 2.5 illustrate the NetBIOS name resolution methods used by Windows 2000.

Cc940063.CNBC05(en-us,TechNet.10).gif

Figure 2.4 NetBIOS Name Resolution Flowchart (part 1 of 2)

Cc940063.CNBC05B(en-us,TechNet.10).gif

Figure 2.5 NetBIOS Name Resolution Flowchart (part 2 of 2)

NetBIOS Name Registration and Resolution for Multihomed Computers

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 network adapter installed. When a name registration packet is sent from a multihomed computer, 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 computer receives a broadcast NetBIOS Name Query, all NetBT and interface bindings that receive the query respond with their addresses, and by default the client chooses the first response and connects to the address supplied by the responder. To have the responder randomly choose the IP address to put in the name query response, set the value of the RandomAdapter registry entry (HKLM\SYSTEM\CurrentControlSet\Services\Netbt\Parameters) to 1. This can be used by a server with two interfaces on the same network for load balancing.

When a directed name query is sent to a WINS server, the WINS server responds with a list of all IP addresses that are registered with WINS by the multihomed computer.

A Windows 2000 client uses the following process to choose the best IP address to connect to on a multihomed computer:

  1. If one of the IP addresses in the name query response list is on the same logical subnet as 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.

  2. If one of the IP addresses in the list is on the same logical subnet as any binding of NetBT on the local computer, then that address is selected. If multiple addresses meet this criteria, one is picked at random.

  3. If none of the IP addresses in the list is on the same subnet as any binding of NetBT on the local computer, then an address is selected at random from the list.

  4. 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 reasonable balancing of connections to a server across multiple network adapters, while still favoring local (same subnet) connections when they are available. To provide some fault tolerance, when there is a list of IP addresses 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, then a connection attempt is made to the first address in the list. This is tried in case there is a firewall or other device filtering ICMP traffic. Windows 2000 supports "per interface" NetBT name caching, and nbtstat -c displays the name cache on a per interface basis.

Windows 2000 NetBT Internet/DNS Enhancements

It is possible to connect from one Windows 2000–based computer to another using NetBT over the Internet. To do so, some means of name resolution has to be provided. Two common methods are the Lmhosts file or a WINS server. Several enhancements were introduced in Windows NT 4.0 and carried forward in Windows 2000 to eliminate these special configuration needs.

It is now possible to connect to a NetBIOS over TCP/IP resource in two new 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 server 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 at the IP address of 198.105.232.1 are shown here.

  • net use f: \\ftp.microsoft.com\data

  • net use \\198.105.232.1\data

  • net view \\198.105.232.1

  • dir \\ftp.microsoft.com\bussys\winnt

In addition, various applications allow you to enter an FQDN or IP address in place of a computer name. This new behavior is illustrated in Figure 2.6.

Cc940063.CNBC06(en-us,TechNet.10).gif

Figure 2.6 Behavior of NetBT Internet/DNS Enhancements

In Windows 2000, it is also possible to use direct hosting to establish redirector or server connections between Windows 2000 computers without the use of NetBIOS. By default, Windows 2000 attempts to make connections using both methods so that it can support connections to older versions of Windows computers. However, in Windows 2000–only environments, you can disable NetBIOS over TCP/IP as described in the "NetBIOS Over TCP/IP Sessions" following in this chapter.

The new interface in Windows 2000 that makes NetBIOS-less operation possible is called the Server Message Block (SMB) device. It appears to the redirector and server as another interface, much like an individual network adapter/protocol stack combination. However, at the TCP/IP stack, the SMB device is bound to ADDR_ANY, and uses the DNS namespace natively like a Windows Sockets application. Calls placed on the SMB device result in a standard DNS lookup to resolve the domain name to an IP address, followed by a single outbound connection request 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 NetBIOS over TCP port 139.

NetBIOS Over TCP/IP Sessions

NetBIOS sessions are established between two names. For example, when a Windows 2000 workstation service makes a file sharing connection to a Windows 2000 server service using NetBIOS over TCP/IP, the following sequence of events takes place:

  1. The NetBIOS name for the server process is resolved to an IP address.

  2. A TCP connection is established from the workstation to the server, using TCP port 139.

  3. The workstation sends a NetBIOS Session Request to the server name over the TCP connection. Assuming the server is listening on that name, it will respond affirmatively and a session is established.

Once the NetBIOS session has been established, the client and server negotiate the file sharing connection with the Server Message Block (SMB) protocol. Microsoft networking uses only one NetBIOS session between two names at any point in time. Any additional file or print sharing connections made after the first one are multiplexed over the same NetBIOS session.

NetBIOS keep-alives are used on each connection to verify that the server and workstation are still both up and able to maintain their session. This way, if a workstation is shut down ungracefully, the server will eventually clean up the connection and associated resources, and vice versa. NetBIOS keep-alives are controlled by the SessionKeepAlive registry entry (HKLM\SYSTEM\CurrentControlSet\Services\Netbt\Parameters) 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 NetBIOS session request using an invalid name will be rejected by the server. If attempting the connection with the net use command, "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 can resolve to a list of IP addresses or a broadcast. For instance, 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: The MAC-level broadcast (0xFF-FF-FF-FF-FF-FF).

  • Source MAC address: The MAC address of the local computer.

  • 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 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 registered that name, and if so, passes up the datagram. If no receive message was posted, the datagram is discarded.

Note that if support for NetBIOS is disabled in Windows 2000, then the NetBIOS datagram is discarded by UDP.