On Sat, Aug 17, 2002 at 12:22:00PM -0700, Chris Waters wrote:
> I want to add an alternative packet capture mechanism to Ethereal. i.e.
> instead of getting the packets from pcap, I want to receive them over a
> socket from another machine. I have spent half an hour reading the sources,
> but it doesn't appear like the packet capture interface is abstracted. It
> seems like everything is very tightly tied to pcap.
Correct.
I, at least, don't consider that necessarily to be a feature.
> It looks like capture-wpcap.c encapsulates the winpcap DLL.
It's a pretty thin encapsulation - its sole purpose is to allow there to
be one Ethereal binary and one Tethereal binary, built with WinPcap,
which can capture packets if you have WinPcap installed and which will
work, but not support capturing packets, if you don't have WinPcap
installed.
It doesn't abstract the capture interface away.
> How is this done under Unix?
It's not. Ethereal and Tethereal binaries on UNIX are either built with
libpcap (in which case they can capture packets; if built with a
"static" libpcap library, they don't require that libpcap be installed,
but if built with a "dynamic" libpcap library, they won't run if you
don't have a dynamic libpcap binary installed).
> I guess I could make a library which has the same API as pcap, but this
> doesn't make it easy for a user to switch between a local capture and a
> remote capture. Ideally I would like the new capture source to appear in the
> drop-down list as an adapter.
>
> Anyway, I am looking for ideas about the best way to abstract the capture
> interface to make it possible to add a new capture mechanism.
I would consider adding to the Wiretap library APIs into which various
packet capture mechanisms, including but not limited to libpcap/WinPcap
and (on UNIX) reading from a FIFO file, plug. That would also absorb
the code in "pcap-util.c", including the stuff to get the interface
list.
