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.
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.
> 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).