Ethereal-dev: Re: [Ethereal-dev] Capturing from multiple interfaces, and why we need this.
Brady Volpe wrote:
a) enable Ethereal to capture from multiple interfaces at once and do
the merging "on the fly"
b) enable Winpcap to support the "all" interface, like in the unix versions
c) integrate a seperate capture tool into the GUI, which is capable of
doing multiple interface capturing
Beyond Ethernet sniffing, having the ability to capture from multiple
interfaces may really expand some of the usages for Ethereal. I'm most
familiar with the DOCSIS realm, whereby sniffing DOCSIS actually uses two
processes. 1) is demodulating the downstream RF channel and 2) is
demodulating the upstream RF channel. The output is two independent, but
related, data streams. Currently we do timing synchronization before
sending to Ethereal. The inherent problem with this is that filtering must
be done in hardware, which ultimately means that one would need to develop
an independent filtering ability in the hardware to filter on specific
protocol or IP based events.
Developing a generalized format in Ethereal that accepts one or more data
streams from either memory or the PCI bus would enable applications such as
DOCSIS sniffing to be more easily accomplished. The ideal situation would
be to use the existing ethereal display filters to function as capture
filters. In this case, WinPcap would be bypassed (or integrated) into
Ethereal.
I think the first step would be to define the data format that would be
captured. This would need to include some timing information wrapped around
each packet so that the packets from independent sources could be
re-synchronized by Ethereal before display. The second step would be to
define a standard memory location or DMA-based interface that hardware
vendors can stream data too.
While this has great benefits for DOCSIS, I am certain there are probably
other protocols that would benefit from this application. For example, any
protocol using a transport channel other than CAT5, like Wifi, GPRS, EDGE,
cdmaONE, etc.
Hmmm, that sound to me like two completely different things only loosely
tied together.
I was talking about to enable Ethereal to be able to capture data from
more than one interface.
When I remember it correctly, it's currently possible in libpcap/winpcap
to open more than one interface for capturing,
that's done when multiple instances of Ethereal capturing the same time.
The only things left to do would be to handle the requested channels in
parallel and change the GUI part corresponding to this.
This task might be somewhat easy to achievs, unless I miss something
important out.
What you are talking about (when I got you correct), is to completely
redefine the capturing interface,
including a somewhat more lowlevel access to the hardware.
To be honest I don't like that idea a lot, although it might be
preferrable in your case:
-as the libpcap currently hides a lot of platform specific stuff (lot's
of platforms supported)
-it would be a *lot* of work to change this things
The only real advantage would be the possibility to do a real stream
capturing, which currently can't be handled with the libpcap,
as far as I know.
Regards, ULFL
