Re: [tcpdump-workers] Any way to filter ether address when type is LINUX_SLL?
--- Begin Message --- On Jan 21, 2021, at 8:41 AM, Bill Fenner via tcpdump-workers wrote: > It would be perfectly reasonable (and fairly straightforward) to update > libpcap to be able to filter on the Ethernet address in DLT_LINUX_SLL or > DLT_LINUX_SLL2 mode. Link-layer address, to be more accurate. The good news is that, for Ethernet, that address appears to be the source address for all packets, incoming and outgoing, at least with the 5.6.7 kernel; I haven't checked the kernel code paths for other kernel versions. That might also be the case for 802.11. However, for FDDI, for example, it appears not to be set (it's marked as zero-length). > There are already filters that match other offsets in > the SLL or SLL2 header. However, I don't think it could be done on live > captures, only against a savefile. At least as of 5.6.7, I don't see an SKF_ #define that would correspond to a link-layer address, so it appears that it's not possible to easily filter on the address in a live capture, at least not with an in-kernel filter. As we're using cooked sockets (PF_PACKET/SOCK_DGRAM), the link-layer header isn't supplied to us, so we can't look at it ourselves. I've been thinking about a world in which we have more pcapng-style APIs. With a capture API that can deliver, for each packet, something similar to a pcapng Enhanced Packet Block, with an interface number from the capturing program can determine a link-layer header type, so that not all captured packet have to have the same link-layer header type, it might be possible to generate a filter program that: could use one of the SKF_ magic offsets to fetch the "next protocol type" value for the protocol after the link-layer protocol, so link-layer-type-independent code could be used to check for common "next protocol type" values such as IPv4, IPv6, and ARP; could use one of the SKF_ magic offsets to fetch the offset, relative to the beginning of the raw packet data, of the first byte past the link-layer header, so that link-layer-type-independent code could be used to check for anything at the next protocol layer (IP address, etc.); could use one of the SKF_ magic offsets to fetch the ARPHRD_ type giving the link-layer header type, and, based on that run different code to check fields in the link-layer header. This would be done by using a raw socket (PF_PACKET/SOCK_RAW) rather than a cooked socket. With all of that, we could do live-capture filtering of MAC addresses (source *or* destination). That's a lot of work, though.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] libpcap detection and linking in tcpdump
--- Begin Message --- On Jan 22, 2021, at 2:54 PM, Denis Ovsienko via tcpdump-workers wrote: > I have tested it again with the current master branches of libpcap and > tcpdump. Both builds (with and without libpcap0.8-dev) now complete > without errors. > > However, in both cases the installed tcpdump fails to run because it > is linked with libpcap.so.1. Which, as far as I can remember, > previously somehow managed to resolve to the > existing /tmp/libpcap/lib/libpcap.so.1, but not amymore: > > $ /tmp/libpcap/bin/tcpdump --version > /tmp/libpcap/bin/tcpdump: error while loading shared libraries: > libpcap.so.1: cannot open shared object file: No such file or directory > > $ ldd /tmp/libpcap/bin/tcpdump > linux-vdso.so.1 (0x7ffdc7ffe000) > libpcap.so.1 => not found > libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 > (0x7f34522ac000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 > (0x7f3451ebb000) > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 > (0x7f3451cb7000) > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 > (0x7f3451a98000) > /lib64/ld-linux-x86-64.so.2 (0x7f3452c6f000) > > $ /tmp/libpcap/bin/pcap-config --libs > -L/tmp/libpcap/lib -Wl,-rpath,/tmp/libpcap/lib -lpcap So that *should* cause /tmp/libpcap/lib to be added to the executable's path, which *should* cause it to look in /tmp/libpcap/lib for shared libraries. So, if there's a /tmp/libpcap/lib/libpcap.so.1 file, that's not happening, somehow. I'll try experimenting with one of my Ubuntu VMs. In the meantime, for some fun head-exploding reading, take a look at https://en.wikipedia.org/wiki/Rpath and perhaps some other documents found by a search for lpath rpath linux--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] libpcap detection and linking in tcpdump
--- Begin Message --- On Wed, 9 Sep 2020 17:07:25 +0100 Denis Ovsienko via tcpdump-workers wrote: > Here are my steps to reproduce: > > libpcap$ ./configure --enable-remote --prefix=/tmp/libpcap > libpcap$ make > libpcap$ make install > tcpdumpbuild$ cmake -DWITH_CRYPTO="yes" > -DCMAKE_PREFIX_PATH=/tmp/libpcap -DCMAKE_INSTALL_PREFIX=/tmp/libpcap > /path/to/tcpdump_git_clone > > The above fails if the package libpcap0.8-dev is installed. After > removing the package the above works and tcpdump links > with /tmp/libpcap/lib/libpcap.so.1 as expected. I have tested it again with the current master branches of libpcap and tcpdump. Both builds (with and without libpcap0.8-dev) now complete without errors. However, in both cases the installed tcpdump fails to run because it is linked with libpcap.so.1. Which, as far as I can remember, previously somehow managed to resolve to the existing /tmp/libpcap/lib/libpcap.so.1, but not amymore: $ /tmp/libpcap/bin/tcpdump --version /tmp/libpcap/bin/tcpdump: error while loading shared libraries: libpcap.so.1: cannot open shared object file: No such file or directory $ ldd /tmp/libpcap/bin/tcpdump linux-vdso.so.1 (0x7ffdc7ffe000) libpcap.so.1 => not found libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x7f34522ac000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f3451ebb000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f3451cb7000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f3451a98000) /lib64/ld-linux-x86-64.so.2 (0x7f3452c6f000) $ /tmp/libpcap/bin/pcap-config --libs -L/tmp/libpcap/lib -Wl,-rpath,/tmp/libpcap/lib -lpcap It may be a user error, or there may be some other edge case hidden in the combination of the two build systems. So long as it does not cause obvious failures to build, I would be fine to leave it as it is now. -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
