[Olsr-users] High-level questions about encryption on OLSR ad-hoc mesh

[Eric Malkowski]

Ben-

Did you find this note on WPA-NONE for AD-hoc mode.  It was on my list 
of things to try on my setup, but never got around to it

http://lists.freebsd.org/pipermail/freebsd-net/2010-April/025052.html

I wanted to chime in here on my experience with the secure plugin.  I've 
done an outdoor network each year for the Head Of The Charles Regatta 
very similar to what Ben wants to do (Mesh Ad-hoc backhauls on 5.8, 
local radios for AP on 2.4) and found that 2 years ago when bringing up 
the last node in the network, routes would disappear within minutes 
whenever the total nodes on the network was 10 or more.  In doing 
investigation I found OLSRd was crashing on what appeared to be random 
nodes (i.e. not sure if they were MPRs / non-MPR neighbors etc. -- I 
wasn't able to characterize since we were scrambling to just make it 
work).  Usually it would crash w/in the secure plugin (kernel was 
reporting some of those details in dmesg I think -- olsr secure .so 
(share lib)).  I ended up having to frantically add a bunch of static 
routes and shut OLSR off on a node or two to get stability.  This was 
running 0.5.8r6 I believe.

The next year I brought up the who setup on the bench and found when 
bringing up the 10th node, usually w/in minutes one or more OLSRd 
crashes.  I tried to run in gdb and do a stack trace but the stack had 
nothing useful (seemed corrupt), so I went to plan B -- I turned off the 
secure plugin -- this year we ran a 12 node network for the entire 
weekend with no crashes and rock solid stability.

I'm thinking there is something that overflows or gets stomped on in the 
secure plugin implementation when the number of nodes is 10 or more.  
Perhaps the signature calculation is overstepping a buffer or something 
to that effect.

My approach to keeping people off the 5.8 mesh was a few things 
(security in layers, not trying to protect traffic -- the goal here is 
to only have proper OLSR participants on the ad-hoc parts of the network):

1. Use the ahdemo mode for MADWIFI -- no management frames at all: no 
beacons, no association, no probes, just data.  Then we don't see other 
"things" on our frequency doing ad-hoc and they typically don't see us 
unless using a sniffer etc.  This also avoids ad-hoc "cell" splits -- 
they just talk.

2. Use WEP -- simple iwconfig commands to set a static WEP key for all 
of the 5.8 ghz radios works well for me.  WEP is weak, but the more 
things you do the better (and the wireless chip does the crypto keeping 
the CPU free for everything else).

3. Use the OLSR secure plugin to have signed OLSR packets so if someone 
cracks the WEP they can't poison the mesh routing

4. No DHCP or DNS services answering on the mesh interface -- mesh 
interface job is to just find routes with OLSR and route data.

Someone with decent knowledge of the setup could certainly cause 
trouble, but with over 300,000 people attending the event smart phones 
and all it hasn't been a problem.  Plus the event is only for 1 weekend 
and the entire setup is temporary outdoor.  This year we had to turn off 
the OLSR secure and it still wasn't an issue -- people are attracted to 
the 2.4 ghz APs since they run DHCP w/ a splashpage for access etc.  
These all end up being HNAs. 

If I manage to get around to trying out WPA-NONE, I'll let you know my 
results.

Ben -- if you are interested in seeing some more details of the setup we 
use send me an e-mail and I can forward some links.  I have a google map 
with points and lines on it showing some of the details of what we do 
each year.  Good luck with your build out.

--
Eric Malkowski
BVWireless, LLC