[tcpdump-workers] DLT type for Libpcap Library

Guy Harris gharris at sonic.net
Mon Aug 29 12:16:53 EDT 2022

On Aug 29, 2022, at 6:13 AM, Christian <chris at argonautx.net> wrote:

>> "Defined" in what sense?
> First of all, I want to define a header, with a magic byte maybe, a time stamp, length of the whole packet and so on. Something which wraps my actual data and which libpcap can recognize or rather expect as data which can be read from my device node.

Unless you will be submitting a pull request to incorporate support for that header into the standard libpcap release, none of that involves us.

> Right now, if I try to connect tcpdump with my device node for reading and receiving data, I only get a:
> listening on kpnode0, link-type 147, snapshot length 262144 bytes
> pcap_stats: this operation isn't properly handelst by that device.

*That* has nothing to do with the definition of the header.

Your pcap module must set the "stats_op" member of the pcap_t structure to point to a function that will provide the results for pcap_stats().  It is currently not doing so.

> My kernel module provides data in packets which is preceded by an header which I deliberately defined for libpcap to recognized as data from MY device.

I mentioned the only places where *libpcap* cares about the header.  If your header provides data in big-endian or little-endian fashion, regardless of the byte order of the machine on which it's running, and if you have no changes to the pcap compiler to add new filter expressions for your packets, then libpcap has nowhere that would need to handle your header and has no place anywhere that would handle your header.

> My question now is, where should I define my datatype within the libpcap source code?

As per the above, perhaps nowhere.

It's not as if you can make *any* change to libpcap that will, by itself, cause tcpdump, or Wireshark, or any other packet analyzer using libpcap to be able to understand your packets.  That's not how libpcap is intended to work, it's not how libpcap is designed to works nd it's not how libpcap works.  Different sniffers have different mechanisms for parsing packets, so it's not as if libpcap could even be designed to do that.

> I associate my data type with the free user defied DLT_USER0, so that is the reason why pcap mentioned link-type 147. Im not stuck on that user defined type. Maybe it's better to define a whole new data type like e.g. DLT_USB_LINUX.

If you do *that*, then you will need to make a publicly-available document that specifies how your header is structured, or provide enough information to allow us to provide such a document, so that we can document it on


Then we will assign a number to your link-layer header type.

However, once that's done, if you want tcpdump to be able to handle your packets, somebody would then have to write code for tcpdump to have it analyze those packets, and if they wanted that to be a standard feature of tcpdump, they'd have to provide a pull request with that change.  The same applies for Wireshark - and the code for tcpdump wouldn't work for Wireshark, as those two programs are structured differently internally.

> Anyway it's nothing destined for release. For now Im just happy if libpcap excepts my header data type to read. Filtering and all this comes later. I guess I have to make changes in my kernel probe, or write a BPF function?

You would have to write *tcpdump* code in order for tcpdump to handle code from your pcap module.

More information about the tcpdump-workers mailing list