On Tue, May 05, 2020 at 08:59:45AM -0400, Lee wrote: > On 5/4/20, Peter Wu <pe...@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-requ...@wireshark.org?subject=unsubscribe
