Date: Mon, 20 May 1996 16:15:47 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: archie@whistle.com (Archie Cobbs) Cc: terry@lambert.org, alk@Think.COM, questions@freebsd.org Subject: Re: ip masquerading Message-ID: <199605202315.QAA28888@phaeton.artisoft.com> In-Reply-To: <199605180824.BAA02382@bubba.whistle.com> from "Archie Cobbs" at May 18, 96 01:24:18 am
next in thread | previous in thread | raw e-mail | index | archive | help
> A simple idea would be to have "detour" devices where you could > open /dev/filteri0 and /dev/filtero0, attach them to some interface, > and have all packets (optionally before or after (de)fragmentation) > passing through that interface routed up one and down the other. > > Better yet, with devfs, they could even have names like /dev/if_ed1 > and /dev/of_ed1 and no binding operation would be necessary. Then the > picture would look roughly like this: > > --> /dev/if_ed1 --> > / \ > network <--> interface ed1 <--> <--> kernel routing > \ / > <-- /dev/of_ed1 <-- > > When either file is not open, packets pass normally without the detour, > and with normal kernel speed. When one is open, you get to play your > games with them but pay a penalty in speed. In the same way that user > land PPP has become more popular and widely developed than kernel land > PPP, even though it is supposedly slower, I think something like this > would also be a net gain both for fostering useful developments and > fighting kernel bloat. > > I guess you could also do this just using the existing tunnel devices > with some kind of "redirect" ioctl(). > > Terry, what do you think of this idea? How would you design a general > purpose user land filtering mechanism? /dev/net/ed1 8-). Open it and ioctl to get an fd for inbound or outbound (you want fd's so that _exit() will fix it when your daemon crashes). I think you want to be able to implement firewalling at this level, so you would need to be able to attach both inbound and outbound control segments. Using fd's would also allow you to use select() to do everything in one daemon. The use of a special /dev/net (if we drag devfs into it 8-)) would let you iterate all devices, and set a select for exceptional conditions for /dev/net itself. Then when you hot-plug a PCMCIA card in, and a device is created, you could install your filtering. You could also bring the interface online and offline automatically based on the select for exceptional /dev/net events... not that you would even open /dev/ed1 for that. ;-). You'd probably want a seperate ioctl for the /dev/net/ed1 to start the break and filter through user space; for a configured device, that would mean that you don't lose packets between opening the fd's via the ioctl() and the point where you are set up enough to be able to process them. Installing BPF would be as simple as running a bpf daemon -- which would create a device /dev/net/bpf using a "device tunnel" (open any device in /dev or /dev iteself and ioctl() to create a subdevice which is a tunnel with your process on the "master" end) and hook itself into the service pipeline. Or you could load the thing as an LKM using the kernel version of the interface (I think you could fix the domain crossing and scheduling problems using locked code segments and RT scheduling classes, respectively... ioctl down the address of the processing function in the process address space (assume PIC code) and the kernel could call it directly, provided the pages were in core and there was no global state. There's really no reason why process context is needed to access code pages if they are dual-mapped). Anything loaded this way would, like a better PTY driver, be a cloning device, so you wouldn't have to preconfigure resource limits. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605202315.QAA28888>