Wireshark-dev: Re: [Wireshark-dev] wireshark-only capture format

From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
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.