Wireshark-dev: Re: [Wireshark-dev] wireshark-only capture format
From: Jeff Morriss <[email protected]>
Date: Tue, 27 May 2014 16:53:52 -0400
On 05/26/14 10:45, Dmitry Bazhenov wrote:
Hello, all,
[BTW, it's bad form to reply to a mailing-list email on a new topic: 
it's better to compose a new email.  That way people's threaded mail 
readers won't think that your email is related to, in this case, a 
question about "Byte matching."]
Recently, the tcpdump-workers mailing list has stopped working for me.
None of my replies posted into the list over the last week have got to
the subscribers.
None of my mails sent directly to the person who previously interacted
with me have been answered.

This makes the situation around the DLT_ value reservation and my patch
for the IPMI-Trace dissector hanged in air.

And I wonder why is it needed requesting for DLT_/LINKTYPE_ values from
PCAP library maintainers for captures which are intended only to be
analyzed in Wireshark/tshark?
Only because you "want" to use a PCAP file (where "want" is not 
necessarily a desire but at least what you've defaulted to doing).
If you want to use a non-PCAP file (and non-PCAPNG as PCAPNG is also 
from tcpdump.org) then you certainly can--Wireshark understands lots of 
file formats.
Is there a chance that for that kind of captures there will be a
separate Wireshark format which does not do anything with libPCAP?
Or probably there is already such format and I can skip the DLT_ value
reservation?
Well, Wireshark understands lots of file formats.  Only two of them 
(okay, I didn't check, but I only know of PCAP and PCAP-NG) use DLT_ values.
As Michael mentioned, you might have some luck with the "Exported PDU" 
interface (epan/exported_pdu.h) in master (and now master-1.12).
Otherwise...  So far nobody's been frustrated enough in their attempts 
to allocate a DLT_ value to create a new file format and write all the 
code necessary to recognize, read, and write the new format.  And 
possibly to get people here to sign on to being keepers of yet another 
magic number.
Also, keep in mind that the folks over at tcpdump.org are, like those 
here, unpaid volunteers (well, I assume so anyway).  They do seem to 
have more technical difficulties than many places but those usually go 
away within a week or two.