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 Tue, May 05, 2020 at 08:59:45AM -0400, Lee wrote:
> On 5/4/20, Peter Wu <peter@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe