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

[c-keel at gmx.de]

> > 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?

It is not able to capture the protocol because it is not supported 
by NDIS (and I guess exactly that is the problem I did not realize first).
Second, the hardware is very special and also the drivers for it. Special 
also means that it is not sold as often as an ethernet card.

I'm going to add an additional capture mechanism, that's true.

> > 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.

OK. As I already said, the *ONLY* in this sentence was the thing I did 
not realize.

> > 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.

Yes, I came to the same result. Thank you very much for your
expert help and knowledge. 

> > 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.) 

Again, thank you for your help. I'm quite new to this topic and 
working in it is not very easy.

> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users