Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] [ntar-workers] Extending Wireshark libpcap format support, o

From: Ulf Lamping <ulf.lamping@xxxxxx>
Date: Thu, 27 Sep 2007 23:01:47 +0200
Gianluca Varenni schrieb:
First of all, sorry for taking a bit of time to answer this thread, I was working on libpcap/WinPcap. libpcap 1.0 is planned to come out soon...
No problem, a few hours is still a good value ;-)
It's true. Consider that PPI and pcap-ng/ntar have different objectives (as written in the PPI spec): PPI is used to append meta-information from packets captured from a live source.
Yes, I understand. But at least some of the meta info (like the capture interface info) is required already to be saved at capture time. So pcapng would in fact be a capture file format.
So no annotations like "oh, this is an interesting packet".
Yes, that would be done *after* the life capture was finished - and probably on a copy of the original capture file.
pcap-ng/NTAR is a trace file format. I would consider pcap-ng/ntar a super-set of PPI
ACK

PPI might even get obsolete once pcapng is implemented in Wireshark and has gained wide acceptance.
The spec at www.winpcap.org/ntar is pretty stable. Back in March 2006 I cleaned up the spec (some items were not clear) and added some appendices. There are still things missing, in particular the definition of blocks for easy navigation in the file.
I have reviewed that doc for a few hours today. Now I have a printout with lot's of minor comments probably worth to be included. Most of them is about clarifying stuff and make the document easier to read (well, and some typos). The only really questionable thing I found was the name resolution block. I don't see a reason to have optional block content and options as well - in fact it was hard to understand. Why not use only option fields there?

I guess it would be a good idea to include my review comments into the spec. What would be best way to get them included?
As far as I know, no. What do you mean by "low level"? A more user-friendly API like "OpenFile/ReadPacket/WritePacket/CloseFile"? One of the main problems I had when developing NTAR was the richness and complexity of the format (e.g. the problem of multiple sections in a file, the support for multiple interfaces within a section).
Yes, I guess one of the problematic things to include pcapng into Wireshark is to find a good interface between libwiretap and Wireshark (or probably no interface at all). There are a lot of new concepts in pcapng that has no counterpart in the current Wireshark implementation.
I can definitely create some trace files, either synthetic or real (with ntar). A friend of mine developed a simple app to convert libpcap files into pcap-ng files. I need to have a look at it. It depends if you want simple captures or something using the various features of pcap-ng (multiple interfaces, multiple sections, different byte order in the file).
Some simple example files would be enough, it's only to find a starting point (but I'm not in a hurry about that).
NTAR is still alive, but in the last year or so I didn't have any time to work on it. In order to work within wireshark, the big missing feature is relative to random access in the file. I have some code on my machine to deal with that, but it doesn't work properly. I might have some time to work on it in the next weeks.
Yes, we need a way to handle random access in the file somehow.

Regarding changes in the file itself while it's open: I guess the best way to include pcapng into WS is to treat the capture file read only (as today). Additional stuff has to be kept in memory (user comments, name resolvings, ...) until the capture file is saved to disk. After the file is saved, it has to be read completely again, so file offsets of packet data is "updated" in memory.

Regards, ULFL