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 up

on the gateway.

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

ip tunnel add tunl1 mode ipip remote
ifconfig tunl1 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.

This entry was posted in freifunk, network, politics, software and tagged , , , , . Bookmark the permalink.

2 Responses to olsr-tunnel

  1. Joerg Albert says:

    Interesting article, some time I’ll try this.

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

    I guess you talk about the node here. Announcing the /29 of your LAN would require more unique IP addresses at the node
    and could lead to multiple announcing of 192.168.X.X via HNA4. Furthermore the PC at the LAN of the node are exposed to the outside. Adding NAT from the LAN to the tunl1 isn’t possible I guess as the packets from the gateway to the node don’t pass the tunnel but arrive on the wlan interface.

    Couldn’t we add tunl1 to the olsr controlled interfaces on both the gateway and the node and select among the set of gateways by setting some LQ multiplicators? This would send the packets from the gateway to the node via the tunl1 on the gateway and allow to use NAT.

  2. alx says:

    I think the need of more unique ip addresses is not an issue, that is actually the way of building networks, but that is a religious issue in freifunk. 😉
    The issue of multiple announcements is a logistic “problem”, to be solved by the ip address allocation system of the community.
    The “exposement” of the individual pc is IMHO no problem at all, if there should be no incoming connections allowed, then that is a firewalling issue, not a nat issue.

    By putting the tunl1 into olsr config, you would just create an assymetric neighbour, as the endpoint has no tunnel back to the node.

    this is just a proof of concept, the implementation of this idea has been done by freifunk leipzig, as they are using nat and policy routing, maybe they solved this issue: http://firmware.leipzig.freifunk.net/ipkg/global/freifunk-gwtun_0.1.2_mipsel.ipk

    Also, the http://ninux.org people developed an even better way of doing gateway selection, they use loose source routing, with the drawback that all intermediate router need to have this enables, as linux drops this packets silently when they are not explicitly allowed: http://svn.ninux.org/ninuxdeveloping/changeset/496

Comments are closed.