Hi list
I just checked in some changes to TCP Sequence Number Analysis.
First there is a cleanup of where and in which structure certain variables
should reside.
They were in the wrong structure previously which made the code more complex
to read.
Fast Retransmissions:
Ethereal now tries to find and flag suspected FastRetransmissions.
While we dont yet have a RFC2988 implementation in the emulation of sliding
windows that
ethereal implements for performing the sequence number analysis we have to
fall back to
heuristics to do this detection.
Hopefully the heuristics will be close enough so that it will not fail too
often
The heuristics are:
IF we have seen >=3 dup acks in the other direction and
IF those dupacks are requesting THIS segment and
IF this segment arrived within 10ms of the last previous dupack (10ms so
that we can tell fast retransmissions
and real RTOs apart)
then we assume this is a FastRetransmission and flag it as such in the
summary pane (COL_INFO)
These segments will be flagged as both tcp.analysis.fast_retransmission and
tcp.analysis.retranmsission in the
tree pane.
OutOfOrder segments:
Previously ethereal would flag any segment that did not advance the right
edge of the window as a retranmission.
This falsely identified as retransmissions segments that were just reordered
by the network.
Ethereal will not attempt to detect and flag this segments as OutOfOrder
segmetns instead.
The heuristics to detect a segment as being OutOfOrder is:
IF this segment has not been ACKed yet.
IF we have not seen this segment before
IF it arrived within 4ms of the next segment to the right in the window
Thse segments will be flaged as OutOfOrder segments in the summary pane
(COL_INFO) and will have the flag
tcp.analysis.out_of_order set in the tree pane.
Please test and report any issues/bugs
best regards
ronnie sahlberg