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:
- install the ipip kernel module, load it on gateway(s) and your node.
- fire you tunl0 on your gateway up with some dumy ip address.
- add a tunnel interface on your node with your gateway ip as the destination ip
- fire your tunl with your meship as its ip
- add a default route with a better metric as the olsr default route pointing to your tunnel interface
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 18.104.22.168 as its ip, my node 22.214.171.124, so on the node:
ip tunnel add tunl1 mode ipip remote 126.96.36.199 ifconfig tunl1 188.8.131.52 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.
Advice: Do not do this at home without policy routing and knowing exactly what you do, it is just a proof of concept.