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

[Jason House <jhouse@xxxxxxxxx>]

Can't a repeat sequence number (for the same source IP) be used as a 
simple yet reasonable heuristic for detecting duplicate IP packets?  The 
grey area is that the numbers will be repeated eventually, this can be 
handled with a "timeout" and/or adding extra fields to verify the match.

ronnie sahlberg 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