Hi Dan,<br><br>I do not know what OLSRd's allowable time offset is, and empirical observation seems to suggest that local time on the order of (T - 3years) is OK, but (T - 40years) is not. Henning thought packets older that 30secs would be rejected, but I have not observed that fine-grained of sensitivity to local time offset at all.<br>
<br>Besides that, Henning and I are curious if this might be exposing a variable out-of-range problem somewhere deep in the bowels of OLSRd. Normally, such problems are expected to surface when the world as Linux knows it ends in 2038, but possibly this instance involves a variable that is already offset very far into its allowable range.<br>
<br>UBNT products seems to skirt by this problem for the most point by having a hardcoded local time at some point well after the UNIX epoch (e.g. date of chip manufacture?). Indeed, I only experienced this problem on a TP-Link node that happens to always power up with local time 1/1/1970, and occasionally on older Engenius ath5k radios.<br>
<br>On Tue, May 21, 2013 at 12:33 PM, Dan Staples <span dir="ltr"><<a href="mailto:danstaples@opentechinstitute.org" target="_blank">danstaples@opentechinstitute.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It seems that if routers without an internal hardware clock can't mesh<br>
with an olsr network, than a workaround like the script you propose<br>
would be quite necessary. Maybe we can add a check to see if the<br>
current date is good enough, and if not set it to the timestamp of<br>
/etc/somewhere/current. Do you know what the allowable time difference<br>
window is for olsrd?<br>
<div class="im"><br>
On Tue 21 May 2013 01:04:43 PM EDT, Ben West wrote:<br>
> Howdy again,<br>
><br>
> I've been having problems with a node that consistently powers up with<br>
> local time @ 1 Jan 1970, getting its OLSR packets rejected by other<br>
> nodes with correct local time. Henning seems to confirm this is done<br>
> intentionally by OLSRd for security reasons, creating a potential<br>
> chicken-and-egg problem for any nodes that depend on a getting a valid<br>
> route via OLSR to set their local time in the first place.<br>
><br>
> This particular node is a TP-Link TL-MR3020, although I believe the<br>
> UBNT radios are a little better about powering up with their local<br>
> time not quite as old as Disco.<br>
><br>
> Anyhoo, the hack I've put into /etc/rc.local is quoted below.<br>
> Basically, it takes the most recent file modification date under<br>
> /etc/somewhere/current and sets local time to that. For Commotion, if<br>
> the local time issue affects you, you could probably set the path just<br>
> to "/etc".<br>
><br>
> ---------- Forwarded message ----------<br>
</div><div class="im">> From: *Ben West* <<a href="mailto:ben@gowasabi.net">ben@gowasabi.net</a> <mailto:<a href="mailto:ben@gowasabi.net">ben@gowasabi.net</a>>><br>
> Date: Mon, May 20, 2013 at 2:10 PM<br>
> Subject: Re: [Olsr-users] Accepting packets from nodes with very old<br>
> localtime<br>
</div><div><div class="h5">> To: Henning Rogge <<a href="mailto:hrogge@googlemail.com">hrogge@googlemail.com</a> <mailto:<a href="mailto:hrogge@googlemail.com">hrogge@googlemail.com</a>>><br>
> Cc: olsr-users <<a href="mailto:olsr-users@lists.olsr.org">olsr-users@lists.olsr.org</a><br>
> <mailto:<a href="mailto:olsr-users@lists.olsr.org">olsr-users@lists.olsr.org</a>>><br>
><br>
><br>
> Hi Henning,<br>
><br>
> Thank you for the explanation. I do try to use link-layer security<br>
> where available (e.g. IBSS-RSN encryption), but would still prefer to<br>
> retain security mechanisms at other layers too.<br>
><br>
> Since OLSRd seems to still accept incoming packets whose timestamps<br>
> are only a couple years or so out of date, I am able to work-around<br>
> this problem by having such nodes run this delightful kludge in<br>
> /etc/rc.local. This kludge just takes advantage of the firmware<br>
> typically having written recently something to /etc/somewhere/current,<br>
> and strips out the most recent file timestamp.<br>
><br>
> # This is a hack to set localtime to something current enough so that<br>
> # remote a OLSRd instance will accept packets from this node.<br>
><br>
> # Get date/time components of most recent filemod under<br>
> /etc/somewhere/current<br>
> FILELISTING=`ls -l -u -e /etc/somewhere/current | tail -1`<br>
> [ -n "${FILELISTING}" ] && {<br>
> FILEMOD_YYYY=`echo $FILELISTING | awk '{printf "%d", $10}'`<br>
> FILEMOD_HHMMSS=`echo $FILELISTING | awk '{printf "%s", $9}'`<br>
> FILEMOD_DD=`echo $FILELISTING | awk '{printf "%s", $8}'`<br>
> FILEMOD_MONTH=`echo $FILELISTING | awk '{printf "%s", $7}'`<br>
><br>
> # Convert Month to numerical MM format<br>
> case "${FILEMOD_MONTH}" in<br>
> "Jan") FILEMOD_MM="01" ;;<br>
> "Feb") FILEMOD_MM="02" ;;<br>
> "Mar") FILEMOD_MM="03" ;;<br>
> "Apr") FILEMOD_MM="04" ;;<br>
> "May") FILEMOD_MM="05" ;;<br>
> "Jun") FILEMOD_MM="06" ;;<br>
> "Jul") FILEMOD_MM="07" ;;<br>
> "Aug") FILEMOD_MM="08" ;;<br>
> "Sep") FILEMOD_MM="09" ;;<br>
> "Oct") FILEMOD_MM="10" ;;<br>
> "Nov") FILEMOD_MM="11" ;;<br>
> "Dec") FILEMOD_MM="12" ;;<br>
> *) FILEMOD_MM="01" ;;<br>
> esac<br>
><br>
> # Set local date/time, assuming format "YYYY-MM-DD hh:mm:ss"<br>
> DATE="${FILEMOD_YYYY}-${FILEMOD_MM}-${FILEMOD_DD} $FILEMOD_HHMMSS"<br>
> date -s "${DATE}"<br>
> }<br>
><br>
> Again, I'm not sure why OLSRd or OSLRd + secure plugin chooses to<br>
> reject packets with timestamp (T - 40years), but still accept packets<br>
> with timestamp (T - 2years). The kludge above would render this<br>
> security provision moot, right?<br>
><br>
><br>
> On Mon, May 20, 2013 at 3:15 AM, Henning Rogge <<a href="mailto:hrogge@googlemail.com">hrogge@googlemail.com</a><br>
</div></div><div class="im">> <mailto:<a href="mailto:hrogge@googlemail.com">hrogge@googlemail.com</a>>> wrote:<br>
><br>
> On Mon, May 20, 2013 at 7:59 AM, Ben West <<a href="mailto:ben@gowasabi.net">ben@gowasabi.net</a><br>
</div><div><div class="h5">> <mailto:<a href="mailto:ben@gowasabi.net">ben@gowasabi.net</a>>> wrote:<br>
> > I've been testing a TP-Link TL-MR3020 running OpenWRT Attitude<br>
> Adjustment<br>
> > v12.09, albeit custom compiled to include the recent release<br>
> olsrd v0.6.5.4.<br>
> > This particular device has no internal hardware clock (not<br>
> unusual for<br>
> > low-cost consumer-grade wifi routers), and it does consistently<br>
> boot up with<br>
> > local time at 1 Jan 1970, which I've found causes other nodes to<br>
> reject its<br>
> > OLSR packets.<br>
><br>
> If I understand the code right the neighbors of the OLSR node should<br>
> forget the last stored timestamp after 30 seconds with no valid<br>
> packet.<br>
><br>
> > Besides that, is it possible to somehow disable timestamp<br>
> checking for<br>
> > incoming OLSR packets? Or is this a drawback of using the (now<br>
> presumably<br>
> > outdated) secure plugin?<br>
><br>
> If you disable the timestamps you will be open to replay attacks,<br>
> which are a trivial way to disrupt your network.<br>
><br>
> The alternative would be to use some kind of linklayer-security, it<br>
> would offer you practically the same security for OLSR than the secure<br>
> plugin, most likely even more.<br>
><br>
> Henning Rogge<br>
><br>
> --<br>
> We began as wanderers, and we are wanderers still. We have lingured<br>
> long enough on the shores of the cosmic ocean. We are ready at last to<br>
> set sail for the stars - Carl Sagan<br>
><br>
><br>
><br>
><br>
> --<br>
> Ben West<br>
> <a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br>
</div></div>> <a href="mailto:ben@gowasabi.net">ben@gowasabi.net</a> <mailto:<a href="mailto:ben@gowasabi.net">ben@gowasabi.net</a>><br>
> <a href="tel:314-246-9434" value="+13142469434">314-246-9434</a> <tel:<a href="tel:314-246-9434" value="+13142469434">314-246-9434</a>><br>
<div class="im">><br>
><br>
><br>
> --<br>
> Ben West<br>
> <a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br>
</div>> <a href="mailto:ben@gowasabi.net">ben@gowasabi.net</a> <mailto:<a href="mailto:ben@gowasabi.net">ben@gowasabi.net</a>><br>
> <a href="tel:314-246-9434" value="+13142469434">314-246-9434</a><br>
><br>
><br>
> _______________________________________________<br>
> Commotion-dev mailing list<br>
> <a href="mailto:Commotion-dev@lists.chambana.net">Commotion-dev@lists.chambana.net</a><br>
> <a href="https://lists.chambana.net/mailman/listinfo/commotion-dev" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-dev</a><br>
<br>
--<br>
Dan Staples<br>
<br>
Open Technology Institute<br>
<a href="https://commotionwireless.net" target="_blank">https://commotionwireless.net</a><br>
_______________________________________________<br>
Commotion-dev mailing list<br>
<a href="mailto:Commotion-dev@lists.chambana.net">Commotion-dev@lists.chambana.net</a><br>
<a href="https://lists.chambana.net/mailman/listinfo/commotion-dev" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-dev</a><br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>Ben West<div><a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br>314-246-9434<br>
</div>