Wireshark · Ethereal-dev: Re: [Ethereal-dev] Retransmissions

[Don Lafontaine <don.lafontaine@xxxxxxxxx>]

No,  it's not a major issue (Yet).  It will have an impact when it
comes to statistics,  the false positives will make it useless.
Ethereal should be able to recognize this duplicated packet easily
enough by looking at the MAC addresses.

Don Lafontaine. 


On Fri, 17 Sep 2004 21:27:12 +1000, ronnie sahlberg
<ronniesahlberg@xxxxxxxxx> wrote:
> 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
> >
> 
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>