[Olsr-users] Accepting packets from nodes with very old localtime

[Ben West]

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.

Here is a snippet from the olsrd debug output on the gateway node for this
TP-Link node:

Recevied hash:
 ...
Calculated hash:
 ...
[ENC]Match for 5.201.40.204
[ENC]Timestamp slack: -2147483648
[ENC]Timestamp scew detected!!
[ENC]Timestamp missmatch in packet from 5.201.40.204!
[ENC]Rejecting packet from 5.201.40.204
[ENC]Adding signature for packet size 20
[ENC]timestamp: 1369027304
Signature message:
   10    0    0   36
    5   49    3   43
    1    0  136  112
    1    2    0    0
   81  153  178  232
  249  200  155  145
  129   37  154  191
  125  220  118   79
   67  201   81   35
[ENC] Message signed
INTERNET GATEWAY VIA eth0 detected in routing table.
[ENC]Checking packet for challenge response message...
Input message:
   10    0    0   36
    5  201   40  204
    1    0  132   58
    1    2    0    0
    0    0    3  146
  210    5  117   73
   30   93   35   39
  117   64  115  152
  167  254  218  235

Although the choice to reject all incoming OLSR packets with substantial
time offset is understandable for security concerns, this creates a
chicken-and-egg problem when using OLSRd to provide routes to nodes that
happen to always power-up with local time set to the beginning of the UNIX
epoch, and which thus depend on a valid route to set their local time via
ntp.

Indeed, this policy of rejecting old packets appears to not be observed
consistently, since I can still trick the gateway node's OLSRd instance
into accepting incoming packets from the TP-Link by manually setting the
TP-Link's local time to something still not current (tested with 30 April
2009).  If OLSRd must throw away old packets for security reasons, is there
really a difference between a packet that is 4 years old vs 33 years old?

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?

For reference, the gateway node was a UBNT Nanostation Loco M2 running the
same OpenWRT/OLSRd combination as the TP-Link.  Here is the
/etc/config/olsrd I used:

config olsrd
    option IpVersion '4'
    option LinkQualityLevel '2'
    option LinkQualityAlgorithm 'etx_ffeth'
    option SmartGateway 'yes'
    option Pollrate '0.2'
    option UseHysteresis 'no'
    option TcRedundancy '2'
    option MprCoverage '7'

config LoadPlugin
    option library 'olsrd_arprefresh.so.0.1'

config LoadPlugin
    option library 'olsrd_dyn_gw.so.0.5'

config LoadPlugin
    option library 'olsrd_dyn_gw_plain.so.0.4'

config LoadPlugin
    option library 'olsrd_secure.so.0.6'
    option Keyfile '/etc/olsrd.d/olsrd_secure_key'

config LoadPlugin
    option library 'olsrd_txtinfo.so.0.1'
    option accept '0.0.0.0'

config Interface
    list interface 'mesh'
    option Mode 'mesh'
    option Ip4Broadcast '255.255.255.255'


-- 
Ben West
http://gowasabi.net
(spam-protected)
314-246-9434
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20130520/741fbc1f/attachment.html>