On Nov 22, 2025, at 12:29 PM, Michael Richardson <[email protected]> wrote:
> For instance, consider > https://www.tcpdump.org/linktypes/LINKTYPE_APPLE_IP_OVER_IEEE1394.html > > It doesn't say anything about where the IP header is. > It says that the packet type is an EtherType. "GOSUB 802.3" Yes. Unlike the 802.x and FDDI specifications, all of which can be directly used as references (and probably should be - I'll update ones that aren't directly citing references to do so), there's no official specification, as far as I know, for the header that Apple's IP-over-FireWire interfaces provide to the packet capture mechanism, so we wrote our own. There *are* RFCs for it - RFC 2734 for IPv4-over-FireWire and RFC 3146 for IPv6-over-FireWire - but the frame format shown in RFC 2734 (which also applies to IPv6, just with a different EtherType) is *not* what you get when you capture on a Mac. And if you were to capture on an IP-over-FireWire interface on Linux or on Windows with Npcap, you might get different headers, in which case a new LINKTYPE_ value would have to be assigned. I.e., the link-layer header formats are not just determined by published specifications, they may be determined, in part or in whole, by the code paths that provide those packets to capture mechanisms. That's why we have a lot of specifications hosted on tcpdump.org for these link-layer header types. > Then there is: > https://www.tcpdump.org/linktypes/LINKTYPE_IEEE802_11_PRISM.html Which makes the same point. This also responds to Deb Cooley's COMMENT at https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcaplinktype/ballotpopup/1095953/?ballot_edit_return_point=/doc/search#draft-ietf-opsawg-pcaplinktype_deb-cooley, wherein she notes that "Many of the references are not stable - anything pointing to a website, for example." The problem is that online references of that sort are all we have in many cases. In some of those cases, such as the Excentis metadata header for DOCSIS captures, there is an existing specification, e.g. https://support.excentis.com/knowledge/article/45 for that header. In other cases, we had to construct one; this are the ones hosted on tcpdump.org. Furthermore, some of the external specifications, such as the AVS metadata header for 802.11 captures, the specification is no longer available at its original home, so we refer to it via the Internet Archive's Wayback Machine - https://web.archive.org/web/20040803232023/http://www.shaftnet.org/~pizza/software/capturefrm.txt Even for official standards, such as the IEEE 802.x standards, citing a particular version of the standard has the problem that the version in question may not, for example, list all available PHYs for the network, as some currently-available PHYs might not have existed at the time the spec was published. For 802.x networks, that's unlikely to be a problem, as the MAC layer frame format is almost always PHY-independent - whatever future Ethernet technologies are developed, they'll probably have a header with a 6-octet destination address, immediately followed by a 6-octet source address, immediately followed by a 2-octet type/length field. One exception there is IEEE 802.11, which originally always used what, in IEEE Std 802-2014 is referred to as "LLC protocol discrimination (LPD)", with the frame payload beginning with an IEEE Std 802.2/ISO 8802 header, possibly followed by a SNAP header, but which, in the 5.9 GHz bands, uses what IEEE 802-2014 refers to as "EtherType protocol discrimination (EPD)", where there's just an EtherType, and where an EtherType of 0x88B7, the "OUI Extended EtherType", means that the next 5 octets are a SNAP header that precedes the *real* payload. EPD was introduced in IEEE Std 802-2014, and the use of EPD in 802.11 was introduced in 802.11-2016. > So it when it works, it works. When it doesn't... > But, better to have what we have than nothing. Exactly. _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
