• babel did not survive the hack-center.
• ahcp did survive.
• measurement needs to be improved

That does not sound much, but i think it’s valuable information as we can now concentrate on some things and forget the other.

Openimp did not run good, it had a memory leak we got not fixed during 26c3, so the router kept rebooting after a few minutes.
Babel also hat real trouble, it ate up a lot of cpu and memory, it felt like olsr 3 years ago.
A few harddrives did not survive the heat of colo, so a part of the topology data are maybe lost.
Firmware building and development did work quite good, but could be better, that was mainly my verpeilung, there is room for improvement.

I will continiue the tests in my local mesh neighbourhood without babel and without ipv4 based olsr, so expect more firmware builds soon.

Based on the last posting, we are doing it now with an olsr mesh between the translators.

Between this two posts, jow fixed all remaining issues, making the setstuff shellscripts obsolete. He also fixed a HNA6 issue in the olsrd-luci package. Thanks, great work, jow.

Easy setup now, one internet4 gateway, one access node to give internet to the attached ipv4 clients.

I tried to draw it: ipv4-throught-ipv6-mesh.

gate:

• wan port is dhcp, lan port is 172.23.1.1/24
• siit0 gets a dummy address: 169.254.42.42
• wl0 gets an ipv6 address, in this case the fdca:ffee:babe::1:1/64
• we do a ::ffff:ffff:0/96 route into siit0, so everything from 6mesh goes into translation.
• an HNA6 of ::ffff:ffff:0:0/96 announces the mapped 0.0.0.0/0 ipv4 space.
• MTU on WAN, LAN down to 1400, ipv6 headers are slighly larger.

access1 has

• 172.23.2.1/24 on its lan, fdca:ffee:babe::1:2 on wl0 and the usual dummy address on siit0.
• we do a ::ffff:ffff:172.13.2.0/120 to siit0, because in this case, only traffic directed to clients needs to go into translation.
• same route as HNA6 announcement to catch the traffic out of the mesh.
• Also, MTU on LAN reduced to 1400.

To reproduce the setup, you need 2 broadcom based OpenWrt boxes, as the siit kernel module has not been ported to kernel 2.6.

its based on OpenWrt 8.09RC1 plus  some patches, which add siit, enable ipv6 forwarding and fix ipv6 static routes. plus a config file.

you can also use ready made firmwareimages. then, there is a config tarball and a uci-dump for gate and a tarball and dump for access1.

for building more accessnodes, you need to alter the lan ipaddress, the ipv6 route into siit0 and the HNA6.

and, as it is just a proof of concept, telnet is open, firewall is open and the wanport of access1 is configured for my local LAN, so i can access telnet and webif from my notebook.

configuration of olsr nameservice plugin to get proper DNS automagically is left as an exercise to the reader.

for questions, you can also join #freifunk on IRCNet or write to the wlanware mailinglist.

i would be happy to hear about any success.

Everything was going fine, except the fact i was too stupid to configure wl0 with the webinterface.

Even on the commandline, i was unable to find it, so in opened the case and saw it:

wl0 died

src:

• 192.168.11.1/24 connected to trans1, defaultgateway to trans1

trans1:

• interface test: 192.168.11.2
• interface lan: 192.168.12.1/24, not used in this test
• interface lan:fdca:ffee:babe:46::1/64 an ULA address.
• interface lan: route to ::ffff:ffff:192.168.15.0/120 via trans2 (linklayer address)
• interface siit0: 169.254.42.42/16 (dummy ipv4 address)
• interface siit0: “route add default dev siit0″ all ipv4 trash goes into translation, if not getting better route to any interface.
• “route add -A inet6 ::ffff:ffff:0:0/96 dev siit0″ to push any to be translated traffic into the translator.

trans2:

• interface test: 192.168.12.2/24 (not used in this test)
• interface test: fdca:ffee:babe:46::2/64
• interface test: route to ::ffff:ffff:192.168.11.0/120 via trans1 (linklayer address)
• interface lan: 192.168.15.1/24
• interface siit0: 169.254.42.42/16 (also dummy)
• interface siit0: “route add default dev siit0″ again
• “route add -A inet6 ::ffff:ffff:0:0/96 dev siit0″ again.

dest:

• 192.168.15.2/24, connected to interface lan of trans2

/etc/init.d/firewall disable on trans1 and trans2

i left the wanports attached to my normal lan at home to be able to telnet onto the boxes, but i removed the default gateway for the wan port.

i had to change the ::ffff:ffff -> ::ffff:0000 translating behavior to plain ::ffff:ffff -> ffff:ffff by changing TRANSLATED_PREFIX into 0xffffffff in siit.h, otherwise the way back into the v4 world would not work.

setup:

src and target are easy, configuration is left to the reader.

trans1 and trans2 are using firmware image with the siit kernel package in packages and this as .config. luci and packages are enabled in feeds.conf, x-wrt not.

trans1 uses following tarball as configuration, files go into /etc/config and set_stuff_trans1.sh to configure things luci cannot configure right now (or i am too dumb to figure it out).

trans2 the same: tarball and setstuff.

important: the linklayer address in set_stuff_* has to be changed to reflect the linklayeraddress of the neighbour, as they are lladdr dependent.

when done right, src should be able to ping target, tcpdump on the ipv6 network should show translated ip packets.

root@target:/# ping 192.168.15.169
PING 192.168.15.169 (192.168.15.169): 56 data bytes
64 bytes from 192.168.15.169: seq=0 ttl=60 time=4.165 ms
64 bytes from 192.168.15.169: seq=1 ttl=60 time=3.113 ms

