<div>I'm starting this as a separate thread, in case the problem also arises for the folks testing on Android.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.)</div>
<div><br></div>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.<br clear="all">
<div><br></div><div>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.</div><div><br></div>-- <br><div>Ben West</div><div>
<a href="mailto:me@benwest.name" target="_blank">me@benwest.name</a></div><br>