[Olsr-users] 0.5.6-r6 testing over OpenVPN tunnel

[Eric Malkowski]

Hi guys-

Not sure if you remember me from last year around this time I had worked 
through some times() system call issues and found a few issues / fixes etc.

This year I'll be setting up a similar mesh network and I was curious if 
you guys think an issue I saw last year might be resolved.
I was using 0.5.6-r2

On part of my network, I can't get a wireless link due to obstructions, 
so I use an OpenVPN tunnel between two internet backhauls to make 
managing the network from one place easier.  I'm using a "tap" style 
interface on OpenVPN so the OLSR broadcasts make it across the tunnel.  
The tunnel is up all the time (no interfaces are if'd down or up -- 
tunnel brought up at boot time before OLSR starts).  For some reason it 
would take several minutes for routes to the network on the other end of 
the tunnel to show up -- much longer than it does w/ WLAN links.  I 
think I saw this on the bench also once, but couldn't reproduce it and 
had to work with what I had in the field.  OLSR shouldn't think of the 
tunnel any different than a wireless link -- it can have some packet 
loss due to it being a simple UDP mode VPN and certainly will have more 
latency than a WLAN link, but I would think it would come up as quick is 
as other pure wireless nodes -- i.e. less than a minute from bootup.

I will do my best to migrate to the about to be released 0.5.6-r6 branch 
tonight and stage it on my bench again.

Is there anything special I should know for the OpenVPN tap interfaces?  
Last year I set them up just like the WLAN links -- i.e. active 
interfaces (not HNA) so once the nodes on each end of the tunnel "see" 
each other they share routes and "glue" my two "sub-meshes" separated by 
the tunnel together.

Also -- for some reason during the 3-4 days of activity I had a node 
become unresponsive for about 30 seconds and then come back.  I don't 
think the routes disappeared -- it was too brief of an outage.  I can't 
complain because this was the only "outage" during the event.  I was 
thinking it could have been due to a bad ad-hoc mode "split" and this 
year I was thinking of going with madwifi's "ahdemo" mode so the nodes 
just peer and avoid any ad-hoc splits.  This has the side benefit of not 
seeing other 5.8 ghz peers out there that are not mine since there's no 
"beacon" type packets.  I'm curious if OLSR with madwifi's ahdemo mode 
(beaconless ad-hoc not subject to ad-hoc split) is a good idea -- any 
"gotchas" I should watch out for using ahdemo mode?  BTW: this is 
madwifi stable 0.9.4.1

I'll report the results of bench tests as soon as possible to help test 
0.5.6-r6.

I'm excited to work with this stuff again and thanks for a great project.

Versions of stuff I use:

Alix 3d2 hardware
gcc 4.2.1 as cross compiler optimized for i586 (geode)
Linux kernel 2.6.26.3  (from kernel.org)
uClibc 0.9.29
madwifi-0.9.4.1
openvpn 2.0.9
wireless_tools.29
olsr-0.5.6-r6 planned

--
Eric Malkowski
BVWireless, LLC
Central Massachusetts, U.S.A.