Ethereal-users: Re: [Ethereal-users] Decoding Raw ATM cells?

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

From: Guy Harris <guy@xxxxxxxxxx>
Date: Wed, 15 Jan 2003 11:44:27 -0800
On Wed, Jan 15, 2003 at 01:45:47PM -0500, Balendran Bala wrote:
> We are trying to debug a customer IP over ATM issue with one of our
> products. So we are thinking about using the Ethereal to debug it, but first
> I have number of questions about the current version of the Ethereal...
> 
> 1) Can Ethereal actually capture Raw ATM cells?

Ethereal can capture only what libpcap can capture, and libpcap can
capture only what the underlying OS lets it capture.  Libpcap currently
doesn't support, for example, capturing ATM traffic with a passive tap,
although that might be possible at some point, depending on what the
hardware to which this person is referring does:

	Subject: [tcpdump-workers] adding new devices to libpcap
	From: Sean Irvine <sairvin@xxxxxxxxxx>
	To: tcpdump-workers@xxxxxxxxxxx
	Cc: richard@xxxxxxxxxxx, sfd@xxxxxxxxxx
	Date: 14 Jan 2003 09:28:11 +1300

	We have pieces of hardware capable of monitoring various
	kinds of network links.  This hardware is not configured
	as a network device (i.e. it is not ifconfig friendly),
	but we do have Linux drivers to talk to the hardware.

	We plan to modify libpcap so it can talk directly with
	this hardware. We are open to suggestions as to the best
	approach to do so.

	So far our options appear to be:

	(a) Modify pcap-linux.c to include support for our
	    device. This would mean it would be possible to
	    simultaneously use our device and eth0. However,
	    there will be a performance penalty deciding
	    which device is to be read from each packet.

	(b) Write a new pcap-xxx.c to support only our
	    device. This has the advantage of smaller
	    changes to the existing libpcap code base, but
	    will limit functionality. Further, programs
	    (i.e. tcpdump, Snort, etc.) will then have to
	    be linked against the appropriate library.

	Does anyone have any comment or preference?

	Regards,
	Sean A. Irvine


	-
	This is the TCPDUMP workers list. It is archived at
	http://www.tcpdump.org/lists/workers/index.html
	To unsubscribe use mailto:tcpdump-workers-request@xxxxxxxxxxx?body=unsubscribe

Whether it would deliver raw cells or, at least in the case of AAL5,
reassembled PDUs is another matter; I don't know which it would do.  (I
don't know if he's referring to Endace's:

	http://www.endace.com/

commercialized version of the DAG hardware:

	http://dag.cs.waikato.ac.nz/

or not; he did CC somebody from Endace, but I don't know whether that's
because he's talking about Endace's hardware or just suggesting that
Endace might want to do something similar to what he's doing.)

> 2) Can Ethereal capture ATM Classical IP frames?

See the first sentence of my reply to the first question.  On some
platforms (Linux, at least some BSDs, Solaris, maybe others), libpcap
can sniff traffic on a machine's ATM interface; that will capture
traffic to and from that machine, but not third-party traffic.  (You'd
need the current CVS version of libpcap on Solaris.) For third-party
traffic you'd need some kind of tap, which currently isn't supported.

Note that, on Linux and the BSDs, you will only get the classical IP
traffic - you won't get signalling traffic, for example.

> 1) Can ethereal actually decode raw on the wire data from an ATM interface?
> (I mean, AAL5 segmented cells that have to be assembled to make a frame).

The current CVS version has some ability to do that, although it can
only do so for capture files from Network Associates' Sniffer.  That
code could conceivably be used to decode raw cells in other capture file
formats; if Ethereal could capture raw cells, libpcap format would have
to be made to support it somehow.

> 2) Can ethereal decode raw frame of Classical IP? (I mean, re-assembled AAL5
> cells into IP frames).

Yes.