Ethereal-users: RE: [Ethereal-users] capturing from multiple interfaces

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

From: "McNutt, Justin M." <McNuttJ@xxxxxxxxxxxx>
Date: Mon, 8 Jan 2001 20:41:47 -0600
Could one simply run multiple instances of ethereal, each of which is
capturing on a separate interface?  It may be super-kludge, but what works,
works, and it might solve the actual problem right now (although it's an
inelegant solution).

Of course, the "any" device may provide all the information necessary in
some cases, although I can see how losing the destination field of the
link-layer headers would negate the usefulness of many captures I've run in
the past...

--J

> -----Original Message-----
> From: Guy Harris [mailto:gharris@xxxxxxxxxxxx]
> Sent: Tuesday, December 26, 2000 5:08 PM
> To: grisha@xxxxxxxxx
> Cc: ethereal-users@xxxxxxxxxxxx
> Subject: Re: [Ethereal-users] capturing from multiple interfaces
> 
> 
> On Tue, Dec 26, 2000 at 05:45:51PM -0500, grisha@xxxxxxxxx wrote:
> > A while back I asked (I think it was on this list) if 
> ethereal supports
> > capture from multiple interfaces, and someone replied that 
> it does, but I
> > don't seem to be able to figure out how.
> 
> Somebody was probably mistaken when they answered that question.
> 
> The current CVS version of Ethereal, *when combined with the 
> current CVS
> version of libpcap*, will allow you, on Linux, to capture on the "any"
> device, which will capture from *all* network interfaces (although you
> will not see the link-layer headers of the packets; instead, 
> you'll see
> a "synthetic" link-layer header, which contains a source 
> address for the
> packet but not a destination address, and an Ethernet 
> subprotocol field,
> along with some other stuff).
> 
> There is no mechanism for capturing on a specified set of interfaces. 
> Supporting that, in general, would require a new capture file type,
> which allows a mixture of different link-layer types (perhaps 
> 90-99% of
> the time they'd both be Ethernet interfaces, but the trouble with a
> 90-99% solution is that somebody's going to try to use the feature in
> a 1%-10% case, and the software has to do *something* in that
> situation...).
> 
> It would also require that Ethereal be able to block waiting 
> for data to
> come in on any of *more than one* libpcap capture stream; I don't know
> whether all OSes on which Ethereal runs will handle this 
> ("select()" and
> "poll()" don't always work right on BPF devices on BSD, and I 
> don't know
> whether you can do a "WaitForMultipleObjects()" or
> "MsgWaitForMultipleObjects()" on multiple packet driver devices in
> Windows 9x or Windows NT, for example).
> 
> So, whilst it would probably be a *useful* feature, it's also probably
> significantly more difficult to implement than one might 
> naively thing,
> so it's also probably less likely to be available any time in the near
> future than one might optimistically hope.
> 
> (I.e., it might be nice, but, unless somebody decides to take the time
> necessary to make it work on *multiple* platforms, it's not likely to
> happen - and there's always a large list of things to be done for
> Ethereal, and those things will have to compete for the 
> limited resource
> that is developer time.)
> 
> _______________________________________________
> Ethereal-users mailing list
> Ethereal-users@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-users
>