Microsoft Networks
`SMB FILE SHARING PROTOCOL
`
`Document Version 6.0p
`
`January 1, 1996
`Microsoft Corporation
`
`This document is an early release of the final specification. It is meant to specify and accompany
`software that is still in development. Some of the information in this documentation may be
`inaccurate or may not be an accurate representation of the functionality of the final specification or
`software. Microsoft assumes no responsibility for any damages that might occur either directly or
`indirectly from these inaccuracies. Microsoft may have trademarks, copyrights, patents or pending
`patent applications, or other intellectual property rights covering subject matter in this document.
`The furnishing of this document does not give you a license to these trademarks, copyrights,
`patents, or other intellectual property rights
`
`LG Electronics, Inc. et al.
`EXHIBIT 1012
`IPR Petition for
`U.S. Patent No. 7,149,511
`
`

`
`
`
`- 2 -
`
`
`
`Introduction
`
`Resource Sharing Connections
`Message Format
`
`Sample Messge Flow
`
`SMB Protocol Dialects
`
`Message Transport
`Reliable NetBIOS Transports
`Connectionless IPX Transport
`Naming On Ipx
`
`Opportunistic Locks
`Exclusive Oplocks
`Batch Oplocks
`Level II Oplocks
`
`NAMED PIPES
`Named Pipe Features
`
`SMB MESSAGES AND FORMATS
`
`SMB Header
`Flags field
`Flags2 Field
`Tid Field
`Pid Field
`Mid Field
`Status Field
`Timeouts
`Data Buffer (Buffer) and String Formats
`
`Time And Date Encoding
`
`Access Mode Encoding
`
`File Attribute Encoding
`
`“ANDX” SMB Messages
`
`SMB MESSAGES
`Valid SMB Messages by Negotiated Dialect
`NEGOTIATE: Negotiate Protocol
`SESSION_SETUP_ANDX: Session Setup And X
`LOGOFF_ANDX: User Logoff And X
`TREE_CONNECT: Tree Connect
`TREE_CONNECT_ANDX: Tree Connect And X
`TREE_DISCONNECT: Tree Disconnect
`CREATE_DIRECTORY: Create Directory
`DELETE_DIRECTORY: Delete Directory
`
`DRAFT
`
`
`
`5
`
`5
`7
`
`8
`
`8
`
`9
`9
`10
`12
`
`12
`13
`14
`15
`
`15
`16
`
`16
`
`16
`17
`17
`18
`18
`19
`19
`19
`19
`
`20
`
`20
`
`21
`
`21
`
`22
`22
`23
`26
`29
`29
`30
`31
`32
`32
`
`

`
`
`
`- 3 -
`
`CHECK_DIRECTORY: Check Directory
`OPEN: Open File
`CREATE: Create File
`CLOSE: Close File
`FLUSH: Flush File
`DELETE: Delete File
`RENAME: Rename File
`QUERY_INFORMATION: Get File Attributes
`SET_INFORMATION: Set File Attributes
`READ: Read File
`WRITE: Write Bytes
`LOCK_BYTE_RANGE: Lock Bytes
`UNLOCK_BYTE_RANGE: Unlock Bytes
`CREATE_TEMPORARY: Create Temporary File
`CREATE_NEW: Create File
`PROCESS_EXIT: Process Exit
`SEEK: Seek in File
`SMB_QUERY_INFORMATION_DISK: Get Disk Attributes
`SEARCH: Search Directory
`OPEN_PRINT_FILE: Create Print Spool file
`WRITE_PRINT_FILE: Write to Print File
`CLOSE_PRINT_FILE: Close and Spool Print Job
`GET_PRINT_QUEUE: Get Printer Queue Entries
`LOCK_AND_READ: Lock and Read Bytes
`WRITE_AND_UNLOCK: Write Bytes and Unlock Range
`READ_RAW: Read Raw
`READ_MPX: Read Block Multiplex
`WRITE_RAW: Write Raw Bytes
`WRITE_MPX: Write Block Multiplex
`SET_INFORMATION2: Set File Information
`QUERY_INFORMATION2: Get File Information
`LOCKING_ANDX: Lock or UnLock Bytes
`MOVE: Rename File
`COPY: Copy File
`ECHO: Ping the Server
`WRITE_AND_CLOSE: Write Bytes and Close File
`OPEN_ANDX: Open File And X
`NT_CREATE_ANDX: Create File
`READ_ANDX: Read Data
`WRITE_ANDX: Write Bytes to file or resource
`TRANSACTIONS
`SMB_COM_TRANSACTION and SMB_COM_TRANSACTION2 Formats
`SMB_COM_NT_TRANSACTION Formats
`Functional Description
`SMB_COM_TRANSACTION Operations
`Mail Slot Transaction Protocol
`Named Pipe Transaction Protocol
`CallNamedPipe
`WaitNamedPipe
`PeekNamedPipe
`GetNamedPipeHandleState
`SetNamedPipeHandleState
`GetNamedPipeInfo
`TransactNamedPipe
`RawReadNamedPipe
`
`DRAFT
`
`
`
`32
`33
`34
`35
`35
`35
`36
`37
`37
`37
`38
`39
`40
`40
`40
`41
`41
`42
`43
`44
`45
`45
`46
`47
`47
`48
`50
`51
`54
`55
`56
`56
`59
`60
`61
`61
`63
`65
`66
`67
`69
`69
`71
`72
`75
`75
`75
`76
`76
`76
`77
`77
`78
`78
`79
`
`

