freifunk@k:ita

12 January 2010

learned on the 26c3

Filed under: ccc, freifunk, network, software — Tags: , , , , , , , — alx @ 16:07

Hi,
26c3 is over and we had quite some experiments going on. Not everything went good, but we learned a lot:

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

10 December 2007

olsr-tunnel

Filed under: freifunk, network, politics, software — Tags: , , , , — alx @ 8:43

Hi,

after being annoyed of the unfair comparisation between b.a.t.m.a.n. and olsr, resulting in “but it has gateway tunnels” i had a talk with tetzlav from freifunk leipzig about olsr and gateway tunnels.

We came to the conclusion that the concept of asymmetric tunnel should be easy to implement without messing with the olsr code:

  1. install the ipip kernel module, load it on gateway(s) and your node.
  2. fire you tunl0 on your gateway up with some dumy ip address.
  3. add a tunnel interface on your node with your gateway ip as the destination ip
  4. fire your tunl with your meship as its ip
  5. add a default route with a better metric as the olsr default route pointing to your tunnel interface

As everybody is using the Freifunk firmware, i tried to do this with a few buffalo router running fff-1.6.22:

I took some already for freifunk configured meshnodes.

switched off all firewalls.
Installed the freifunk-recommended-de, freifunk-openwrt-compat and the kmod-ipip package via the webinterface.
After reboot, did a

ifconfig tunl0 10.23.23.23 up

on the gateway.

my gateway has 104.128.30.3 as its ip, my node 104.128.30.1, so on the node:

ip tunnel add tunl1 mode ipip remote 104.128.30.3
ifconfig tunl1 104.128.30.1 up
route add default dev tunl1 metric 0

Now you should be able to observe tunnel packets leaving your node and nontunneld answers coming back.

As packets coming from the LAN port will not pass nat, their answers will not routed back. To circumvent this, put a small /29 on your lan, switch off NAT and announce the /29 via HNA4.

Writing a small script to get the best gateway from olsr and to set the tunnel destination should be easy.

Thinking further, it should be possible to use the olsr service announcement plugin to advertise the available average bandwith of a gateway, giving a better advise to choose an uplink.

Involving some connection tracking, it might be possible to switch gateways with keeping the existing connections to the old gateway, resulting in less hurting behavior while using always the best gateway.

Update: the nice people from freifunk leipzig made a packet for freifunkfirmware, you find it in their packet repository.

Advice: Do not do this at home without policy routing and knowing exactly what you do, it is just a proof of concept.

Powered by WordPress