[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

On 23 August 2015 at 04:07, Guy Harris <guy@xxxxxxxxxxxx> wrote:

On Aug 22, 2015, at 11:07 AM, Pascal Quantin <pascal.quantin@xxxxxxxxx> wrote:

> DLT_NULL does not work as expected because Npcap is still providing a linktype of type Ethernet instead of Null. I was able to fix the encapsulation of a captue by running editcap -T null dlt_null.pcapng dlt_null_fixed.pcapng.

OK, that's issue 1) in my "why it wouldn't work" list.

The driver and DLL need to provide NdisMediumNull as the medium type to the WinPcap library, so it maps it to DLT_NULL.

> Another issue is that value 23 is not interpreted as IPv6 for Windows, but as Netware IPX/SPX. Should we "steal" the value of another system? For now the NULL dissector supports IPv6 codes for BSD (24), FreeBSD (28) and OS X (30). Guy, what do you think?

That's the issue I mentioned for IPv6; any of those three values should work.

As AF_INET6 is defined as 23 on the Windows platform:

ws2def.h(109): #define AF_INET6        23              // Internetwork Version 6

 Shouldn't code running on that platform, i.e. Wireshark use the appropriate value rather than faking that of another OS?

Or is the issue of value clash between different platforms such that it's impossible to differentiate for a particular capture?

--

Graham Bloice