Credo che il plug-in in questione potrebbe essere molto utile per
prevenire lo squacquerellamento delle nostre VPN.

ciao,
Clauz

-------- Original Message --------
Subject: [Olsr-dev] Meshing over VPNs
Date: Tue, 04 Oct 2011 02:00:51 +0200
From: Benny Baumann <benbe1...@gmx.net>
To: olsr-dev <olsr-...@lists.olsr.org>, olsr-users
<olsr-us...@lists.olsr.org>

Hi guys,

I'm writing to the list in order to introduce one small plugin we have
been working on for Freifunk Chemnitz which has helped us better
organize the routes OLSR generates when you are trying to mesh over a
VPN link like Tinc. But in detail.

As the Freifunk network in Chemnitz is still quite small we have several
hotspots of local access to the Freifunk network. In order to be able to
access every node from everywhere and to operate the network securely in
accordance with German legislation, we are using a VPN to interconnect
the nodes that face the internet. Those nodes with internet connection
form a VPN using Tinc, but are doing OLSR routing so other nodes can
find them and the services they provide (DNS, Proxying, ...). All the
local nodes with Wireless network just do plain OLSR over the air and
mesh locally. This way - even without being in the reach of any of the
hotspots - we can do remote administration of the whole (reachable) network.

Now there's one problem we faced: As Tinc itself has to be used with
Switching mode we got a fully connected graph for ALL of the Tinc nodes
even if the nodes themselves couldn't reach each other. This is due to a
feature in Tinc which distributes broadcasts too all nodes of the VPN
and not only as a matter of OSI layer 2 as would be practical in this
situation. This basically works for the generated network graph, but
gives routing tables which are much too large for most routers to handle
(well, several of our routers died regularly from the routing tables
being too large).

One solution we (Nemesis, Florz and me) now implemented is using the
Link Quality Multiplier to worsen the percieved link quality of links
inside the Tinc cloud where links we know to be direct connections of
Tinc nodes are treated like normal, but non-direct links get a penalty.
The way this was implemented was by asking Tinc to dump a GraphDumpFile
every minute (unfortunately you can't make this more often) and
reconfiguring the link quality multiplier per link dynamically. The
resulting plugin has been in production for about 4 weeks now and no
major fuckups have been found.

The plugin itself is quite flexible too: It only requires to have two
conditions met:
1. The list of nodes to prefer has to be in Dot File Format as written
bei Tinc (i.e. /\t(\S+) -> (\S+)/m)
2. Nodes have to be numbered in a way that the name of the node relates
to the IP (i.e. "node_42_something" = 42 -> 10.0.0.42, the used network
can be configured)

For more information you can have a look at my blog[1] or download the
plugin via SVN from the Freifunk Chemnitz SVN[2] for Version 0.6.1 (but
should work without changes for 0.6.2 too).

Feedback and improvements to the plugin code are very welcome.

Happy meshing ;-)

BenBE.

[1] http://blog.benny-baumann.de/?p=1107 (German)
[2] http://svn.chemnitz.freifunk.net/svn/freifunk/tinclqmult/olsrd-0.6.1/

P.S.: The ARP Roaming Plugin Amadeus and me have been working on got
some fine tuning too and now does proper roaming of clients in about
5-10 seconds (which is only little worse than doing this in 1 second in
hardware ;-)). One feature we are still lacking there is finding new
clients by sniffing air traffic directly. But the basic functions to
accieve this have been introduced already; just not been linked in yet
due to being incomplete.


-- 
Olsr-dev mailing list
olsr-...@lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Rispondere a