On May 11, 2019, at 2:51 PM, Damir Franusic <damir.franu...@gmail.com> wrote:
> PDU types are extendable and there might be more of them in the future. I
> wanted to make it like this so adding new types would not present a big
> issue. I can define the two PDU types used at present moment but maybe it
> would be more practical to leave PDU payload part as generic octet stream if
> that's possible.
Why would it be more practical not to define *what you already implementString
s are pure ASCII C null terminated, no need for utf-8.
> The formats of PDUs will be described in protocol documentation, sure. I am
> just not sure how many types of PDUs will it consist of when it's done. Is we
> just leave as a data octet stream, any kind of PDU added later would not
> break the initial design.
If you're planning on extending this, then what you should do is:
put a specification for the *current* set of PDU types on your Web
site, *including* the payload formats for each of those PDU types;
update it as *new* PDU types are added;
and the entry for your LINKTYPE_ value on tcpdump.org can link to that
specification.
pcapng has a specification:
http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/pcapng/pcapng/master/draft-tuexen-opsawg-pcapng.xml&modeAsFormat=html/ascii&type=ascii
and it *does* list the block type values, and formats, for existing block
types, and the option number values, and formats, for existing options, but
that does *not* prevent it from being extensible; as new block types or options
are added, the specification is updated.
Our goal is to have a registry of link-layer header types that would allow
somebody to write their *own* code to process pcap or pcapng files with packets
of that type *without* having to read tcpdump or Wireshark code to figure out
how to analyze it.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
