ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Ethereal-dev: Re: [Ethereal-dev] Feature request on TCP Analysis Flags

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>
Date: Thu, 27 Mar 2003 21:03:40 +1100
From: "Kevin"
Sent: Wednesday, March 19, 2003 2:52 AM
Subject: [Ethereal-dev] Feature request on TCP Analysis Flags


> Using Ethereal 0.9.11 on Freebsd 4.8 Release.
>
> In the summary screen, when a TCP Duplicate ACK is found, can the frame
> number that is duplicated be displayed?  Also in the protocol detail
> display?

Thanks for the suggestion on how to improve ethereal.
I have tested and checked in a patch that will make ethereal  display in the
summary pane
"[ TCP Dup ACK <frame>#<number> ]"
both which was the original ACK and also the Dup ACK number.
The first DupACK to the ACK in frame n will be displayed as
...n:1...
the second one
...n:2...
etc.

The frame the dup ack is a duplicate and the dup ack number is also
awailable in the
tree pane with display filterable fields.

thanks for suggesting a very useful enhancement to ethereal.
i hope you will find this enhancement useful.


>
> If possible, all the TCP Analysis fields should reference the frame
> that caused the flag to be set.  The Retransmission would be another
> big help if it displayed these values.

Retransmissions are more difficult, mainly due to the way it works and what
state the tcp analysis code
keeps between frames.
It would certainly be possible to add this feature which would be useful
without too much
brain surgery of the tcp analysis code.
I, or someone else, might look into this soon. If no patch is implemented
within a few weeks I might have simply forgotten your request, then just
poke me again and i will look at it.

Displaying which frame something is a retransmission of is also tricky
because the original frame might not even exist in the capture file at all.

It would be very useful if retransmitted frames also displayed the time
delta from the original frame, or estimate of when the original frame should
have been seen (like time delta either from the original, if seen, or from
the first dup ack this retransmission referres to.
I plan to do this in some unknown future.