["Rhythmic One" <rhythmic1@xxxxxxxxx>]

Thanks for your reply Guy.  Here is a 'backtrace' as requested...
unfortunately, there wasn't any README distributed with this particular
version of ethereal so I hope what I've pasted below is helpful.  I'd love
to know why tethereal is dumping core regularly.  I'm not a developer so
please let me know if you'd like to see any more info and I'll be happy to
send it along.

root@ns:/pkg > pkg_info -L ethereal-0.8.14.tgz
Information for ethereal-0.8.14.tgz:

Files:
/usr/local/bin/editcap
/usr/local/bin/ethereal
/usr/local/bin/tethereal
/usr/local/lib/ethereal/plugins/0.8.14/libgryphon.so.0.0
/usr/local/lib/ethereal/plugins/0.8.14/gryphon.la
/usr/local/lib/ethereal/plugins/0.8.14/libgryphon.a
/usr/local/man/man1/editcap.1
/usr/local/man/man1/ethereal.1
/usr/local/man/man1/tethereal.1
/usr/local/share/ethereal/manuf

root@ns:/home/log/Codes/CORE > gdb tethereal tethereal.core
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd2.8"...(no debugging symbols
found)...
Core was generated by `tethereal'.
Program terminated with signal 6, Abort trap.
#0  0x4020de1b in ?? ()
(gdb) backtrace
#0  0x4020de1b in ?? ()
#1  0x4015b3ac in ?? ()
#2  0x4015b459 in ?? ()
#3  0x40159b22 in ?? ()
#4  0x4014f549 in ?? ()
#5  0x4014f121 in ?? ()
#6  0x113260 in ?? ()
#7  0x4015d214 in ?? ()
#8  0x4015d62a in ?? ()
#9  0x11323b in ?? ()
#10 0x112f4d in ?? ()
#11 0x112bf1 in ?? ()
#12 0x112dcb in ?? ()
#13 0x112ba4 in ?? ()
#14 0x112a39 in ?? ()
#15 0x105054 in ?? ()
#16 0x10481e in ?? ()
#17 0x40182151 in ?? ()
#18 0x401935a7 in ?? ()
#19 0x104715 in ?? ()
#20 0x10402d in ?? ()
#21 0x109c in ?? ()
(gdb) quit

Also, I understand the buffer situation and why grep isn't outputting each
line in real time to the file as I was hoping for.  Upon thinking about this
some more, it seems that sed might be a better tool for the job.  I'll have
to play with it some and see if I can get it to do what I want.  In any
case, maybe more filterable fields for SMTP could be put into the dissector
as you suggested.  With SMTP being such a popular protocol, I'm sure many
would find additional filtering a plus.

I did think about constructing a capture filter based on the tcpdump docs
showing some examples for creating them, and it occurred to me I would have
at least have to calculate the number of header bytes for protocols IP, TCP,
and SMTP.  I imagine the location of the SMTP bytes would be the same for
all SMTP packets (at least the headers), and I'm not even sure if the
'Message Body' stuff is in the header or not.  It seemed really messy and
then I still wasn't sure how to filter on a string (eg. 'Message Body').
The man page says that it possible, but doesn't go into any examples.  As
you can see, the advanced capture filtering is a bit beyond me right now.

Thanks again for your assistance.
- Dave

----- Original Message -----
From: "Guy Harris" <gharris@xxxxxxxxx>
To: "The Rythmic One" <rhythmic1@xxxxxxxxx>
Cc: <ethereal-users@xxxxxxxxxxxx>
Sent: Sunday, July 07, 2002 6:05 PM
Subject: Re: [Ethereal-users] SMTP; filtering out message body; capture vs.
read filters


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