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

[Jason Cohen <kryojenik2 () gmail com>]

I think for some workflows it would be ideal to know if you are getting the
relative or raw sequence numbers independent of preference.
If that means there are three iterations, tcp.seq_raw, tcp.seq_rel and
tcp.seq that changes based on pref...  Or just two iterations.  Either
(tcp.seq_raw or tcp.seq_rel) and tcp.seq which is what ever the other
isn't.  My preference would be tcp.seq be representative of actual data in
the packet (raw) and tcp.seq_rel be the generated valued flagged as
generated.

I think having the 3 fields is the least departure from status quo.  That
could see the tcp.seq shown in the proto details flagged as generated when
the tcp pref is set to relative and then show tcp.seq_raw, tcp.seq_rel
would be hidden.  If the tcp pref is set to absolute, tcp.seq would not be
flagged as generated, tcp.seq_rel would be shown and tcp.seq_raw would be
hidden.

My thoughts on the ideal would be that tcp.seq is always absolute,
tcp.seq_rel is always relative and flagged as generated.  Both visible in
the protocol decode.  A tcp pref could still exist to control which value
is used in the info column.

Maybe for either of the above cases only need one line in the protocol
decode formatted depending on preference.
Sequence number: 3939720242 (1 realative)
Sequence number: 1 (3939720242 raw)

The above holds for all needed sequence values.  seq, ack, nxtseq, etc...

Jason


On Thu, May 7, 2020 at 6:11 PM Peter Wu <peter () lekensteyn nl> wrote:

> On Tue, May 05, 2020 at 08:59:45AM -0400, Lee wrote:
> > On 5/4/20, Peter Wu <peter () lekensteyn nl> wrote:
> > > Hi all,
> > >
> > > 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.
> >
> > I prefer non-breaking changes and this sounds like it's going to break
> > at least my setup.
>
> I am aware it is user-visible, but I hope it is for good. How exactly
> would it break?
>
> > How hard is it to add a new field?
>
> There is a non-zero cost. My primary concern is that -Tpdml and maybe
> -Tjson outputs get even bigger than they already are.
>
> > How hard is it to change the existing fields only if the user wants
> > relative sequence numbers & leave them alone if they do not want
> > relative sequence numbers: ie.
> > tcp.relative_sequence_numbers: FALSE
>
> The aim was to make tcp.seq/tcp.ack provide the relative sequence
> numbers independent of the preference, so it would not be possible
> unless the proposal is rejected. For use cases, see
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16515
>
> > How much of the following breaks if you change the existing fields:
> > column.width:
> >   ...
> >         "%Cus:tcp.seq", 80,
> >         "%Cus:tcp.nxtseq", 80,
> >         "%Cus:tcp.ack", 80,
>
> If you intend to always display raw numbers, you have to replace
> "tcp.seq" by "tcp.seq_raw" and "tcp.ack" by "tcp.ack_raw". You do raise
> a very interesting case, "tcp.nxtseq" currently does not have a
> "tcp.nxtseq_raw" variant and I don't think that changing this to always
> become relative is a good idea.
>
> With that issue and the problem of breaking existing workflows, I think
> that I will drop the proposal.
>
> The next question is whether "tcp.seq_rel" and "tcp.ack_rel" fields are
> needed? There are patches in review that add options to specifically
> recognize TCP Fast Open. One hypothetical case was raised, but if there
> are no real-world use cases I would prefer not adding a new field.
>
> Thanks for your feedback!
> --
> Kind regards,
> Peter Wu
> https://lekensteyn.nl
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe