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.<br>
<br>Here is a snippet from the olsrd debug output on the gateway node for this TP-Link node:<br><br><div style="margin-left:40px">Recevied hash:<br> ...<br>Calculated hash:<br> ...<br>[ENC]Match for 5.201.40.204<br>[ENC]Timestamp slack: -2147483648<br>
[ENC]Timestamp scew detected!!<br>[ENC]Timestamp missmatch in packet from 5.201.40.204!<br>[ENC]Rejecting packet from 5.201.40.204<br>[ENC]Adding signature for packet size 20<br>[ENC]timestamp: 1369027304<br>Signature message:<br>
   10    0    0   36<br>    5   49    3   43<br>    1    0  136  112<br>    1    2    0    0<br>   81  153  178  232<br>  249  200  155  145<br>  129   37  154  191<br>  125  220  118   79<br>   67  201   81   35<br>[ENC] Message signed<br>
INTERNET GATEWAY VIA eth0 detected in routing table.<br>[ENC]Checking packet for challenge response message...<br>Input message:<br>   10    0    0   36<br>    5  201   40  204<br>    1    0  132   58<br>    1    2    0    0<br>
    0    0    3  146<br>  210    5  117   73<br>   30   93   35   39<br>  117   64  115  152<br>  167  254  218  235<br clear="all"></div><br>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.<br>
<br>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?<br>
<br>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?<br><br>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:<br>
<br><div style="margin-left:40px">config olsrd<br>    option IpVersion '4'<br>    option LinkQualityLevel '2'<br>    option LinkQualityAlgorithm 'etx_ffeth'<br>    option SmartGateway 'yes'<br>
    option Pollrate '0.2'<br>    option UseHysteresis 'no'<br>    option TcRedundancy '2'<br>    option MprCoverage '7'<br><br>config LoadPlugin<br>    option library 'olsrd_arprefresh.so.0.1'<br>
<br>config LoadPlugin<br>    option library 'olsrd_dyn_gw.so.0.5'<br><br>config LoadPlugin<br>    option library 'olsrd_dyn_gw_plain.so.0.4'<br><br>config LoadPlugin<br>    option library 'olsrd_secure.so.0.6'<br>
    option Keyfile '/etc/olsrd.d/olsrd_secure_key'<br><br>config LoadPlugin<br>    option library 'olsrd_txtinfo.so.0.1'<br>    option accept '0.0.0.0'<br><br>config Interface<br>    list interface 'mesh'<br>
    option Mode 'mesh'<br>    option Ip4Broadcast '255.255.255.255'<br></div><br><br>-- <br>Ben West<div><a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br>
314-246-9434<br></div>