Re: DLT type for Libpcap Library

[Guy Harris via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Guy Harris <gharris () sonic net>
>
> Date: Mon, 29 Aug 2022 09:16:53 -0700
>
> On Aug 29, 2022, at 6:13 AM, Christian <chris () 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