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 16:22:08 -0700

(Moving some discussion from the bug to the e-mail thread.)

On Apr 17, 2013, at 13:33:47 PDT, in comment #3 to bug 8590, Brandon Carpenter <hashstat () pnnl gov> wrote:

(In reply to comment #2)

With this change, could I, for example, read a pcap-ng file containing only Ethernet packets and write out a pcap 
file, or a Microsoft NetMon file, with the packets in question?

It depends on on how much the other formats depend on the interface and section information filled in by the current 
PCAP-NG wiretap routines.  This patch does not currently fill in most of those fields, however, it would not take 
much to fill in those details from the PCAP-NG dissector so that saving/exporting works as expected.

I'm not talking about saving/exporting from Wireshark (or "-r" and "-w" from 

I'm talking about using *editcap*, which includes no dissectors and should not include any dissectors, to do that form 
of transformation.

The dissection might be better, but the question is whether most of the goals could be achieved with changes to the 
Wiretap library API (which might also improve the handling of *other* file formats)?

I would not consider this enhancement feature complete.  I did not want put much more time into it unless the 
Wireshark community thinks it worth pursuing.  If there is interest in moving this forward, I would love to work with 
the community to complete it.  Or if there is alternative approach that produces similar results, I would love to 
help out there as well.

What I am really interested in is being able to easily add support for additional block types without having to add a 
bunch of pointers to special structures to move that data from libwiretap to libwireshark.  It is also valuable to 
view some non-packet data mixed in with the packet data.

As per my earlier mail message (this is one reason why there should be only one discussion thread here, rather than one 
on wireshark-dev and one in the bug), those can be accomplished with libwiretap API changes.

Doing it there makes it possible for *other* file formats to export information that doesn't fit neatly into an 
abstract model of capture files; we might be able to handle some stuff that's currently done with pseudo-header hacks, 
and "encapsulation" types that actually correspond to file formats, such as the WTAP_ENCAP_NETTL_* types and 
WTAP_ENCAP_CATAPULT_DCT2000, more cleanly this way.

This is actually my second attempt at meeting these goals.  The first left the block dissection in libwiretap,

It's best thought of not as "dissection", which presents the data being dissected as a protocol tree, but as 

Not all the details of how stuff is stored in a capture file are relevant to somebody reading the file to see network 
traffic.  If we were to show all those details, it might clutter up the packet summary list with blocks that don't 
actually correspond to communication events and clutter up the packet dissection with fields that don't correspond to 
information about communication messages.

but it was difficult to implement without making a mess of things.

Probably because the APIs exported by libwiretap were inadequate to the job, as the API currently supplies packets, not 
arbitrary typed records.

The libwiretap (and libwireshark) APIs are not immutable; they can change significantly, and incompatibly, between 
"major" releases.  (Or "super-major" releases, or whatever Wireshark 2.0, if it ever happens, should be called.)

This implementation is much cleaner because it lets the two libraries do what they do best: libwiretap just reads and 
writes record blocks and libwireshark handles the dissection.

Actually, that's *not* what libwiretap was intended to do, and what it's been doing.  What it's been doing is providing 
packets to programs, in a format that abstracts away the particular file format containing the packets.

Perhaps, in order to do a better job of that, it needs to provide records for other events, such as capturing starting 
on an interface (which would be an IDB in pcap-ng; we don't require all IDBs to be at the beginning of the capture, and 
we shouldn't do so, as a capture on the "any" device would ideally provide IDBs for the interfaces on which capturing 
is being done, with new IDBs showing up when interfaces arrive, and with packets labeled by the interface on which they 
arrive), capture statistics being taken (an ISB in pcap-ng), etc.

It probably shouldn't supply SHBs, as they don't correspond to events, and would, I think, just clutter the display.  
The same probably applies to NRBs; they should just show up in the capture by having some addresses resolve to names on 
the network where the capture was being done rather than not resolving or resolving to other names.

  By Date           By Thread  

Current thread: