2.1 Emulating NetBIOS LANs

2.1 Emulating "NetBIOS LANs"

At this point, we hit an interesting twist in the terminology. NetBIOS is a driver that presents an API; it is neither a protocol nor a topology. The API does, however, make a number of assumptions about the workings of the underlying network, and it presents some quirky restrictions. The terms "NetBIOS Network" and "NetBIOS LAN" are commonly used to identify the network architecture that is, essentially , defined by the NetBIOS API.

RFCs 1001 and 1002 list three basic services that must be supported in order to implement NetBIOS LAN emulation. These are:

  • the Name Service,

  • the Datagram Service, and

  • the Session Service.

The Name Service is used to map NetBIOS names (addresses) to IP addresses in the underlying IP network. The Datagram Service provides for the delivery of NetBIOS datagrams via UDP. Finally, the Session Service is used to establish and maintain point-to-point, connection-oriented NetBIOS sessions over TCP.

2.1.1 The NetBIOS Name Service

The NetBIOS LAN architecture is very simple. No routers, no switches just a bunch of nodes connected to a (virtual) wire. Unlike IP, there is no need for separate hardware addresses, network addresses, or even port numbers . Instead, the communications endpoints are identified by 16-byte strings known as "NetBIOS names."

NetBIOS addressing is dynamic. Applications may add names as needed and remove those names when they are finished. Each node on the LAN will also have a default name, known as the Machine Name or the Workstation Service Name , which is typically added when NetBIOS starts. The process of adding a name is called registration .

There are two kinds of names that can be registered: unique and group . Group names may be shared by multiple clients , thus providing a mechanism for multicast. In contrast, unique names may only be used by one client per LAN. Keep in mind, though, that these are virtual LANs which may actually be spread out across different subnets in a routed IP internetwork.

Figure 2.2. Group names

In addition to their Machine Names, some of the nodes on this IP LAN have registered the group name Lindisfarne . Nodes Mick and Ringo are not members of the group Lindisfarne .

graphics/02fig02.gif

The Name Service is supposed to keep track of all the NetBIOS names in use within the virtual LAN and ensure that messages sent to a given NetBIOS name are directed to the correct underlying IP address. It does this in two ways:

On an IP LAN

Each node keeps a list of the names it has registered (that is, the names it "owns"). When sending a message, the first step is to send an IP broadcast query, called a NAME QUERY REQUEST . If there is a machine on the IP LAN that owns the queried name, it will reply by sending a NAME QUERY RESPONSE .

So, to send a message to the node which has registered the name EADFRITH , the sender calls out "Yo! Eadfrith!" EADFRITH responds with an "I am here!" message, giving its IP address.

This is known as "B mode" (broadcast) name resolution, and the participants are referred to as "B n odes." In B mode, each node keeps track of and answers queries for its own names, so the NetBIOS Name Service "database" is a distributed database.

Figure 2.3. B mode name resolution

Node Chad wishes to contact node Eadfrith . Since the underlying transport is IP, Chad must first discover the IP address of Eadfrith .

Chad sends a broadcast name query to all nodes on the local segment, asking Eadfrith to respond. All other nodes should ignore the request.

graphics/02fig03.gif

Over a routed Internet

Broadcasts aren't meant to cross subnet boundaries, so a different mechanism is used when the nodes are separated by routers.

The Network Administrator chooses a machine to be the N et B IOS N ame S erver (NBNS, aka WINS Server [1] ). Typically this will be a Unix host running Samba, or a Windows NT or W2K server. In order to use the NBNS, all of the nodes that are participating in the virtual NetBIOS LAN must be given the server's IP address. This can be done by entering the address in the client's NetBIOS configuration or, on Windows systems, via DHCP.

[1] Microsoft calls their NBNS implementation " W indows I nternet N ame S ervice" (WINS). The term WINS is now commonly used instead of NBNS, but we will be pedantic and stick with the latter.

NBT client nodes send NetBIOS name registrations and queries directly to the NBNS, which maintains a central database of all registered names in the virtual LAN. This is known as "P mode" (point-to-point) name resolution, and its participants are referred to as "P nodes."

Figure 2.4. P mode name resolution
  1. Node Bede registers its name with Cuthbert , the NBNS (WINS server).

  2. Node Backhouse is looking for Bede and sends a query to Cuthbert .

  3. Cuthbert provides the IP address of Bede to Backhouse .

graphics/02fig04.gif

