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.)