Date: Thu, 15 Aug 1996 11:11:54 -0700 (PDT) From: Archie Cobbs <archie@whistle.com> To: avalon@coombs.anu.edu.au (Darren Reed) Cc: julian@whistle.com, hackers@freebsd.org Subject: Re: DIVERT Message-ID: <199608151811.LAA14400@bubba.whistle.com> In-Reply-To: <199608151024.DAA29735@freefall.freebsd.org> from "Darren Reed" at Aug 15, 96 08:23:57 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> In some mail from Julian Elischer, sie said: > > > > No, that isn't quite what divert does.. > > divert is a bit more powerful than that > > it uses a divert socket type to pass the packets up to the user. > > this allows other info to be passed as well.. > > the main difference is that you can using the divert socket, re-inject the > > packet back at the point that it was taken out, and control to a greater > > extent what happens to it.. > > > > divert sockets are an experiment which may or may not survive > > but we have found that they allow us to do things that we couldn't do > > using the tunnel interface. > > > > firstly sockets are inherrently packet oriented, so you can do > > 'sendto' on them for example to give different sematics to what > > happens to the packet after re-injection. > > > > there are other problems that are solved by this approach. > > we looked at tun interfaces and decided that it was banging a square > > peg into a round hole. > > What was/is the aim of it ? > > To me it sounds a lot like what screend does, except there is a way to > open multiple instances for intercepting packets. > > Although, I don't quite see how they fit in to the operational scheme of > things. > > > each divert socket can be bound to a differnt port, so you can divert > > different packets to different sockets (with tun, how do you do that?) > > Multiple tun devices ? The idea behind divert is pretty simple.. it just adds another possible "action" that an ipfw rule can have, which is "send this packet to the user-land process listening on this socket". It also allows the reverse, that is, the user process can re-inject the packet (possibly modified) back into the system exactly at the point where it was diverted. Divert sockets were motivated by a discussion about how one would implement something like address translation (or packet encryption) under FreeBSD. Lots of people commented that more kernel bloat is a hated thing. I happened to agree strongly with this sentiment. The logical observation (to me, anyway) was that there needed to be some way to easily and efficiently redirect chosen packets out of the kernel and to some user process, and then get them back in where they left off. Hence divert sockets. Now with what language do you specify what packets to divert? Well, the ipfw packet selection language seemed a good fit. Another possibility was the BPF stuff (which I'm not that familiar with to be honest). The problem with using tunnel interfaces is that packets written to them are subject to routing. This would make doing something like address translation difficult, where you're changing the IP addresses in the packet header (but you don't want to change where the packet is going). The problem with BPF is that it doesn't divert packets, it just copies them. And again, it's based on interfaces. By the way, there is a man page.. divert(4). -Archie ___________________________________________________________________________ Archie L. Cobbs, archie@whistle.com * Whistle Communications Corporation
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608151811.LAA14400>