Ethereal-dev: [ethereal-dev] Support for reading Full Frontal ATM from Sniffer files added
I added a new encapsulation type for ATM Sniffer files; instead of
returning only LANE or RFC 1483 frames after stripping off (in the
former case) the LANE header, Wiretap now returns all the packet data
from the capture file, as well as supplying a "pseudo-header" giving
stuff from the record header (traffic type, VPI/VCI, etc.).
Ethereal now includes some ATM decoding for the pseudo-header and LANE;
it decodes the header on LANE data (and then hands the payload off to
"packet_eth()" or "packet_tr()", both of which have been modified to
take an "offset" argument and to treat that as the offset at which the
Ethernet/802.3 or 802.5 frame begins - Gilbert, you may want to check to
make sure I updated "packet-tr.c" correctly).
NOTE: I'm not an ATM expert; what I know about ATM I learned from
writing the initial code to handle the ATM Sniffer files, and from
digging stuff out of the LANE 1.0 spec to write the LANE decoding stuff.
There may well be byte-order or other errors in this code, and it may
not do as good a job of filling in the COL_INFO column as it should, and
it's definitely lacking lots of other stuff (full LANE control frame
decoding, e.g. decoding all the type/length/value parameters; decoding
non-LANE frames; ILMI; decoding ATM addresses as something other than
uninterpreted byte strings; etc.).
Note that this doesn't replace the stuff in "packet-clip.c"; the ATM on
Linux code doesn't hand up all the low-level ATM stuff you can get from
an ATM Sniffer capture file.
The current way I'm supplying the "pseudo-header" data is as a
generalization of the "flags" stuff handed up for X.25 decodes; that
adds a pile of extra stuff to every "frame_data" structure - a better
way to handle this might be to
1) have the packet read routines in Wiretap, for all files where
stuff from the record header goes into a pseudo-header,
return as the offset in the file for the packet the offset of
the record header;
2) have those routines take an argument that's a pointer to a
pseudo-header, and fill in the pseudo-header;
3) add a routine to Wiretap to read a packet and its
pseudo-header (i.e., read what's needed to dissect the
packet, but not the stuff we'd continue to keep in the
"frame_data" structure) given the offset returned by the
packet read routine, filling in both a pseudo-header and a
packet buffer, and use that instead of raw "fseek()" and
"fread()" in Ethereal.
The pseudo-header for ATM might also be best defined independently of
the definition of the record header in an ATM Sniffer capture, in case
we ever have any other capture file formats that supply Full Frontal
ATM. (Note that any other capture file types with pseudo-headers
supplying useful information above and beyond the packet data could also
use the pseudo-header mechanism; I don't know if there's any such data
in the X.25 captures other than the flags currently returned.)
