Sounds interesting. You want to make something like netfilter/eth_queue that could be somewhat protocol independent. You could also use something like this for IPX/SPX filtering on those networks. I don't know how many are out there, but I have been places where they still had this. I haven't done much in the way of kernel coding myself yet, but I would help if I could. I've done some work with libpcap with their bpf filters for ethernet packets. If there was a way to hook into the kernel to allow work to be done on an ether packet before the kernel got it, I could use that instead of the libpcap bpf filters. Is this along the lines of what you are looking at or am I totally off base? > -----Original Message----- > From: Jason Lunz [SMTP:j@trellisinc.com] > Sent: Wednesday, February 28, 2001 5:02 PM > To: linux-net@vger.kernel.org > Subject: high-speed userspace ethernet filtering > > > I've been working on a network IDS that analyzes raw ethernet frames. It > uses the mmap'ed IO mode of packet sockets (net/packet/af_packet.c), and > has been very successful in efficiently scanning large volumes of > ethernet traffic. > > I'd now like to extend this to allow filtering of packets, rather than > just scanning them. There are a couple of facilities already in the > kernel for doing similar things, but they fall short for one reason or > another: > > - socket filtering (aka bpf): allows a set of virtual instructions sent > from userspace to be executed on each packet. It's fast, but is too > inflexible for my purposes. I'd like an arbitrary user program to > make the decision on whether a packet may be processed by the rest of > the networking code. > > - netfilter/ip_queue: very nice, very generalized, but doesn't look > below the IP layer. I'd like the user program to see ethernet frames, > not IP packets. It would be ideal if there were another netfilter > hook for pre-IP, with a module attached to it that did the job of > ip_queue, except with a fast mmap mechanism like in af_packet to > obviate copying every packet to userspace. > > The second method is appealing aesthetically, but would duplicate some > of the function of packet sockets. What I want can be achieved by > changing packet socket, but it wouldn't have the generality of a new > netfilter hook (in that you couldn't write other modules to deal with > packets at that level). > > comments? This will be my first substantial foray into kernel coding, > and I wouldn't mind discussing an implementation here before getting my > feet wet. > > thanks, > > Jason - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
