--- Begin Message ---On Jan 21, 2021, at 8:41 AM, Bill Fenner via tcpdump-workers <tcpdump-workers@lists.tcpdump.org> 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
