Re: New official link-layer type request

[Damir Franusic <damir.franusic () gmail com>]

No problem, I will do my best to describe the current version, you'll get it tomorrow.

Thank You for being so prompt

On May 12, 2019 12:02:42 AM GMT+02:00, Guy Harris <gharris () sonic net> wrote:
> On May 11, 2019, at 2:51 PM, Damir Franusic <damir.franusic () 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.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers