Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] The field called Command Sequence Number in the SMB2 dissect

From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Thu, 01 Aug 2013 12:04:40 -0400
I took a half-educated whack at fixing those in r51080. Thanks for pointing it out (and feel free to point out any mistakes I may have made).

On 07/31/13 17:08, Dirk Jagdmann wrote:
while you are renaming the displayed name of this variable, the rest of the SMB2
dissector is using the term "sequence number" in many places. It's now confusing
if source code comments talk about sequence numbers and use them in hash tables,
while the dissection shows it as Message ID. To really wrap this up, you might
want to rename hf_smb2_seqnum, but then also struct smb2_saved_info_t and code
using that struct.

On 2013-07-31 06:00, Richard Sharpe wrote:
Hi folks,

This patch needs to be applied:

Index: epan/dissectors/packet-smb2.c
===================================================================
--- epan/dissectors/packet-smb2.c	(revision 51065)
+++ epan/dissectors/packet-smb2.c	(working copy)
@@ -7100,8 +7100,8 @@ proto_register_smb2(void)
   		{ "NT Status", "smb2.nt_status", FT_UINT32, BASE_HEX,
   		VALS(NT_errors), 0, "NT Status code", HFILL }},
   	{ &hf_smb2_seqnum,
-		{ "Command Sequence Number", "smb2.seq_num", FT_INT64, BASE_DEC,
-		NULL, 0, "SMB2 Command Sequence Number", HFILL }},
+		{ "Message ID", "smb2.msg_id", FT_INT64, BASE_DEC,
+		NULL, 0, "SMB2 Messsage ID", HFILL }},
   	{ &hf_smb2_tid,
   		{ "Tree Id", "smb2.tid", FT_UINT32, BASE_HEX,
   		NULL, 0, "SMB2 Tree Id", HFILL }},

See section 2.2.1.1. The field is called the Message ID, not the
Command Sequence Number.

That confusion has probably caused one of the WAN Accelerator
companies to break SMB2 Signing by mishandling that field. Not sure
which one it is, since the customer hasn't told me whose WAN
Accelerator they use. (Hint, it is possible for those numbers to be
out of order in a TCP stream.)
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe