this is a tricky area
for your particular example maybe the heuristics could be changed to
detect that eventhough the left edge of the segment went backward and
thus could potentially be either a retransmission/fastretransmission
or outoforder segment that since it also had a right edge that
covered the entire previous segment that in that case it must be a
retransmission and not a simple outoforder segment.
if you can send me a capture with it ill try to implement this kind of
heuristics
and also make sure it doesnt break any of my other examples of
"tricky" packet sequences.
since we have so much less information available to us compared to the
tcp endpoints themself this is a very tricky area.
On 4/27/07, Jeff Morriss <jeff.morriss@xxxxxxxxxxx> wrote:
Hi list,
The other day I was looking at a TCP sequence that went like:
time: sequence:
0 1-10
2 11-20
2.1 1-20
The last frame was a retransmission of the first frame but the TCP
implementation in question (XP) decided to stick the data from the 2nd
frame in there, too.
Wireshark called the 3rd frame an out of order packet which confused me
a bit. The test for an out of order packet is the same as that for a
retransmission plus an additional test to see if that frame arrived
within 3ms of of the highest sequence number (with a note that 3ms is
arbitrary).
This seems an odd definition of "out of order" but I haven't really
figured out how to define it. What makes the most sense to me so far is
"if it looks like a retransmission but we've already seen an ack for it"
though that doesn't seem quite right either (just because we saw the ack
doesn't mean the intended recipient did).
Any ideas?
-J
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
