Wireshark-users: Re: [Wireshark-users] Proposed changes to make tcp.ack and tcp.seq relative
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
