16.4 Transaction SMBs

We are going to blast through this, so you'd better get your running shoes on.

The purpose of the Transaction SMBs is to carry specialized sub-protocols. Examples include the R emote A dministration P rotocol (RAP) and Microsoft's implementation of DCE/RPC (MS-RPC). There are other, more esoteric sets of calls as well. We will play with some of them when we get to the Browse Service.

Think of these sub-protocols as sets of function calls that are stretched across the network. As suggested in Figure 16.1, a function call is made on the client side and the parameters and data are packed up and shoved across the network. The call is then completed at the remote end and the results (if any) are packed up and shoved back. In CIFS jargon, that's called a transaction .

Figure 16.1. Remote Procedure Call via transaction

• Software on the client calls the function fn() .

• The parameters and pass-by-reference data are packed into an SMB Transaction and sent to the server.

• The server processes the function call.

• If results are expected, the server packs the return value(s) and any pass-by-reference data into a reply transaction.

Transactions are designed to be able to transfer more data than the limit imposed by the negotiated buffer size. They do so by fragmenting the payload. The protocol for sending large P rotocol D ata U nits (PDUs) is described in a variety of documents, but here is a quick run-down:

1. A primary Transaction SMB is sent. It includes the total expected size of the transaction (so that the server can prepare to receive the data). It also contains as much of the data as will fit in a single SMB message. If everything fits, skip to step 4.

2. The server sends back an interim response. If the interim response contains an error code then the transaction will be aborted. Otherwise, it is a signal telling the client to continue. The WORDCOUNT and BYTECOUNT fields are both zero in this message (it's a disembodied header).

3. The client sends as many secondary Transaction SMBs as necessary to complete the transaction request.

4. The server executes the called function.

5. The server sends as many response messages as necessary to return the results. In some cases the request does not generate results, and no response is required.

There are three primary Transaction SMBs:

 SMB_COM_TRANSACTION  == 0x25 SMB_COM_TRANSACTION2 == 0x32 SMB_COM_NT_TRANSACT  == 0xA0 

Those are really long names , so folks on the various mailing lists tend to shorten them to "SMBtrans," "Trans2," and "NTtrans," respectively. Each of these also has a matching secondary:

 SMB_COM_TRANSACTION_SECONDARY  == 0x26 SMB_COM_TRANSACTION2_SECONDARY == 0x33 SMB_COM_NT_TRANSACT_SECONDARY  == 0xA1 

There is very little difference between these three transaction types, except that the NTtrans SMB has 32-bit fields where the other two have 16-bit fields. That means that NTtrans can handle a lot more data (that is, much larger transactions). Besides that, the real difference between these three is the set of functions that are traditionally carried over each.

The SNIA doc and the Leach/Naik CIFS draft provide examples of transactions that use Trans2 and NTtrans. Calls that use SMBtrans are documented elsewhere. Places to look include Luke's book ( DCE/RPC over SMB ), the Leach/Naik Browser and RAP Internet Drafts, and the X/ Open documentation (particularly IPC Mechanisms for SMB ). These (as you already know) are listed in the References section.

16.4.1 Mailslots and Named Pipes

Just to simplify things even further, SMBtrans supports yet another layer of abstraction.

Mailslots and Named Pipes are used to access specific sets of remote functions. For example, the "LANMAN" pipe (which is identified as \PIPE\LANMAN ) is always used for RAP calls.

Named Pipes are two-way inter-process communications channels. Once opened, they can be read from or written to as if they were files. In contrast, Mailslots are used for one-way, connectionless communications.

...and this is where something unexpected happens. Mailslot messages are sent using SMBs transported via the NBT Datagram Service . You'll have to see it to believe it, but that is easily arranged. All you need to do is grab a packet capture of port 138 on an active LAN, one with a few local servers that announce themselves to the working Network Neighborhood. If you don't like to wait, reboot something. A Windows 9x system that offers shares will do nicely .

This topic will be revisited in Part III on page 335. If you want to do some extra-curricular reading, the X/Open IPC Mechanisms for SMB document is recommended.