• 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.

Eine kurze mailkonversation mit postmaster@freenet.de und etwas googlen ergab, das es möglich ist: man kann die reverse lookup delegation einfach bei 6to4.nro.net einstellen.

Letzten mittwoch setzte ich mich dann mit Michael zusammen, da er das gleiche problem hat, um die zonen in unseren nameservern einzutragen.

2 details, die recht nützlich sein können:

• Die delegation kann man initial nur einstellen für “seinen” IP space, dafür muss man eine eigene 6to4 adresse als absenderadresse des browsers haben. Da die jedoch auf dem server liegt, hilft es, sich per ssh mit -D 1080 auf dem server einzuloggen und dem firefox dann 127.0.0.1 port 1080 als socks5 proxy mitzugeben, (erst) dann kommt man auf das richtige webinterface.
• wenn man sich (wie wir) viel arbeit und denken sparen will, dann hilft der passende zonebuilder, welcher nicht nur die zone generiert, sondern auch den passenden eintrag in der named.conf

Wir haben uns dann jeweils gegenseitig versklavt und können jetzt auch wieder mails per ipv6 an freenet user schicken.

We will be right next to other interesting project like:

• GSM Hackers
• Console Hacking
• The Bricophone people

More on the floorplan.

We are going to build a ipv6 only mesh using siit to transport translated ipv4 traffic.

So, preparation are happening all over, even if you can see them only if you have a very close look:

Jow is fixing tickets and enhancing the openwrt luci framework to make sure we have a good start into the experiment.

Meanwhile, Daniel is working hard on our BGP routers to make sure we get a direct routing for the freifunk PI network into the 25c3. As you can see, our RIPE entry has been updated to enable routing to and from AS249, the congress network.

Felix has ported the siit kernel module to kernel 2.6 and commited.

Lehox and friends are working hard on n2n to get at least the worst bugs fixed, as we are going to use it as the backup vpn to our other BGP routers.

There is still a lot to do, but it looks like we are on a good way.

kamikaze package dir: http://nbd.name/siit.tar.gz

joti did som make stuff for “normal” linux: https://norwegen.soziologiker.org/hg/siit

please test and give feedback.

Update: first tests succeeded.

I have a VM with a 6to4 tunnel running lighttpd, so i let the AAAA record for this blog point on that machine, enabled the proxy module and added following config to the proxy configuration:

$HTTP["host"] == "blogs.k-ita.de" {
  proxy.server  = ( "" => ( ( "host" => "80.237.196.30" ) ) )
}

It’s not the cleanest solution, but it works for me[TM].

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.

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!