Using Samba, Second Edition

Understanding NetBIOS

To begin, let’s step back in time. In 1984, IBM authored a simple application programming interface (API) for networking its computers, called the Network Basic Input/Output System (NetBIOS). The NetBIOS API provided a rudimentary design for an application to connect and share data with other computers.

It’s helpful to think of the NetBIOS API as networking extensions to the standard BIOS API calls. The BIOS contains low-level code for performing filesystem operations on the local computer. NetBIOS originally had to exchange instructions with computers across IBM PC or Token Ring networks. It therefore required a low-level transport protocol to carry its requests from one computer to the next.

In late 1985, IBM released one such protocol, which it merged with the NetBIOS API to become the NetBIOS Extended User Interface (NetBEUI ). NetBEUI was designed for small LANs, and it let each computer claim a name (up to 15 characters) that wasn’t already in use on the network. By a “small LAN,” we mean fewer than 255 nodes on the network—which was considered a generous number in 1985!

The NetBEUI protocol was very popular with networking applications, including those running under Windows for Workgroups. Later, implementations of NetBIOS over Novell’s IPX networking protocols also emerged, which competed with NetBEUI. However, the networking protocols of choice for the burgeoning Internet community were TCP/IP and UDP/IP, and implementing the NetBIOS APIs over those protocols soon became a necessity.

Recall that TCP/IP uses numbers to represent computer addresses (192.168.220.100, for instance) while NetBIOS uses only names. This was a major issue when trying to mesh the two protocols together. In 1987, the IETF published standardization documents, titled RFC 1001 and 1002, that outlined how NetBIOS would work over a TCP/UDP network. This set of documents still governs each implementation that exists today, including those provided by Microsoft with its Windows operating systems, as well as the Samba suite.

Since then, the standard that this document governs has become known as NetBIOS over TCP/IP , or NBT for short.^[3]

The NBT standard (RFC 1001/1002) currently outlines a trio of services on a network:

A name service
Two communication services:
- Datagrams
- Sessions

The name service solves the name-to-address problem mentioned earlier; it allows each computer to declare a specific name on the network that can be translated to a machine-readable IP address, much like today’s Domain Name System (DNS) on the Internet. The datagram and session services are both secondary communication protocols used to transmit data back and forth from NetBIOS computers across the network.

Getting a Name

In the NetBIOS world, when each computer comes online, it wants to claim a name for itself; this is called name registration. However, no two computers in the same workgroup should be able to claim the same name; this would cause endless confusion for any computer that wanted to communicate with either of them. There are two different approaches to ensuring that this doesn’t happen:

Use an NBNS to keep track of which hosts have registered a NetBIOS name.
Allow each computer on the network to defend its name in the event that another computer attempts to use it.

Figure 1-8 illustrates a (failed) name registration, with and without an NBNS.

Figure 1-8. Broadcast versus NBNS name registration

As mentioned earlier, there must be a way to resolve a NetBIOS name to a specific IP address; this is known as name resolution. There are two different approaches with NBT here as well:

Have each computer report back its IP address when it “hears” a broadcast request for its NetBIOS name.
Use an NBNS to help resolve NetBIOS names to IP addresses.

Figure 1-9 illustrates the two types of name resolution.

Figure 1-9. Broadcast versus NBNS name resolution

As you might expect, having an NBNS on your network can help out tremendously. To see exactly why, let’s look at the broadcast method.

Here, when a client computer boots, it will broadcast a message declaring that it wishes to register a specified NetBIOS name as its own. If nobody objects to the use of the name, it keeps the name. On the other hand, if another computer on the local subnet is currently using the requested name, it will send a message back to the requesting client that the name is already taken. This is known as defending the hostname. This type of system comes in handy when one client has unexpectedly dropped off the network—another can take its name unchallenged—but it does incur an inordinate amount of traffic on the network for something as simple as name registration.

With an NBNS, the same thing occurs, except the communication is confined to the requesting computer and the NBNS. No broadcasting occurs when the computer wishes to register the name; the registration message is simply sent directly from the client to the NBNS, and the NBNS replies regardless of whether the name is already taken. This is known as point-to-point communication , and it is often beneficial on networks with more than one subnet. This is because routers are generally configured to block incoming packets that are broadcast to all computers in the subnet.

The same principles apply to name resolution. Without an NBNS, NetBIOS name resolution would also be done with a broadcast mechanism. All request packets would be sent to each computer in the network, with the hope that one computer that might be affected will respond directly back to the computer that asked. Using an NBNS and point-to-point communication for this purpose is far less taxing on the network than flooding the network with broadcasts for every name-resolution request.

