Wireshark-dev: Re: [Wireshark-dev] PCAP File Question
From: Ulf Lamping <ulf.lamping@xxxxxx>
Date: Tue, 02 Dec 2008 18:47:36 +0100
Barry Constantine schrieb:
Hello,

My company builds hardware based network analyzers and we are going to capture 1G/10G line rate and store in native pcap format.

If possible, it would be beneficial for us to store some extra information in the packet headers that is unique to our ability to use custom NIC hardware (FCS errors, collisions, etc..).

I looked at the PCAP format and am thinking there are no spare bits / fields to accomplish this. We do plan to enable nsec timestamp option.

Can anyone tell me if there is a way to store additional information in the pcap file (per packet) that would not cause problems for normal Wireshark decoding?

Hi!

First of all, are you aware of: http://wiki.wireshark.org/Development/LibpcapFileFormat ?

The sources to look in Wireshark are basically: wiretap/libpcap.c / .h

There you'll find PCAP_NSEC_MAGIC (0xa1b23c4d) which is the magic number for a pcap file with nsec resolution. Simply use this number and the normal pcap file format and you'll get nanosecond timestamp resolution.

This is the easy part ;-)


Storing additional info is not that easy :-(

a) You could build up your own pcap network link type (I don't know the details here, if it would be possible to put stuff like FCS errors in it). Anyway, in that case you'll need to implement your own special file handling in Wireshark's wiretap and a dissector to display it then.

b) You could also use pcapng http://wiki.wireshark.org/Development/PcapNg which is especially developed to store additional info as you described, but in Wireshark it's in experimental state for quite a while (e.g. you can store special information in that file, but it won't be currently displayed). I wouldn't expect to have big progress in the near future here, unless you spend some effort yourself ...


Looking at the two alternatives I see, I would like to see some effort spend in b), as this would be the much cleaner solution in the long run ...

Regards, ULFL