Ethereal-dev: Re: [Ethereal-dev] unsupported network type in capture file

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Mon, 24 Mar 2003 21:53:26 -0800
On Mon, Mar 24, 2003 at 05:26:20PM -0500, Nathan Jennings wrote:
> I receive the following error using Ethereal 0.9.11 when I try to open a
> certain capture file:
> 
> "The file <filename> is a capture for a network type that Ethereal
> doesn't support."
> 
> The capture file was written by the default, IBM provided tcpdump
> included with AIX 4.3. I've read other captures in Ethereal written by
> this tcpdump previously, but these successful reads have been of
> captures from the host's ethernet interface. The error message above is
> generated when I try to read a capture from the host's loopback
> interface (lo0).

Yup, Ethereal does, in fact, not support loopback captures from AIX.

It would have supported it if somebody at IBM hadn't had the bright idea
of changing the set of values used for link-layer types *without*
changing the magic number used for capture files.  Given that they
*also* changed the time stamps from being seconds/microseconds to
seconds/nanoseconds, changing the magic number, as those files do *NOT*
have the same binary format as regular tcpdump/libpcap files, would have
been the right thing to do.  Unfortunately, they didn't, so Ethereal has
some hacks to try to recognize AIX capture files.

> I compiled/installed the latest tcpdump on my desktop and tried to read
> the capture file. It outputs an error message as well, saying datalink
> type 24 not found (maybe this helps?).

Yes, it does - it indicates that AIX does, in fact, use the SNMP ifType
value for "loopback" for loopback interfaces.

> I was hoping someone might have some suggestions or guidance on how I
> might modify Ethereal so it can read these capture files.

Here's a patch that, *IF* loopback devices on AIX supply DLT_NULL-style
headers to BPF, will allow Ethereal to read the capture.  If they don't
supply DLT_NULL-style headers, more work will be necessary, and it might
require that we have a capture file from an AIX loopback interface.  I
will be checking this patch in - if it doesn't work, let us know, so we
can try to make it work.
Index: wiretap/libpcap.c
===================================================================
RCS file: /usr/local/cvsroot/ethereal/wiretap/libpcap.c,v
retrieving revision 1.94
diff -c -r1.94 libpcap.c
*** wiretap/libpcap.c	8 Mar 2003 09:11:53 -0000	1.94
--- wiretap/libpcap.c	25 Mar 2003 05:47:57 -0000
***************
*** 517,525 ****
  	 *	FDDI		15
  	 *
  	 * which correspond to DLT_IEEE802 (used for Token Ring),
! 	 * DLT_PPP, and DLT_SLIP_BSDOS, respectively.  We shall
! 	 * assume that if the minor version number is 2, and
! 	 * the network type is 6, 9, or 15, that it's AIX libpcap.
  	 *
  	 * I'm assuming those older versions of libpcap didn't
  	 * use DLT_IEEE802 for Token Ring, and didn't use DLT_SLIP_BSDOS
--- 517,533 ----
  	 *	FDDI		15
  	 *
  	 * which correspond to DLT_IEEE802 (used for Token Ring),
! 	 * DLT_PPP, and DLT_SLIP_BSDOS, respectively.  The ifType value
! 	 * for a loopback interface is 24, which currently isn't
! 	 * used by any version of libpcap I know about (and, as
! 	 * tcpdump.org are assigning DLT_ values above 100, and
! 	 * NetBSD started assigning values starting at 50, and
! 	 * the values chosen by other libpcaps appear to stop at
! 	 * 19, it's probably not going to be used by any libpcap
! 	 * in the future).
! 	 *
! 	 * We shall assume that if the minor version number is 2, and
! 	 * the network type is 6, 9, 15, or 24, that it's AIX libpcap.
  	 *
  	 * I'm assuming those older versions of libpcap didn't
  	 * use DLT_IEEE802 for Token Ring, and didn't use DLT_SLIP_BSDOS
***************
*** 546,551 ****
--- 554,564 ----
  
  		case 15:
  			hdr.network = 10;	/* DLT_FDDI, FDDI */
+ 			aix = TRUE;
+ 			break;
+ 
+ 		case 24:
+ 			hdr.network = 0;	/* DLT_NULL, loopback */
  			aix = TRUE;
  			break;
  		}