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.
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.
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 |
---|---|---|
|
|
Protocol identifier |
|
|
Command code, from 0x00 to 0xFF |
|
|
Error class |
|
|
Reserved |
|
|
Error code |
|
|
Reserved |
|
|
Reserved |
|
|
TID; a unique ID for a resource in use by the client |
|
|
Caller process ID |
|
|
User identifier |
|
|
Multiplex identifier; used to route requests inside a process |
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 |
---|---|---|
|
|
Word count |
|
Variable |
Parameter words (size given by WCT) |
|
|
Parameter byte count |
|
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.
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 |
| |
| ||
| ||
LAN Manager 2.0 |
| |
LAN Manager 2.1 |
| |
|
Windows NT 4.0 | |
|
Samba | |
|
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.
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
.
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.
The client and server must complete three steps to establish a connection to a resource:
Establish a NetBIOS session.
Negotiate the protocol variant.
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.
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.
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.
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.
Get Using Samba, Second Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.