> displaying tcpdump data captured on Sun 5.7 using the pf0 (fddi)
> interface
>
> The src or dest MAC address is being incorrectly displayed e.g.
>
> actual MAC 08:00:02:04:89:ed appears as 10:00:40:20:91:b7
The same happens if I hand your sample capture to "snoop" on a SunOS
5.5.1 machine here - it reports:
FDDI: ----- FDDI Header -----
FDDI:
FDDI: Packet 1 arrived at 3:42:16.56
FDDI: Packet size = 73 bytes
FDDI: Destination = 10:0:40:20:24:d9,
FDDI: Source = 10:0:40:20:91:b7,
FDDI: Frame Control = 50 (LLC)
FDDI: Dest Service Access Point = aa
FDDI: Source Service Access Point = aa
FDDI: Control = 03
FDDI: Protocol Id = 000000
FDDI: LLC Type = 0800 (IP)
and it also happens if I hand it to "snoop" on a 5.6 machine.
The underlying problem is almost certainly that
1) FDDI probably specifies that MAC addresses be put onto the
wire in a bit-reversed fashion of some sort;
2) some FDDI cards, when they receive a packet, put the MAC
addresses in memory in the right bit order, and others don't;
3) the drivers for at least some cards that don't put them in
memory in the right bit order don't themselves fix the data
in the packet before handing it to whatever mechanism
implements raw packet capture;
which means that some FDDI captures have the MAC addresses bit-reversed
and some don't.
What's worse:
4) there isn't necessarily a way for code doing raw packet
capture to inquire of the interface on which they're doing
the capture whether the MAC addresses are in the right bit
order or not
and
5) even if they could there's no way to specify, in most if not
all capture file formats, whether the MAC addresses are in
the right bit order or not (which may be a consequence of the
fact that you probably can't find that out in the first
place...)
so the display part of packet analyzer programs is pretty much screwed -
at best it can guess whether the addresses will be bit-swapped or not.
That's what tcpdump and Ethereal do - tcpdump assumes that on Ultrix
systems, Alpha-based systems, and BSD/OS systems the addresses aren't
bit-swapped, and on other systems they are (to quote the tcpdump code in
"print-fddi.c":
/*
* Some FDDI interfaces use bit-swapped addresses.
*/
#if defined(ultrix) || defined(__alpha) || defined(__bsdi)
int fddi_bitswap = 0;
#else
int fddi_bitswap = 1;
#endif
), which in turn assumes that the capture tcpdump is reading is being
done on the machine tcpdump is running *and* that all FDDI interfaces on
machines of the specified type behave the same way (neither of which is
necessarily true, but, as per the above, tcpdump can't really do much
better than that), and Ethereal makes the same assumption about
libpcap-format captures and assumes that all captures in snoop format
have bit-swapped FDDI addresses - it looks as if snoop may make the same
assumption.
I seem to remember that captures made on Suns with Network Peripherals,
Inc. FDDI cards (which we had here) had bit-swapped addresses; it
appears that the FDDI card you're using doesn't.
At best, we could add a command-line/dialog box option to specify
whether the addresses should be treated as bit-swapped or not; I know of
no way for a packet analyzer to figure that out, short of being told by
a human.