Ethereal-dev: [Ethereal-dev] tcptrace graph of one sided TCP conversation crashes Ethereal v0.

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

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next
From: "Jim Young" <SYSJHY@xxxxxxxxxxxxxxx>
Date: Wed, 24 Nov 2004 10:02:56 -0500
Hello,

Ethereal v0.10.7 (and the 2004-11-23 pre-release v0.10.8)
will crash on a Windows XP system, if one tries to generate a 
"tcptrace" style TCP Stream Graph of a capture containing only 
one side of a TCP conversation.

To reproduce the crash open the attached trace file, 
"simple-telnet-a2b.trace", and then select the "tcptrace" 
graph function via Ethereal's "Statistics" menu:

  "TCP Stream Graph"  ==> "Time-Sequence (tcptrace)"

Although not the norm, captures containing only one-side of 
a TCP conversation can occur for a several reasons.  One
reason might be caused by asymmetric routes. Another reason
might be a switch "span" or "monitor" setup configured to only 
forward "incoming" or "outgoing" packets to the analysis 
interface.

I've contrived a trace file that can be used to reproduce the 
problem. Two trace files are attached to this message.  The 
first trace file, "simple-telnet.trace", contains both sides of 
a simple telnet conversation.  The second trace, 
"simple-telnet-a2b.trace", (which was derived from the first 
trace) contains only one side of the TCP conversation: the 
packets originating from host A and destined to host B.   It is 
this second trace file that will cause Ethereal to crash if one 
tries to generate a "tcptrace" style TCP Stream Graph.

This same "simple-telnet-a2b.trace" trace file can be 
successfully processed by the other three "TCP Stream Graph" 
formats (although with varying amounts of usability ;-)

  "Round Trip Time Graph"
  "Throughput Graph"
  "Time-Sequence Graph (Steven's)"

I've taken a look, without any luck, at the source module 
./ethereal/gtk/tcp_graph.c to see if their might be an
obvious fix but nothing jumped out at me.  I suspect that 
the "tcptrace" graphing code needs to defend against some 
assumptions made about the availability of the other side 
of the conversation.

I hope someone finds the above info useful.

Best regards,

Jim Young

Attachment: simple-telnet.trace
Description: Binary data

Attachment: simple-telnet-a2b.trace
Description: Binary data