Yes, I understand that the packet is a retransmission and that the packets
are being desegmented. But if you look at the frame in packet 7258 you will see
the valid data is the same as the segmented data with the exception that the
segmented data seems to be off by 1 byte in the starting offset. Is this
something that should be looked at? Or can we contribute this to bad data? Is
there someone familiar with this part of the code that is investigating or
should I try to debug it further?
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.)
_______________________________________________
Ethereal-dev
mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
