Wireshark · Ethereal-users: Re: [Ethereal-users] Reading AIX tcpdump files

[Guy Harris <gharris@xxxxxxxxxxxx>]

On Wed, Jan 17, 2001 at 02:12:47PM -0500, randy.coleman@xxxxxxx wrote:
> I'm capturing traffic using tcpdump (with the -w option) on an AIX
> system.  The files read into Ethereal fine, but every packet shows
> up as "TR MAC" in the protocol column and "Report Monitor Errors" in
> the Info column.  This is seen on both a Win32 as well as Solaris
> version of Ethereal, so I suspect it is anAIX-related problem.  I
> can dump the tcpdump file to text using 'tcpdump -r <filename>', and
> I see what I expect to see...mostly TCP/IP and UDP packets.
> 
> Any idea as to what may be going on or what I may have f---ed up?

You probably didn't f---up, IBM probably did.

The folks in Austin appear to have decided that they needed to improve
the tcpdump file format; for one thing, they decided that they should
support nanosecond time resolution for packet time stamps - OK, fine -
and also appear to have decided that DLT_ values are Bad and that they
should, instead, use IFT_ values from <net/if_types.h>, perhaps because
at least some of them are standard values specified by SNMP.

Then they made the colossal screwup of changing the format *AND NOT
BOTHERING TO CHANGE THE MAGIC NUMBER ON THE CAPTURE FILE*, so that you
*CANNOT* tell an AIX tcpdump capture from a standard tcpdump capture
merely by looking at the magic number, so libpcap - or wiretap - can't
just transparently hide the differences between AIX tcpdump captures and
standard tcpdump captures from applications reading those capture files!

Grrrr....

(I sent mail a while ago to some folks in the AIX group asking that,
among other things, they change the magic number; I haven't heard back
from them, and mail to one of the people to whom I sent that stuff
bounced, so I guess he's not at IBM any more.  I may ask a friend of
mine who's contracting there to see if she can poke people, but I
suspect there's a lot of people there and she may not be able to poke
the right people.)

IFT_ETHER is 0x6 (I think this is specified by SNMP as the interface
type for Ethernet).

DLT_EN10MB (the "10MB" means "as opposed to the 3Mb experimental
Ethernet, which I think had 2-byte source and destination addresses",
not "this is only for 10 megabit Ethernet" - it's for use on anything
with an Ethernet-style packet header) is, however, 1 - 6 is DLT_IEEE802,
which was defined as "IEEE 802 Networks", but that makes no sense as
different 802.* networks have different MAC headers, so it has been used
for Token Ring on a number of platforms (Linux and the BSDs, for
example).

Other screwups of the "duh, we forgot to change the magic number" type
are worked around, with somewhat ugly code, by wiretap.

However, those screwups involved changing the *size* of the per-packet
record headers, so, as long as the capture contains two or more packets,
the workarounds, which attempt to read the first record and then, based
on the packet size in that record, attempt to read the second record,
and if the header for the second record looks like garbage, tries to
read those two records again, with a different per-packet record header
format, will probably figure out which flavor of capture you have.

Detecting an AIX capture might be harder - it'd have to look either for
packets whose "microseconds" value in the time stamp is >= 1,000,000
(which indicates that it's probably a nanoseconds value), or look for
link-layer headers inconsistent with the capture file type.

Looking for packets with a bogus "microseconds" value could involve
looking at a lot of packets before you can come to a conclusion - and,
if you're reading a *standard* tcpdump packet, involves reading the
entire file before you can conclude what type it is and read it again
for real; that'd be prohibitively expensive on large captures.

Looking for link-layer headers that don't match the purported DLT_ type
works only if there are link-layer headers that obviously don't match -
and the trick there is to distinguish between a bad link-layer header
and, say, a link-layer header specifying some unknown but valid Ethernet
type, or some unlikely but valid set of flags, or something such as
that.

I'm inclined to require the user to run a deAIXifier program on the
capture file; this would be useful not only for Ethereal users but for
anybody *else* who wants to read an AIX capture file with any program
other than the AIX version of tcpdump.