Wireshark mailing list archives
Re: Proposed changes to make tcp.ack and tcp.seq relative
From: Jim Aragon <Jim () agdatasystems com>
Date: Mon, 04 May 2020 16:52:02 -0700
At 01:50 PM 5/4/2020, Peter Wu wrote: >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). > - Modify the "Relative sequence numbers" preference to affect the > displayed value in the Info column only.If someone changes this preference, they probably want the change to be reflected in both places. I do occasionally change the "Relative sequence numbers" preference. I can't think of a use case where I would want to see absolute sequence numbers in the Info column, but relative sequence numbers in the Packet Details pane. I want the two displays to stay in sync.
> - 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.And relative numbers would always be available through the new requested "tcp.ack_rel" (and I assume there would be a "tcp.seq_rel") fields.
(And I assume you mean "tcp.ack_raw" and tcp.seq_raw.") >Are there any objections to this change? Yes. I'd prefer: Keep the absolute values available through tcp.ack_raw and tcp.seq_raw. Make the relative values available through tcp.ack_rel and tcp.seq_rel.Continue to have tcp.seq and tcp.ack behave according to the "Relative sequence numbers" setting, whether in a column or in the Packet Details. This gives us every possible combination a user could want. Your proposed change does not leave us with a field that stays in sync with the preference setting.
Regards, Jim Aragon
___________________________________________________________________________ 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
Current thread:
- Proposed changes to make tcp.ack and tcp.seq relative Peter Wu (May 04)
- Re: Proposed changes to make tcp.ack and tcp.seq relative Jasper Bongertz (May 04)
- Re: [Wireshark-dev] Proposed changes to make tcp.ack and tcp.seq relative Peter Wu (May 04)
- Re: Proposed changes to make tcp.ack and tcp.seq relative Jasper Bongertz (May 05)
- Re: Proposed changes to make tcp.ack and tcp.seq relative Peter Wu (May 07)
- Re: [Wireshark-dev] Proposed changes to make tcp.ack and tcp.seq relative Peter Wu (May 04)
- Re: Proposed changes to make tcp.ack and tcp.seq relative Jasper Bongertz (May 04)
- Re: Proposed changes to make tcp.ack and tcp.seq relative Jim Aragon (May 04)
- Re: Proposed changes to make tcp.ack and tcp.seq relative Peter Wu (May 07)
- Re: Proposed changes to make tcp.ack and tcp.seq relative Jim Aragon (May 08)
- Re: Proposed changes to make tcp.ack and tcp.seq relative Peter Wu (May 07)
- Re: Proposed changes to make tcp.ack and tcp.seq relative Lee (May 05)
- Re: Proposed changes to make tcp.ack and tcp.seq relative Peter Wu (May 07)
- Re: [Wireshark-users] Proposed changes to make tcp.ack and tcp.seq relative Jason Cohen (May 07)
- Re: Proposed changes to make tcp.ack and tcp.seq relative Peter Wu (May 07)
- Re: [Wireshark-users] Proposed changes to make tcp.ack and tcp.seq relative Sake Blok | SYN-bit (May 11)