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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless