--- Begin Message ---
On Aug 29, 2022, at 6:13 AM, Christian <ch...@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. 

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.

--- End Message ---
tcpdump-workers mailing list

Reply via email to