["Alex Bennee" <Alex.Bennee@xxxxxxxxxxx>]

Guy,

We went for the easy option. A college of mine write a perl scipt to reformat
the verbose output of netfmt (provided as part of HP-UX's nettl tool) into a
binary tcpdump format. The latest ethereal happily reads the dump (and decodes
the LLC_HEADER) and everything works just dandy.

for the record:

(on HP-UX)
     nettl -tn pduin pduout -e atm -f /tmp/dump         (start trace)
     nettl -tf -e atm                         (stop trace)

     netfmt -v dump.TRC0 > dump.TRC0.fmt
(copy to linux box - uses perl and a lot of libs)
     netfmt.pl -l dump.TRC0.fmt               (lists VPI/VCI in dump)
     netfmt.pl -p 1 -c 80 -o trace dump.TRC0.fmt   (dumps VP1 VC80 frames into
trace)

And then load the trace file into ethereal and bobs your uncle.

Does anyone know where we can send the script to as it may be useful to other
people (maybe in ~/tools/ dir of the ethereal tarball?). The perl script is ugly
and a hack but it works and people are welcome to clean it up of re-implement it
as an ethereal loader for nettl formated files.

Regards,

Alex.








Guy Harris <guy@xxxxxxxxxx> on 06/06/2001 19:42:23
                                                                                
                                                                                
                                                                                


                                                              
                                                              
                                                              
 To:      Alex Bennee/MAIN/MC1@MCMAIN                         
                                                              
 cc:      ethereal-users@xxxxxxxxxxxx                         
                                                              
                                                              
                                                              
 Subject: Re: [Ethereal-users] Capturing IP over ATM traces,  
          best approach?                                      
                                                              







> 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.

Attachment: att1.eml
Description: Binary data