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