Re: New DLT_ value request

[Guy Harris <guy () alum mit edu>]

Will Barker wrote:

> So either approach should be OK - the latter being a bit more flexible. Is
> there no general preference in this regard? Or (non-formalised?) standard
> approach generally adopted now in the libpcap/wireshark world?

There is no standard approach, nor any generally-adopted approach for 
libpcap.  Wireshark defines no capture file formats, so the question 
doesn't apply to it.

"zero means received, non-zero means sent" has the advantages that

        1) the byte order doesn't matter;

	2) you don't have to worry about what to do with packets where the 
header doesn't have one of the known values, as there's an 
interpretation for all values.

"A particular value means sent" has the advantage that

        1) you have room for more information, e.g. "direction not known";

	2) if, instead of "a particular value means sent", you do "a particular 
bit being set means sent", you have some additional bits to use if 
that's useful.

> > So what's the header for your encapsulation type?
>
> In this case I would want the frame-specific info to be in the frame content
> itself (and decoded by the DLT-specific dissector)  and so no fixed header
> would be required. This approach will allow the captured content to be
> version-specific without affecting the plumbing of libpcap/wireshark - only
> the capturing device and the dissector itself would need to know the
> specifics of the message content.

Hopefully by "version-specific" you don't mean "specific to the versions 
of libpcap and Wireshark", but instead mean that one field in the header 
would be a version number, so that you won't, for example, have the 
information change in such a way that one version of Wireshark can't 
read the files from a mismatched version of libpcap.  If that's the 
case, you might as well just use one of the DLT_USERn/WTAP_ENCAP_USERn 
values, as we wouldn't want something like that in the libpcap or 
Wireshark releases.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.