[Guy Harris <guy@xxxxxxxxxx>]

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

No.  It includes no cell reassembly code.

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

"Header", in that context, means "LLC header", as I remember.  Ethereal
doesn't *currently* have any Wiretap encapsulation type of that sort,
but it could probably be added (with a lot less difficulty than cell
reassembly) - WTAP_ENCAP_ATM_RFC1483 would probably be the right Wiretap
encapsulation type for that.

> So this is what I have tried so far:
> 
> 1. Capture direct from the ATM interface on the HP-UX machine
> 
> Didn't work. It was hard to work out which interfaces to use (some are
> abstract) and when I finally seemed to hit one libcap complained that
> the card driver wasn't providing the necessary features to capture stuff.
> I tried the interfaces atm0, ipa0 and cip to no avail.

You'd probably have to take libpcap (I'd suggest using version 0.6.2,
either directly from tcpdump.org or from the HP-UX Porting and Archive
Centre:

	http://hpux.cs.utah.edu/

and see if you can modify it to work with the ATM interfaces -
unfortunately, you might need some help from HP people to do that.  (If
you succeed, please send the patches to patches@xxxxxxxxxxx, so that
they can be incorporated into future libpcap releases.)

I might be able to help you some on this, although I might not be able
to respond quickly to questions.

> 2. Capture ATM subsystem with nettl on the HP-UX machine
> 
> Unfortunately the raw data cannot be parsed by ethereal. I believe this
> is only because the filter only understands IP dumps (which I don't want
> because we think the problem bay stem from sub-IP packets (ARP etc)).

You might have to figure out the format of the capture and fix
Ethereal's Wiretap library to read them; perhaps Olivier Abad (the
Ethereal developer who wrote the nettl support) can help here.

> Which brings me to the options I have yet to try and for which I seek
> advice on what people think will be the best approach:
> 
> 1. Write a diags routine to dump frames on our product in a parsable format
> 
> I was thinking of an ASCII format the ethereal will understand
> (suggestions?) or as the traffic may be to much for our serial diags
> interface I could try streaming a binary format file (snoop rfc1761?)
> over the ethernet.

RFC 1761 doesn't document it, but

	1) the values for the "Datalink Type" field, as described in RFC
	   1761, are just DLPI DL_ values (which should not come as a
	   big surprise, given that, on Solaris, snoop uses DLPI to
	   capture packets);

	2) http://www.opengroup.org/onlinepubs/9638599/apdxf.htm gives a
	   list of DL_ values that inclues some for ATM, and Solaris 7
	   uses the same values;

	3) atmsnoop uses DL_IPATM - it's called "classical IP", but, in
	   fact, what appears in the capture are *not* frames starting
	   with an 802.2 LLC header, but, apparently, raw AAL5 frames,
	   with a pseudoheader at the beginning with

		one byte of flags (I don't know what most of the flags
		do, but the 0x80 flag bit appears to means "DTE->DCE";
		Ethereal doesn't look at the other flags at present,
		although it might at some point);

		one byte of VPI;

		two bytes of VCI (big-endian);

	   followed by the payload.

Ethereal can read that format.

Another option would be to use libpcap format, with a link-layer type of
DLT_ATM_RFC1483, in which the frames begin with an LLC header; however

	1) DLT_ATM_RFC1483 has different values on different platforms -
	   but 100 is a libpcap-format-header-file value for RFC
	   1483-style ATM that, in libpcap 0.6 and later, is the same
	   for all platforms, so you should use that rather than 11 (the
	   value on most platforms) or 13 (the value on BSD/OS);

	2) that format supports only RFC 1483-format AAL5 frames, so if
	   you want to handle *other* AAL5 frames, it won't work;

	3) Ethereal doesn't *currently* dissect it.