Repository navigation
protocols: add DLT_NULL and DLT_RAW link-layer handlers #839
Description
Split out of #838 on the maintainer's instruction: "let's add the handlers (protocols) for DLT_NULL and DLT_RAW as part of wave 2/3 work in the work tracker then."
pcapkit/protocols/misc/pcap/frame.py:93-95 registers exactly three link types:
Enum_LinkType.ETHERNET: ModuleDescriptor('pcapkit.protocols.link', 'Ethernet'),
Enum_LinkType.IPV4: ModuleDescriptor('pcapkit.protocols.internet', 'IPv4'),
Enum_LinkType.IPV6: ModuleDescriptor('pcapkit.protocols.internet', 'IPv6'),LinkType.NULL (0, DLT_NULL, BSD loopback — a 4-byte host-order AF_ family field ahead of the IP header) and LinkType.RAW (101, DLT_RAW — a bare IP packet, no link header at all) are genuine DLTs with no handler. That is what makes them unusable as a fallback for an unknown link-layer name, which is the ruling recorded on #838.
Scope: a handler per DLT, registered into Frame.__proto__, plus tests. DLT_NULL's family field decides IPv4 vs IPv6 and is written in the capturing host's byte order, so it cannot be read as fixed-endian. DLT_RAW needs the IP version nibble to pick IPv4 vs IPv6.
Not blocking #838 — that PR raises rather than guessing, which is correct with or without these handlers.
Activity
JarryShaw commentedon Sep 27, 2026
Checkable blocker: scheduling — the maintainer assigned this to wave 2/3, in his words on #838: "let's add the handlers (protocols) for DLT_NULL and DLT_RAW as part of wave 2/3 work in the work tracker then."
So this is deliberately not started now, rather than unowned. It is not a dependency of #838 — that PR raises on an unresolvable link-layer name, which is correct with or without these handlers, and the ruling that produced it was made on exactly that basis.
Re-examine when wave 2/3 opens.
blockeduntil then.JarryShaw commentedon Sep 27, 2026
wave 2/3 requests are saved in the pep.rst doc or discussion threads i think. not in the issues. we should move to the right place so that we dont block the original release criterion.
JarryShaw commentedon Sep 27, 2026
Recorded, verbatim: "wave 2/3 requests are saved in the pep.rst doc or
discussion threads i think. not in the issues. we should move to the right place
so that we dont block the original release criterion."
Moved and closing.
docs/source/pep.rstnow sequences this as "Wave 2 or 3 —handlers for the
DLT_NULLandDLT_RAWlink types", placed immediately beforethe wave 3 paragraph and next to the
LINUX_SLLentry, since all four are linktypes the library enumerates but cannot parse. The entry carries the evidence from
this issue:
__proto__inpcapkit/protocols/misc/pcap/frame.pyregisters exactlyETHERNET,IPV4andIPV6, so aDLT_NULL(0) orDLT_RAW(101) capturereaches no dissector.
Pushed docs-only to
mainas6216de505.docutilsparses the file with no newsevere messages — the
Unknown interpreted text roleerrors it reports arepre-existing Sphinx roles that bare docutils cannot resolve, present from
pep.rst:57onward and not from these lines.