3.3.5.57 Receiving any SMB_COM_TRANSACTION Subcommand Request

  • Article

SMB_COM_TRANSACTION and SMB_COM_TRANSACTION_SECONDARY implement the original transaction subprotocol created for the LAN Manager 1.0 dialect. The purpose of these transactions is to transfer requests and associated data to mailslots or to and from named pipes. With respect to CIFS, the operations sent to mailslots and exchanged with named pipes are known as subcommands.

The subcommands are not defined by the transaction subprotocol itself. Transactions simply provide a means for delivery and retrieval of the results. Support for and interpretation of an SMB_COM_TRANSACTION subcommand are specified by the mailslot or named pipe to which the subcommand is sent.

For example, the Remote Administration Protocol (RAP, also known as Remote API Protocol) is defined for use with the \PIPE\LANMAN named pipe. That is, if the Name field passed in the initial SMB_COM_TRANSACTION request contains the string "\PIPE\LANMAN", the message is designated to be delivered to the RAP subsystem, which listens on the \PIPE\LANMAN named pipe. The RAP subsystem interprets and processes the contents of the transaction request and provides the response. The RAP subsystem is documented in [MS-RAP]. Additional information is provided below.

Other than the \PIPE\LANMAN named pipe used by RAP, all named pipes accessed via the SMB transaction subprotocol support the set of subcommands specified in section 2.2.5 of this document, and in the following sections. These are commonly known as the SMB Trans subcommands. Each SMB Trans subcommand is identified by a subcommand code, which is specified in the first Setup word--Setup[0]--of the SMB_COM_TRANSACTION_SECONDARY request.

Mailslots typically support only the TRANS_MAILSLOT_WRITE subcommand. TRANS_MAILSLOT_WRITE requests are formatted as SMB_COM_TRANSACTION request messages, but they are not sent over an SMB connection. Instead, mailslot transactions are sent as individual datagrams outside of the context of any SMB connection. The transaction subprotocol allows for the reliable transmission of mailslot requests (Class 1 mailslot messages) within the CIFS Protocol, but no operations make use of this type of exchange and no such usage has been specified or implemented. Mailslot subcommands are, therefore, not covered in this document. See [MS-MAIL] for the mailslot subprotocol specification.

The transaction processing subsystems can be implemented in a variety of ways:

  • As an integral part of the CIFS server.

  • As a loadable library module.

  • As a separate process running independently.

  • Via some other mechanism not listed here.

If a transaction processing subsystem is independent of the CIFS server, the CIFS server MUST verify that transaction processing is available. The mechanism for doing so is implementation-dependent. If the transaction processing subsystem (RAP or SMB Trans) is not available, the server MUST return an error response with Status set to STATUS_NOT_IMPLEMENTED (ERRDOS/ERRbadfunc).

Named pipes MUST exist within the IPC$ share on the server. The TID in the SMB_COM_TRANSACTION request MUST represent a connection to the IPC$ share.

A named pipe can be opened, just as a file or device can be opened. The resulting FID is used by some of the SMB Trans subcommands to identify the pipe.

The SMB_COM_TRANSACTION request, when received by the server, is handled as specified in sections 3.3.5.31 and 3.3.5.2.4. Transfer of the full transaction request might require one or more SMB_COM_TRANSACTION_SECONDARY messages, as specified in section 3.2.4.1.4. When the transaction is received in full, the Setup, Trans_Parameters, and Trans_Data are passed to the subsystem that supports operations on the named pipe. In the case of a RAP request, the transaction is passed to the RAP subsystem. Otherwise, the transaction is passed to the subsystem that implements the SMB Trans calls specified in section 2.2.5.

When processing of the transaction has been completed, the subsystem returns the transaction response to the CIFS server, which returns the transaction response to the client. If the transaction response is too large to fit within a single SMB_COM_TRANSACTION response message (based upon the value of Server.Connection.ClientMaxBufferSize), the server MUST send multiple SMB_COM_TRANSACTION Final Transaction Response messages, as specified in section 3.2.4.1.4, in order to transport the entire transaction response to the client.