It can be argued that broadcast packets do not cause significant problems in modern, high-bandwidth networks of hosts with fast CPUs, if only a small number of hosts are on the network, or the demand for bandwidth is low. There are certainly cases where this is true; however, our advice throughout this book is to avoid relying on broadcasts as much as possible. This is a good rule to follow for large, busy networks, and if you follow our advice when configuring a small network, your network will be able to grow without encountering problems later on that might be difficult to diagnose.

Node Types

How can you tell what strategy each client on your network will use when performing name registration and resolution? Each computer on an NBT network earns one of the following designations, depending on how it handles name registration and resolution: b-node, p-node, m-node, and h-node. The behaviors of each type of node are summarized in Table 1-1.

Table 1-1. NetBIOS node types

Role	Value
b-node	Uses broadcast registration and resolution only.
p-node	Uses point-to-point registration and resolution only.
m-node (mixed)	Uses broadcast for registration. If successful, it notifies the NBNS of the result. Uses broadcast for resolution; uses the NBNS if broadcast is unsuccessful.
h-node (hybrid)	Uses the NBNS for registration and resolution; uses broadcast if the NBNS is unresponsive or inoperative.

In the case of Windows clients, you will usually find them listed as h-nodes or hybrid nodes. The first three node types appear in RFC 1001/1002, and h-nodes were invented later by Microsoft, as a more fault-tolerant method.

You can find the node type of a Windows 95/98/Me computer by running the winipcfg command from the Start → Run dialog (or from an MS-DOS prompt) and clicking the More Info>> button. On Windows NT/2000/XP, you can use the ipconfig /all command in a command-prompt window. In either case, search for the line that says Node Type.

What’s in a Name?

The names NetBIOS uses are quite different from the DNS hostnames you might be familiar with. First, NetBIOS names exist in a flat namespace. In other words, there are no hierarchical levels, such as in oreilly.com (two levels) or ftp .samba.org (three levels). NetBIOS names consist of a single unique string such as navaho or hopi within each workgroup or domain. Second, NetBIOS names are allowed to be only 15 characters and can consist only of standard alphanumeric characters (a-z, A-Z, 0-9) and the following:

! @ # $ % ^ & ( ) - ' { } . ~

Although you are allowed to use a period (.) in a NetBIOS name, we recommend against it because those names are not guaranteed to work in future versions of NBT.

It’s not a coincidence that all valid DNS names are also valid NetBIOS names. In fact, the unqualified DNS name for a Samba server is often reused as its NetBIOS name. For example, if you had a system with a hostname of mixtec.ora.com , its NetBIOS name would likely be MIXTEC (followed by 9 spaces).

Resource names and types

With NetBIOS, a computer not only advertises its presence, but also tells others what types of services it offers. For example, mixtec can indicate that it’s not just a workstation, but that it’s also a file server and can receive Windows Messenger messages. This is done by adding a 16th byte to the end of the machine (resource) name, called the resource type, and registering the name multiple times, once for each service that it offers. See Figure 1-10.

Figure 1-10. The structure of NetBIOS names

The 1-byte resource type indicates a unique service that the named computer provides. In this book, you will often see the resource type shown in angled brackets (<>) after the NetBIOS name, such as:

MIXTEC<00>

You can see which names are registered for a particular NBT computer using the Windows command-line nbtstat utility. Because these services are unique (i.e., there cannot be more than one registered), you will see them listed as type UNIQUE in the output. For example, the following partial output describes the toltec server:

C:\>nbtstat -a toltec

       NetBIOS Remote Machine Name Table
   Name               Type         Status
---------------------------------------------
TOLTEC          <00>  UNIQUE      Registered
TOLTEC          <03>  UNIQUE      Registered
TOLTEC          <20>  UNIQUE      Registered
...

This says the server has registered the NetBIOS name toltec as a machine (computer) name, as a recipient of messages from the Windows Messenger service, and as a file server. Some possible attributes a name can have are listed in Table 1-2.

Table 1-2. NetBIOS unique resource types

Named resource	Hexadecimal byte value
Standard Workstation Service	00
Messenger Service	03
RAS Server Service	06
Domain Master Browser Service (associated with primary domain controller)	1B
Master Browser name	1D
NetDDE Service	1F
Fileserver (including printer server)	20
RAS Client Service	21
Network Monitor Agent	BE
Network Monitor Utility	BF

Group names and types

SMB also uses the concept of groups, with which computers can register themselves. Earlier we mentioned that the computers in our example belonged to a workgroup , which is a partition of computers on the same network. For example, a business might very easily have an ACCOUNTING and a SALES workgroup, each with different servers and printers. In the Windows world, a workgroup and an SMB group are the same thing.

