From owner-freebsd-net@FreeBSD.ORG Tue Jul 8 07:34:34 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BE9337B401 for ; Tue, 8 Jul 2003 07:34:34 -0700 (PDT) Received: from hysteria.spc.org (hysteria.spc.org [195.206.69.234]) by mx1.FreeBSD.org (Postfix) with SMTP id E81FD43F85 for ; Tue, 8 Jul 2003 07:34:32 -0700 (PDT) (envelope-from bms@hysteria.spc.org) Received: (qmail 29598 invoked by uid 5013); 8 Jul 2003 14:32:35 -0000 Date: Tue, 8 Jul 2003 15:32:35 +0100 From: Bruce M Simpson To: "M. Warner Losh" Message-ID: <20030708143235.GK22331@spc.org> Mail-Followup-To: Bruce M Simpson , "M. Warner Losh" , sam@errno.com, freebsd-net@freebsd.org, consume-thenet@lists.consume.net References: <20030708055626.GH22331@spc.org> <20030708.060709.22312307.imp@bsdimp.com> <686583785.1057648110@melange.errno.com> <20030708.081303.122408805.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030708.081303.122408805.imp@bsdimp.com> User-Agent: Mutt/1.4.1i cc: sam@errno.com cc: consume-thenet@lists.consume.net cc: freebsd-net@freebsd.org Subject: AODV RFC is now ratified X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2003 14:34:34 -0000 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