User: gerald
Date: 2005/12/21 07:23 PM
Log:
From Bill Meier:
After investigating the time-sequence graphs (Stevens and tcptrace) produced
using an FTP capture file supplied by Eduardo Segura
(see http://www.ethereal.com/lists/ethereal-users/200512/msg00153.html )
I've identified several problems in tcp_trace.c.
The problems mostly involve incorrect determination of the lower/upper
sequence number bounds (for the Y axis) in certain cases (e.g. having to do
with 'partial' conversations).
I've reworked the '...get_bounds' code to handle cases such as:
1. out of order data segments (e.g.: the first segment in a captured
conversation has a higher sequence number than a later segment);
2. 'ack' sequence numbers for initial ack segments in a conversation lower
than the sequence numbers of the initial data segments;
3. maximum 'ack + win' sequence number in a conversation greater than the
max data sequence number;
4. Stevens graph: only use data segment sequence numbers when
determining bounds;
5. TCP RST packet without 'ack' flag: do not try to use the 'ack' seq num from
the packet in this case. (This was the specific cause of the originally reported
problem).
I've also reworked the tcptrace display code slightly to properly handle
the initial ack packet of a sequence;
As an example of the some of the fixes the Ethereal tcptrace style graph
of the following conversation fragment will now be similar to the graph
produced by Tcptrace.
data: seq 10000 len 100
data: seq 10100 len 200
ack: ack 5000 win 6000
ack: ack 5400 win 5600
Directory: /trunk/gtk/
Changes Path Action
+130 -101 tcp_graph.c Modified
Directory: /trunk/
Changes Path Action
+1 -0 AUTHORS Modified
http://anonsvn.ethereal.com/viewcvs/viewcvs.py?rev=16874&view=rev