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

[Ben West]

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>
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>
Cc: olsr-users <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>wrote:

> On Mon, May 20, 2013 at 7:59 AM, Ben West <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
314-246-9434



-- 
Ben West
http://gowasabi.net
ben at gowasabi.net
314-246-9434
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20130521/4522aefc/attachment.html>