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>