`
`
`
`- 4 -
`
`RawWriteNamedPipe
`SMB_COM_TRANSACTION2 Operations
`TRANS2_OPEN2
`TRANS2_FIND_FIRST2
`SMB_INFO_STANDARD
`SMB_INFO_QUERY_EA_SIZE
`SMB_INFO_QUERY_EAS_FROM_LIST
`SMB_FIND_FILE_DIRECTORY_INFO
`SMB_FIND_FILE_FULL_DIRECTORY_INFO
`SMB_FIND_FILE_BOTH_DIRECTORY_INFO
`SMB_FIND_FILE_NAMES_INFO
`TRANS2_FIND_NEXT2
`TRANS2_QUERY_FS_INFORMATION
`SMB_INFO_ALLOCATION
`SMB_INFO_VOLUME
`TRANS2_QUERY_PATH_INFORMATION
`SMB_INFO_STANDARD & SMB_INFO_QUERY_EA_SIZE
`SMB_INFO_QUERY_EAS_FROM_LIST & SMB_INFO_QUERY_ALL_EAS
`SMB_INFO_IS_NAME_VALID
`TRANS2_SET_PATH_INFORMATION
`SMB_INFO_STANDARD & SMB_INFO_QUERY_EA_SIZE
`SMB_INFO_QUERY_ALL_EAS
`TRANS2_QUERY_FILE_INFORMATION
`TRANS2_SET_FILE_INFORMATION
`TRANS2_CREATE_DIRECTORY
`SMB_COM_NT_TRANSACTION Operations
`NT_TRANSACT_CREATE
`NT_TRANSACT_IOCTL
`NT_TRANSACT_SET_SECURITY_DESC
`NT_TRANSACT_NOTIFY_CHANGE
`NT_TRANSACT_QUERY_SECURITY_DESC
`NT_CANCEL: Cancel request
`FIND_CLOSE2: Close Search
`
`SMB COMMAND CODES
`
`ERROR CODES AND CLASSES
`
`
`
`79
`79
`80
`82
`84
`84
`84
`85
`85
`85
`85
`86
`86
`88
`88
`88
`88
`89
`89
`89
`90
`90
`90
`90
`91
`91
`92
`92
`93
`93
`94
`94
`94
`
`95
`
`96
`
`DRAFT
`
`

