[Olsr-users] 0.5.6-r6 testing over OpenVPN tunnel
Mon Sep 28 16:56:07 CEST 2009
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
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 126.96.36.199 (from kernel.org)
Central Massachusetts, U.S.A.
More information about the Olsr-users