[ronnie sahlberg <ronniesahlberg@xxxxxxxxx>]

Hmmm.

Ethereal retransmission detection works essentially as keeping
its own per-session implementation of sliding windows where data segmetns and
acks more the window edges.
(it is far from being perfect yet but still reasonably good and
accurate for the normal case (very much more accurate than any other
tool anyway))

Essentially, Ethereal thinks the second segment is a retransmission since
* the first segment was aligned at the left edge of the window (i.e.
no hole == missing packet) and thus advanced the left edge of the
window.
* the second packet, when it arrived in the capture now lies
completely to the left of the window and ethereal then assumes it must
be a retransmission.

In a sense, for an ignorant observer, it IS a retransmissions.
You know it is not a retransmission but a duplicate packet only
because you have additional information available about the network
topology. Knowledge that is not available for ethereal.


In theory, Ethereal could be changed to keep track of a little bit
more than just the sliding windows and then be able to detect that
this is an exact duplicate of the previous segment and then it might
be a packet duplicated by the network.
That is in theory possible to implement heuristically, but it would
have consequences.
It would take some time to implement and test.
It would require ethereal to keep track of a lot more state (which
eats memory) to be able to try to match this as a duplicate (which
would eat cpu and slow down ethereal)
Right now i would prefer not to implement that since I dont know how
to do it in a reasonably efficient way, yet.


How important would it be to have ethereal detect that that was not a
normal retransmission? I dont know how common this problem is or how
severe it is perceived as.
Do you see it as mainly a small cosmetic glitch that can be lived with
 or is it a major problem?


Let me think about it and keep it in the back of my head for a while.
If you dont hear or see anything in this area after a some time,   you
are welcome to ping me and remind me about this issue. I might forget.



On Wed, 15 Sep 2004 09:41:26 -0400, Don Lafontaine  wrote:
> I ran across a small problem with retransmissions that are false positives.
> 
> Here's two packets, one that was labelled a retransmission:
> 
> ---------------------------------------[Snip]------------------------------------------------------------------------
> No.     Time        Source                Destination           Protocol
> Info
>     16 0.107557    165.115.62.75         216.240.70.39         SSLv3
> Continuation Data, [Unreassembled Packet]
> 
> Frame 16 (594 bytes on wire, 594 bytes captured)
> Ethernet II, Src: 00:30:48:2a:57:69, Dst: 00:50:5a:73:3e:01
> Internet Protocol, Src Addr: 165.115.62.75 (165.115.62.75), Dst Addr:
> 216.240.70.39 (216.240.70.39)
> Transmission Control Protocol, Src Port: https (443), Dst Port: 1131
> (1131), Seq: 1072, Ack: 0, Len: 536
>    Source port: https (443)
>    Destination port: 1131 (1131)
>    Sequence number: 1072    (relative sequence number)
>    Next sequence number: 1608    (relative sequence number)
>    Acknowledgement number: 0    (relative ack number)
>    Header length: 20 bytes
>    Flags: 0x0010 (ACK)
>    Window size: 5840
>    Checksum: 0x1dd3 (correct)
> Secure Socket Layer
> [Unreassembled Packet: SSL]
> 
> No.     Time        Source                Destination           Protocol
> Info
>     19 0.109021    165.115.62.75         216.240.70.39         SSLv3
> [TCP Retransmission] Continuation Data, [Unreassembled Packet]
> 
> Frame 19 (594 bytes on wire, 594 bytes captured)
> Ethernet II, Src: 00:a0:8e:77:e6:19, Dst: 00:a0:8e:77:a5:75
> Internet Protocol, Src Addr: 165.115.62.75 (165.115.62.75), Dst Addr:
> 216.240.70.39 (216.240.70.39)
> Transmission Control Protocol, Src Port: https (443), Dst Port: 1131
> (1131), Seq: 1072, Ack: 0, Len: 536
>    Source port: https (443)
>    Destination port: 1131 (1131)
>    Sequence number: 1072    (relative sequence number)
>    Next sequence number: 1608    (relative sequence number)
>    Acknowledgement number: 0    (relative ack number)
>    Header length: 20 bytes
>    Flags: 0x0010 (ACK)
>    Window size: 5840
>    Checksum: 0x1dd3 (correct)
>    SEQ/ACK analysis
> Secure Socket Layer
> [Unreassembled Packet: SSL]
> 
> ---------------------------------------------------------[EOS]--------------------------------------------------------------
> 
> The problem is that this packet is only a retransmission at the TCP
> level,  but in actual fact it is a copy of a packet between completely
> different MAC addresses. The reason I am seeing this is because of load
> balanced firewalls exchanging each packet between themselves. Let's not
> talk about the evilness of this occuring on the network,  but look at
> possibly changing the way ethereal decides if a packet is a retransmission.
> 
> Don Lafontaine
> 
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>