Re: [tcpdump-workers] DLT type for Libpcap Library
--- Begin Message --- On Aug 29, 2022, at 6:13 AM, Christian 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
Re: [tcpdump-workers] DLT type for Libpcap Library
--- Begin Message --- "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. 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. 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. This is what I understood to do it. My question now is, where should I define my datatype within the libpcap source code? 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. 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? Another question is: how to map the structure(s) in which I define my data types with the symbol in dlt.h? "Map" in what sense? In a way, so that I can define a struct of my header data (with other structs nested maybe) and this struct is asociated as DLT_USER0. Or a something similar? Thanks in advance BR Christian --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] DLT type for Libpcap Library
--- Begin Message --- On Aug 24, 2022, at 11:31 AM, Christian via tcpdump-workers wrote: > Hello everyone, another question that I have is which DLT-type I should use > for my libpcap-module. Since Im writing a module which acquires data from a > kernel module, which in turn has no IP-based packages at all. I have to > define my very own data-type from the base onwards. But because this is > nothing worth to release (maybe only for documentation of an example) I would > rather use a DLT_USERn linktype. But this is only defined on applications > which use pcap lib, not libpcap itself? "Defined" in what sense? The only ways in which the code in the libpcap library "defines" a LINKTYPE_/DLT_ value's format are 1) the code that compiles filter expressions needs to know the format of the data in a packet of a given link-layer type; 2) in order to deal with some link-layer header types where data is in the byte order of the host that wrote the file, libpcap, when reading a file, may have to byte-swap host-byte-order fields from the byte order of the host that wrote the file into the byte order of the host that's reading the file if the two are different, and the remote-pcap protocol code must do so with packet data from a remote server if the byte orders of the two hosts are different. Code that reads pcap and pcapng files, whether with libpcap or independent code for reading pcap and pcapng files, has to provide its *own* code to interpret the packets; if a new LINKTYPE_/DLT_ value is added, neither tcpdump nor Wireshark nor any other program will acquire the ability to handle that file format as a result of any changes to libpcap for that format - new code will have to be written for those programs. I.e., making tcpdump or Wireshark or... handle your data-link type is up to you. You'l have to modify tcpdump or Wireshark, or add a plugin for Wireshark. (And note that code that processes those files doesn't define the formats; they follow the definitions of the formats. The *definitions* of the formats are currently at https://www.tcpdump.org/linktypes.html However, those definitions themselves may refer to other specifications. For example, the format of LINKTYPE_ETHERNET/DLT_EN10MB packet data is really defined by the LAN/MAN Standards Committee of the IEEE Computer Society, not by The Tcpdump Group or the libpcap code.) > Another question is: how to map the structure(s) in which I define my data > types with the symbol in dlt.h? "Map" in what sense?--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
