Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 9 Jul 2003 14:47:37 +0800
From:      "Morton Lin" <mtlin1@ms36.hinet.net>
To:        "Bruce M Simpson" <bms@spc.org>
Cc:        freebsd-net@freebsd.org
Subject:   Re: AODV RFC is now ratified
Message-ID:  <01cc01c345e5$ff91abf0$3c55608c@mtlin>
References:  <beekqa$18jf$1@FreeBSD.csie.NCTU.edu.tw>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Sir :

I am very interesting in your post. Would you please give me some
web pages or information about your brief FreeBSD Howto ?

I had built a ad-hoc testbed by using CMU's Monarch DSR 
implementation. But it's buggy. In 802.11 environment our platform
didn't work very well. And I had done simulation for DSR and AODV 
in OPNET. It seems the performance of AODV was better. 

Anyway, It's happy to see Perkins and folks make it. :-)

PS : Do you ever think the possibility that those ad-hoc routing protocol
       stack running over Bluetooth environment ?


Best Regards,
Morton Lin.

----- Original Message ----- 
From: "Bruce M Simpson" <bms@spc.org>
Newsgroups: mailing.freebsd.net
Sent: Tuesday, July 08, 2003 10:34 PM
Subject: AODV RFC is now ratified


> 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
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01cc01c345e5$ff91abf0$3c55608c>