Ethereal-dev: Re: [ethereal-dev] Antwort: Re: [ethereal-users] Reading AIX-iptrace on at0
> My guess is that it's a 32-bit quantity, but 4-gigabyte packets
> scare me.
That's my guess, too - maybe they just made it a 32-bit field because
that's the word size of (32-bit) POWER-family processors.
> I have no idea why. Here's my updated
> iptrace_pkt_hdr struct. junk1 and junk2 appear to always be 0.
>
> typedef struct {
> /* 0-3 */ guint32 pkt_length; /* packet length + 32 */
> /* 4-7 */ guint32 tv_sec0; /* copy of tv_sec */
> /* 8-11 */ guint32 junk1; /* ?? */
> /* 12-15 */ char if_name[4]; /* null-terminated */
> /* 16-27 */ char if_desc[12]; /* interface description. */
> /* 28 */ guint8 if_type; /* BSD net/if_types.h */
> /* 29 */ guint8 tx_flag; /* 0=receive, 1=transmit */
> /* 30-31 */ guint16 junk2;
> /* 32-35 */ guint32 tv_sec;
> /* 36-39 */ guint32 tv_usec;
> } iptrace_phdr;
Yup. That's what it looked like to me, too.
For ATM, the interface description appears to be a string of the form
"atvcX.Y", where X is the virtual path identifier and Y is the virtual
circuit identifier of the connection.
It's beginning to look as if an "at"/IFT_ATM "iptrace" capture contains
raw AAL5 frames as the packet data.
Unfortunately, I'm not sure how one infers from that the type of traffic
it is, in general. Frames 3 and 4 are to virtual circuit 0.16, and some
stuff on the ATM Forum site indicate that VC 0.16 is for use by ILMI,
and "ipreport" *did* dissect that as ILMI, and it looks as if it's
probably valid ILMI traffic (ILMI appears to be "SNMP inside AAL5", and
it looks as if the traffic is getting something in an ATM MIB of some
sort).
VC 0.567 looks like Classical IP, with an 802.2 LLC header at the
beginning of the frame; it appears to have correctly dissected that.
VC 0.561's traffic begins with 0xFF 0x00, which is the header for a LANE
control frame, and that's what it dissected it as. VC 0.563 could be
LANE data, but it's being dissected in a non-obvious fashion - the first
0.563 frame is
00 02 01 80 c2 00 00 00 08 00 8f 41 22 02 00 26 42 42 03 00
00 00 00 00 80 00 08 00 8f 19 42 a9 00 00 00 0a 80 00 08 00
8f 26 31 39 81 21 01 00 14 00 02 00 0f 00 00 00 00 00 0d 0f
08 00 8f 4f 00 00
which would, as Ethernet LANE data, be:
00 02 LE header
01 80 c2 00 00 00 Destination Ethernet address
08 00 8f 41 22 02 Source Ethernet address
00 26 Type/length (a length)
with
42 42 03 00
00 00 00 00 80 00 08 00 8f 19 42 a9 00 00 00 0a 80 00 08 00
8f 26 31 39 81 21 01 00 14 00 02 00 0f 00 00 00 00 00 0d 0f
08 00 8f 4f 00 00
as the payload - and that looks like a UI frame with source and
destination SAPs of 0x42, i.e. Spanning Tree BPDU - but, for some
unknown reason, it's dissecting it as IP, with the payload being treated
as purely IP data! Perhaps "ipreport" is just buggy....
However, that still doesn't indicate how it knew that VC 0.561 and 0.563
were LANE, and VC 0.567 was Classical IP. There doesn't seem to be
anything in the header that would indicate the type of traffic; perhaps
it doesn't know what type of traffic it is, perhaps it just looks at the
first few bytes of the packet and tries to *guess* what it is....
