mailing list archives
Re: Enhanced PCAP-NG dissection
From: Guy Harris <guy () alum mit edu>
Date: Wed, 17 Apr 2013 11:53:00 -0700
On Apr 17, 2013, at 11:11 AM, Brandon Carpenter <hashstat () pnnl gov> 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.
Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org>
mailto:wireshark-dev-request () wireshark org?subject=unsubscribe