Hi Henning,<br><br>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.<br><br>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.<br>
<br><div style="margin-left:40px"># This is a hack to set localtime to something current enough so that<br># remote a OLSRd instance will accept packets from this node.<br><br># Get date/time components of most recent filemod under /etc/somewhere/current<br>
FILELISTING=`ls -l -u -e /etc/somewhere/current | tail -1`<br>[ -n "${FILELISTING}" ] && {<br> FILEMOD_YYYY=`echo $FILELISTING | awk '{printf "%d", $10}'`<br> FILEMOD_HHMMSS=`echo $FILELISTING | awk '{printf "%s", $9}'`<br>
FILEMOD_DD=`echo $FILELISTING | awk '{printf "%s", $8}'`<br> FILEMOD_MONTH=`echo $FILELISTING | awk '{printf "%s", $7}'`<br><br> # Convert Month to numerical MM format<br> case "${FILEMOD_MONTH}" in<br>
"Jan") FILEMOD_MM="01" ;;<br> "Feb") FILEMOD_MM="02" ;;<br> "Mar") FILEMOD_MM="03" ;;<br> "Apr") FILEMOD_MM="04" ;;<br>
"May") FILEMOD_MM="05" ;;<br> "Jun") FILEMOD_MM="06" ;;<br> "Jul") FILEMOD_MM="07" ;;<br> "Aug") FILEMOD_MM="08" ;;<br>
"Sep") FILEMOD_MM="09" ;;<br> "Oct") FILEMOD_MM="10" ;;<br> "Nov") FILEMOD_MM="11" ;;<br> "Dec") FILEMOD_MM="12" ;;<br>
*) FILEMOD_MM="01" ;;<br> esac<br> <br> # Set local date/time, assuming format "YYYY-MM-DD hh:mm:ss"<br> DATE="${FILEMOD_YYYY}-${FILEMOD_MM}-${FILEMOD_DD} $FILEMOD_HHMMSS"<br>
date -s "${DATE}"<br>}<br></div><br>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?<br>
<br><div class="gmail_quote">On Mon, May 20, 2013 at 3:15 AM, Henning Rogge <span dir="ltr"><<a href="mailto:hrogge@googlemail.com" target="_blank">hrogge@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, May 20, 2013 at 7:59 AM, Ben West <<a href="mailto:ben@gowasabi.net">ben@gowasabi.net</a>> wrote:<br>
> I've been testing a TP-Link TL-MR3020 running OpenWRT Attitude Adjustment<br>
> v12.09, albeit custom compiled to include the recent release olsrd v0.6.5.4.<br>
> This particular device has no internal hardware clock (not unusual for<br>
> low-cost consumer-grade wifi routers), and it does consistently boot up with<br>
> local time at 1 Jan 1970, which I've found causes other nodes to reject its<br>
> OLSR packets.<br>
<br>
</div>If I understand the code right the neighbors of the OLSR node should<br>
forget the last stored timestamp after 30 seconds with no valid<br>
packet.<br>
<div class="im"><br>
> Besides that, is it possible to somehow disable timestamp checking for<br>
> incoming OLSR packets? Or is this a drawback of using the (now presumably<br>
> outdated) secure plugin?<br>
<br>
</div>If you disable the timestamps you will be open to replay attacks,<br>
which are a trivial way to disrupt your network.<br>
<br>
The alternative would be to use some kind of linklayer-security, it<br>
would offer you practically the same security for OLSR than the secure<br>
plugin, most likely even more.<br>
<br>
Henning Rogge<br>
<br>
--<br>
We began as wanderers, and we are wanderers still. We have lingured<br>
long enough on the shores of the cosmic ocean. We are ready at last to<br>
set sail for the stars - Carl Sagan<br>
</blockquote></div><br><br clear="all"><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>