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=1but the next step is to build it into a router. Cheers Sam Sent from my iPhone On 14/06/2013, at 8:50 PM, Ondrej Zajicek <[email protected]> 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: [email protected]) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
