Home page logo
/

wireshark logo Wireshark 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>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]