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
[tcpdump-workers] DLT type for Libpcap Library
--- Begin Message --- 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? Another question is: how to map the structure(s) in which I define my data types with the symbol in dlt.h? Thanks for your help again BR Christian --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] configure script problem while working on extention
--- Begin Message --- Maybe this should be also mentioned within the libpcap module howto? https://www.tcpdump.org/libpcap-module-HOWTO.html BR Christian Make sure that libpcap.a includes pcap-kpnode.o, by making sure that pcap-kpnode.c is in the list of source modules to be compiled and included in libpcap. For Makefile.in, that means adding it to MODULE_C_SRC = @MODULE_C_SRC@ after @MODULE_C_SRC@ so you have MODULE_C_SRC = @MODULE_C_SRC@ pcap-kpnode.c --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] configure script problem while working on extention
--- Begin Message --- Make sure that libpcap.a includes pcap-kpnode.o, by making sure that pcap-kpnode.c is in the list of source modules to be compiled and included in libpcap. For Makefile.in, that means adding it to MODULE_C_SRC = @MODULE_C_SRC@ after @MODULE_C_SRC@ so you have MODULE_C_SRC = @MODULE_C_SRC@ pcap-kpnode.c And this solved the problem, now I can configure and build tcpdump. Even with my extensions Thank you very much. BR Christian --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] configure script problem while working on extention
--- Begin Message --- configure:6075: checking for pcap_loop configure:6075: gcc -o conftest -g -O2 conftest.c -L/usr/local/lib -Wl,-rpath,/usr/local/lib -lpcap >&5 /usr/bin/ld: /usr/local/lib/libpcap.so: undefined reference to `scsimon_create' /usr/bin/ld: /usr/local/lib/libpcap.so: undefined reference to `scsimon_findalldevs' Has the pcap.c in the libpcap that was built and installed in /usr/local/lib been modified to add a pcap module "scsimon", in addition to your "kpnode" module? If so, is there a pcap-scsimon.c, or whatever, that defines them, and was it also added to Makefile.in when the library was built? My dumbness again, scsimon is just a synonym for kpnode. This is the actual latest config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by tcpdump configure 5.0.0-PRE-GIT, which was generated by GNU Autoconf 2.69. Invocation command line was $ ./configure ## - ## ## Platform. ## ## - ## hostname = rockpro64 uname -m = aarch64 uname -r = 5.10.76-rockchip64 uname -s = Linux uname -v = #trunk SMP PREEMPT Thu Oct 28 16:53:35 EDT 2021 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = aarch64 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: . PATH: /usr/local/bin PATH: /usr/bin PATH: /bin PATH: /usr/local/games PATH: /usr/games ## --- ## ## Core tests. ## ## --- ## configure:2463: checking build system type configure:2477: result: aarch64-unknown-linux-gnu configure:2497: checking host system type configure:2510: result: aarch64-unknown-linux-gnu configure:2655: checking for gcc configure:2671: found /usr/bin/gcc configure:2682: result: gcc configure:2911: checking for C compiler version configure:2920: gcc --version >&5 gcc (Debian 10.2.1-6) 10.2.1 20210110 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2931: $? = 0 configure:2920: gcc -v >&5 Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/10/lto-wrapper Target: aarch64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.1 20210110 (Debian 10.2.1-6) configure:2931: $? = 0 configure:2920: gcc -V >&5 gcc: error: unrecognized command-line option '-V' gcc: fatal error: no input files compilation terminated. configure:2931: $? = 1 configure:2920: gcc -qversion >&5 gcc: error: unrecognized command-line option '-qversion'; did you mean '--version'? gcc: fatal error: no input files compilation terminated. configure:2931: $? = 1 configure:2951: checking whether the C compiler works configure:2973: gcc conftest.c >&5 configure:2977: $? = 0 configure:3025: result: yes configure:3028: checking for C compiler default output file name configure:3030: result: a.out configure:3036: checking for suffix of executables configure:3043: gcc -o conftest conftest.c >&5 configure:3047: $? = 0 configure:3069: result: configure:3091: checking whether we are cross compiling configure:3099: gcc -o conftest conftest.c >&5 configure:3103: $? = 0 configure:3110: ./conftest configure:3114: $? = 0 configure:3129: result: no configure:3134: checking for suffix of object files configure:3156: gcc -c conftest.c >&5 configure:3160: $? = 0 configure:3181: result: o configure:3185: checking whether we are using the GNU C compiler configure:3204: gcc -c conftest.c >&5 configure:3204: $? = 0 configure:3213: result: yes configure:3222: checking whether gcc accepts -g configure:3242: gcc -c -g conftest.c >&5 configure:3242: $? = 0 configure:3283: result: yes configure:3300: checking
Re: [tcpdump-workers] configure script problem while working on extention
--- Begin Message --- Am 15.08.22 um 20:09 schrieb Guy Harris: What are the contents of config.log? Ohhh f**. Ok sorry it's moday afternoon here it comes: This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by tcpdump configure 5.0.0-PRE-GIT, which was generated by GNU Autoconf 2.69. Invocation command line was $ ./configure ## - ## ## Platform. ## ## - ## hostname = debian0 uname -m = x86_64 uname -r = 5.18.0-3-amd64 uname -s = Linux uname -v = #1 SMP PREEMPT_DYNAMIC Debian 5.18.14-1 (2022-07-23) /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = x86_64 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/bin PATH: /usr/bin PATH: /bin PATH: /usr/local/games PATH: /usr/games ## --- ## ## Core tests. ## ## --- ## configure:2463: checking build system type configure:2477: result: x86_64-pc-linux-gnu configure:2497: checking host system type configure:2510: result: x86_64-pc-linux-gnu configure:2655: checking for gcc configure:2671: found /usr/bin/gcc configure:2682: result: gcc configure:2911: checking for C compiler version configure:2920: gcc --version >&5 gcc (Debian 12.1.0-8) 12.1.0 Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2931: $? = 0 configure:2920: gcc -v >&5 Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 12.1.0-8' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-12-WXbu70/gcc-12-12.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-WXbu70/gcc-12-12.1.0/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.1.0 (Debian 12.1.0-8) ... rest of stderr output deleted ... configure:2931: $? = 0 configure:2920: gcc -V >&5 gcc: error: unrecognized command-line option '-V' gcc: fatal error: no input files compilation terminated. configure:2931: $? = 1 configure:2920: gcc -qversion >&5 gcc: error: unrecognized command-line option '-qversion'; did you mean '--version'? gcc: fatal error: no input files compilation terminated. configure:2931: $? = 1 configure:2951: checking whether the C compiler works configure:2973: gcc conftest.c >&5 configure:2977: $? = 0 configure:3025: result: yes configure:3028: checking for C compiler default output file name configure:3030: result: a.out configure:3036: checking for suffix of executables configure:3043: gcc -o conftest conftest.c >&5 configure:3047: $? = 0 configure:3069: result: configure:3091: checking whether we are cross compiling configure:3099: gcc -o conftest conftest.c >&5 configure:3103: $? = 0 configure:3110: ./conftest configure:3114: $? = 0 configure:3129: result: no configure:3134: checking for suffix of object files configure:3156: gcc -c conftest.c >&5 configure:3160: $? = 0 configure:3181: result: o configure:3185: checking whether we are using the GNU C compiler configure:3204: gcc -c conftest.c >&5 configure:3204: $? = 0 configure:3213: result: yes configure:3222: checking whether gcc accepts -g configure:3242: gcc -c -g conftest.c >&5 configure:3242: $? = 0 configure:3283: result: yes configure:3300: checking for gcc option to accept ISO C89 configure:3363: gcc -c -g -O2 conftest.c >&5 configure:3363: $? = 0 configure:3376: result: none needed configure:3396: checking for gcc option to accept ISO C99 configure:3545: gcc -c -g -O2 conftest.c >&5 configure:3545: $? = 0 configure:3558: result: none needed
Re: [tcpdump-workers] configure script problem while working on extention
--- Begin Message ---
Then I opened the tcpdump.zip archive
(.zip? Not .tar.gz? The current releases from
https://www.tcpdump.org/index.html#latest-releases
are provided in .tar.gz form, as are all the other release in
https://www.tcpdump.org/release/
Gzipped tarballs are probably easier to extract on a UN*X, as they're likely to have either a
version of tar that reads gzipped files or have gzcat and tar; to unpack a zip archive requires a
command such as unzip or a GUI tool that unpacks zip archives. Perhaps you mean ".zip
archive" in a metaphorical sense of "some form of archive"? Or is this a ZIP
archive provided by somebody other than tcpdump.org?)
Okay I was not quite consequent, got the sources of libpcap from git but
tcpdump from the zip archive of github. But today I tried it again with
git. And this time I didn't put it into the libpcap directory but into
the parent directory, so that they have the same parent. But the result
remains the same.
No, they're not attached. Either you forgot to attach them or some mail
software stripped the attachments. Michael/Denis/François - do we strip
attachments at any point before sending messages to the list?
Okay bad idea of mine, attached files are hard to comment in a list anyway.
Now I paste it here:
pcap-kpnode.c
#include
#include "pcap-int.h"
#include
#include
#include
#define LINUX_KPNODE_DEV "/dev/kpnode0"
#define KPNODE_IFACE "kpnode"
#define KPNODE_LINE_LEN 4096
struct pcap_kpnode {
};
/* facility to add an USB device to the device list*/
static int
kpnode_dev_add(pcap_if_list_t *devlistp, int n, char *err_str)
{
char dev_name[10];
char dev_descr[30];
snprintf(dev_name, 10, KPNODE_IFACE"%d", n);
/*
* XXX - is there any notion of "up" and "running"?
*/
/*
* As this refers to all buses, there's no notion of
* "connected" vs. "disconnected", as that's a property
* that would apply to a particular USB interface.
*/
if (add_dev(devlistp, dev_name,
PCAP_IF_CONNECTION_STATUS_NOT_APPLICABLE,
"Open kpnode interface ", err_str) == NULL)
return -1;
return 0;
}
int
kpnode_findalldevs(pcap_if_list_t *devlistp, char *err_str)
{
char kpnode_dev[PATH_MAX];
char *kpnode_prefix;
//size_t usb_mon_prefix_len;
//struct dirent* data;
// int ret = 0;
//DIR* dir;
//int n;
//char* name;
/*
* We require 2.6.27 or later kernels, so we have binary-mode support.
* What do the device names look like?
* Split LINUX_USB_MON_DEV into a directory that we'll
* scan and a file name prefix that we'll check for.
*/
pcap_strlcpy(kpnode_dev, LINUX_KPNODE_DEV, sizeof kpnode_dev);
kpnode_prefix = strrchr(kpnode_dev, '0');
if (kpnode_prefix == NULL) {
/*
* This "shouldn't happen". Just give up if it
* does.
*/
return 0;
}
*kpnode_prefix++ = '\0';
//usb_mon_prefix_len = strlen(usb_mon_prefix);
/*
* Open the directory and scan it.
*/
// dir = opendir(usb_mon_dir);
// if (dir != NULL) {
// while ((ret == 0) && ((data = readdir(dir)) != 0)) {
// name = data->d_name;
//
// /*
// * Is this a usbmon device?
// */
// if (strncmp(name, usb_mon_prefix, usb_mon_prefix_len) != 0)
// continue; /* no */
//
// /*
// * What's the device number?
// */
// if (sscanf([usb_mon_prefix_len], "%d", ) == 0)
// continue; /* failed */
//
// ret = kpnode_dev_add(devlistp, n, err_str);
// }
//
// closedir(dir);
kpnode_dev_add(devlistp, 0, err_str);
return 0;
} /* kpnode_findalldevs */
pcap_t *
kpnode_create(const char *device, char *ebuf, int *is_ours)
{
const char *cp;
char *cpend;
long devnum;
pcap_t *p;
/* Does this look like a USB monitoring device? */
cp = strrchr(device, '/');
if (cp == NULL)
cp = device;
/* Does it begin with USB_IFACE? */
if (strncmp(cp, KPNODE_IFACE, sizeof KPNODE_IFACE - 1) != 0) {
/* Nope, doesn't begin with USB_IFACE */
*is_ours = 0;
return NULL;
}
/* Yes - is USB_IFACE followed by a number? */
cp += sizeof KPNODE_IFACE - 1;
devnum = strtol(cp, , 10);
if (cpend == cp || *cpend != '\0') {
/* Not followed by a number. */
*is_ours = 0;
return NULL;
}
if (devnum < 0) {
/* Followed by a non-valid number. */
*is_ours = 0;
return NULL;
}
/* OK, it's probably ours. */
*is_ours = 1;
p = PCAP_CREATE_COMMON(ebuf, struct pcap_kpnode);
if (p == NULL)
return (NULL);
//p->activate_op = usb_activate;
return (p);
} /* kpnode_create */
and pcap-kpnode.h
int kpnode_findalldevs(pcap_if_list_t *devlistp, char *err_str);
pcap_t *kpnode_create(const char *device,
[tcpdump-workers] configure script problem while working on extention
--- Begin Message ---
I pick up this thread of mine again from 7th march of this year
(wireshark extension for a Kernel Module (like Usbmon) ) enhanced with
a configure issue, which was discussed lot of times ( tcpdump configure
script doesn't correctly handle static builds ). But Im not sure, if
this is a real issue for github.
In my case, I was able to build Tcpdump with these steps:
Get libpcap with git, step into the directory invoke: ./configure
--disable-dbus --without-dbus --without-dpdk --disable-rdma
then make and make install.
Then I opened the tcpdump.zip archive within the libpcap directory. step
into the directory, call ./configure and it build. success!
Then I took my changes for libpcap from march, a pcap-kpnode.c and
pcap-kpnode.h (attached)
further I added into pcap.c:
100: #include "pcap-kpnode.h"
690: {kpnode_findalldevs, kpnode_create }
and in Makefile.in I added my sourcefiles
after that, I evoked make clean and the configure call again like that
one before with all these switches. Then make and make install. The
library was successfully build, also with my changes. Then I unzipped
the tcpdump archive again to start from scratch and this time
./configure leads to that error message about no pcap_loop support. I
added the config.log as well.
/usr/local/bin/pcap-config --static --libs puts out -L/usr/local/lib -lpcap
As expected my build environment is a Debian unstable system, before
that I tried it on a Pine64 board with Armbian 22.05.3 Bullseye
What could be the problem here? I have some changes for tcpdump for
processing my kpnode packages, but I did not apply them for now. Because
the tcpdump from upstream was not able to configure, even without my
changes.
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] wireshark extension for a Kernel Module (like Usbmon)
--- Begin Message --- forget to evoke autoconf again, now it's within the library and I have to do the next step. Thank you so far BR Christian > ___ > tcpdump-workers mailing list > tcpdump-workers@lists.tcpdump.org > https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] wireshark extension for a Kernel Module (like Usbmon)
--- Begin Message --- Hello Guy, thank you for your help. >> further down: >> #ifdef PCAP_SUPPORT_KPNODE >> || strstr(device, "kpnode") != NULL >> #endif > That's presumably in pcap_lookupnet(); if so, that's the correct way to add > kpnode there. > > (I need to change that to use a better mechanism, so that it's the > responsibility of the module to handle that, rather than hardcoding module > information in a function.) In general, that is my perception of the whole pcap library. There are so many different kinds of interfaces, which have to be recognized. Device nodes like usbnode and mine kernelprobe, IP interfaces like eth and lo which cannot be represented as simple character node devices, and many more. But there must be at least one function to parse the system of all these interfaces which can be scanned? I searched the source code of each appearance of usbmon, and tried to do something similar. >> If you're just doing it on your own, and you will be using this modified >> libpcap only on systems where kpnode is available, the easiest way to do it >> would be to leave out the #ifdef`s for PCAP_SUPPORT_KPNODE. I did it, leave out the #ifdef, so that my symbols are defined anyway. > >> After execution of the configure script I put >> manually my files into the EXTRA_DIST list. > EXTRA_DIST is useful only if you plan to do "make releasetar" to make a > source tarball - and if you want to do *that*, add it to Makefile.in, not to > Makefile, so you won't have to fix Makefile manually. It was a hack of mine, to add my sourcecode files into the list of files for building the project. Now I changed this by adding MODULE_C_SRC="$MODULE_C_SRC pcap-kpnode.c" > >> But so far, when I build the pcap library not even the symbol kpnode >> appears in the binary > Do you mean that a symbol named "kpnode" doesn't appear in the (shared) > library binary? > > Or do you mean that symbols with "kpnode" in their names, such as > kpnode_findalldevs and kpnode_create, don't appear in the library binary? > > If so, are you looking for *exported* symbols or *all* symbols? On most > platforms - and Linux is one such platform - we compile libpcap so that > *only* routines we've designated as being libpcap APIs are exported by the > library; others are internal-only symbols. For example, if I do > It didn't appear at all within the symbol list, neither with nm nor with readelf or objdump. No symbols which starts with "kpnode" at all. > > 4$ nm libpcap.so.1.11.0-PRE-GIT | egrep pcap_open > 00012ea0 T pcap_open > 0001bdc0 T pcap_open_dead > 0001bce0 T pcap_open_dead_with_tstamp_precision > 0001b9a0 T pcap_open_live > 0002cf20 T pcap_open_offline > 0001ab10 t pcap_open_offline_common > 0002cde0 T pcap_open_offline_with_tstamp_precision > 00015b70 t pcap_open_rpcap > > symbols such as pcap_open(), pcap_open_live(), pcap_open_offline(), etc. > *are* exported symbols - they're shown with 'T'. > > So, to check for symbols, you should do "nm" and pipe the result to "egrep > kpnode_". Those symbols should show up with 't', not 'T', as they aren't > part of the API - kpnode_findalldevs() should automatically get called if a > program calls pcap_findalldevs() (e.g., if tcpdump is compile with this > library, "tcpdump -D" should cause kpnode_findalldevs() to be called, and > should show the kpnode device(s)), and kpnode_create() should automatically > get called if a program calls pcap_create() (or pcap_open_live()) on a kpnode > device (e.g., if tcpdump is compile with this library, "tcpdump -i kpnode", > or whatever the name of a kpnode device is, should cause kpnode_create() to > be called, and should capture on that kpnode device if run with sufficient > privileges to do so). After my recent changes (adding MODULE_C_SRC, leave out the #ifdef ...) I get my symbols listed with nm, but they are flagged with an U as undefined. So I presume they are defined as symbols, but not assigned to any function? When I install and use this latest build with tcpdump -D, I get an "undefined symbol: kpnode_findalldevs" which figures, I think. It says: tcpdump: symbol lookup error: /lib/aarch64-linux-gnu/libpcap.0.8: undefined symbol: kpnode_findalldevs > > You *also* need to modify configure.ac so that, if it sets > PCAP_SUPPORT_KPNODE, it also does > > MODULE_C_SRC="$MODULE_C_SRC pcap-kpnode.c" Did so. > > to add pcap-kpnode.c to the the list of libpcap module source files. Not > only will that cause it to be compiled into an object file, it will also > cause that object file to be included in the library. > > Given that you got a pcap-kpnode.o file, then either you compiled it manually > yourself, or you made a change of that sort, or you manually added > pcap-kpnode.c to the list of module source files in the Makefile after > configuring, or you manually added it to the list of module source files in > Makefile.in *before*
[tcpdump-workers] wireshark extension for a Kernel Module (like Usbmon)
--- Begin Message ---
hello out there, I created a kernel probe module and I want to watch the
outputs of that module with pcap/Wireshark or tcpdump... Just like
usbmon. My prefered tool is dumpcap. So I defined a char device in the
dev-directory /dev/kpnode from which the pcap interface can read the
output of that module. In order to enable reading, I started to place a
handler function into libpcap:
In pcap.c I put in
#ifdef PCAP_SUPPORT_KPNODE
#include "pcap-kpnode.h"
#endif
and later:
#ifdef PCAP_SUPPORT_KPNODE
{ kpnode_findalldevs, kpnode_create },
#endif
further down:
#ifdef PCAP_SUPPORT_KPNODE
|| strstr(device, "kpnode") != NULL
#endif
The functions kpnode_findalldevs and kpnode_create are in my files
pcap-kpnode.c and pcap-kpnode.h. They are not finished yet but the
subject of this mail is for now, how to connect these functions into
libpcap and Wireshark so that they are evoked if a device /dev/kpnode
emerges.
Further I added an entry to configure.ac: AC_DEFINE(PCAP_SUPPORT_KPNODE,
1, [target host supports Linux kpmode])
Im not sure if editing the autoconf input file is too much, because I
don't want to commit my changes to other platforms, it's just a small
project of my own. But there are also some entries for USBMON in e.x.
CMakeList.txt and more. After execution of the configure script I put
manually my files into the EXTRA_DIST list.
But so far, when I build the pcap library not even the symbol kpnode
appears in the binary but there is an object file of my handler file
pcap-kpnode.c. So my changes are not in the library. I use the master
branch sources of last week and gcc version 11.2.0 of Debian testing.
What did I miss to integrate my handlers into pcap library?
Thank you in advance
BR /Christian
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
