[Guy Harris <guy@xxxxxxxxxxxx>]

(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@xxxxxxxx> 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 "processing".

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.