--- 192.168.15.169 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.113/3.639/4.165 ms

and

root@trans1:~# tcpdump -n -i eth0.0 not port 698
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.0, link-type EN10MB (Ethernet), capture size 96 bytes
00:54:51.064695 IP6 ::ffff:ffff:c0a8:b01 > ::ffff:ffff:c0a8:fa9: ICMP6, echo request, seq 0, length 64
00:54:51.067329 IP6 ::ffff:ffff:c0a8:fa9 > ::ffff:ffff:c0a8:b01: frag (0|64) ICMP6, echo reply, seq 0, length 64
00:54:52.061440 IP6 ::ffff:ffff:c0a8:b01 > ::ffff:ffff:c0a8:fa9: ICMP6, echo request, seq 1, length 64
00:54:52.063117 IP6 ::ffff:ffff:c0a8:fa9 > ::ffff:ffff:c0a8:b01: frag (0|64) ICMP6, echo reply, seq 1, length 64
00:54:56.059208 IP6 fe80::216:1ff:feaf:c520 > fdca:ffee:babe:46::1: ICMP6, neighbor solicitation, who has fdca:ffee:babe:46::1, length 32
00:54:56.059376 IP6 fdca:ffee:babe:46::1 > fe80::216:1ff:feaf:c520: ICMP6, neighbor advertisement, tgt is fdca:ffee:babe:46::1, length 32
00:54:56.060094 IP6 fe80::216:1ff:feaf:a6d4 > fdca:ffee:babe:46::2: ICMP6, neighbor solicitation, who has fdca:ffee:babe:46::2, length 32
00:54:56.060427 IP6 fdca:ffee:babe:46::2 > fe80::216:1ff:feaf:a6d4: ICMP6, neighbor advertisement, tgt is fdca:ffee:babe:46::2, length 32

8 packets captured
8 packets received by filter
0 packets dropped by kernel
root@trans1:~#

The basic idea behind it was to translate ip4 stateless into ipv6 packets, route them through the mesh and translate them back into ipv4 packets at the border of the mesh.

i tried to visualize it: ipv6-translation.

Experiments with trt did not succeed, but after reading more rfc documents, i found rfc2765, which descibes exactly what i wanted to do.

But there was no implementation.

Some more googleing led to russian documents, doing mostly what i wanted.

With some help from Daniel and google translate, we got the source and a vague idea of how i might work. Felix from the OpenWrt project helped a lot to make a broadcom-2.4 kernel package.

Took 2 router and a notebook, put a 192.168.11.0/24 on one lan between the 2 router, put a ::ffff:0:192.168.13.0/96 between the router and the notebook and was finally able to see a translated ping on my routers siit0 interface:

07:30:19.583928 IP 192.168.11.1 > 192.168.13.3: ICMP echo request, id 51461, seq 31, length 64
07:30:19.584046 IP6 ::ffff:ffff:c0a8:b01 > ::ffff:0:c0a8:d03: ICMP6, echo request, seq 31, length 64
07:30:20.583894 IP 192.168.11.1 > 192.168.13.3: ICMP echo request, id 51461, seq 32, length 64
07:30:20.584012 IP6 ::ffff:ffff:c0a8:b01 > ::ffff:0:c0a8:d03: ICMP6, echo request, seq 32, length 64
07:30:21.583923 IP 192.168.11.1 > 192.168.13.3: ICMP echo request, id 51461, seq 33, length 64
07:30:21.584038 IP6 ::ffff:ffff:c0a8:b01 > ::ffff:0:c0a8:d03: ICMP6, echo request, seq 33, length 64

resulting in:

07:31:00.584243 IP6 ::ffff:ffff:c0a8:b01 > ::ffff:0:c0a8:d03: ICMP6, echo request, seq 72, length 64
07:31:01.584215 IP6 ::ffff:ffff:c0a8:b01 > ::ffff:0:c0a8:d03: ICMP6, echo request, seq 73, length 64

on the lan segment to the notebook, where i can see the packets arriving.

The route back is still missing, the 2nd translator is missing, the prefixes and the prefixlenght is hardcoded in the driver, but it is a first success on the way to a better world.

And, the kernelmodule is only 13340 bytes, which makes it much more interesting than putting it together in click, which also should be possible.

I would like to see it working with click too, as the code is much cleaner and better maintained, even when its much bigger and therefore not so well suited for our small wireless router.

Now some sleep.

update: source here.

to be continued…

P.S.: openwrt build is here.

Update2: setting the defaultroute to an fe80:: link local address on the notebook worked, so the route back works and the ping gets back. It works!

Sure, tinc is nice, tinc is peer2peer, but without an efficient key distribution system, it eats too much workpower for maintainance.

I found ELA, “A Fully Distributed VPN System over Peer-to-Peer Network”, but it is from 2005 and written for linux 2.4.20.

I also found n2n, which looks quite promising, as it is quite new, runs in userspace, has not many dependencies and is quite small, so it should be able to run on our linksys based nodes.

One could argue, a shared key is nno security at all, if you have a big group, but security is not the main issue, it is about connectivity. without all that key exchange hassle, it could be easy to install and to configure and spread the use of vpn technology in freifunk and other wireless community networks.

I still did not find out how to run the network with more then one supernode, as stated in the paper, but it looks like it is going to be implemented soon.

I will keep playing with it and would be happy about anybody sharing his experiences with n2n as vpn backend for interconnecting meshclouds.

Update: Frithjof did an kamikaze ipkg.

Looks like the big players in muni mesh are getting pressure from below.

Have to have a look on that, did anybody see the downloadbuttom?