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
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe
