On Apr 17, 2013, at 11:11 AM, Brandon Carpenter <hashstat@xxxxxxxx> wrote:
> I just posted a patch to improve dissection of PCAP-NG captures. Below is the introductory paragraph describing the issues the patch addresses. See Bug 8590 for more information and for the patch. I am looking forward to feedback.
>
>> The current processing of PCAP-NG has limitations that are addressed by the attached patches. First, dissection of the PCAP-NG blocks is occurring in the wiretap library instead of the wireshark library where dissection errors are less likely to cause problems.
So what are some examples of that?
>> Second, it is difficult to present any data other than real packet data to the dissection engine.
That could also be addressed by changes to the libwiretap API and the dissection engine, so that a capture file, instead of being viewed as a sequence of packets, is, instead, viewed as a sequence of records, with a dissector table for record types. I think some other capture file formats could also make use of those changes.
>> Third, multiple section header blocks are not supported.
That could also be addressed by changes to the pcap-ng handling module in libwiretap; fortunately, libwiretap, unlike libpcap/WinPcap, doesn't expose an API that lets you query the byte order of a file. (libpcap/WinPcap needs a new API to allow full support for pcap-ng; the old API would continue to exist, with limited support for pcap-ng, and the new API would also support pcap and possibly additional file formats.)
>> Finally, there is no way to add additional block types and/or options via a plug-in dissector.
See my comment on "Second" above. A "record type" might be a combination of a file format type, with a special value for "generic", and a record type, so that records that are understood by Wiretap could be mapped to a "generic" file format and a record type value exported by Wiretap, and record types not understood by Wiretap could be exported as a file format type and a per-file-format record type (e.g., the block type for pcap-ng).
Bug 8590 introduces a *major* change to the Wireshark/TShark architecture. In the existing architecture, the purpose of libwiretap is to hide file format details from applications, so that, for example, editcap can, in many cases, read files in one format and write them in another format. Splitting the interpretation of the file format between libwiretap and libwireshark might break that.
