| From | Sent On | Attachments |
|---|---|---|
| Clint Marek | May 16, 1996 8:02 pm | |
| Doug White | May 17, 1996 11:33 am | |
| Tony Kimball | May 17, 1996 2:11 pm | |
| Terry Lambert | May 17, 1996 2:23 pm | |
| Tony Kimball | May 17, 1996 6:04 pm | |
| Archie Cobbs | May 17, 1996 6:05 pm | |
| Terry Lambert | May 17, 1996 6:13 pm | |
| Tony Kimball | May 17, 1996 7:46 pm | |
| Terry Lambert | May 17, 1996 10:48 pm | |
| Archie Cobbs | May 18, 1996 1:23 am | |
| francis yeung | May 18, 1996 5:26 am | |
| Bruce A. Mah | May 18, 1996 8:43 am | |
| Eric J. Schwertfeger | May 18, 1996 11:06 am | |
| Stephen Hovey | May 18, 1996 11:59 am | |
| Archie Cobbs | May 18, 1996 1:05 pm | |
| Terry Lambert | May 18, 1996 3:15 pm | |
| Clint Marek | May 18, 1996 10:09 pm | |
| Michael Smith | May 18, 1996 10:36 pm | |
| Tony Kimball | May 19, 1996 12:50 am | |
| Carl Makin | May 19, 1996 5:01 am | |
| Pedro A M Vazquez | May 19, 1996 6:01 am | |
| Michael Smith | May 19, 1996 7:40 am | |
| Charlie ROOT | May 19, 1996 4:37 pm | |
| Michael Smith | May 19, 1996 7:07 pm | |
| Garrett Wollman | May 20, 1996 7:40 am | |
| Bruce A. Mah | May 20, 1996 8:37 am | |
| Tony Kimball | May 20, 1996 11:48 am | |
| Jim Dennis | May 20, 1996 12:47 pm | |
| Garrett Wollman | May 20, 1996 1:29 pm | |
| Tony Kimball | May 20, 1996 1:36 pm | |
| Terry Lambert | May 20, 1996 3:22 pm | |
| Terry Lambert | May 20, 1996 3:28 pm | |
| Terry Lambert | May 20, 1996 3:32 pm | |
| Gary Palmer | May 20, 1996 3:34 pm | |
| Archie Cobbs | May 20, 1996 3:42 pm | |
| Terry Lambert | May 20, 1996 3:45 pm | |
| Terry Lambert | May 20, 1996 3:56 pm | |
| Terry Lambert | May 20, 1996 4:15 pm | |
| Tony Kimball | May 20, 1996 4:54 pm | |
| Tony Kimball | May 20, 1996 5:09 pm | |
| Bruce A. Mah | May 20, 1996 5:10 pm | |
| Bruce A. Mah | May 20, 1996 5:23 pm | |
| Tony Kimball | May 20, 1996 5:25 pm | |
| Michael Smith | May 20, 1996 6:38 pm | |
| Terry Lambert | May 20, 1996 6:47 pm | |
| Jim Dennis | May 20, 1996 8:13 pm | |
| Tony Kimball | May 20, 1996 8:24 pm | |
| Jim Dennis | May 20, 1996 9:14 pm | |
| Terry Lambert | May 20, 1996 9:30 pm | |
| Terry Lambert | May 20, 1996 9:34 pm | |
| Tony Kimball | May 20, 1996 10:02 pm | |
| Bruce A. Mah | May 20, 1996 10:12 pm | |
| Bruce A. Mah | May 20, 1996 10:44 pm | |
| Tony Kimball | May 20, 1996 10:47 pm | |
| M.R.Murphy | May 21, 1996 5:59 am | |
| Carl Makin | May 21, 1996 6:46 am | |
| Terry Lambert | May 21, 1996 10:40 am | |
| Terry Lambert | May 21, 1996 10:45 am | |
| Scott Blachowicz | May 22, 1996 9:28 am | |
| Pedro A M Vazquez | May 22, 1996 11:13 am | |
| Bill Fenner | May 22, 1996 11:45 am |
| Subject: | Re: ip masquerading | |
|---|---|---|
| From: | Terry Lambert (ter...@lambert.org) | |
| Date: | May 20, 1996 4:15:27 pm | |
| List: | org.freebsd.freebsd-questions | |
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 ter...@lambert.org
--- Any opinions in this posting are my own and not those of my present or previous employers.





