[Olsr-dev] OLSRd IPv6 Mesh @ 25c3

Kelvin Chan (spam-protected)
Mon Jan 5 07:23:04 CET 2009


>
> Date: Tue, 30 Dec 2008 17:27:17 +0100
> From: Jo-Philipp Wich <(spam-protected)>
> Subject: [Olsr-dev] OLSRd IPv6 Mesh @ 25c3
> To: (spam-protected)
> Message-ID: <(spam-protected)>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi list,
>
> I just wanted to share our success story with olsrd in a pure IPv6  
> mesh at 25c3.
>
> This year's Freifunk experiment at the Chaos Communication Congress  
> was about building a
> pure IPv6 based OLSR mesh and using SIIT translation technique [1]  
> to transport IPv4
> traffic via the IPv6 mesh without using tunnels or similar  
> encapsulation techniques.
>
> We had a small mesh of 15-20 nodes up and running at the congress  
> [2]. Some nodes operated
> in 802.11g / channel 1, some in 802.11a / channel 100, 2.4GHz and  
> 5GHz clouds where
> interconnected using Alix-Boards with two radio interfaces.
>
> The interface IPv6 addresses were composed of a common 64bit prefix
> (fdca:ffee:babe:dada::/64) and the upper 64bit of the wifi  
> interface's link local address
> (fe80::/64). A sample configuration can be found at [3]
>
> When the experiment started we used the most recent OLSRd release,  
> v0.5.6-r3 running on
> top of OpenWrt Kamikaze which worked surprisingly well :) [4]
>
> On several nodes we observed a "slow-start" problem with OLSRd  
> v0.5.6-r3, when a node (or
> it's OLSRd instance) was restarted, it took several minutes to re- 
> aquire neighbour routes.
> The node successfully received hellos from it's neighbours but the  
> neighbour connections
> were stuck with LQ >> 0 and NLQ = 0 for a long time and then  
> suddenly changed the ETX from
> INFINITE to near 1.0. Aaron suggested to try again with a more  
> recent version (the hg tip
> from 2008/12/29).
>
> So we compiled a more recent version, applied a patch from this list  
> [5] and installed it
> on one of the Mesh nodes and gave it a try only to discover that our  
> previously used
> configuration file wasn't accepted anymore. A quick run with debug  
> level 1 revealed that
> the options "LinkQualityWinSize", "LinkQualityLevel" and  
> "UseHysteresis" weren't supported
> anymore, so we just removed them from our configuration.
>
> After the deprecated config options were removed, another proplem  
> arised, olsrd reported
> that it can't find the IPv6 address of the interface. After looking  
> at the code changes we
> figured out that new options for "Ip6AddrType" were introduced since  
> 0.5.6-r3. We
> previously used "global" as Ip6AddrType but in the meanwhile a check  
> was added that
> rejected "global" IPv6 addresses that begin with "fc" or "fd". After  
> probing around a bit,
> we figured that a type of "unique-local" was the right one to choose  
> in our case.
>
> Now something really weird happened, OLSRd managed it to determine  
> the interface IPv6
> address and reported it correctly with -d 5 but then corrupted the  
> address when converting
> it from the string to an address struct (e.g.: fdca:ffee:babe:dada: 
> 202:6fff:fe4a:31f4/64
> suddenly became 202:6fff:fe4a:31f4::/64). Henning helped me to debug  
> that problem and we
> came up with a patch that just changed some debug printf()'s but  
> seemed to address this
> issue. [6]
>
> After some more tries and recompilations, the OLSRd tip worked  
> nicely together with the
> 0.5.6-r3 versions and IPv6 addresses on the mesh interfaces.
>
> Finally we wanted to install OLSRd on our x86 BGP router machine  
> (running Debian) but
> couldn't get it to work with IPv6. The OLSRd successfully received  
> and transmitted routes
> with the mesh network but every attempt to insert kernel routes was  
> answered with an
> Invalid Argument error from the kernel. After tinkering around a bit  
> and trying different
> OLSRd versions with different modifications the machine died because  
> of a disk failure :(

Perhaps the IPv6 feature was not enable in the kernel on your Debian.

First, the Linux kernel must be built with IPv6 support, this kernel  
option:
	CONFIG_IPV6=y
must be set when building the kernel.

Second, the system must be configured to enable IPv6.
In the past, I was running OLSRd (version 0.5.4) IPv6 on system V  
(Fedora Core) filesystem,
I had to set these in the "/etc/sysconfig/network" system configuration:
	NETWORKING_IPv6=yes
	IPV6FORWARDING=yes

I have never tried to setup IPv6 on Debian system.

>
>
> So we took an old laptop running x86 OpenWrt and installed the OLSRd  
> there. To our
> surprise routes were successfully added and everything was well in  
> contrast to Debian.
> This leaves us a bit clueless why it works on OpenWrt but not on  
> Debian, this is a thing
> we still have to investigate.
>
>
> All in all it was a nice experience and we were really surprised  
> that we even manged it to
> setup a pure IPv6 mesh with OLSRd :D
>
> I personally really appreciate the work you put into OLSRd and hope  
> that this little real
> live experience report keeps you motivated to fix and enhance IPv6  
> support for OLSR ;)
>
> We now plan to build a permanent IPv6 test mesh network so that the  
> OLSR developers have a
> real live testbed for IPv6-related issues.
>
>
> Greetings from the 25c3,
> JoW + Freifunk Crew
>
>
> References:
> [1] http://blogs.k-ita.de/~alx/?tag=siit
> [2] http://quamquam.org/~jow/6mesh.png
> [3] https://events.ccc.de/congress/2008/wiki/Wireless:ipv6-config
> [4] http://quamquam.org/~jow/6mesh-screenshots/
> [5] + [6]
> https://luci.subsignal.org/trac/browser/luci/trunk/contrib/package/olsrd-luci/patches/010-olsrd-ip6addr.patch
> https://luci.subsignal.org/trac/browser/luci/trunk/contrib/package/olsrd-luci/patches/011-olsrd-ip6addr-2.patch
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFJWkvldputYINPTPMRAlvLAJ95z/pS+7hloafbQu+eARftZg9u0ACbBOXw
> o/7L1Xrgw16y1xQUgnlYFHI=
> =OBxF
> -----END PGP SIGNATURE-----
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20090105/5eadba86/attachment.html>


More information about the Olsr-dev mailing list