[Commotion-dev] Fwd: Hack to set node's local time on boot in case remote OLSRd rejects its packets
Ben West
ben at gowasabi.net
Tue May 21 17:52:20 UTC 2013
Hi Dan,
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.
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.
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.
On Tue, May 21, 2013 at 12:33 PM, Dan Staples <
danstaples at opentechinstitute.org> wrote:
> 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
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> https://lists.chambana.net/mailman/listinfo/commotion-dev
>
>
--
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/81b12118/attachment-0001.html>
More information about the Commotion-dev
mailing list