Re: [Wireshark-dev] Proposed changes to make tcp.ack and tcp.seq relative

[Peter Wu <peter () lekensteyn nl>]

Hi Jasper,

On Tue, May 05, 2020 at 01:24:33AM +0200, Jasper Bongertz wrote:
> Hello Peter,
>
> > 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).
>
> To avoid cluttering the TCP tree with redundant fields: can we only show the
> absolutes if the relatives are also displayed? I don't think it's useful to
> show the absolutes twice.

Sure! The fields will be hidden in the view, but you will still be able
to use them in filter expressions.

> >  - Modify the "Relative sequence numbers" preference to affect the
> >    displayed value in the Info column only.
>
> Good.
>
> >  - 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.
>
> I guess you mean "were only visible when "Relative sequence numbers" was **enabled**?
> At least that's what my Wireshark does, unless I'm not thinking straight right
> now (at 1:30am, it's quite possible...) :-)

You are right, my logic was reversed :P

> >  - Document these changes clearly in the release notes and corresponding
> >    user guides if needed.
> >
> > Are there any objections to this change?
>
> No, sounds like a good solution (the "document clearly" is indeed critical here,
> I guess). And I hadn't even noticed the new way of displaying
> the relative sequence numbers in 3.2 yet :-)

Cool, thanks for your reply, I was already hoping for your feedback!
If there are no further objections I'll submit a patch for this.

On a related note, to address one of the use cases that prompted for the
new field, I added expert info to mark connections where the server
accepted TCP Fast Open (TFO) data. Is that useful to have?
Patch in question: https://code.wireshark.org/review/36994
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___________________________________________________________________________
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-request () wireshark org?subject=unsubscribe