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:
- New DLT_ value request Will Barker (Nov 28)
- Re: New DLT_ value request Guy Harris (Nov 28)
- Re: New DLT_ value request Will Barker (Nov 29)
- Re: New DLT_ value request Guy Harris (Nov 29)
- Re: New DLT_ value request Will Barker (Nov 30)
- Re: New DLT_ value request Guy Harris (Dec 12)
- Re: New DLT_ value request Will Barker (Dec 18)
- Re: New DLT_ value request Guy Harris (Dec 19)
- Re: New DLT_ value request Will Barker (Dec 20)
- Re: New DLT_ value request Guy Harris (Dec 21)
- Re: New DLT_ value request Fulko Hew (Dec 21)
- Re: New DLT_ value request Will Barker (Nov 29)
- Re: New DLT_ value request Guy Harris (Nov 28)
- Re: New DLT_ value request Will Barker (Dec 12)