Getting Familiar with an SMB Network

+ +

Now that you have had a brief tour of +Samba, let's take some time to get familiar with +Samba's adopted environment: an SMB network. +Networking with SMB is significantly different from working with +common TCP/IP protocols such as FTP and Telnet because there are +several new concepts to learn and a lot of information to cover. +First, we will discuss the basic concepts behind an SMB network, +followed by some Microsoft implementations of it, and finally we will +show you where a Samba server can and cannot fit into the picture.

+ + +

+ +

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.
+

+ +

+ + +

+ Field +	+ Size (bytes) +	+ Description +
+ `0xFF 'SMB`' +	+ `1` +	+ Protocol identifier +
+ `COM` +	+ `1` +	+ Command code, from 0x00 to 0xFF +
+ `RCLS` +	+ `1` +	+ Error class +
+ `REH` +	+ `1` +	+ Reserved +
+ `ERR` +	+ `2` +	+ Error code +
+ `REB` +	+ `1` +	+ Reserved +
+ `RES` +	+ `14` +	+ Reserved +
+ `TID` +	+ `2` +	+ TID; a unique ID for a resource in use by the client +
+ `PID` +	+ `2` +	+ Caller process ID +
+ `UID` +	+ `2` +	+ User identifier +
+ `MID` +	+ `2` +	+ Multiplex identifier; used to route requests inside a process +

+ Field +	+ Size (bytes) +	+ Description +
+ `WCT` +	+ `1` +	+ Word count +
+ `VWV` +	+ Variable +	+ Parameter words (size given by WCT) +
+ `BCC` +	+ `2` +	+ Parameter byte count +
+ `DATA` +	+ Variable +	+ Data (size given by BCC) +

+ Protocol name +	+ ID string +	+ Used by +
+ Core +	+ `PC NETWORK PROGRAM 1.0` +	+
+ Core Plus +	+ `MICROSOFT NETWORKS 1.03` +	+
+ LAN Manager 1.0 +	+ `LANMAN1.0` +	+
+ LAN Manager 2.0 +	+ `LM1.2X002` +	+
+ LAN Manager 2.1 +	+ `LANMAN2.1` +	+
+ NT LAN +Manager 1.0 +	+ `NT LM 0.12` +	+ Windows NT 4.0 +
+ Samba's NT LM 0.12 +	+ `Samba` +	+ Samba +
+ Common +Internet File System +	+ `CIFS 1.0` +	+ Windows 2000/XP +

+ Role +	+ Can perform? +
+ File server +	+ Yes +
+ Printer server +	+ Yes +
+ Microsoft Dfs server +	+ Yes +
+ Primary domain controller +	+ Yes +
+ Backup domain controller +	+ No +
+ Active Directory domain controller +	+ No +
+ Windows 95/98/Me authentication +	+ Yes +
+ Windows NT/2000/XP authentication +	+ Yes +
+ Local master browser +	+ Yes +
+ Local backup browser +	+ Yes +
+ Domain master browser +	+ Yes +
+ Primary WINS server +	+ Yes +
+ Secondary WINS server +	+ No +

Chapter 1. Learning the Samba

What Is Samba?

What Can Samba Do for Me?

Sharing a Disk Service

Sharing a Printer

Seeing things from the Unix side

Getting Familiar with an SMB Network

Understanding NetBIOS

Getting a Name

Node Types

Table 1-1. NetBIOS node types

What's in a Name?

Resource names and types

Table 1-2. NetBIOS unique resource types

Group names and types

Table 1-3. NetBIOS group resource types

Scope ID

Datagrams and Sessions

Table 1-4. Datagram primitives

Table 1-5. Session primitives

An Introduction to the SMB Protocol

SMB Format

SMB header format

Table 1-6. SMB header fields

SMB command format

Table 1-7. SMB command contents

TIP

SMB variations

Table 1-8. SMB protocol dialects

SMB Clients and Servers

A Simple SMB Connection

TIP

Establishing a NetBIOS Session

Negotiating the Protocol Variant

Set Session and Login Parameters

Windows Workgroups and Domains

Windows Workgroups

Browsing

WARNING

Browsing elections

Windows 95/98/Me authentication

TIP

Windows NT Domains

Domain controllers

Primary and backup domain controllers

Authentication

Name service with WINS and DNS

Trust relationships

Active Directory Domains

Can a Windows Workgroup Span Multiple Subnets?

What's New in Samba 2.2?

PDC Support for Windows 2000/XP Clients

Microsoft Dfs Support

Windows NT/2000/XP Printing Support

ACLs

Support for Windows Client Administration Tools

Integration with Winbind

Unix CIFS Extensions

And More...

What's New in Samba 3.0?

What Can Samba Do?

Table 1-9. Samba roles (as of Version 3.0)

An Overview of the Samba Distribution

How Can I Get Samba?

Footnotes