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.