From: "Guy Harris"
| On Sun, Feb 01, 2004 at 12:19:39PM +0100, Olivier Biot wrote:
| > Additionally, we could add support for remote capturing and for
| > network taps via an API similar to the libpcap or wiretap API.
|
| How about adding them to an API identical to the WinPcap 3.01 API?
|
| http://winpcap.polito.it/301a/docs/group__remote.html
That's one really good way at implementing something.
| If that's done in libpcap/WinPcap, it's available to more programs
than
| just Ethereal.
And every application sticks to its goals, which makes lots of sense
to me :)
| > As a result, Ethereal would indeed only know about display filters
(which I
| > *really* want to be renamed to *dissection filters* as I think
that's
| > a more intuitive name for those), and the interaction with packet
| > capturing would be hidden by the file descriptor.
|
| What do you mean "know about"?
Ahh... I've been too quick in trying to express what I wanted to say.
Here's a 2nd attempt :)
Ethereal dissects the packets, and generates state information by
setting up conversations, reassembling packet data fragments,
interpreting the protocol data and handing off the transported
protocol data to a subdissector. It defines the display filters as a
way to reach to information from the interpretation of the packet
data, and it knows what to do if a display filter expression pops up
somewhere (compile the dfilter code and apply it). So Ethereal "knows
about" display filters.
Ethereal doesn't rely upon capture filters to run correctly. Actually,
today Ethereal *blindly* (so: doesn't know about) passes the capture
filter string to the libpcap packet filter compiler and looks at the
outcome of the compilation in order to see if the filter was valid or
not.
I can imagine that one day there will be a native packet filter engine
from an OS (SUN Solaris, MS Windows) which is not based on libpcap,
but which eventually will make it in the packet capture logic... with
which Ethereal interacts (but it passes the filters as opaque data to
the capturing subsystem). In the last 3 years I've seen the discussion
whether we would support some MS Windows packet capture subsystem or
not popping up several times, so I think it makes sense to put this up
as an extra argument for maybe separating the capture code in a more
explicit way from the Ethereal code (however this is already a fact
for 95% today).
Hence the following question arises: can we (and do we want to)
support non-libpcap/WinPcap packet capture engines? If so, how will we
do this?
| Presumably if a user's capturing with Ethereal, they'd supply a
capture
| filter expression to Ethereal.
Yes, but as written above, maybe the end-user will use a syntax s/he
knows from the "network tap", and it may be something totally
different from libpcap format.
Regards,
Olivier