Hi All,<div><br></div><div>In lieu of discussion about diminishing returns for enabling whatever limited encryption is supported for adhoc/mesh modes, I'm curious if anyone on the list has good experience using OpenVPN with OpenWRT meshes? I'm curious about the prospect of just setting up VPN tunnels thru the unencrypted mesh as needed, but I would be wary of placing undue load on any embedded CPU, whether in the access point or in a downstream router.<br>
<br></div><div>The documentation for OpenWRT + VPN seems to be a bit out of date or incomplete:</div><div><a href="http://wiki.openwrt.org/oldwiki/IPSec">http://wiki.openwrt.org/oldwiki/IPSec</a></div><div><a href="http://wiki.openwrt.org/inbox/vpn.howto">http://wiki.openwrt.org/inbox/vpn.howto</a></div>
<div><a href="http://wiki.openwrt.org/doc/howto/openvpn_bridging">http://wiki.openwrt.org/doc/howto/openvpn_bridging</a></div><div><br><div class="gmail_quote">On Tue, Mar 1, 2011 at 10:05 AM, Eric Malkowski <span dir="ltr"><<a href="mailto:eric@bvwireless.net">eric@bvwireless.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Ben-<br>
<br>
Did you find this note on WPA-NONE for AD-hoc mode. It was on my list<br>
of things to try on my setup, but never got around to it<br>
<br>
<a href="http://lists.freebsd.org/pipermail/freebsd-net/2010-April/025052.html" target="_blank">http://lists.freebsd.org/pipermail/freebsd-net/2010-April/025052.html</a><br>
<br>
I wanted to chime in here on my experience with the secure plugin. I've<br>
done an outdoor network each year for the Head Of The Charles Regatta<br>
very similar to what Ben wants to do (Mesh Ad-hoc backhauls on 5.8,<br>
local radios for AP on 2.4) and found that 2 years ago when bringing up<br>
the last node in the network, routes would disappear within minutes<br>
whenever the total nodes on the network was 10 or more. In doing<br>
investigation I found OLSRd was crashing on what appeared to be random<br>
nodes (i.e. not sure if they were MPRs / non-MPR neighbors etc. -- I<br>
wasn't able to characterize since we were scrambling to just make it<br>
work). Usually it would crash w/in the secure plugin (kernel was<br>
reporting some of those details in dmesg I think -- olsr secure .so<br>
(share lib)). I ended up having to frantically add a bunch of static<br>
routes and shut OLSR off on a node or two to get stability. This was<br>
running 0.5.8r6 I believe.<br>
<br>
The next year I brought up the who setup on the bench and found when<br>
bringing up the 10th node, usually w/in minutes one or more OLSRd<br>
crashes. I tried to run in gdb and do a stack trace but the stack had<br>
nothing useful (seemed corrupt), so I went to plan B -- I turned off the<br>
secure plugin -- this year we ran a 12 node network for the entire<br>
weekend with no crashes and rock solid stability.<br>
<br>
I'm thinking there is something that overflows or gets stomped on in the<br>
secure plugin implementation when the number of nodes is 10 or more.<br>
Perhaps the signature calculation is overstepping a buffer or something<br>
to that effect.<br>
<br>
My approach to keeping people off the 5.8 mesh was a few things<br>
(security in layers, not trying to protect traffic -- the goal here is<br>
to only have proper OLSR participants on the ad-hoc parts of the network):<br>
<br>
1. Use the ahdemo mode for MADWIFI -- no management frames at all: no<br>
beacons, no association, no probes, just data. Then we don't see other<br>
"things" on our frequency doing ad-hoc and they typically don't see us<br>
unless using a sniffer etc. This also avoids ad-hoc "cell" splits --<br>
they just talk.<br>
<br>
2. Use WEP -- simple iwconfig commands to set a static WEP key for all<br>
of the 5.8 ghz radios works well for me. WEP is weak, but the more<br>
things you do the better (and the wireless chip does the crypto keeping<br>
the CPU free for everything else).<br>
<br>
3. Use the OLSR secure plugin to have signed OLSR packets so if someone<br>
cracks the WEP they can't poison the mesh routing<br>
<br>
4. No DHCP or DNS services answering on the mesh interface -- mesh<br>
interface job is to just find routes with OLSR and route data.<br>
<br>
Someone with decent knowledge of the setup could certainly cause<br>
trouble, but with over 300,000 people attending the event smart phones<br>
and all it hasn't been a problem. Plus the event is only for 1 weekend<br>
and the entire setup is temporary outdoor. This year we had to turn off<br>
the OLSR secure and it still wasn't an issue -- people are attracted to<br>
the 2.4 ghz APs since they run DHCP w/ a splashpage for access etc.<br>
These all end up being HNAs.<br>
<br>
If I manage to get around to trying out WPA-NONE, I'll let you know my<br>
results.<br>
<br>
Ben -- if you are interested in seeing some more details of the setup we<br>
use send me an e-mail and I can forward some links. I have a google map<br>
with points and lines on it showing some of the details of what we do<br>
each year. Good luck with your build out.<br>
<br>
--<br>
Eric Malkowski<br>
BVWireless, LLC<br>
<font color="#888888"><br>
<br>
--<br>
Olsr-users mailing list<br>
<a href="mailto:Olsr-users@lists.olsr.org">Olsr-users@lists.olsr.org</a><br>
<a href="http://lists.olsr.org/mailman/listinfo/olsr-users" target="_blank">http://lists.olsr.org/mailman/listinfo/olsr-users</a><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Ben West<br><a href="mailto:westbywest@gmail.com" target="_blank">westbywest@gmail.com</a><br>
</div>