tcpdump mailing list archives

Re: New DLT_ value request


From: "Will Barker" <w.barker () zen co uk>
Date: Tue, 18 Dec 2007 10:46:49 -0000

OK - can we go for:

"zero means received, non-zero means sent"

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.  

I was not thinking of producing anything that wasn't backward compatible -
but I agree - there should be no version field - we won't need it.

Thanks

Will

-----Original Message-----
From: tcpdump-workers-owner () lists tcpdump org
[mailto:tcpdump-workers-owner () lists tcpdump org] On Behalf Of Guy Harris
Sent: 12 December 2007 18:58
To: tcpdump-workers () lists tcpdump org
Subject: Re: [tcpdump-workers] New DLT_ value request

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.

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.


Current thread: