Ben West | 20 May 2013 07:59
Favicon

Accepting packets from nodes with very old localtime

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
--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users
LuigiScop | 19 May 2013 09:26
Picon

olsrd running .Very basic

I 'm trying to run olsrd on my Linux ubuntu by following the procedure 
on https://code.commotionwireless.net/projects/commotion-linux

I get the error:
lscopelliti <at> lscopelliti-Latitude-E4310:~$ sudo /etc/init.d/olsrd start
Setting mesh on 'wlan0' to channel 5:
     attaching to 'commotionwireless.net' with BSSID '02:ca:ff:ee:ba:be'
Turning off NetworkManager wifi control: done
Setting up ad-hoc networking: Error for wireless request "Set Bit Rate" 
(8B20) :
     SET failed on device wlan0 ; Network is down.
done
Setting up IP address: done
OLSR ad-hoc setup on wlan0 using commotionwireless.net on channel 5 with 
IP 172.29.135.151
     ad-hoc Cell BSSID: 00:00:00:00:00:00
olsrd already running, doing nothing.

Any help?

Thanks.

luigi

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

Ferry Huberts | 16 May 2013 19:17
Gravatar

[announce] olsrd 0.6.4.1 released & release-0.6.4 branch EOL

Hello olsrd users/developers,

Henning has just released olsrd 0.6.4.1, see http://www.olsr.org/?q=download

It contains an important buffer overflow fix for the txtinfo plugin and
all users are strongly advised to upgrade.

===========
End-Of-Life
===========
This marks the end-of-life for the release-0.6.4 branch.
It has been removed from the repository and users are strongly urged to
move to a newer version.

> 0.6.4.1 -------------------------------------------------------------------
> 
> Ferry Huberts (20):
>       main: add release script
>       release: move the stringTrim function up a bit
>       release: make gitIsGitDirectory do the correct thing
>       release: fix usage of literal dot in regular expressions
>       release: move into the base directory earlier
>       release: convert some code into checkIsOlsrdGitCheckout function
>       release: convert some code into checkGitSigningKeyIsConfigured function
>       release: convert some code into getPrevRelTag function
>       release: the script can now also create a release branch
>       release: use olsrd-version prefix for files in the tarballs
>       Remove mercurial ignore file; we use git
>       build: ignore builddata.c when hashing sources
>       release: fix the list of generated files
>       release: update some comments
>       release: refactor the checkVersionIncrementing function
>       release: do not update the version on master when it's already higher
>       release: only report that master changed when it was actually changed
>       release: checkVersionIncrementing: optionally allow equal versions
>       release: also check against the Makefile version when branching
>       txtinfo: prevent buffer overflow
> 
> Henning Rogge (2):
>       Fix multicast join for IPv6
>       Release v0.6.4.1

-- 
Ferry Huberts

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

Saverio Proto | 9 May 2013 22:17
Picon
Gravatar

Re: [Olsr-dev] Configuring TC redundancy parameter?

> do you mean a parameter to have a static hop cost between two nodes
> regardless of any ETX statistic ?
>
> I wish we had it instead of LinkQualityMult ! We actually started some
> experimental work at ninux but it is not trivial at all to implement
> it :)
>
> Saverio

please look at this branch:
https://github.com/zioproto/olsrd/commits/lq-fixed-metric

there is a new parameter LinkLossFixed

there is for sure a lot of bugs still to fix :)

ciao :)

Saverio

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

chris - | 9 May 2013 21:38
Picon
Gravatar

Re: [Olsr-dev] Configuring TC redundancy parameter?

Yes, that's what I mean. It's a shame it's not available.


On Thu, May 9, 2013 at 11:45 AM, Saverio Proto <zioproto <at> gmail.com> wrote:
> Saverio, that's helpful advice. I also was able to look up how these two
> algorithms work. One thing: is there a parameter for hop cost?

do you mean a parameter to have a static hop cost between two nodes
regardless of any ETX statistic ?

I wish we had it instead of LinkQualityMult ! We actually started some
experimental work at ninux but it is not trivial at all to implement
it :)

Saverio

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users
Henning Rogge | 9 May 2013 21:02

Re: [Olsr-dev] Configuring TC redundancy parameter?

Maybe we should talk about "Metric Postprocessing" on the WCW in Berlin...

an optional layer to modify metric values before they are pushed into
TCs and Hellos.

Henning

On Thu, May 9, 2013 at 8:45 PM, Saverio Proto <zioproto <at> gmail.com> wrote:
>> Saverio, that's helpful advice. I also was able to look up how these two
>> algorithms work. One thing: is there a parameter for hop cost?
>
> do you mean a parameter to have a static hop cost between two nodes
> regardless of any ETX statistic ?
>
> I wish we had it instead of LinkQualityMult ! We actually started some
> experimental work at ninux but it is not trivial at all to implement
> it :)
>
> Saverio
>
> --
> Olsr-dev mailing list
> Olsr-dev <at> lists.olsr.org
> https://lists.olsr.org/mailman/listinfo/olsr-dev

-- 
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

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

Breno Silva | 9 May 2013 14:21
Picon

OLSR between different networks

Hello,

I would like to setup OLSR between some computers, however each computer is connected in a Radio (ethernet interface) and they transmit data to each other using a wireless radio interface.

The radio is Half-Duplex and i already com send IP/UDP data to each other. This is a common flow to send/recv data

COMPUTER1 (10.1.1.2)  <-> (10.1.1.1) RADIO1 ( 192.168.0.1)  <------------------>              (192.168.0.2) RADIO2 (10.1.2.1) <-> COMPUTER2 (10.1.2.2).

So each computer is a member of different network. I would like to know if the OLSRD will work with this environment.

Thanks

Breno
--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users
Henning Rogge | 7 May 2013 07:22
Picon
Favicon

Re: [Olsr-dev] Configuring TC redundancy parameter?

On 05/06/2013 09:19 PM, chris - wrote:
> Thanks very much for your reply. My thought is that using solely the MPR
> set may increase reliability in our particular routing scenario, however
> it would be too much work to test. It may make a good project, though.

There are two reasons why MPRs make networks unreliable with the current 
implementation.

The first one is that the ETX metric tends to go up and down on all 
links except the ones with no packet loss at all (see 
http://en.wikipedia.org/wiki/Bernoulli_trial). This means even a totally 
stable network will give you some fluctiations because you can only 
measure packet loss, not the loss-probability itself.

The second one is that the current MPR algorithm is a pure greedy 
algorithm, which doesn't care about the former MPR set. This means there 
are situations where it will constantly switch MPR settings because of 
metric fluctuations. Which will result in a more instable flooding of 
control traffic.

Henning Rogge
-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:henning.rogge <at> fkie.fraunhofer.de http://www.fkie.fraunhofer.de

Attachment (smime.p7s): application/pkcs7-signature, 6169 bytes
--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users
chris - | 3 May 2013 23:09
Picon
Gravatar

Configuring TC redundancy parameter?

Hello all,

I'm running olsrd v 0.6.1 on openwrt. I set TcRedundancy=0 in the olsr.conf.base and got a message like: "Sorry, tc-redundancy 0/1 are not working on 0.5.6. It was discovred late in the stable tree development and cannot bes olved without a difficult change in the dijkstra code ... ". Then olsrd exited. I notice that TcRedundancy=2 works. Also, if TcRedundancy is unspecified, olsrd starts with no problem.

Has this been fixed in the latest version or are there plans to fix it? Also, could someone point me to the relevant route calculation section of the code of the code?

Thanks in advance for any help!
Chris Patton

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users
Simon Ebnicher | 30 Apr 2013 17:06
Picon

Routing problem with bad ETX

Hi,
we have set up a small OLSR mesh network with three routers (TP-Link
TL-WDR3600 running OpenWrt 12.09rc1, olsrd 0.6.3). We placed two routers
near to each other, and the third router at quite some distance.
R1 <----ETX:~1----> R2 <---------------ETX: 1.x to 2.x-----------> R3

The ETX on the direct link between R1 and R3 is usually below 2 (about
1.3 to 1.7), so the direct route is preferred. However, the direct route
is completely unusable for data transfer (e.g., ping reports >95% packet
loss). As soon as two hop route via R2 is used, ping and other traffic
works fine.
We are wondering why the unreliable link is rated too optimistically. We
suspect that the Hello and TC multicast packets (which are used to
calculate the ETX) may have a better reception probability than unicast
packets (e.g., because they are sent at lower rates, no RTS/CTS). This
would lead to ETX values that do not reflect the link accurately.

Can anyone confirm or explain this behaviour and maybe offer a solution?

Best regards,
Simon Ebnicher

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

Vigneswaran R | 30 Apr 2013 09:08

dlep-app reg.

Hello,

Just curious to know about dlep-app 
<http://wiki.confine-project.eu/soft:dlep> as it seems to be a 
preliminary working version of DLEP (yet to try).

1. What version of dlep-draft is being used as the basis for dlep-app?
2. What custom changes make it not inter-operable with the existing 
drafts? (please point me to the documents or white paper, if any)

Thank you.

Regards,
Vignesh

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users


Gmane