O'Reilly logo

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

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

An Introduction to the SMB Protocol

Now we’re going to cover some low-level technical details and explore the elementals of the SMB protocol. You probably don’t need to know much about this to implement a simple Samba network, and therefore you might want to skip or skim over this section and go on to the next one (“Windows Workgroups and Domains”) on your first reading. However, assuming you are going to be responsible for long-term maintenance of a Samba network, it will help if you understand how it actually works. You will more easily be able to diagnose and correct any odd problems that pop up.

At a high level, the SMB protocol suite is relatively simple. It includes commands for all the file and print operations that you might perform on a local disk or printer, such as:

  • Opening and closing files

  • Creating and deleting files and directories

  • Reading and writing files

  • Searching for files

  • Queueing and dequeueing files in a print spool

Each operation can be encoded into an SMB message and transmitted to and from a server. The original name “SMB” comes from the way in which the commands are formatted: they are versions of the standard DOS system-call data structures, or Server Message Blocks, redesigned for transmitting to another computer across a network.

SMB Format

Richard Sharpe of the Samba team defines SMB as a request-response protocol.[4] In effect, this means that a client sends an SMB request to a server and the server sends an SMB response back to the client. In only one rare circumstance does a server send a message that is not in response to a client.

An SMB message is not as complex as you might think. Let’s take a closer look at the internal structure of such a message. It can be broken down into two parts: the header, which is a fixed size, and the command string, whose size can vary dramatically based on the contents of the message.

SMB header format

Table 1-6 shows the format of an SMB header. The COM field identifies the command being performed. SMB commands are not required to use all the fields in the SMB header. For example, when a client first attempts to connect to a server, it does not yet have a tree identifier (TID) value—one is assigned after it successfully connects—so a null TID is placed in its header field. Other fields can be padded with zeros when not used.

The SMB header fields are listed in Table 1-6.

Table 1-6. SMB header fields

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

SMB command format

Immediately after the header is a variable number of bytes that constitute an SMB command or reply. Each command, such as Open File (COM field identifier: SMBopen) or Get Print Queue (SMBsplretq ), has its own set of parameters and data. Like the SMB header fields, not all of the command fields need to be filled, depending on the specific command. For example, the Get Server Attributes (SMBdskattr) command sets the WCT and BCC fields to zero. The fields of the command segment are shown in Table 1-7.

Table 1-7. SMB command contents

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)

