On Sat, Jul 06, 2002 at 04:49:02PM -0400, The Rythmic One wrote:
> Anyhow, there are two problems...
>
> 1) I really don't care about the message bodies (and they can obviously
> take up significant space), just the initial session info such as HELO or
> EHLO, MAIL FROM, RCPT TO. However, the only supplied read filters for SMTP
> are smtp.req and smtp.rsp which are of type boolean. This would suggest
> there isn't a way to look inside the SMTP protocol and filter more finely.
> Is this correct?
It's correct in that there's no way in the current Ethereal SMTP
dissector to do that. It might, however, be possible to put more
filterable fields into the dissector.
> As a workaround I've tried piping output through grep
> first before going to a file. This has worked in some tests, but with weird
> results. For instance, no output occurs in the file until tethereal is
> killed, and then only in SOME of my tests. Here is an example:
>
> tethereal -l -n -t ad -s 110 -R ' smtp.req or smtp.rsp ' | grep -v 'SMTP
> Message Body' > today &
>
> The above worked (sort of) but not seemingly in real time and something is
> going on with the buffering that I can't explain. The man page suggests
> the -l option is useful for piping tethereal output to another command but
> doesn't say much more about how that works.
It causes Tethereal to write to the standard output at the end of each
packet, so that the program you're piping to sees output from Tethereal
for a given packet as soon as the packet arrives and is dissected,
rather than that output possibly being delayed until enough packets
arrive to cause the "standard I/O library" routines' buffer to fill up
and cause the library routines to write to the standard output.
> Why wouldn't the above filter
> put output in file today as email traffic happened?
Because the output is coming from grep, not from Tethereal. grep,
unlike Tethereal, might not have a flag to force line buffering, so
output arrives in "today" when grep decides to write it to that file,
which might not be on nice packet boundaries or even line boundaries.
> Conversely, the following works everytime, but with large and unneeded
> DATA/Message Body lines:
>
> tethereal -l -n -t ad -s 110 -R ' smtp.req or smtp.rsp ' > today &
>
> The unfortunate side effect being that:
>
> 2) tethereal dumps core, presumably at times of heavy traffic. I've read
> that capture filters are more efficient than read filters, but the
> ethereal/tcpdump documentation only discussed capture filters with regard to
> core IP protocols such as IP, TCP, UDP, ICMP, ARP, etc.
>
> Could a capture filter be used to accomplish what we need???
Not easily. Capture filters are even more limited in their capability
than display filters/read filters. It *might* be possible to construct,
by hand, a capture filter that does that, by looking at the TCP payload,
but it'd be a real pain to construct, and I don't have time to suggest
how to do that.
> Also, could tethereal be dumping core for another reason?
Yes, there are many reasons why it could be dumping core; however, we
can't enumerate all of them, as we don't know all the bugs present in
all of Tethereal.
In fact, it probably *is* dumping core for other reasons; we can't
determine what the reason is, however, without a stack trace. As you're
running on OpenBSD, follow the directions in Ethereal's README file for
getting us a stack trace:
If Ethereal died on you with a 'segmentation violation', 'bus
error', 'abort', or other error that produces a UNIX core dump
file, you can help the developers a lot if you have a debugger
installed. A stack trace can be obtained by using your debugger
('gdb' in this example), the ethereal binary, and the resulting
core file. Here's an example of how to use the gdb command
'backtrace' to do so.
$ gdb ethereal core
(gdb) backtrace
..... prints the stack trace
(gdb) quit
$
The core dump file may be named "ethereal.core" rather than
"core" on some platforms (e.g., BSD systems). If you got a core
dump with Tethereal rather than Ethereal, use "tethereal" as the
first argument to the debugger; the core dump may be named
"tethereal.core".
I don't know whether OpenBSD uses "{program}.core" rather than "core" as
the core dump file name, the way FreeBSD does, but if it does, note the
last paragraph.