[Guy Harris <gharris@xxxxxxxxx>]

On Mon, Jun 25, 2001 at 12:30:49PM +0800, dongjingyu wrote:
> Dear Mr Author,

Well, there's no "Mr. Author" for Ethereal; Gerald Combs is the original
author, but there's a list of contributors to Ethereal at

	http://www.ethereal.com/introduction.html#authors

and it's rather long....

I'm not the author of the code that's crashing, but I did find the bug,
and checked in a fix.  (It's not specific to Windows, or to any
particular version of GTK+, and exists in, I think, all versions of
ethereal that have the "Decode As" dialog.)

>     I'm writing to report a bug in the Ethereal, and hope the follow
> information will be helpful to you.

I reproduced the problem with the current CVS version of Ethereal, on
FreeBSD 3.4, and checked in a fix.  (The code to handle "Decode As" was,
if "Do not decode" was chosen, clearing the selection in the list of
protocols *before* fetching the currently selected row number in that
list - the selection was null, so it crashed when it tried to
dereference the pointer to the currently selected row.  However, it
doesn't need to find the row number if "Do not decode" was chosen, so I
changed it not to do so.)

>     #Why Ethereal can only receive packet but can not send?

Because libpcap provides an interface for receiving packets, but not one
for sending them; we'd either have to add an interface to libpcap for
sending packets, or use another library (but using libpcap to receive
packets and libnet to send them is gross - the "cap" in "libpcap"
nonwithstanding, it's bogus to require that the same
device/socket/whatever be opened *twice*).

WinPcap has such an interface; at some point I may add
"pcap_sendpacket()" to libpcap (at least on the platforms where it can
be implemented).

>     The latter is as important as the former, i think.

I don't - there are some people for whom it's as important, but there
have been only a couple of times in my career where I've wanted to send
a raw network packet that I've synthesized, but I've probably done tens
if not hundreds of network captures.

>     NetXray can perform them two!

NetXRay only has to run on Windows....

>     #Can i operate the capture filter as convenient as the display
>     filter in the next version?

In the next version?  The chances of that are very small.

In some future version?  Probably.

>     And i would be glad to see the two filters share the same
>     instruction.

Capture filters are implemented as "programs" in a simulated machine
language; the interpreter for that machine language runs in the kernels
of some OSes, and it's not powerful enough to do all that a display
filter can do.

(Doing the filtering in the kernel is better, from a performance point
of view, than doing it in the program, because if you filter in the
kernel, packets that the program doesn't care about aren't copied from
the kernel to user mode - or, if you have a memory-mapped capture
buffer, copied into that buffer - whereas if you filter in user mode
every packet received by the interface gets copied even if it's later
discarded.)

At some point, we will probably write code to translate filters in a
language much list a *subset* of the display filter language into the
language supported by the libpcap library for packet capturing, so that
you can specify capture filters either in a language with a syntax like
that of display filters or in the libpcap language currently used by
Ethereal, and also used by tcpdump.

However, that language won't have the power that display filters have;
display filters require more CPU than capture filters, both because they
have to run in user mode so that all packets get copied to user mode,
and because they require a detailed dissection of the packet and a
search through the resulting protocol tree for the fields in question.

We may support using both a capture filter *and* a display filter when
capturing; the capture filter should try to filter out as many
un-interesting packets as possible, so as to minimize the number of
packets the display filter has to work on.