Wireshark · Wireshark-dev: Re: [Wireshark-dev] Npcap 0.04 call for test

[Guy Harris <guy@xxxxxxxxxxxx>]

On Aug 21, 2015, at 10:55 PM, Yang Luo <hsluoyb@xxxxxxxxx> wrote:

> Npcap 0.04 r5 has added the DLT_NULL protocol support, you need to check the "Use DLT_NULL protocol as loopback packets' link layer instead of Ethernet II" option when installing (default is not checked). The problem is Wireshark didn't recognize these loopback packets correctly, I think Windows is little-endian system, so "02 00 00 00" protocol header should be right.

Windows machines are all little-endian, so, on Windows, a DLT_NULL header should be 4 bytes long, with the bytes being, in order:

	0x02, 0x00, 0x00, and 0x00 for an IPv4 packet;

	an appropriate value for an IPv6 packet.
	
Immediately following those four bytes should be an IPv4 packet or an IPv6 packet.

The tricky part is the "appropriate value".  The assumption in tcpdump and Wireshark is that a DLT_NULL capture comes from a BSD-flavored OS, so they only check for the values:

	decimal 24 - the value of AF_INET6 in NetBSD, OpenBSD, and BSD/OS;

	decimal 28 - the value of AF_INET6 in FreeBSD and DragonFly BSD;

	decimal 30 - the value in OS X, iOS, and anything else Darwin-based.

So the appropriate values for IPv6 are:

	0x18, 0x00, 0x00, and 0x00;

	0x1C, 0x00, 0x00, and 0x00;

	0x1E, 0x00, 0x00, and 0x00.

You could use any of those; I don't have any preference.

So if you're not using one of those values, that would explain why IPv6 packets aren't being recognized.  If it's not recognizing IPv4 packets, then:

	1) make sure you're supplying the right value for DLT_NULL, i.e. 0, as the return value of pcap_datalink();

	2) make sure that the first four bytes of IPv4 packets are, in order, 0x02, 0x00, 0x00, and 0x00, followed *immediately* by an IPv4 header and the rest of the IPv4 packet.