These are the two basic modes of NetBIOS name resolution over NBT. There are, of course, others. The RFCs describe "M mode" (mixed mode) which combines characteristics of P and B modes. "H mode" (hybrid mode) was introduced later; it is similar to M mode except for the order in which B and P mode behavior is applied.

The Name Service runs on UDP port 137. According to the RFCs the use of TCP port 137 can be negotiated for some queries, though few (if any) implementations actually support this.

2.1.2 The NetBIOS Datagram Service

In the IP world, TCP provides connection-oriented sessions in which packets are acknowledged , put in order, and retransmitted if lost. This creates the illusion of a continuous, sequential data stream from one end to the other. In contrast, UDP datagrams are simply sent. Thus, UDP requires less overhead, but it is less reliable than TCP. NetBIOS also provides connection-oriented (session) and connectionless (datagram) communications. Naturally, NBT maps NetBIOS sessions to TCP and NetBIOS datagrams to UDP.

The Datagram Distribution Service is the NBT service that handles NetBIOS datagram transport. It runs on UDP port 138, and can handle unicast (also known as "specific"), multicast (group), and broadcast NetBIOS datagrams.

Unicast (specific)

The handling of unicast datagrams is fairly straightforward. The Name Service is used to resolve the destination name to an IP address. The NetBIOS packet is then encapsulated in a UDP packet and sent to the specified IP.

Multicast (group) and broadcast

According to the RFCs, a B node can simply encapsulate NetBIOS multicast and broadcast datagrams in UDP and send them to the IP broadcast address. The UDP datagram will then be picked up by all local nodes listening on the Datagram Service port (138/UDP). Thus, NetBIOS broadcast datagrams will reach all nodes in the virtual LAN. In the case of multicast datagrams, nodes which are not members of the group (have not registered the group name) will discard the message.

P , M , and H nodes are a bit more complicated, as you might expect. When the virtual LAN extends beyond the physical LAN, an IP broadcast will not reach all of the nodes in the NetBIOS name space. In order to deliver group and broadcast datagrams, the NBNS database must be consulted. How this is (or isn't) actually done will be explained in strikingly painful detail later on. Chapter 5 on page 115 is dedicated to the workings of datagram distribution.

The Datagram Service is probably the second least well understood aspect of NBT, most likely because its correct implementation isn't critical to filesharing. Many implementations get it wrong, and there is much debate over the value of getting it right.

2.1.3 The NetBIOS Session Service

The Session Service is the traditional transport for SMB, and this is our primary reason for caring about NetBIOS at all. The Session Service runs on TCP port 139. [2] There is no particular mechanism for multicast or broadcast because each session is, by definition, a one-to-one connection. The RFCs do, however, briefly discuss what might happen if a session setup request were sent to a group name (see RFC 1001, Section 16.1.1.2).

[2] If the NBT authors had used TCP/138 instead of 139 for the Session Service, they could have saved a couple of ports. Instead, TCP/138 and UDP/139 are wasted .

We will get to the details of session creation, use, and closure when we discuss Session Service implementation.

Weirdness Alert

graphics/alert.gif

TCP/138 has no defined behavior under NBT and Microsoft never implemented support for NBT Name Resolution over TCP/137, yet some versions of Windows seem to listen on these two TCP ports when NBT is active.

 C:\> netstat -a Active Connections   Proto  Local Address     Foreign Address  State   TCP    paris:137         PARIS:0          LISTENING   TCP    paris:138         PARIS:0          LISTENING   TCP    paris:nbsession   PARIS:0          LISTENING   UDP    paris:nbname      *:*   UDP    paris:nbdatagram  *:* 

It turns out that this is due to a known bug in the netstat utility included with older Windows releases.


Email

graphics/email.gif

 From: Jean-Baptiste Marchand   To: Chris Hertel Hello, I've noticed that, in Section 2.1, there is a weirdness alert about the Windows netstat program showing TCP ports 137 and 138 open, whereas only UDP ports 137 and 138 are actually opened by the NetBT driver. In fact, it is a known problem in Windows NT (this is fixed in Windows 2000 and later) that netstat shows TCP ports opened, whereas only UDP ports with the same number are opened. This is documented in an entry of Microsoft's knowledge base (Q194171). This article states that this is only a display problem. This is true and can be verified using any TCP port scanner. 


Implementing CIFS. The Common Internet File System
Implementing CIFS: The Common Internet File System
ISBN: 013047116X
EAN: 2147483647
Year: 2002
Pages: 210

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net