Wireshark · Ethereal-dev: Re: [ethereal-dev] wanted - tethereal: tcp segment dumps

[Neal McBurnett <nealmcb@xxxxxxxxx>]

Thanks for the quick response, Guy!

See my follup in-line below.

Once upon a time, Guy Harris <gharris@xxxxxxxxxxxx> wrote:
> On Wed, Aug 02, 2000 at 10:15:02AM -0600, Neal McBurnett wrote:
> > I just ran across ethereal.  Thanks for a wonderful program!
> > 
> > One feature that I've wanted for a long time in sniffing programs is
> > something suitable for analyzing TCP-based ASCII protocols like http
> > and smtp.
> > 
> > When running ethereal itself, the Tools/Follow TCP Stream
> > feature is nice.
> > 
> > But it would be really handy to be able to do that with tethereal
> > also, via an option that takes a filter or (when reading a capture
> > file) a packet number to indicate which tcp stream to watch.
> 
> "Follow TCP Stream" is useful only if you can specify which stream you
> want to follow; in Ethereal, you can do that as long as the packet in
> question is displayed, so it's useful not only with "dead" captures
> (i.e., existing capture files), it's also useful with live captures if
> 
> 	1) you're doing an "Update list of packets in real time" capture
> 
> or
> 
> 	2) the capture is now dead (i.e., you've finished capturing)
> 
> but in Tethereal, there's no way to do that, so, in Tethereal, it's
> useful only when reading a capture file.

Good point on ethereal - I hadn't though of real-time observactions.
It would be nice if the tcp stream window also updated in real time.

But I did suggest a way to specify which tcp stream (via packet
number) to target in tethereal. I should clarify that what I'm mostly
looking for is a nicely formatted and timestamped ascii/hex dump of
just the tcp stream itself.

> There *is* a Tethereal command-line option that "takes a filter" - you
> specify, on the command line, either a libpcap/tcpdump-style capture
> filter, with the "-f" flag, or an Ethereal-style display filter, with
> the "-R" flag.
> 
> (Note that, on some platforms, capture filters are handled inside the
> kernel, so that packets that don't match are not copied up to
> Ethereal/Tethereal, saving a lot of CPU time; display/read filters,
> however, are done inside Ethereal/Tethereal, so even packets that don't
> match are copied up to userland.
> 
> In addition, the display-filter filtering routines require more CPU as
> the packet's protocol tree has to be constructed - i.e., the packet has
> to be dissected - and the filter expression checked against that tree,
> even if the packet is then discarded.
> 
> As such, you probably want to use a capture filter if possible, even
> though the syntax may not be as convenient.)
> 
> *If* you know, *before* starting the capture, the IP addresses and ports
> between which the conversation will be taking place, you could use that,
> e.g.
> 
> 	tethereal -f "(host foo and tcp port X) and (host bar and tcp port Y)"
> 
> If you don't know that before starting the capture, it's obviously
> intrinsically impossible to specify any filter that'd select only
> packets in the conversation.

Sure.  I was focussed on existing tcpdump capture files, but your
method would work fine.

Again it is a convenient output format that I'm looking for, and I'd
often like to generate it from the command line perhaps from a remote
client, not via a GUI.  A nice uncluttered output format could even be
used when publishing examples in protocol specs, or as fodder for
developing protocol test suites.


> > It would help to provide output in a format that differentiates
> > packets sent in each direction.  The hex version of the TCP Stream
> > display in ethereal does that, but the ascii display doesn't provide
> > any differentiation.
> 
> Well, the current version of Ethereal (and this goes back to at least
> Ethereal 0.8.8) displays the two sides in different colors - by default
> it uses red and blue.  You can select which colors you want from the
> "TCP Streams" tab in the "Edit->Preferences" dialog box - and the "Save"
> button will save your preferences, so you would only have to do this
> once.
>
> Perhaps it should also indent the output differently, if the colors
> aren't sufficient (which they wouldn't be for somebody completely
> color-blind, and might not even be for people with partial
> color-blindness).

Ahh - interesting.  I didn't observe this because of some problems
with a remote X11 session which I neglected to mention.  For some
reason, when running ethereal on a redhat 6.2 machine, with $DISPLAY
pointing to a solaris 2.5.1 display, the stream view window appeared
completely blank.  This made the whole thing very confusing until
I happened to drag the mouse thru the display, in which case it
highlighted the text, making it readable (but all one color)!

I don't know if this is a bug in the Openwindows server or
the ethereal client, but it does explain why I didn't see the
color coding.

And by-the-way, I do have different color vision than most,
so I like the options to choose the color.  Running it now locally,
I don't notice any difference between the blue and red.  I recommend
a yellow background for the client text.

Sorry for the confusion.  So here, again, is my main goal:

 Also, a way to save the captured stream data in a plain text file
 would be very helpful.  Hmmm - maybe an XML format for describing the
 data would be handy - does such a thing exist?  It could provide
 timestamps, separation of streams in each direction, etc.

 Outputing two files, one showing the stream from A to B and the other
 showing it from B to A would be easier, and also very handy.

 Are there other programs that do this already?

>-- End of excerpt from Guy Harris

Cheers,

Neal McBurnett <neal@xxxxxxxxxxxxxxxxx>  303-538-4852
Avaya Communication / Internet2 / Bell Labs / Lucent Technologies
http://bcn.boulder.co.us/~neal/      (with PGP key)