Thanks for the reply Ondrej,

The reason I want to separate both the kernel and devices is to build something like RouteFlow - create fake interfaces that relate to physical interfaces on a router, assign IPs to them (and drive ARP and ping from that), but also translate the routes from the fake kernel into flows on the router.

I've covered tun/tap with openflow on my blog�http://pieknywidok.blogspot.co.nz/2012/09/tunneling-traffic-through-your-openflow.html?m=1 but the next step is to build it into a router.

Sam

Sent from my iPhone

On 14/06/2013, at 8:50 PM, Ondrej Zajicek <santiago@crfreenet.org> wrote:

On Fri, Jun 14, 2013 at 11:16:00AM +0200, Ondrej Zajicek wrote:

On Fri, Jun 14, 2013 at 04:14:19PM +1200, Sam Russell wrote:

Thanks for the reply. I think the kernel/iface stuff is a little bit more

complicated than you've explained - there are lots of places around the

code where calls are made directly rather than referring to the functions

in the proto structure.

Well, we should discuss separately kernel protocol and device protocol.

Kernel protocol is essentially just another protocol (there is one small

hack when kernel protocol abuses attached kernel table by temporarily

Here should be 'attached BIRD table' instead of 'attached kernel table'.

--
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."