Server Message Block version 2 and 3
SMB2 is a new version of the old Windows filesharing protocol SMB and is used for filesharing on modern and future Windows hosts. Windows 8 introduced several new features, so Microsoft has decided to bump the revision number up to SMB v3.
As the packet signature is the same for SMB versions 2 and 3, Wireshark uses the display filter smb2 for both versions.
SMB2 was introduced with Microsoft Vista and is a redesign of the older SMB protocol. It adds larger types for various fields as well as a fixed size header. To separate it from the older SMB protocol it uses a slighty different signature 0xFE 'S' 'M' 'B' instead of the older 0xFF 'S' 'M' 'B' signature.
The following table lists the version number and the operating that brought them.
Windows Vista, Server 2008
Windows 7, Server 2008 R2
Windows 8, Server 2012
Windows 8.1, Server 2012 R2
Windows 10, Server 2016
SMB2 runs on top of TCP ports 139 and 445 which are the same ports used by the older SMB protocol.
XXX - Add example traffic here (as plain text or Wireshark screenshot).
The SMB2 dissector is partially functional.
(XXX add links to preference settings affecting how DCE/RPC is dissected).
Example capture files
ifstest.cap.gz A capture of two Vista beta2 boxes running ifstest.exe
ifstest.out The log output from the ifstest.exe tool
smb-on-windows-10.pcapng Handshake between two workstations running Windows 10
smb2-peter.pcap Simulated traffic (containing file reads/writes) between a Samba 4.4.x client and server on Arch Linux (from June 2016).
A complete list of SMB2 display filter fields can be found in the display filter reference
Show only the SMB2 based traffic :
You cannot directly filter on SMB2 while capturing but you can capture for TCP port 445
The smb2-protocol mailing list.
An implementation in Samba4.
SMB2 Header Structure
As for the older SMB protocol, all multibyte integers are represented in little-endian format.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFE | 'S' | 'M' | 'B' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header Length | (padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NT_Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opcode | (padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :S:C:P:R| | | | Flags +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chain Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Sequence- | +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Process ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tree ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+ User ID +-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+ +-+-+-+-+ | | +-+-+-+-+ Signature +-+-+-+-+ | | +-+-+-+-+ +-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Total length of the SMB2 header including the 0xFE 'S' 'M' 'B' signature. Minimum header length is 64 bytes.
The NT Status error code. Same as for SMB.
The command being issued. See below for a list of known command opcodes.
R: Response flag. ==1 if this is a response, ==0 for a request P: PID valid. ==1 the PID field is valid, ==0 PID is not valid C: End of Chain ==1 this is the last PDU in a chain S: Signature present. ==1 signature is present, ==0 signature is not present
The offset to the next SMB2 PDU within the current NBT PDU.
Command Sequence Number
This is the command sequnce number for the TCP session used to match requests to responses. The command sequnce number starts with 0 for the initial SMB2/NegotiateProtocol command and is incremented by one for each additional command.
Command sequence number -1 is used when servers sends unsolicited oplock breaks SMB2/Break to clients.
The Process ID of the server process/thread for a command with deferred/async completion. If a SMB2 command can not be completed immediately the server will respond immediately with STATUS_PENDING and specify a value for the PID that the client can use later to Cancel the request. This STATUS_PENDING reply has the P bit set to 1 to indicate that the PID is valid. Once the command completes later the server will send a second reply to the command, this time still keeping the P bit set to 1 and repeating the same PID as in the initial STATUS_PENDING reply.
This is used by SMB2/Notify and SMB2/Cancel to set and cancel a directory watch but can also be used for reads from named pipes if they can not be completed immediately. See SMB2/Cancel for a discussion on how the PID is used in these cases.
Normally for non-async commands the P bit will be set to 0 and the PID will be set to the default value of 0x0000feff.
An integer that identifies a specific share that is mounted. The value of this integer is generated by the server upon completion of a successful SMB2/TreeConnect call. The Tree ID is scoped by UID/Session.
A 64 bit integer that identifies a specific authenticated user on this TCP session. The server will generate this identifier upon completion of a SMB2/SessionSetup command. (In fact, the server will assign this id already in the second packet of the four packet NTLMSSP Challenge/Response dance.)
Is the S bit is set this field contains the signature for SMB2 Signing. If the S bit is clear this field is 0. It is not yet known how the signature is calculated.
SMB2 commands listed by opcode value. Every Command PDU starts with a SMB2/BufferCode.
When a client tries to discover whether a server supports the SMB2 protocol or not it will initiate a TCP session to port 445 on the server and issue a normal SMB/NegotiateProtocol to the server but also specify the new dialect "SMB 2.001".
If the server supports SMB2 instead of sending a SMB/NegotiateProtocol back selecting this dialect it will send a SMB2/NegotiateProtocol back. The client now knows the server supports SMB2 and will issue a new SMB2/NegotiateProtocol request to the server and from thereon the client will only talk SMB2 on that session.
A client will "remember" that a server supports "SMB2" so later setups of new sessions will attempt SMB2 immediately.