--- Begin Message ---
Guy Harris via tcpdump-workers <tcpdump-workers@lists.tcpdump.org> wrote:
> 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:
I like this as an idea for an API.
> 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.);
That would be very nice.
The kernel already has done all the L2 processing, might as well leverage it.
> 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).
Cool.
--- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers