On Sun, Feb 01, 2004 at 11:18:29PM +0100, Olivier Biot wrote:
> 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,
With the possible exception of WinPcap - and, if you split WinPcap into
"packet driver plus packet.dll" and "wpcap.dll", it arguably even
applies there - *no* packet capture mechanism/filter engine is based on
libpcap; instead, it's the other way around - libpcap uses those
mechanisms.
Solaris has a native packet capture mechanism (DLPI) that includes a
filter mechanism. libpcap supports DLPI (on HP-UX as well as Solaris);
the filter mechanism is currently not supported by libpcap, but I've
been thinking about a couple of ways of handling that:
1) attempting to translate BPF programs into CMU/Stanford packet
filter programs ("attempting" because the CMU/Stanford packet
filter used by Solaris isn't as powerful as BPF and there are
some programs that simply couldn't be translated - in that
case, libpcap would have to do BPF filtering in userland,
although it *might* be possible in some cases to do some
filtering in the kernel)
or
2) split "pcap_compile()" into a parser that generates an
expression tree and code generators that produce programs,
have a routine that takes an expression tree and a pcap_t and
either generates code and sets a filter or fails if it can't
generate code or set the filter, and have multiple code
generators for different filter engines.
The first has the advantage that it does the filtering without
application changes, and the disadvantage that it might be pretty
difficult to do.
The second scheme could also make it easier for applications that want
to use a different filter syntax generate the expression tree and still
let libpcap do the code generation. (It also could, I suspect, let us
handle operators such as "vlan" a bit more cleanly, by having it apply
only to a subtree rather than to everything in the expression after it.)
> 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 "we" refers to tcpdump.org, I'd say the answer is "yes". :-)
I.e., as there's no notion of a "libpcap packet capture engine", just
packet capture engines that libpcap uses, I think the right way to do
that would be to, whenever possible, make libpcap use those engines
itself, so that applications other than Ethereal can use them.
The Endace people have done that for their DAG cards and support library
for those cards - libpcap 0.8.1 and later can, if libpcap is built with
DAG support, capture on DAG cards.
Or, to put it another way, we already have the capture code separated in
a more explicit way from the Ethereal code - you get the capture code
from www.tcpdump.org and the Ethereal code from www.ethereal.com. :-)
> 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.
What would be a case where you'd have such a filter syntax not involving
a different capture program (if the syntax comes from a different
capture program, that's an issue of the different capture programs, in
which case the end-user might want the other syntax regardless of what
type of device they're capturing on)?