I'm trying to read a pcap file that was created with TShark 1.10.6 with libpcap version 1.4.0 on FreeBSD 9.2, and am doing this on Windows 7 with c# in Visual Studio, SharpPcap 4.2, PacketDotNet 0.13 and WinPcap 4.1.3.
The exception being raised is Unable to open offline adapter: bad dump file format, and it occurs in the routine CaptureFileReaderDevice at line:
IntPtr adapterHandle = LibPcapSafeNativeMethods.pcap_open_offline( captureFilename, errbuf);
What's interesting, is that Wireshark Version 1.10.3 on the same system -- and is also using the same version of WinPcap, is able to open the file!
What would cause SharpPcap to be unable to open this file?
EDIT #1:
I looked more closely at WireShark's version information, and apparently it's using a version of WinPcap without AirPcap support. I believe SharpPcap includes AirPcap, so I wonder if that somehow makes a difference.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap.
Also, I'm compiling for a 32-bit output.
EDIT #2:
Using WireShark's Statistics / Summary for the pcap, it displays the following about the capture:
The short answer is that the originating server is generating pcap-ng capture files, and that format is not currently supported by WinPcap, therefore SharpPcap cannot open those files. The current version of Wireshark, however, does support pcap-ng capture files.
The gory details of what led me to that answer:
I found the Libpcap File Format in the Wireshark docs, and according to the Global Header section, I've got a dump file containing the magic number 0x4d3c2b1a (as displayed on my Windows 7 system).
The doc says:
For nanosecond-resolution files, the writing application writes 0xa1b23c4d, with the two nibbles of the two lower-order bytes swapped, and the reading application will read either 0xa1b23c4d (identical) or 0x4d3cb2a1 (swapped).
None of these match this magic number, so I ran the file command for the pcap file on the originating FreeBSD system and it reported:
em0.pcap: pcap-ng capture file - version 1.0
So I took a look at /usr/share/misc/magic on that server and found the pcap-ng entry:
#
# "pcap-ng" capture files.
# http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html
# Pcap-ng files can contain multiple sections. Printing the endianness,
# snaplen, or other information from the first SHB may be misleading.
#
0 ubelong 0x0a0d0d0a
>8 ubelong 0x1a2b3c4d pcap-ng capture file
>>12 beshort x - version %d
>>14 beshort x \b.%d
0 ulelong 0x0a0d0d0a
>8 ulelong 0x1a2b3c4d pcap-ng capture file
>>12 leshort x - version %d
>>14 leshort x \b.%d
Which pointed me to the PCAP Dump File Format (see the Section Header Block description).
And hexdump of the pcap file showed:
0000000 0d0a 0a0d 0070 0000 3c4d 1a2b 0001 0000
0000010 ffff ffff ffff ffff 0003 0017 7246 6565
0000020 5342 2044 2e39 2d32 4552 454c 5341 2d45
which confirms that: