https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16372
--- Comment #8 from Peter Wu ---
By "purity" I was thinking about consistency, having generated fields indicated
as such. Generally I would also be quite picky about details, and "doing it
right", so I guess I am with you there :-)
Howeve
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16372
--- Comment #7 from David Perry ---
(In reply to Peter Wu from comment #6)
> At that time I decided it was not worth persuing the change to make tcp.seq
> show relative numbers in all cases. Apart from a purity perspective, is
> there any
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16372
Peter Wu changed:
What|Removed |Added
CC||pe...@lekensteyn.nl
See Also
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16372
--- Comment #5 from Gerrit Code Review ---
Change 37993 had a related patch set uploaded by David Perry:
TCP: always provide absolute seq#
https://code.wireshark.org/review/37993
--
You are receiving this mail because:
You are watching
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16372
David Perry changed:
What|Removed |Added
CC||boolean...@gmail.com
--- Comment #4
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16372
Guy Harris changed:
What|Removed |Added
Hardware|x86 |All
OS|Linux
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16372
--- Comment #3 from dandav1992+...@gmail.com ---
(In reply to Jaap Keuter from comment #1)
> The creation of the TCP seq# fields is atypical to say the least. When
> enabled the relative sequence number is added as tcp.seq and the packet
>
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16372
--- Comment #2 from dandav1992+...@gmail.com ---
Created attachment 17611
--> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17611&action=edit
This marks the relative seq field as generated
This is how I would solve this :)
--
Y
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16372
Jaap Keuter changed:
What|Removed |Added
Component|GTK+ UI |Qt UI
--- Comment #1 from Jaap Keut
