[Olsr-users] Problem with establishing robust relaying in OLSRD

[Denia Bouhired]

Hello all,

Basically we're trying to run olsrd in embedded devices to create
dynamic mesh networks. We have however been facing problems with olsrd
that we are finding difficult to understand, let alone fix.

In a simple 3 node setting with nodes A B C, we tried to cause some
relaying to happen from A to C through B.

A<--->B<--->C
A<------------>C

We have tried to do this both physically by moving nodes A and C out of
sight of each other and also by introducing a link multiplyer in
olsrd.conf between A and C. We tried both etx_ff and etx_fpm for this,
with little improvement from both. Find attached the olsrd.conf file, we
are using olsrd 0.6.3.

In the case where we tried to break the link physically between A and C,
by, say, having A and B fixed and C moving away from A but within LOS to
C, such that:

A<--->B<--->C
A<      x       >C

What happens is that the link between A and B starts to degrade even
though the two of them haven't moved and only C has. If C comes back to
it's original position than the link between A and B is re-established
again.


In another instance, of what we think is the same problem, we manage to
establish a 2-hop link between A and C by forcing a link multiplyer
between A and C so for instance

t1: A<--------------ETX=4------------->C  #Only two nodes in the
network, only one route exists
t2: A<---ETX=1--->B<---ETX=1--->C  #Node B inserted, olsrd chooses lower
cost route through B, ETX=2

The switch between routes was seemless as soon as node B is up in the
network. This result has been repeatable for any number of power off and
reboots of node B, the routing table can switch between direct and 2-hop
links without any problem. The problem has manifested itself when, for
instance, node C is moved away, then, not only the links from A to B and
B to C are lost (normal) but alarmingly the link between A and C also
disappears from the topology and then it is impossible to re-establish
communication between A and C unless olsrd is restarted. **Even though
their state hasn't changed.**

As you can see  from the config file, we have enabled the fish-eye
algorithm as we thought it might be a solution, but it hasn't made any
difference as far as we can tell.

This same problem has happend to us in various settings, but not
consistently, so it has not been repeatable. I must also say that most
times this had happened we had been trying to establish a VoIP link
between A and C with B relaying the conversation.

We are at loss as to what causes this problem and how to fix it, I hope
my explanation has been detailed enough and that you'll be able to give
me some suggestions.

Cheers
Denia


 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: olsrd.conf
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20111024/e0df898c/attachment.ksh>