[Commotion-dev] OLSR sensitivity to node's local time, repeater nodes sporadically don't find default gateway

[Ben West]

I'm starting this as a separate thread, in case the problem also arises for
the folks testing on Android.

I've found that if a repeater node boots up with its local time grossly out
of sync (ath5k devices especially), and it is unable to sync its local time
via ntpdate, then it may not find its gateway route and thus not pass any
client traffic.  The node will still be accessible to SSH from other nodes
on the mesh, so you can login manually to set a default route and update
local time, but the OLSR assignment of default route appears to fail until
local time is updated.

A further complication is that a repeater node with badly out-of-sync local
time seems to also cause neighboring repeater nodes to also not find their
default route, i.e. spreading the problem to more than one node.  This
problem, as I've observed it, is extremely sporadic.  E.g. rebooting all
nodes in the mesh can fix it.

The best measure I've found to avoid the problem is to use the OLSR
SmartGateway feature (which Commotion OpenWRT does), along with a recurring
ntpdate job that periodically sync the node's local time.  That is, if
ntpdate doesn't succeed on boot-up due to no Internet access, it will run
again (and again) after a few minutes, until the gateway node is available.
 (The images I just published in the previous thread do this.)

I had posed this question on the olsr-users listserv a while back, although
no one was quite sure what caused the problem.  OLSRd itself shouldn't have
a hard dependency on whether the node's local time is in sync.

Finally, do please note this problem is not unique to Commotion.  I've
experienced it on mesh nodes running ROBIN and plain vanilla OpenWRT
Backfire.

-- 
Ben West
me at benwest.name
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20120628/831dc0db/attachment.html>