[Commotion-dev] Fwd: Hack to set node's local time on boot in case remote OLSRd rejects its packets

Tue May 21 17:33:47 UTC 2013

It seems that if routers without an internal hardware clock can't mesh 
with an olsr network, than a workaround like the script you propose 
would be quite necessary. Maybe we can add a check to see if the 
current date is good enough, and if not set it to the timestamp of 
/etc/somewhere/current. Do you know what the allowable time difference 
window is for olsrd?

On Tue 21 May 2013 01:04:43 PM EDT, Ben West wrote:
> Howdy again,
>
> I've been having problems with a node that consistently powers up with
> local time @ 1 Jan 1970, getting its OLSR packets rejected by other
> nodes with correct local time.  Henning seems to confirm this is done
> intentionally by OLSRd for security reasons, creating a potential
> chicken-and-egg problem for any nodes that depend on a getting a valid
> route via OLSR to set their local time in the first place.
>
> This particular node is a TP-Link TL-MR3020, although I believe the
> UBNT radios are a little better about powering up with their local
> time not quite as old as Disco.
>
> Anyhoo, the hack I've put into /etc/rc.local is quoted below.
> Basically, it takes the most recent file modification date under
> /etc/somewhere/current and sets local time to that.  For Commotion, if
> the local time issue affects you, you could probably set the path just
> to "/etc".
>
> ---------- Forwarded message ----------
> From: *Ben West* <ben at gowasabi.net <mailto:ben at gowasabi.net>>
> Date: Mon, May 20, 2013 at 2:10 PM
> Subject: Re: [Olsr-users] Accepting packets from nodes with very old
> localtime
> To: Henning Rogge <hrogge at googlemail.com <mailto:hrogge at googlemail.com>>
> Cc: olsr-users <olsr-users at lists.olsr.org
> <mailto:olsr-users at lists.olsr.org>>
>
>
> Hi Henning,
>
> Thank you for the explanation.  I do try to use link-layer security
> where available (e.g. IBSS-RSN encryption), but would still prefer to
> retain security mechanisms at other layers too.
>
> Since OLSRd seems to still accept incoming packets whose timestamps
> are only a couple years or so out of date, I am able to work-around
> this problem by having such nodes run this delightful kludge in
> /etc/rc.local.  This kludge just takes advantage of the firmware
> typically having written recently something to /etc/somewhere/current,
> and strips out the most recent file timestamp.
>
> # This is a hack to set localtime to something current enough so that
> # remote a OLSRd instance will accept packets from this node.
>
> # Get date/time components of most recent filemod under
> /etc/somewhere/current
> FILELISTING=`ls -l -u -e /etc/somewhere/current | tail -1`
> [ -n "${FILELISTING}" ] && {
>     FILEMOD_YYYY=`echo $FILELISTING | awk '{printf "%d", $10}'`
>     FILEMOD_HHMMSS=`echo $FILELISTING  | awk '{printf "%s", $9}'`
>     FILEMOD_DD=`echo $FILELISTING | awk '{printf "%s", $8}'`
>     FILEMOD_MONTH=`echo $FILELISTING | awk '{printf "%s", $7}'`
>
>     # Convert Month to numerical MM format
>     case "${FILEMOD_MONTH}" in
>         "Jan") FILEMOD_MM="01" ;;
>         "Feb") FILEMOD_MM="02" ;;
>         "Mar") FILEMOD_MM="03" ;;
>         "Apr") FILEMOD_MM="04" ;;
>         "May") FILEMOD_MM="05" ;;
>         "Jun") FILEMOD_MM="06" ;;
>         "Jul") FILEMOD_MM="07" ;;
>         "Aug") FILEMOD_MM="08" ;;
>         "Sep") FILEMOD_MM="09" ;;
>         "Oct") FILEMOD_MM="10" ;;
>         "Nov") FILEMOD_MM="11" ;;
>         "Dec") FILEMOD_MM="12" ;;
>         *) FILEMOD_MM="01" ;;
>     esac
>
>     # Set local date/time, assuming format "YYYY-MM-DD hh:mm:ss"
>     DATE="${FILEMOD_YYYY}-${FILEMOD_MM}-${FILEMOD_DD} $FILEMOD_HHMMSS"
>     date -s "${DATE}"
> }
>
> Again, I'm not sure why OLSRd or OSLRd + secure plugin chooses to
> reject packets with timestamp (T - 40years), but still accept packets
> with timestamp (T - 2years).  The kludge above would render this
> security provision moot, right?
>
>
> On Mon, May 20, 2013 at 3:15 AM, Henning Rogge <hrogge at googlemail.com
> <mailto:hrogge at googlemail.com>> wrote:
>
>     On Mon, May 20, 2013 at 7:59 AM, Ben West <ben at gowasabi.net
>     <mailto:ben at gowasabi.net>> wrote:
>     > I've been testing a TP-Link TL-MR3020 running OpenWRT Attitude
>     Adjustment
>     > v12.09, albeit custom compiled to include the recent release
>     olsrd v0.6.5.4.
>     > This particular device has no internal hardware clock (not
>     unusual for
>     > low-cost consumer-grade wifi routers), and it does consistently
>     boot up with
>     > local time at 1 Jan 1970, which I've found causes other nodes to
>     reject its
>     > OLSR packets.
>
>     If I understand the code right the neighbors of the OLSR node should
>     forget the last stored timestamp after 30 seconds with no valid
>     packet.
>
>     > Besides that, is it possible to somehow disable timestamp
>     checking for
>     > incoming OLSR packets?  Or is this a drawback of using the (now
>     presumably
>     > outdated) secure plugin?
>
>     If you disable the timestamps you will be open to replay attacks,
>     which are a trivial way to disrupt your network.
>
>     The alternative would be to use some kind of linklayer-security, it
>     would offer you practically the same security for OLSR than the secure
>     plugin, most likely even more.
>
>     Henning Rogge
>
>     --
>     We began as wanderers, and we are wanderers still. We have lingured
>     long enough on the shores of the cosmic ocean. We are ready at last to
>     set sail for the stars - Carl Sagan
>
>
>
>
> --
> Ben West
> http://gowasabi.net
> ben at gowasabi.net <mailto:ben at gowasabi.net>
> 314-246-9434 <tel:314-246-9434>
>
>
>
> --
> Ben West
> http://gowasabi.net
> ben at gowasabi.net <mailto:ben at gowasabi.net>
> 314-246-9434
>
>
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> https://lists.chambana.net/mailman/listinfo/commotion-dev

--
Dan Staples

Open Technology Institute
https://commotionwireless.net