[Commotion-dev] Fwd: Hack to set node's local time on boot in case remote OLSRd rejects its packets
Will Hawkins
hawkinsw at opentechinstitute.org
Tue May 21 18:53:54 UTC 2013
It looks like the code for this is somewhere in olsr_input_tc in
tc_set.c in the src directory of olsr. It seems to take the time from
the incoming packet and converts it to a relative timestamp. That
relative timestamp is used to expire the hello(s). There is a special
configuration value (min_tc_vtime) that might be able to control this
behavior. I'm not sure how to set that value from a config file (Google
thinks it is MinTCVTime). I hope this information helps!
Will
On 05/21/2013 02:22 PM, Josh King wrote:
> I would like to include this workaround, but we should definitely try
> and nail down what it's doing first, so that we know that it will work
> in the largest possible set of cases.
>
> On 05/21/2013 01:52 PM, Ben West wrote:
>> 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
>> <mailto: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>
>> <mailto: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> <mailto: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>
>> > <mailto: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>
>> > <mailto: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>
>> > <mailto: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>
>> <mailto:ben at gowasabi.net <mailto:ben at gowasabi.net>>
>> > 314-246-9434 <tel:314-246-9434> <tel:314-246-9434 <tel:314-246-9434>>
>> >
>> >
>> >
>> > --
>> > Ben West
>> > http://gowasabi.net
>> > ben at gowasabi.net <mailto:ben at gowasabi.net>
>> <mailto:ben at gowasabi.net <mailto:ben at gowasabi.net>>
>> > 314-246-9434 <tel:314-246-9434>
>> >
>> >
>> > _______________________________________________
>> > Commotion-dev mailing list
>> > Commotion-dev at lists.chambana.net
>> <mailto: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
>> <mailto:Commotion-dev at lists.chambana.net>
>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>>
>>
>>
>>
>> --
>> 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
>>
>
>
>
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> https://lists.chambana.net/mailman/listinfo/commotion-dev
>
More information about the Commotion-dev
mailing list