On Nov 20, 2025, at 7:05 PM, Ketan Talaulikar <[email protected]> wrote:
> The only point to clarify is that this info would need to be there in the
> specification/reference provided. I would expect that at least the size of
> the DLT header (if fixed) is required for parsing. If size is not fixed then
> the specification for parsing is required? If this is not provided then I
> would wonder how TCPDUMP and other implementations using these types would be
> able to parse.
Parsing the packet is the job of the packet analyzer, and writing the code (or
the packet format, in some packet description language, or whatever) to parse
it is the job of the developers of the packet analyzer.
The specification would say "the packet looks like this". Some examples:
For LINKYPE_ETHERNET, "the packets are IEEE 802.3 frames" is sufficient,
perhaps with a clarification that this does *not* include the preamble or start
frame delimiter and might or might not include the FCS. That should be
sufficient to start parsing the frame, but you'll need a table of EtherType
values (and DLSAP values for frames with 802.2 headers, and OID/PID pairs for
SNAP frames), and know the specifications for them; to parse the "MAC client
data" field (e.g., use RFC 791 etc. if the type/length field is 0x0800) -
that's all outside the scope of the LINKTYPE_ETHERNET specifications.
For LINKTYPE_IEEE802_11, "the packets are IEEE 802.11 MAC frames" is
sufficient. Again, it should be sufficient to parse the MAC header, and to
parse the frame body of Control and Management frames, but, again, you'll need
more to parse the frame body of Data frames.
For LINKTYPE_IEEE802_11_RADIOTAP, "the packets begin with a Radiotap header, as
specified by https://www.radiotap.org/, followed by an 802.11 MAC frame" is
sufficient; the MAC frame would be parsed the same way that it is in
LINKTYPE_IEEE802_11.
For LINKTYPE_NULL, https://www.tcpdump.org/linktypes/LINKTYPE_NULL.html tells
you have to parse the LINKTYPE_NULL header, and how to determine the type of
the payload; you'll need the speciifcations for those types to parse the
payload.
For LINKTYPE_RAW, the packets are just raw IPv4 or IPv6 frames, so you start
with RFC 791 if the "version" field is 4 and RFC 8200 if the "version" field is
6.
For LINKTYPE_RDS, IEC 62106-1 specifies what the data looks like "on the air",
but you'll also need https://www.tcpdump.org/linktypes/LINKTYPE_RDS.html to
know how the on-the-air data is represented in the capture. For example, the
26-bit words in the on-the-air format, consisting of a 16-bit information word
and a 10-bit checkword, are represented by the 16-bit information word; the
checkword isn't saved in the capture. There are no protocols encapsulated in
those packets, so you don't need any other specifications than those two.
This is independent of whether the link-layer header (including any metadata)
has a fixed or variable length.
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