`
`
`
`- 5 -
`
`
`
`Introduction
`
`This document describes the Lan Manager Server Message Block (SMB) file sharing protocol. Client
`systems use this protocol to request file, print, and communications service from server systems over a
`network.
`
`There are several different versions and sub-versions of this protocol, a particular version is referred to as a
`dialect. When two machines first come into network contact they negotiate the dialect to be used. For
`example, two NT systems would agree to use the NT-specific protocol dialect, while a Windows For
`Workgroups client communicating with an NT server might negotiate a Windows For Workgroups dialect.
`Different dialects can include both new messages as well as changes to the fields and semantics of existing
`messages in other dialects.
`
`
`Resource Sharing Connections
`Each server makes a set of resources available to clients on the network. A resource being shared may be a
`directory tree, named pipe, printer, etc. So far as clients are concerned, the server has no storage or service
`dependencies on any other servers; a client considers the server to be the sole provider of the file (or other
`resource) being accessed.
`
`The SMB protocol requires server authentication of users before file accesses are allowed, and each server
`authenticates its own users. A client system must send authentication information to the server before the
`server will allow access to its resources.
`
`The SMB protocol defines two methods which can be selected by the server for security: share level and
`user level:
`• A share level server makes some directory on a disk device (or other resource) available. An optional
`password may be required to gain access. Thus any user on the network who knows the name of the
`server, the name of the resource and the password has access to the resource. Share level security
`servers may use different passwords for the same shared resource with different passwords allowing
`different levels of access. Windows for Workgroups and Windows 95 servers, for instance, implement
`the share level security model.
`• A user level server makes some directory on a disk device (or other resource) available but in addition
`requires the client to provide a user name and corresponding user password to gain access. NT servers
`and LM/U servers implement this security model and do not support the share level model. User level
`servers are preferred over share level servers for any new server implementation, since corporations
`generally find user level servers easier to administer as employees come and go.
`
`
`When a user level server validates the account name and password presented by the client, an identifier
`representing that authenticated instance of the user is returned to the client in the Uid field of the response
`SMB. This Uid must be included in all further requests made on behalf of the user from that client. A
`share level server returns no useful information in the Uid field.
`
`The user level security model was added after the original dialect of the SMB protocol was issued, and
`subsequently some clients may not be capable of sending account name and passwords to the server. A
`server in user level security mode communicating with one of these clients will allow a client to connect to
`resources even if the client has not sent account name and password information:
`
`1.
`
`If the client's computer name is identical to an account-name known on the server, and if the password
`supplied to connect to the shared resouce matches that account’s password, an implicit "user logon"
`will be performed using those values.
`
`
`
`If the above fails, the server may fail the request or assign a default account name of its choice.
`
`DRAFT
`
`

`
`
`
`- 6 -
`
`
`
`2. The value of Uid in subsequent requests by the client will be ignored and all access will be validated
`assuming the account name selected above.
`
`
`The following examples illustrate a possible command line user interface for a server to offer a disk
`resource, and for a client to connect to and use that resource.
`
`a) NET SHARE
`
`The NET SHARE command, when executed on the server, specifies a directory name to be made available
`to clients on the network. A share name must be given, and this name is presented by clients wishing to
`access the directory.
`
`
`Examples:
`
`
`NET SHARE src=c:\dir1\src "bonzo"
`
`assigns password bonzo to all files within directory c:\dir1\src and its subdirectories with the share
`name src being the name used to connect to this resource.
`
`
`NET SHARE c=c:\ " " RO
`
`NET SHARE work=c:\work "flipper" RW
`
`
`offers read-only access to everything on the C drive. Offers read-write access to all files within the
`C:\work directory and its subdirectories.
`
`
`The above example is appropriate for servers operating as a share level server. A user level server would
`not require the permissions or password, since the combination of the client’s account name and specific
`access control lists on files is sufficient to govern access.
`
`b) NET USE
`
`Clients can gain access to one or more offered directories via the NET USE command. Once the NET USE
`command is issued the user can access the files freely without further special requirements.
`
`
`Examples:
`
`1. NET USE d: \\Server1\src "bonzo"
`
`
`gains full access to the files and directories on Server1 matching the offer defined by the netname
`src with the password of bonzo. The user may now address files on Server1 c:\dir1\src by
`referencing d:. E.g. "type d:srcfile1.c".
`
`
`2. NET USE e: \\Server1\c
`3. NET USE f: \\Server1\work "flipper"
`
`
`Now any read request to any file on that node (drive c) is valid (e.g. "type e:\bin\foo.bat"). Read-
`write requests only succeed to files whose pathnames start with f: (e.g. "copy foo f:foo.tmp" copies
`foo to Server1 c:\work\foo.tmp).
`
`
`For user level servers, the client would not provide a password with the NET USE command.
`
`The client software must remember the drive identifier supplied with the NET USE request and associate it
`with the Tid value returned by the server in the SMB header. Subsequent requests using this Tid must
`include only the pathname relative to the connected subtree as the server treats the subtree as the root
`directory (virtual root). When the user references one of the remote drives, the client software looks
`
`DRAFT
`
`

`
`
`
`- 7 -
`
`
`
`through its list of drives for that node and includes the tree id associated with this drive in the Tid field of
`each request.
`
`Note that one shares a directory and all files underneath that directory are then affected. If a particular file
`is within the range of multiple shares, connecting to any of the share ranges gains access to the file with the
`permissions specified for the offer named in the NET USE. The server will not check for nested directories
`with more restrictive permissions.
`
`
`
`
`
`
`
`
`
`// 8 unsigned bits
`// 16 unsigned bits
`// 32 unsigned bits
`
`// 64 bits of data
`
`Message Format
`Clients exchange messages with a server to access resources on that server. These messages are called
`Server Message Blocks (SMBs), and every SMB message has a common format:
`
`typedef unsigned char UCHAR;
`typedef unsigned short USHORT;
`typedef unsigned long ULONG;
`typedef struct {
` ULONG LowPart;
` LONG HighPart;
`} LARGE_INTEGER;
`
`typedef struct {
`
`ULONG LowTime;
`
`LONG HighTime;
`} TIME;
`
`typedef struct {
` UCHAR Protocol[4]; // Contains 0xFF,'SMB'
` UCHAR Command; // Command code
` union {
` struct {
` UCHAR ErrorClass; // Error class
` UCHAR Reserved; // Reserved for future use
` USHORT Error;
`// Error code
` } DosError;
` ULONG NtStatus; // NT-style 32-bit error code
` } Status;
` UCHAR Flags; // Flags
` USHORT Flags2;
` // More flags
` union {
` USHORT Pad[6];
` struct {
` USHORT PidHigh; // High part of PID (NT Create And X)
` struct {
` ULONG HdrReserved; // Not used
` USHORT Sid; // Session ID
` USHORT SequenceNumber; // Sequence number
`
`
` } Connectionless; // IPX
` }
` };
`// Tree identifier
` USHORT Tid;
`// Caller's process id
` USHORT Pid;
`// Unauthenticated user id
` USHORT Uid;
`// multiplex id
` USHORT Mid;
`// Count of parameter words
` UCHAR WordCount;
`
`
` USHORT ParameterWords[ WordCount ]; // The parameter words
` USHORT ByteCount;
`
`
`// Count of bytes
` UCHAR Buffer[ ByteCount ];
`// The bytes
`} SMB_HEADER;
`
`All SMBs have identical format up to the ParameterWords fields. Different SMBs have a different number
`and interpretation of ParameterWords and Buffer. All reserved fields in the SMB header must be zero. All
`quantities are sent in native Intel format.
`
` // Ensure this section is 12 bytes
`
`DRAFT
`
`

`
`
`
`- 8 -
`
`
`
` •
`
` Command is the operation code which this SMB is requesting, or responding to.
`•
`Status.DosError.ErrorClass and Status.DosError.Error are set by the server and combine to give the
`error code of any failed server operation. If the client is capable of receiving 32 bit error returns, the status
`is returned in Status.NtStatus instead. When an error is returned, the server may choose to return only the
`header portion of the response SMB.
`• Flags and Flags2 contain bits which, depending on the negotiated protocol dialect, indicate vairous
`client capabilities.
`• PidHigh is used in the NtCreateAndX request SMB
`• Connectionless. Sid, and Connectionless.SequenceNumber are used when the client to server
`connection is on a datagram oriented protocol such as IPX or UDP.
`•
`StreamProtocol.SMBLength is used to frame this SMB when the client to server connection is on a byte
`stream protocol such as TCP. It is the entire length of the SMB from the initial 0xFF to the final byte.
`• Tid identifies the subdirectory, or “tree”, on the server which the client is accessing. SMBs which do
`not reference a particular tree should set Tid to 0xFFFF
`• Pid is the caller’s process id, and is generated by the client to uniquely identify a process within the
`client computer.
`• Mid is reserved for multiplexing multiple messages on a single Virtual Circuit (VC). A response
`message will always contain the same value as the corresponding request message.
`
`Sample Messge Flow
`The following illustrates a typical message exchange for a client connecting to a user level server, opening a
`file, reading its data, closing the file, and disconnecting from the server.
`
`
`Client Command
`SMB_COM_NEGOTIATE
`
`SMB_COM_TREE_CONNECT
`
`SMB_COM_OPEN
`
`Server Response
`Must be the first message sent by client to the server. Includes a
`list of SMB dialects supported by the client. Server response
`indicates which SMB dialect should be used.
`SMB_COM_SESSION_SETUP_ANDX Transmits the user’s name and credentials to the server for
`verification. Successful server response has Uid field set in SMB
`header used for subsequent SMBs on behalf of this user.
`Transmits the name of the disk share the client wants to access.
`Successful server response has Tid field set in SMB header used
`for subsequent SMBs referring to this resource.
`Transmits the name of the file, relative to Tid, the client wants to
`open. Successful server response includes a file id (fid) the client
`should supply for subsequent operations on this file.
`Client supplies Tid, fid, file offset, and number of bytes to read.
`Successful server response includes the requested file data
`Client closes the file represented by Tid and fid. Server responds
`with success code.
`Client disconnects from resource represented by Tid
`
`SMB_COM_READ
`
`SMB_COM_CLOSE
`
`SMB_COM_TREE_DISCONNECT
`
`SMB Protocol Dialects
`The first message sent from an SMB client to an SMB server must be one whose Command field is
`SMB_COM_NEGOTIATE. The format of this client request includes an array of NULL terminated strings
`indicating the dialects of the SMB protocol which the client supports. The server compares this list against
`the list of dialects the server supports and returns the index of the chosen dialect in the response message.
`
`
`DRAFT
`
`

`
`
`
`- 9 -
`
`
`
`This is the list of SMB protocol dialects, ordered from least functional (earliest) version to most functional
`(most recent) version:
`
`
`Dialect Name
`PC NETWORK PROGRAM 1.0
`
`PCLAN1.0
`
`MICROSOFT NETWORKS 1.03
`
`MICROSOFT NETWORKS 3.0
`
`Comment
`The original MSNET SMB protocol (otherwise known as the
`“core protocol” )
`Some versions of the original MSNET defined this as an alternate
`to the core protocol name
`This is used for the MS-NET 1.03 product. It defines
`Lock&Read,
`Write&Unlock, and a special version of raw read and raw write.
`This is the DOS LANMAN 1.0 specific protocol. It is equivilant
`to the LANMAN 1.0 protocol, except the server is required to map
`errors from the OS/2 error to an appropriate DOS error.
`This is the first version of the full LANMAN 1.0 protocol
`This is the first version of the full LANMAN 2.0 protocol
`This is the dos equivilant of the LM1.2X002 protocol. It is
`identical to the LM1.2X002 protocol, but the server will perform
`error mapping to appropriate DOS errors.
`DOS LANMAN2.1
`LANMAN2.1
`OS/2 LANMAN2.1
`Windows for Workgroups 3.1a Windows for Workgroups Version 1.0
`NT LM 0.12
`The SMB protocol designed for NT. This has special SMBs
`which duplicate the NT semantics.
`
`
`LANMAN1.0
`
`LM1.2X002
`
`DOS LM1.2X002
`
`DOS LANMAN2.1
`
`
`
`
`SMB servers select the most recent version of the protocol known to both client and server. Any SMB
`server which supports dialects newer than the original core dialect must support all the messages and
`semantics of the dialects between the core dialect and the newer one. This is to say that a server which
`supports the NT LM 0.12 dialect must also support all of the messages of the previous 10 dialects. It is
`the client’s responsibility to ensure it only sends SMBs which are appropriate to the dialect negotiated.
`
`Message Transport
`Clients and servers exchange messages over either a reliable NetBIOS transport or a connectionless
`transport such as IPX.
`
`Reliable NetBIOS Transports
`The client and server can use NETBIOS to establish and maintain communications. The server ‘posts’ a
`name on the network and the client connects to that name. For compatibility with pre-Windows 95 and pre-
`Windows NT clients, a server’s NetBIOS name should comply with the standard DOS 8.3 format and be
`blank padded to the right. All NETBIOS-based SMB servers have a name whose 16-th character is 20 hex.
`
`When using such a reliable message-oriented transport, the SMB protocol makes no higher level attempts to
`ensure reliable sequenced delivery of messages between the client and server. The transport should have
`some mechanism to detect failures of either the client or server node, and to deliver such an indication to
`the client or server software so they can clean up state. When a reliable transport from a client terminates,
`all work in progress by that client is terminated and all resources open by that client are closed.
`
`The rules for reliable transport establishment and dissolution are:
`
`•
`If a server receives a transport establishment request from a client with which it is already conversing,
`the server may terminate all other transport connections to that client. This is to recover from the situation
`where the client was suddenly rebooted and was unable to cleanly terminate its resource sharing activities
`with the server.
`
`DRAFT
`
`

`
`
`
`- 10 -
`
`
`
`• A server may drop the transport connection to a client at any time if the client is generating malformed
`or illogical requests. However, wherever possible the server should first return an error code to the client
`indicating the cause of the abort.
`
`•
`If a server gets a hard error on the transport (such as a send failure) the transport connection to that
`client may be aborted.
`
`• A server may terminate the transport connection when the client has no open resources on the server,
`however, we recommend that the termination be performed only after some time has passed or if resouces
`are scarce on the server. This will help performance in that the transport connection will not need to be
`reestablished if activity soon begins anew. Client software is expected to be able to automatically reconnect
`to the server if this happens.
`
`Connectionless IPX Transport
`Unlike a traditional transport protocol, the connectionless SMB protocol is asymmetric. Wherever possible,
`processing overhead has been moved from the server to the client so that the server can scale to a large
`number of clients efficiently. For example, the server does not initiate retransmission of lost responses. It
`is entirely up to the client to resend the request in the case of lost packets in either direction.
`
`Five IPX sockets are used as follows:
`
`
`
`Socket Name
`SMB_SERVER_SOCKET
`SMB_NAME_SOCKET
`REDIR_SOCKET
`
`Value
`0x0550
`0x0551
`0x0552
`
`MAILSLOT_SOCKET
`
`0x0553
`
`MESSENGER_SOCKET
`
`0x0554
`
`Purpose
`SMB requests from clients
`name claims and name query messages
`is used by the redirector for sending SMB requests and
`receiving SMB replies.
`is used by the redirector and browser for mailslot
`datagrams.
`is used by the redirector to send messages from client to
`client (NetMessageBufferSend).
`
`
`The SMB header includes two fields specifically designed for use on IPX. Sid is the server's session ID and
`SequenceNumber is the message sequence number. The Sid value is generated by the server, and returned
`to the client in the Negotiate Protocol response. The client must use this Sid value in all future SMB
`exchanges with this server during this resource sharing session. SequenceNumber is supplied by the client.
`A valid SequenceNumber is either zero or one greater than the previous sequence number sent by the client.
`For unsequenced commands (i.e. SequenceNumber is 0) the redirector must use the Mid field to identify
`SMB responses. The redirector should take steps to generate relatively unique values for Mid for each
`request. In particular, the client must ensure that it never has two or more distinct requests outstanding to
`the server whose SequenceNumbers are 0 and whose Mids are identical.
`
`The maximum packet size for some IPX routers is 576 bytes including the IPX header. Because of this, the
`client must limit the size of the negotiated buffer size to 546 bytes when the server's network ID is not the
`same as the client's network ID. If desired, the client could dynamically determine the maximum packet
`size by sending echo SMBs to the server using various packet sizes and then selecting the largest size which
`worked correctly.
`
`Sequenced commands are used for operations which cause a state change on the server that cannot be
`repeated. For example, file open/close or record locking. Unsequenced commands are used for operations
`which can be performed as many times as necessary with the same result each time. For example, reading
`or writing to a disk file. The server maintains a small save area for each client to keep the response
`information from the previous sequenced command. Because the server has a limited amount of space
`available for this save area, the client must send all commands with a large response size as unsequenced.
`Such commands include file read and file search. If the response to a sequenced command is too large, the
`
`DRAFT
`
`

`
`
`
`- 11 -
`
`
`
`server will fail the request with a Status.DosError.ErrorClass set to SMB_ERR_CLASS_SERVER and
`Status.DosError.Error set to ERRerror. If the Sid value in incorrect, the server will fail the request with a
`Status.DosError.ErrorClass set to SMB_ERR_CLASS_SERVER and Status.DosError.Error set to
`SMB_ERR_BAD_SID. If the server has an SMB in progress which matches either SequenceNumber for
`sequenced commands or Mid for unsequenced commands, it will respond with Status.DosError.ErrorClass
`set to SMB_ERR_CLASS_SERVER and Status.DosError.Error set to SMB_ERR_WORKING. For
`sequenced commands, the server requires that the sequence numbers progress in order, S, S+1, S+2, ... The
`sequence number wraps to one (1) not zero. The wrap around progression is: 65534, 65535, 1, 2, ... Out of
`sequence commands are ignored by the server.
`
`The exceptions to the “large response requires unsequenced” rule are transaction SMBs. These SMBs are
`used both to retrieve bulk data from the server (EG: enumerate shares, enumerate servers, etc.) and to
`change the server's state (EG: add a new share, change file permissions, etc.) Transaction requests are also
`unusual because they can have a multiple part request and/or a multiple part response. For this reason,
`transactions are handled as a set of sequenced commands to the server. Each part of a request is sent as a
`sequenced command using the same Mid value and an increasing Seq value. The server responds to each
`request piece except the last one with a response indicating that the server is ready for the next piece. The
`last piece is responded to with the first piece of the result data. The client then sends a transaction
`secondary SMB with ParameterDisplacement set to the number of parameter bytes received so far and
`DataDisplacement set to the number of data bytes received so far and ParameterCount, ParameterOffset,
`DataCount, and DataOffset set to zero (0). The server responds with the next piece of the transaction
`result. The process is repeated until all of the response information has been received. When the
`transaction has been completed, the redirector must send another sequenced command (an echo SMB will
`do fine) to the server to allow the server to know that the final piece was received and that resources
`allocated to the transaction command may be released.
`
`The flow is as follows, where (S) is the SequenceNumber, (N) is the number of request packets to be sent
`from the client to the server, and (M) is the number of response packets to be sent by the server to the client:
`
`
`
`
`Client
`SMB(S) Transact
`
` [ repeat N-1 times:
`SMB(S+1) Transact secondary
`
`SMB(S+N-1)
`
`Server
`
`
`
`→
`← OK (S) send more data
`
`
`
`→
`← OK (S+1) send more data
`
`
`
`
`]
`← OK (S+N-1) transaction response (1)
`
`
`
` [ repeat M-1 times:
`
`SMB(S+N) Transact secondary
`→
`← OK (S+N) transaction response (2)
`
`
`SMB(S+N+M-2) Transact secondary →
`← OK (S+N+M-2] transaction response (M)
`
`
`
`→
`← OK (S+N+M-1) echoed
`
`
` ]
`SMB(S+N+M-1) Echo
`
`
`
`In order to allow the server to detect clients which have been powered off, have crashed, etc., the client
`must send commands to the server periodically. If nothing has been received from a client for awhile, the
`server will assume that the client is no longer running and disconnect the client. This includes closing any
`files that the client had open at the time and releasing any resources being used on behalf of the client.
`Clients should at least send an echo SMB to the server every four (4) minutes if there is nothing else to
`send. The server will disconnect clients after a configurable amount of time which cannot be less than five
`(5) minutes. The NT server has a default timeout value of 15 minutes.
`
`DRAFT
`
`

`
`
`
`- 12 -
`
`
`
`Naming On Ipx
`The name claim/query packet and mailslot datagram packets use the structure:
`
`
`struct ipxnm {
`uchar
`uchar
`uchar
`ushort
`uchar
`uchar
`
`
`inm_route[32];
`
`inm_op;
`
`inm_type;
`
`inm_msgid;
`
`inm_name[16];
`inm_srcname[16];
`
`/* routing info (used by IPX routers) */
`/* operation being requested */
`/* type of name */
`/* message ID for sender */
`/* name being sought or claimed */
`/* name of requesting machine */
`
`};
`
`// server name claim message
`0xf1
`// relinquish server name
`// locate server name
`// response to INAME_QUERY
`0xf5
`// Messenger Hangup (contained in SMB)
`0xfc
`// packet contains mslot write, no resp needed
`// find name for mslot write, no data included
`// find name response
`
`
`
`Below are the values for inm_op:
`
`INAME_CLAIM
`
`
`INAME_DELETE
`0xf2
`
`INAME_QUERY
`0xf3
`
`INAME_FOUND
`0xf4
`
`IMSG_HANGUP
`
`
`IMSLOT_SEND
`
`
`IMSLOT_FIND
`0xfd
`
`IMSLOT_NAME
`0xfe
`
`The following are the values for inm_type:
`
`INTYPE_MACHINE
`1
`
`INTYPE_WKGROUP
`2
`
`INTYPE_BROWSER
`3
`
`When the server starts, it sends broadcasts a name claim (inm_type == INAME_CLAIM) packet five (5)
`times at 500 millisecond intervals. The server's name is put into both the inm_name and the inm_srcname
`fields. The IPX packet type is 32 (0x20) which IPX routers will forward through up to eight (8) hops. If no
`other machine responds within 500 milliseconds of the transmission of the last broadcast, the server claims
`the name as its own.
`
`When a client wishes to locate the address of a server, it broadcasts a name query (inm_type ==
`INAME_QUERY) packet with the server's name in inm_name and its own name in inm_srcname. The first
`broadcast is an IPX type 4 packet which is not forwarded by routers. After 500 milliseconds, the client will
`perform an all nets broadcast (IPX type 32) four (4) times at 500 milliseconds intervals. The client extracts
`the server's address from the IPX header of the response packet.
`
`Once a client has the address of a server, it may open a circuit to the server by sending a negotiate SMB to
`the SMB_SERVER_SOCKET. In the negotiate request, smb_sid must be zero (0), smb_seq must be one
`(1) and two 16 bytes names are appended to the end of the SMB in NetBIOS name format. The size of the
`names is NOT included in the smb_bcc value. The first 16 bytes contains the client computer name space
`padded with a zero (0) in the 16th position. The second 16 bytes contains the remote server's name space
`padded to 16 bytes. The server retains the client's name for informational purposes and verifies that the
`server name matches its own name. If the server name does not match, the server will respond to the
`negotiate with an ERRSRV class error ERRnotme. The server returns a session identifier in smb_sid which
`the client must place in smb_sid in all subsequent requests sent to the server.
`
`Opportunistic Locks
`Network performance can be increased if the client can locally buffer file data. For example, the client does
`not have to write information into a file on the server if the client knows that no other process is accessing
`the data. Likewise, the client can buffer read-ahead data from the file if the client knows that no other
`process is writing the data.
`
`DRAFT
`
`

`
`
`
`- 13 -
`
`
`
`
`The mechanism which allows clients to dynamically alter their buffering strategy in a consistent manner is
`knows as “opportunistic locks”, or oplocks for short. Versions of the SMB file sharing protocol including
`and newer than the LANMAN1.0 dialect support oplocks.
`
`There are three different types of oplocks:
`
`1. An exclusive oplock allows a client to open a file for exclusive access and allows the client to perform
`arbitrary buffering
`2. A batch oplock allows a client to keep a file open on the server even though the local accessor on the
`client machine has closed the file.
`3. A Level I