[Winpcap-users] Using DLT_USERx link type for unknown protocol
guy at alum.mit.edu
Tue Jun 5 18:33:40 GMT 2007
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
> 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 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
> - 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.)
More information about the Winpcap-users