Ethereal-dev: Re: [ethereal-dev] Antwort: Re: [ethereal-users] Reading AIX-iptrace on at0
> Thanks, yes, I'm starting to understand your trace now. In an iptrace file,
> there's a large field, 16 bytes, which describes the interface. We
> never had any use for before for the other datalink types, but for ATM
> there appears to be needed information in that field, letting us know
> what appears in the traced ATM "packet" (LANE, RFC1483-LLC-encapsulation,
> etc.). The one thing I cannot figure out is which flag designates
> the type of emulated LAN you're running. What types of emulated
> LANs do you run, ethernet, token-ring, or both?
He said it was Classical IP, and frame 9 appears to bear that out - it
begins with "aa aa 03", which has SNAP as the SSAP and DSAP, and UI as
the control field, of an LLC header.
As for what stuff in the header specifies that, that's a good question:
bytes 0 and 1 always appear to be 0;
bytes 2 and 3 contain the frame size + 32 (or perhaps that's in
bytes 0-3, as a 32-bit quantity);
bytes 4-11 contain, at least in frames 1, 2, 3, and 9:
0x38
0x2c
0xa2
0xab in frames 1 and 2, 0xad in frame 3, 0xaf in frame 9;
bytes 12-15 contain "at"
bytes 16-25 contain "atvc", followed by the VC number that
"ipreport" showed, as text;
bytes 26 and 27 contain 0x6c 0x42
bytes 28-31 contain 0x25 0x00 0x00 0x00 in frames 1, 2, and 3,
and 0x25 0x01 0x00 0x00 in frame 9.
Hmm. I saw, in one of the threads on the "tcpdump-workers" mailing list
(and I think some of that may have shown up on "ethereal-dev", as well),
a discussion of the problem wherein "libpcap" was, on AIX, reporting a
DLT_ type of 6 for an Ethernet interface. Somebody on "tcpdump-workers"
indicated that the BPF code may have been failing to translate the BSD
"IFT_" value (from "/usr/include/net/if_types.h" on many systems), which
is 6 for IFT_ETHER, to a DLT_ value.
This prompted me to look at the dual-homed "iptrace" file you put up on
the Ethereal site.
It looks as if byte 28 is an IFT_ value:
it's 0x09 (IFT_ISO88025, which the comment on FreeBSD 3.2 says
is Token Ring) in the first frame, which is a Token Ring frame;
it's 0x06 (IFT_ETHER) in the second frame, which is an Ethernet
frame;
it's 0x25 (IFT_ATM) in the ATM capture.
That then raises the question of what the rest of the bytes are. In the
multi-homed trace, it's 0x01 in frame 1 and 0x00 in frame 2 - I didn't
look at the other frames. The next two bytes are 0 in those frames I
looked at.
So byte 28 won't tell you what ATM encapsulation it has, and bytes 27
and 28 seem to be 0x6c 0x42 in all the frames I looked at.
