Wireshark-users: Re: [Wireshark-users] Proposed changes to make tcp.ack and tcp.seq relative
From: Jim Aragon <Jim@xxxxxxxxxxxxxxxxx>
Date: Mon, 04 May 2020 16:52:02 -0700
At 01:50 PM 5/4/2020, Peter Wu wrote:

>A request was filed earlier to add a new "tcp.ack_rel" field to ensure
>that color filters can be created that always work on the relative
>sequence numbers independent of the "Relative sequence numbers" option.
>Instead of adding a new field, I propose to change the existing ones.
>
>My proposed change:
>
> - Change the TCP sequence number-related fields to display the relative
>   numbers when available. Fallback to raw numbers if they are simply
>   not available (for example, when the "Analyze TCP sequence numbers"
>   preference is disabled).

> - Modify the "Relative sequence numbers" preference to affect the
>   displayed value in the Info column only.

If someone changes this preference, they probably want the change to be reflected in both places. I do occasionally change the "Relative sequence numbers" preference. I can't think of a use case where I would want to see absolute sequence numbers in the Info column, but relative sequence numbers in the Packet Details pane. I want the two displays to stay in sync.

> - The raw fields will always be available through the existing
>   tcp.ack_abs and tcp.seq_abs fields. Previously they were only visible
>   when "Relative sequence numbers" was disabled. This field was added
>   in Wireshark 3.2.

And relative numbers would always be available through the new requested "tcp.ack_rel" (and I assume there would be a "tcp.seq_rel") fields.

(And I assume you mean "tcp.ack_raw" and tcp.seq_raw.")

>Are there any objections to this change?

Yes. I'd prefer:

Keep the absolute values available through tcp.ack_raw and tcp.seq_raw.
Make the relative values available through tcp.ack_rel and tcp.seq_rel.
Continue to have tcp.seq and tcp.ack behave according to the "Relative sequence numbers" setting, whether in a column or in the Packet Details. This gives us every possible combination a user could want. Your proposed change does not leave us with a field that stays in sync with the preference setting.

Regards,
Jim Aragon