Ethereal-dev: RE: [Ethereal-dev] Capturing from multiple interfaces, and why we need this.

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Brady Volpe" <brady@xxxxxxxxxx>
Date: Sun, 1 Feb 2004 10:24:36 -0500
>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.

Thoughts?

-Brady