Repository navigation
feat(link): implement LINUX_SLL and LINUX_SLL2 (the tcpdump -i any cooked-capture headers) #2438
Description
Is your feature request related to a problem? Please describe.
Wave 2 of the roadmap. LINUX_SLL (DLT 113) and LINUX_SLL2 (DLT 276) -- the Linux "cooked capture" link-layer headers every tcpdump -i any capture uses -- have no implementation at all. Both DLT values are already registered in pcapkit/const/reg/linktype.py; resolving either currently has nowhere to dispatch to.
Describe the solution you'd like
Two concrete Link subclasses (schema/data/protocol split, per Loopback as the closest existing precedent), registered onto Link the same way Loopback/Ethernet/etc. already are.
LINUX_SLL (16-byte header): packet_type (2B u16, direction: 0=to us, 1=broadcast, 2=multicast, 3=sent to another host promiscuously, 4=sent by us), arphrd_type (2B u16, ARPHRD_* hardware type, e.g. 1=Ethernet), link_addr_length (2B u16, actual address length, ≤8), link_addr (8B, padded -- only the first link_addr_length bytes meaningful), protocol_type (2B u16, usually an EtherType).
LINUX_SLL2 (20-byte header, reordered and extended): protocol_type (2B, moved to the front), reserved (2B), interface_index (4B u32, new), arphrd_type (2B), packet_type (1B, shrunk from 2B), link_addr_length (1B), link_addr (8B, padded).
Neither should blindly reuse Link.__proto__'s existing EtherType-keyed next-layer dispatch table. Loopback already sets this precedent -- its own next-layer selection isn't an EtherType lookup, since LINKTYPE_NULL/LOOP's selector works differently, so it has its own address-family lookup instead. LINUX_SLL's protocol_type is only an EtherType in the common case (arphrd_type == ARPHRD_ETHER); for other hardware types it isn't, so next-layer dispatch needs to branch on arphrd_type rather than assume EtherType universally.
Describe alternatives you've considered
None -- this is well-specified from the wire formats above, not a design question.
Additional context
Matters out of proportion to its size: pep.rst specifically calls out that every tcpdump -i any capture uses one of these two, so this is high real-world coverage for a small, unambiguous implementation.
Activity
JarryShaw commentedon Oct 30, 2026
Correction to this issue's own text: "LINUX_SLL's
protocol_typefield is only a real EtherType whenarphrd_type == ARPHRD_ETHER" is backwards. Per tcpdump.org's own LINUX_SLL/LINUX_SLL2 pages,protocol_typeis the Ethernet protocol type for everyarphrd_typeexcept five: NETLINK (824), IPGRE (778), IP6GRE (823), IEEE80211_RADIOTAP (803), FRAD (770). The dispatch logic should be an exclusion list of those five, not an inclusion list of Ethernet alone — otherwise atcpdump -i anycapture's loopback traffic (by far the most common non-Ethernet case) would come out asRawdespite a perfectly valid EtherType. Caught by cross-review on PR #2443, which implemented my original (wrong) framing faithfully.feat(link): implement LINUX_SLL and LINUX_SLL2 dissectors
feat(link): implement LINUX_SLL and LINUX_SLL2 dissectors
feat(link): implement LINUX_SLL and LINUX_SLL2 dissectors
feat(link): implement LINUX_SLL and LINUX_SLL2 dissectors
fix(link): resolve SLL protocol_type exactly as Ethernet resolves type (
feat(link): implement LINUX_SLL and LINUX_SLL2 dissectors
fix(link): resolve SLL protocol_type exactly as Ethernet resolves type (
feat(link): implement LINUX_SLL and LINUX_SLL2 dissectors (#2438)
feat(link): implement LINUX_SLL and LINUX_SLL2 dissectors (#2438)
feat(link): implement LINUX_SLL and LINUX_SLL2 dissectors (#2438)
test(const): count pcapkit.const.linux.arphrd in the census (#2438)
refactor(const): put linux ARPHRD on the EnumRegistry shape (#2438)
feat(link): implement LINUX_SLL and LINUX_SLL2 dissectors (#2443)
docs(contributing): fix a botched pep.rst merge resolution
feat(internet): add IGMPv1/IGMPv2 as concrete classes over an abstrac…