On Apr 8, 2012, at 1:17 PM, Martin Mathieson wrote:
> I would like to do this. Looking at the other definitions in http://www.tcpdump.org/linktypes.html, they have quite formal specifications, so I'm wondering what I would need to do first.
>
> Really all we have is the description in http://anonsvn.wireshark.org/wireshark/trunk/epan/dissectors/packet-mac-lte.h (and the function dissect_mac_lte_context_fields(), and the example program for encoding a file of this format (http://www.wireshark.org/~martinm/mac_pcap_sample_code.c). There are some existing parameters in the struct mac_lte_info that you can't currently set using this framing method - these are optional fields that could be added later if someone wanted them. And it is always possible we'd want to add more (probably optional) fields that aren't yet in mac_lte_info.
If you want to be able to add optional fields, make sure that the header is extensible in some fashion, so that, if the fields are added, the existing code that handles that pseudo-header will be able to handle the new header (even if it just ignores the additional fields) and so that code updated to handle the new fields can still handle files with the old header that lacks those fields.
> What would you recommend I submit? The header file is the ultimate authority...
...but it's less useful if the code to process the pseudo-header isn't going to be written in C.
My goals with http://www.tcpdump.org/linktypes.html and the pages under http://www.tcpdump.org/linktypes to which it links are to:
allow arbitrary applications that process pcap or pcap-ng captures to be extended to handle link-layer header types that they don't already handle (i.e., those pages are not supposed to be tcpdump-specific or Wireshark-specific or even application-written-in-a-derivative-of-C-specific);
ensure that the header format won't ever change in a way that would either render old captures not processable by newer code or require a preference setting to control which version of the header format is used.
