Date: Tue, 8 Jul 2003 15:32:35 +0100 From: Bruce M Simpson <bms@spc.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-net@freebsd.org Subject: AODV RFC is now ratified Message-ID: <20030708143235.GK22331@spc.org> In-Reply-To: <20030708.081303.122408805.imp@bsdimp.com> References: <20030708055626.GH22331@spc.org> <20030708.060709.22312307.imp@bsdimp.com> <686583785.1057648110@melange.errno.com> <20030708.081303.122408805.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 08, 2003 at 08:13:03AM -0600, M. Warner Losh wrote: > Cool! Hopefully this work will include fixing lucent cards too :-) Hail Eris. All hail Discordia. By the way, have you seen RFC 3561? It's just out. http://www.faqs.org/rfcs/rfc3561.html Ad hoc On-Demand Distance Vector (AODV) Routing I'm putting together a brief FreeBSD HOWTO -- 'On-demand Routing with XRESOLVE for Dummies' -- hinted at by fenestro. My technique is quite simple, I create a CLONE+XRESOLVE route pointing to disc0 (to avoid routing loops when ip forwarding is enabled) for the route(s) intended to use the wireless cloud as a next-hop, then listen for RTM_RESOLVE messages when the stack tries to use those route entries to clone routes from. That then enables our hypothetical aodvd to issue RTM_CHANGE to route the data to its peer. Seems pretty clean. We can of course tweak the net.inet.ip.rt* cache tunables to prevent the stack getting swamped with stale wireless routes. I may not be able to get AODV all done on my own, but I may have a crack at it - have a lot on my plate just now. BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030708143235.GK22331>