Wireshark-users: Re: [Wireshark-users] Proposed changes to make tcp.ack and tcp.seq relative
On Mon, May 04, 2020 at 04:52:02PM -0700, Jim Aragon wrote:
> 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.
There is no way to control the Info column other than a preference. The
aim of this change is to ensure that the Packet Details view will always
show the relative sequence numbers field if possible:
Sequence number: 95 (relative sequence number)
Sequence number (raw): 354738450
[Next sequence number: 95 (relative sequence number)]
Acknowledgment number: 156 (relative ack number)
Acknowledgment number (raw): 4021290310
> > - 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
(My minor mistake: the "was disabled" should have been "was enabled".)
> > 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.
I don't like to add more fields for the same thing because it enlarges
the output of commands such as tshark -Tpdml.
> (And I assume you mean "tcp.ack_raw" and tcp.seq_raw.")
Ah yes, the variable in the source code is called _abs while the field
name is called _raw, that is somewhat confusing.
> >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.
You can achieve the same packet list view even after the proposed
change, it is just not controlled through the preference. After this
change, you can add two columns, tcp.seq and tcp.seq_raw. Then toggle
visibility of either column to match the desired view. This could be
stored in a configuration profile if desired.
I think that the consistent value of a tcp.seq/tcp.ack field has
benefits, it has been requested by at least one user. In what real
workflow would this change make your life significantly more difficult?
Thanks for your feedback!
--
Kind regards,
Peter Wu
https://lekensteyn.nl
