When Wireshark 1.8.0 is released in the next few months it will introduce two major features: the ability to capture from multiple interfaces at once and the ability to annotate packets. These features have been on the wishlist for years and they will make Wireshark much more useful. They both share dependency on pcap-ng.
Packet comment example
Pcap-ng is Wireshark’s new default file format. It is more complex than its predecessor (pcap) but it’s also more flexible. Along with multiple interface types and annotations you can store host information, extended interface information, and much more. Wireshark has had basic support for pcap-ng for several years now and 1.8.0 will bring it to the forefront.
But there’s a catch. Suppose you sit down at a computer with Wireshark 1.7 or 1.8 installed. What file format will Wireshark use by default? Unfortunately the answer is “It depends.” If this is a fresh install of Wireshark on a new computer you’ll get pcap-ng files. If this is an upgrade from 1.6 or below you’ll get pcap files. If the preferences were changed or copied from another machine the default format will be affected as well.
There’s another catch. Suppose you’ve just saved a capture file and you want to read it using tcpdump, Cascade Pilot, Snort, or any of the dozens of other applications that use the classic pcap file format. What will happen? Again, it depends. If that application has been updated to support pcap-ng or if it’s using a recent version of libpcap it will probably work. Otherwise don’t hold your breath.
If you’re a Wireshark user you might want to try a recent build of Wireshark 1.7 to see the new features and new file format in action. If you’re a developer and your application reads pcap files you’re most likely in for some grief. For that I apologize. You should probably investigate adding pcap-ng support now before your users start complaining.
Despite the migration pains the switch to pcap-ng is long overdue and will make Wireshark more useful to more people.
In “If that application has been updated to support pcap-ng or if it’s using a recent version of libpcap it will probably work.”, “a recent version of libpcap” means “libpcap 1.1.0 or later”. Libpcap 1.1.0 and later versions (the current version is 1.2.1) can read pcap-NG files that have packets only from one interface (the “any” device counts as one interface in this context) or packets from multiple interfaces if all interfaces have the same link-layer header type and snapshot length.
For applications such as tcpdump that use libpcap to read capture files, using libpcap 1.1.0 or later is sufficient – no changes to the application itself are needed. The application won’t see the additional information Gerald refers to, but it will see the packets.
Applications that have their own code to read pcap files aren’t so lucky. (That’s why, when people asked what pcap files look like, I always warned them not to write their own code to read them, but to use libpcap instead. Wrappers for libpcap exist for languages such as Perl, Python, etc.)
Unfortunately, there’s currently no version of WinPcap based on libpcap 1.1.0 or later, so even WinPcap-based applications are out of luck on Windows.
Will it be possible to migrate files from one format to the other? I understand some information may be lost in the process, even if it’s possible to extract packets coming from different interfaces into different .pcap output files.
@Mario You can translate trace files with only one encapsulation type between a variety for formats (not just pcap and pcap-ng) using Wireshark, TShark, editcap, and mergecap. It’s a bit more complicated when multiple encapsulation types are involved. For example the current development version of mergecap returns an error when I try to merge files containing Ethernet, PPP, and IEEE 802.11 packets when it should arguably Just Work. Hopefully we’ll have that fixed for 1.8.0.
HOORAH!
I can’t wait to see how people like the annotations! I’m going through hundreds of trace files adding notes regarding what’s good/bad in those files. This is a FABULOUS feature that I’ve been not-so-patiently waiting for! Congrats Gerald and all the faboo developers!
I need just that. thanks. Keep the good job up.