Continuing our nbtstat example, the toltec Samba server is also a member of the METRAN workgroup (the GROUP attribute hex 00) and will participate in elections for the browse master (GROUP attribute 1E). Here is the remainder of the nbtstat output:

       NetBIOS Remote Machine Name Table
   Name               Type         Status
---------------------------------------------
METRAN         <00>   GROUP       Registered
METRAN         <1E>   GROUP       Registered
..__MSBROWSE__.<01>   GROUP       Registered

The possible group attributes a computer can have are illustrated in Table 1-3. More information is available in Windows NT in a Nutshell by Eric Pearce, also published by O’Reilly.

Table 1-3. NetBIOS group resource types

Named resource	Hexadecimal byte value
Standard Workstation group	00
Logon server	1C
Master Browser name	1D
Normal Group name (used in browser elections)	1E
Internet Group name (administrative)	20
`<01><02>_ _MSBROWSE_ _<02>`	01

The final entry, _ _ MSBROWSE _ _ , is used to announce a group to other master browsers. The nonprinting characters in the name show up as dots in an nbtstat printout. Don’t worry if you don’t understand all of the resource or group types. Some of them you will not need with Samba, and others you will pick up as you move through the rest of the chapter. The important thing to remember here is the logistics of the naming mechanism.

Scope ID

In the dark ages of SMB networking before NetBIOS groups were introduced, you could use a very primitive method to isolate groups of computers from the rest of the network. Each SMB packet contains a field called the scope ID , with the idea being that systems on the network could be configured to accept only packets with a scope ID matching that of their configuration. This feature was hardly ever used and unfortunately lingers in modern implementations. Some of the utilities included in the Samba distribution allow the scope ID to be set. Setting the scope ID in a network is likely to cause problems, and we are mentioning scope ID only so that you will not be confused by it when you later encounter it in various places.

Datagrams and Sessions

At this point, let’s digress to discuss the responsibility of NBT: to provide connection services between two NetBIOS computers. NBT offers two services: the session service and the datagram service . Understanding how these two services work is not essential to using Samba, but it does give you an idea of how NBT works and how to troubleshoot Samba when it doesn’t work.

The datagram service has no stable connection between computers. Packets of data are simply sent or broadcast from one computer to another, without regard to the order in which they arrive at the destination, or even if they arrive at all. The use of datagrams requires less processing overhead than sessions, although the reliability of the connection can suffer. Datagrams, therefore, are used for quickly sending nonvital blocks of data to one or more computers. The datagram service communicates using the simple primitives shown in Table 1-4.

Table 1-4. Datagram primitives

Primitive	Description
Send Datagram	Send datagram packet to computer or groups of computers.
Send Broadcast Datagram	Broadcast datagram to any computer waiting with a Receive Broadcast datagram.
Receive Datagram	Receive a datagram from a computer.
Receive Broadcast Datagram	Wait for a Broadcast datagram.

The session service is more complex. Sessions are a communication method that, in theory, offers the ability to detect problematic or inoperable connections between two NetBIOS applications. It helps to think of an NBT session as being similar to a telephone call, an analogy that obviously influenced the design of the CIFS standard.

Once the connection is made, it remains open throughout the duration of the conversation, each side knows who the caller and the called computer are, and each can communicate with the simple primitives shown in Table 1-5.

Table 1-5. Session primitives

Primitive	Description
Call	Initiate a session with a computer listening under a specified name.
Listen	Wait for a call from a known caller or any caller.
Hang-up	Exit a call.
Send	Send data to the other computer.
Receive	Receive data from the other computer.
Session Status	Get information on requested sessions.

Sessions are the backbone of resource sharing on an NBT network. They are typically used for establishing stable connections from client computers to disk or printer shares on a server. The client “calls” the server and starts trading information such as which files it wishes to open, which data it wishes to exchange, etc. These calls can last a long time—hours, even days—and all of this occurs within the context of a single connection. If there is an error, the session software (TCP) will retransmit until the data is received properly, unlike the “punt-and-pray” approach of the datagram service (UDP).

In truth, while sessions are supposed to handle problematic communications, they sometimes don’t. If the connection is interrupted, session information that is open between the two computers might become invalid. If that happens, the only way to regain the session information is for the same two computers to call each other again and start over.

If you want more information on each service, we recommend you look at RFC 1001. However, there are two important things to remember here:

Sessions always occur between two NetBIOS computers. If a session service is interrupted, the client is supposed to store sufficient state information for it to reestablish the connection. However, in practice, this often does not happen.
Datagrams can be broadcast to multiple computers, but they are unreliable. In other words, there is no way for the source to know that the datagrams it sent have indeed arrived at their destinations.

Using Samba, Second Edition by Jay Ts, Robert Eckstein, David Collier-Brown

Getting Familiar with an SMB Network