Re: Any way to filter ether address when type is LINUX_SLL?

[Guy Harris via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Guy Harris <gharris () sonic net>
>
> Date: Fri, 22 Jan 2021 22:17:47 -0800
>
> 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