SharpPcap 4.2 with WinPcap 4.1.3 gives "Unable to open offline adapter: bad dump file format"

Question

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:

• OS: FreeBSD 9.2-RELEASE-p10
• Capture application: Dumpcap 1.10.6 (Git Rev Unknown from unknown)

Answer 1

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:

1. this is indeed, a next-generation pcap file -- as the block header starts with Block Type = 0x0A0D0D0A (displayed as 0d0a 0a0d), and
2. the header contains the pcap-ng magic number 0x1a2b3c4d (displayed as 3c4d 1a2b).

Answer 2

Copy WinPcap DLLs from this package to your application folder. It should solve issue.

Answer 3

As a short term measure, I downloaded the latest version of Wireshark (v2.0) and opened then save the file as Redhat 6.1 *.tcpdump and SharpPcap read it fine.