In rev 1.6 of sys/net/if_fddi.h, we prepended the following to
struct fddi_header:

        u_char  fddi_ph[3];             /* makes the FDDI header 16 bytes */

the commit message syas this is done to avoid alignment problmes.

I think this also means that libpcap files of fddi interfaces are no
longer portable between NetBSD and any other libpcap platform: they
use the struct fddi_header in tcpdump's own fddi.h, which does not
have this extra padding.

This is causing me some real grief: Craig Partrige and I have some
confidential (non-redistributable) network dumps, which we're trying
to analyze with libpcap-based tools.  NetBSD's tcpdump doesn't print
the old FDDI dumps we have.

For now, I've kludged my own copy of usr.sbin/tcpdump/print_fddi.c to
work around this: before copying to the I subtract three bytes from
the input argument and add three bytes to the length:


--- print-fddi.c.DIST	Sun Sep 20 04:14:42 1998
+++ print-fddi.c	Mon May 15 20:36:06 2000
@@ -282,6 +282,23 @@
 
 	ts_print(&h->ts);
 
+#ifndef justforkicks
+	/* OOPS. At some point NetBSD decided to prepend 3 bytes to
+	 * struct fddi_header, to make it aligned.  But that breaks
+	 * binary compatiblity with pre-existing lipcap dumps from
+	 * FDDI interfaces, or dumps from other systems.
+	 * (compare tcpdump's own fddi.h; cf.  u_char fddi_ph[3])
+	 *
+	 * For now, kludge around that by backing up the packet
+	 * pointer by 3 bytes, effectively aliasing 3 bytes of junk 
+	 * as the 3 bytes of "padding" at the start of NetBSD's struct
+	 * fddi_header.  */
+	length += 3;
+	p -= 3;
+	fddip = (struct fddi_header*) p;	/* 3 bytes of junk aliased as "padding"*/
+	caplen += 3;
+#endif
+
 	if (caplen < FDDI_HDRLEN) {
 		printf("[|fddi]");
 		goto out;

so it looks like this extra 3 bytes is included in NetBSD's idea of
the pcap dumpfile fddi header size.  Anyone else care to confirm
this analysis?

Anyway, with the above kludge, I can at least read the dump files
(some of which date back several years) and print them.  I doubt it
works for live pcap dumps (I dont have a FDDI card to test).  i don't
know whether the same problem exists when reading native,
produced-on-netbsd dump files (instead of live pcap) or not;
anyone tried it recently?

What, if anything, can we do to fix this bug in what was supposed
to be a portable file format?

(PS: I'll send a PR if someone can confirm this really is a NetBSD
bug, not my buge :)