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 --- On Aug 16, 2022, at 12:49 PM, Christian wrote: >>> 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 I.e., that other log was from some *earlier* attempt to configure tcpdump? > configure:5389: checking whether to look for a local libpcap > configure:5410: result: yes OK, so *this* time you're building with the library from a local build, rather than with a library that was installed. > configure:5415: checking for local pcap library > configure:5445: result: ../libpcap/libpcap.a > configure:5908: checking for pcap-config > configure:5926: found ../libpcap/pcap-config > configure:5938: result: ../libpcap/pcap-config > configure:6075: checking for pcap_loop > configure:6075: gcc -o conftest -g -O2 conftest.c ../libpcap/libpcap.a >&5 > /usr/bin/ld: ../libpcap/libpcap.a(pcap.o):(.data.rel.ro+0x10): undefined > reference to `kpnode_findalldevs' > /usr/bin/ld: ../libpcap/libpcap.a(pcap.o):(.data.rel.ro+0x18): undefined > reference to `kpnode_create' ... > which shows the actual problem, if I evoke nm libpcap.so.1-11.0-PRE-GIT | > grep kpnode > > I got U kpnode_create > > U kpnode_findalldevs > > So the symbols are known but seems to be undefined. How to fix this? 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 --- 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 --- On Aug 15, 2022, at 1:37 PM, Christian wrote: > 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?--- 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 --- 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 --- What are the contents of config.log? --- 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 ---
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,
Re: [tcpdump-workers] configure script problem while working on extention
--- Begin Message --- On Aug 15, 2022, at 12:50 AM, Denis Ovsienko via tcpdump-workers wrote: > On Sun, 14 Aug 2022 11:49:57 -0700 > Guy Harris via tcpdump-workers > wrote: > >> Or is this a ZIP archive provided by somebody other than tcpdump.org? > > github.com -> code -> download ZIP. I vaguely remember there was a > "download tar.gz" there as well, but not anymore. Anyway, git clone is > better order of magnitudes, in that it allows to tell which commit the > working copy is at. So they're building from the current main branch, rather than from a release tarball (or from the source used to build the versions of libpcap and tcpdump in the OS they're using)? If so, then, yes, they should use git clone, not only for the reason you mention, but because it's not a snapshot, it's a repository, so it can be updated to the current state of the main branch.--- 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 --- On Sun, 14 Aug 2022 11:49:57 -0700 Guy Harris via tcpdump-workers wrote: > Or is this a ZIP archive provided by somebody other than tcpdump.org? github.com -> code -> download ZIP. I vaguely remember there was a "download tar.gz" there as well, but not anymore. Anyway, git clone is better order of magnitudes, in that it allows to tell which commit the working copy is at. -- Denis Ovsienko --- 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 --- On Fri, 12 Aug 2022 16:27:29 +0200 Christian via tcpdump-workers wrote: > Then I opened the tcpdump.zip archive within the libpcap directory. > step into the directory, call ./configure and it build. success! The git clone of libpcap and the git clone of tcpdump are supposed to be next to each other, not one inside the other. Also the libpcap directory must be named "libpcap" because tcpdump build process is checking in ../libpcap for the "local" libpcap. If the check is unsuccessful, tcpdump tries to build with the "system" libpcap. -- Denis Ovsienko --- 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 ---
On Aug 12, 2022, at 7:27 AM, Christian via tcpdump-workers
wrote:
> 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,
Unless I've missed something, "again" means "again, in a different mailing
list", as the only previous message I can find about it was to the
wireshark-dev mailing list...
> 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:
...and my response, in the previous mail thread, to the question
> 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.
was
> You do it in libpcap.
So:
> Get libpcap with git, step into the directory invoke: ./configure
> --disable-dbus --without-dbus --without-dpdk --disable-rdma
>
> then make and make install.
OK, so far so good.
> 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?)
> within the libpcap directory. step into the directory, call ./configure and
> it build. success!
There's no requirement to unpack the tcpdump source in the libpcap source
directory. If you *haven't* installed the libpcap that you built from source,
the best place to unpack it is in the *parent* directory of the libpcap source
directory, but if you *have* installed that libpcap, the tcpdump configure
script won't have to look for it in a directory at the same level as the
tcpdump source directory, so you can unpack the tcpdump repository anywhere.
> Then I took my changes for libpcap from march, a pcap-kpnode.c and
> pcap-kpnode.h (attached)
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?
> 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.
There were no attachments to the copy of your message that I received, so if
you attached it, something stripped the attachment.--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[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
