Ethereal-dev: Re: [Ethereal-dev] TCP Framentation bug?

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxx>
Date: Wed, 26 Feb 2003 20:51:59 -0800
On Thu, Feb 27, 2003 at 02:01:30AM +0000, didier wrote:
> It's retransmited frames 2828, 5034, 7050. Should be discarded, frame 
> 709 is ACKed, problem with keep alive?

Yeah, the TCP sequence is a bit bizarre there.  If you turn on the
"Analyze TCP sequence numbers" TCP preference, it reports 2828, 5034,
and 7050 as retransmissions.

Frame 709 is ACKed in frames 794 *and* 2829 *and* 5034 *and* 7051,
according to "Analyze TCP sequence numbers"; the latter 3 are flagged as
duplicate ACKs.

Perhaps if that preference is enabled, the TCP dissector shouldn't
supply retransmitted data to subdissectors and shouldn't use it for
reassembly - it should just display the data as "Retransmitted data".

(We could also add another option to do the checking without adding the
SEQ/ACK analysis, but I'm not sure that'd be useful - the reason for an
option is that we have to allocate a per-conversation data structure,
and if, for example, we have a capture of a SYN flood, we could end up
allocating a *lot* of memory - tcpdump, by default, allocates a data
structure for each TCP connection it sees, so that it can display
relative sequence numbers, and I seem to remember somebody complaining
that it ran out of memory reading a SYN-flood capture - you'd use the
"-S" flag, to make it print absolute sequence numbers, in that case.)