Don’t worry if you don’t understand each field; they are not necessary for using Samba at an administrator level. However, they do come in handy when debugging system messages. We will show you some of the more common SMB messages that clients and servers send using a modified version of tcpdump later in this section. (If you prefer an SMB sniffer with a graphical interface, try Ethereal, which uses the GTK libraries; see http://www.ethereal.com for more information on this tool.)

Tip

For more information on each command in the SMB protocol, see the CIFS Technical Reference at http://www.snia.org/tech_activities/CIFS.

SMB variations

The SMB protocol has been extended with new commands several times since its inception. Each new version is backward-compatible with the previous versions, so it is possible for a LAN to have clients and servers concurrently running different versions of the SMB protocol.

Table 1-8 outlines the major versions of the SMB protocol. Within each “dialect” of SMB are many sub-versions that include commands supporting particular releases of major operating systems. The ID string in column 2 is used by clients and servers to determine in which level of the protocol they will speak to each other.

Table 1-8. SMB protocol dialects

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

Samba implements the NT LM 0.12 specification for NT LAN Manager 1.0. It is backward-compatible with all the other SMB variants. The CIFS specification is, in reality, LAN Manager 0.12 with a few specific additions.

SMB Clients and Servers

As mentioned earlier, SMB is a client/server protocol. In the purest sense, this means that a client sends a request to a server, which acts on the request and returns a reply. However, the client/server roles can often be reversed, sometimes within the context of a single SMB session. For example, consider the two Windows 95/98/Me computers in Figure 1-11. The computer named maya shares a printer to the network, and the computer named toltec shares a disk directory. maya is in the client role when accessing toltec’s network drive and in the server role when printing a job for toltec.

Two computers that both have resources to share

Figure 1-11. Two computers that both have resources to share

This brings out an important point in Samba terminology:

  • A server is a computer with a resource to share.

  • A client is a computer that wishes to use that resource.

  • A computer can be a client, a server, or both, or it can be neither at any given time.

Microsoft Windows products have both the SMB client and server built into the operating system, and it is common to find Windows acting as a server, client, both, or neither at any given time in a production network. Although Samba has been developed primarily to function as a server, there are also ways that it and associated software can act as an SMB client. As with Windows, it is even possible to set up a Unix system to act as an SMB client and not as a server. See Chapter 5 for more details on this topic.

A Simple SMB Connection

The client and server must complete three steps to establish a connection to a resource:

  1. Establish a NetBIOS session.

  2. Negotiate the protocol variant.

  3. Set session parameters, and make a tree connection to a resource.

We will examine each step through the eyes of a useful tool that we mentioned earlier: the modified tcpdump that is available from the Samba web site.

Tip

You can download the tcpdump program at http://www.samba.org in the samba/ftp/tcpdump-smb directory; the latest version as of this writing is 3.4-10. Use this program as you would use the standard tcpdump application, but add the -s 1500 switch to ensure that you get the whole packet and not just the first few bytes.

Establishing a NetBIOS Session

When a user first makes a request to access a network disk or send a print job to a remote printer, NetBIOS takes care of making a connection at the session layer. The result is a bidirectional channel between the client and server. The client and server need only two messages to establish this connection. This is shown in the following example session request and response, as captured by tcpdump .

First, the client sends a request to open a session, and tcpdump reports:

>>> NBT Packet
NBT Session Request
Flags=0x81000044
Destination=TOLTEC      NameType=0x20 (Server)
Source=MAYA             NameType=0x00 (Workstation)

Then the server responds, granting a session to the client:

>>> NBT Packet
NBT Session Granted
Flags=0x82000000

At this point, there is an open channel between the client and server.

Negotiating the Protocol Variant

Next, the client sends a message to the server to negotiate an SMB protocol. As mentioned earlier, the client sets its tree identifier (TID) field to zero, because it does not yet know what TID to use. A tree identifier is a number that represents a connection to a share on a server.

The command in the message is SMBnegprot, a request to negotiate a protocol variant that will be used for the entire session. Note that the client sends to the server a list of all the variants that it can speak, not vice versa:

>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=154

SMB PACKET: SMBnegprot (REQUEST)
SMB Command   =  0x72
Error class   =  0x0
Error code    =  0
Flags1        =  0x0
Flags2        =  0x0
Tree ID       =  0
Proc ID       =  5315
UID           =  0
MID           =  257
Word Count    =  0
Dialect=PC NETWORK PROGRAM 1.0
Dialect=MICROSOFT NETWORKS 3.0
Dialect=DOS LM1.2X002
Dialect=DOS LANMAN2.1
Dialect=Windows for Workgroups 3.1a
Dialect=NT LM 0.12

The server responds to the SMBnegprot request with an index (with counting starting at 0) into the list of variants that the client offered, or with the value 0xFF if none of the protocol variants is acceptable:

>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=84

SMB PACKET: SMBnegprot (REPLY)
SMB Command   =  0x72
Error class   =  0x0
Error code    =  0
Flags1        =  0x80
Flags2        =  0x1
Tree ID       =  0
Proc ID       =  5315
UID           =  0
MID           =  257
Word Count    =  17
NT1 Protocol
DialectIndex=5
[...]

In this example, the server responds with the value 5, which indicates that the NT LM 0.12 dialect will be used for the remainder of the session.

Set Session and Login Parameters

The next step is to transmit session and login parameters for the session, which you do using the SMBSesssetupX command. The parameters include the following:

  • The account name and password (if there is one)

  • The workgroup name

  • The maximum size of data that can be transferred

  • The number of pending requests that can be in the queue at a time

The resulting output from tcpdump is:

>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=150

SMB PACKET: SMBsesssetupX (REQUEST)
SMB Command   =  0x73
Error class   =  0x0
Error code    =  0
Flags1        =  0x10
Flags2        =  0x0
Tree ID       =  0
Proc ID       =  5315
UID           =  1
MID           =  257
Word Count    =  13
Com2=0x75
Res1=0x0
Off2=120
MaxBuffer=2920
MaxMpx=50
VcNumber=0
SessionKey=0x1380
CaseInsensitivePasswordLength=24
CaseSensitivePasswordLength=0
Res=0x0
Capabilities=0x1
Pass1&Pass2&Account&Domain&OS&LanMan=  
  JAY METRAN Windows 4.0 Windows 4.0

SMB PACKET: SMBtconX (REQUEST) (CHAINED)
smbvwv[]=
Com2=0xFF
Off2=0
Flags=0x2
PassLen=1
Passwd&Path&Device=
smb_bcc=23
smb_buf[]=\\TOLTEC\SPIRIT

In this example, the SMBsesssetupX Session Setup command allows for an additional SMB command to be piggybacked onto it (indicated by the letter X at the end of the command name). The hexadecimal code of the second command is given in the Com2 field. In this case the command is 0x75, which is the SMBtconX (Tree Connect and X) command. The SMBtconX message looks for the name of the resource in the smb_buf buffer. In this example, smb_buf contains the string \\TOLTEC\SPIRIT, which is the full pathname to a shared directory on toltec. Using the “and X” commands like this speeds up each transaction because the server doesn’t have to wait on the client to make a second request.

Note that the TID is still zero. Finally, the server returns a TID to the client, indicating that the user has been authorized access and that the resource is ready to be used:

>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=85

SMB PACKET: SMBsesssetupX (REPLY)
SMB Command   =  0x73
Error class   =  0x0
Error code    =  0
Flags1        =  0x80
Flags2        =  0x1
Tree ID       =  1
Proc ID       =  5315
UID           =  100
MID           =  257
Word Count    =  3
Com2=0x75
Off2=68
Action=0x1
[000] Unix Samba 2.2.6
[010] METRAN

SMB PACKET: SMBtconX (REPLY) (CHAINED)
smbvwv[]=
Com2=0xFF
Off2=0
smbbuf[]=
ServiceType=A:

The ServiceType field is set to “A” to indicate that this is a file service. Available service types are:

  • “A” for a disk or file

  • “LPT1” for a spooled output

  • “COMM” for a direct-connect printer or modem

  • “IPC” for a named pipe

Now that a TID has been assigned, the client can use it as a handle to perform any operation that it would use on a local disk drive. It can open files, read and write to them, delete them, create new files, search for filenames, and so on.



[4] See http://www.samba.org/cifs/docs/what-is-smb.html for Richard’s excellent summary of SMB.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required