[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
> 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  
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:

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
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> iD8DBQFJWkvldputYINPTPMRAlvLAJ95z/pS+7hloafbQu+eARftZg9u0ACbBOXw
> o/7L1Xrgw16y1xQUgnlYFHI=
> =OBxF
-------------- 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