Wireshark · Ethereal-cvs: [Ethereal-cvs] rev 16874: /trunk/gtk/: tcp_graph.c /trunk/: AUTHORS

[gerald@xxxxxxxxxxxx]

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