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: "Gianluca Varenni" <gianluca.varenni@xxxxxxxxxxxx>
Date: Thu, 27 Sep 2007 13:02:27 -0700
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...

Replies embedded below.

Have a nice
GV

----- Original Message ----- From: "Ulf Lamping" <ulf.lamping@xxxxxx>
To: "Developer support list for Wireshark" <wireshark-dev@xxxxxxxxxxxxx>
Sent: Thursday, September 27, 2007 12:26 PM
Subject: Re: [Wireshark-dev] [ntar-workers] Extending Wireshark libpcap format support, or start using pcapng now ?!?


Gerald Combs schrieb:
Pekka Pietikainen wrote:

Oh. If you add a new DLT_ value, having it in a way that is extensible
+ has a way of saying "Here's the raw packet data. It's plain old
DLT_EN10MB". And the next one might be 802.11 and the next one 802.11 with
a radiotap header.

Ugliest hack I've seen for a quite a while ;-)

I agree. It's putting another scary hack into the old tcpdump/libpcap file format, which is kinda obsolete. But it's also what we do (currently) for PPI. And I'm the one who added PPI support to libpcap, so feel free to yell at me :-P

The Per-Packet Information header (PPI) does exactly that:
http://www.cacetech.com/documents/
Hmmm, after I took a deep look at the pcapng format I guess this would
be the way to go for me. As it contains all stuff that I need (and some
optional stuff that I don't need to implement as a first step) ;-)

There are things that PPI is missing, e.g. meta information if captured
from more than one capture interface (which is one of the things I need
first).

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. So no annotations like "oh, this is an interesting packet". pcap-ng/NTAR is a trace file format. I would consider pcap-ng/ntar a super-set of PPI.


I see that bringing pcapng to life in Wireshark will be some effort to
do. However, I tend to do things right so I can build on that cleanly.


So what's the state of pcapng? The spec seems ok, at least for the parts
I'm interested in. Is there a "real world" implementation (except for

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.

the ntar library, which is low level "only")?

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).

Are there some example
capture files somewhere?

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).

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.

Have a nice day
GV




Regards, ULFL
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev