[Winpcap-users] Using DLT_USERx link type for unknown protocol

[Guy Harris]

c-keel at gmx.de wrote:

> I want to use a protocol analyzer to analyze a protocol that WinPcap is not
> able to capture.

"Not able to capture" for what reason?

Is it supported by NDIS, which is the standard mechanism used by WinPcap 
to capture packets (just as, on various UN*Xes, libpcap will use BPF, or 
DLPI, or PF_PACKET sockets, or...)?  Or will you have to add an 
additional capture mechanism, similar to the DAG, Linux Bluetooth and 
USB, and Intel/Septel SS7 card mechanisms supported on some platforms 
with libpcap?

> Because of that I want to adapt the WinPcap libraries to
> fit my needs. I'd like to do this with as less effort as possible. I want to
> use the DLT_USER0 for my protocol. The protocol defines layer 1 and 2 of the
> OSI model and as already mentioned, WinPcap has no idea of it by now.
> 
> The problem is that I have to tell wpcap.dll that the link type of my
> protocol is DLT_USER0. I thought I could do that in PacketGetNetType of the
> packet.dll. 

packet.dll is used *ONLY* with NDIS.  If you can't capture traffic for 
your protocol with NDIS, that's not the code you'd change.

> But there are 2 problems with that: 
> - I can't set DLT_USER0 in PacketGetNetType (am I already wrong here?)

Possibly.  PacketGetNetType() is part of the NDIS-capture code path; if 
you're not going to capture using NDIS, that won't work. 
PacketGetNetType() doesn't return DLT_ values, it returns NDIS medium 
type values.

> - even if I could do this, unfortunately pcap_open_live from wpcap.dll calls
> this function and after calling this function it checks the link type with
> the effect that the unknown DLT_USER0 would be assumed to be ethernet (But
> my protocol is neither ethernet nor ethernet based).

Again, if you aren't going to be using NDIS to capture traffic, you 
shouldn't be modifying packet.dll at all.  You should, instead, do the 
same thing that's done for other special capture mechanisms - modify 
pcap_open_live() in pcap-win32.c to recognize the special device names 
you provide for whatever type of device you're capturing on, and call 
your special open routine, which would set the other function pointers 
in the pcap_t structure to point to the special functions (the "XXX_op" 
pointers) for your device.

> So what is the purpose of the DLT_USERx link types

They're for use when a site needs a link-layer type and, for whatever 
reason, doesn't want to request an official link-layer type from 
tcpdump-workers at tcpdump.org.  The tcpdump-workers group guarantees that 
it will never assign any of the DLT_USERx values to any official DLT_ 
type, so there will never be any collisions between the "user-reserved" 
types and official types.

However, it, and the Wireshark development group, also guarantee that 
neither tcpdump nor Wireshark will ever assign any particular dissectors 
for the DLT_USERx (and corresponding WTAP_ENCAP_USERx values in 
Wireshark), so you will have to maintain your own special versions of 
tcpdump and Wireshark (or your own special plugins for, or configuration 
of, Wireshark), and if you send your captures to a site that doesn't 
have your specialized software, they won't be able to read it - and they 
might have assigned *their* own special protocols to the same DLT_USERx 
value to which you assigned your protocol, so *they* might have 
specialized versions of tcpdump/Wireshark/whatever that will 
mis-interpret your captures.

I.e., use a DLT_USERx value only if you will be keeping the captures 
within your organization, *not* if you plan to send captures with that 
value outside your organization.

> and how should one use
> them? And what about the various other link type values defined in
> pcap-bpf.h? How are they assigned?

They are assigned by tcpdump-workers at tcpdump.org (which usually means by 
me, Hannes Gredler, or Michael Richardson - usually me).  Requests for 
an official DLT_ value should be sent to tcpdump-workers at tcpdump.org, 
for public discussion.

> I'd like to tell the application that it is DLT_USER0. I'd like to do that
> by only changing the packet.dll  because there are some changes I have to
> make in it.

Don't focus on that - there's no reason to avoid changing wpcap.dll as 
well, if you won't be capturing using NDIS.

(Yes, I know that the DAG support for Windows appears to be done in 
packet.dll.  I suspect it could be done just as well - and perhaps 
somewhat more simply - in wpcap.dll, as the DAG support for Linux and 
FreeBSD are done; that's why I put in the whole XXX_op thing into the 
pcap_t structure, to support multiple capture mechanisms.)