--- 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.
> 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
https://www.tcpdump.org/linktypes.html
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
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
