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

[Denia Bouhired]

Yes absolutely 100%.
The problem does not happen all the time. We thought it might be related
to infinite loops between two nodes updating one another, hence why we
though the fish-net algorithm.

On 10/24/2011 01:56 PM, Markus Kittenberger wrote:
> are u sure, your wireless interfaces are working (in adhoc mode)?
>
> Markus
>
> On Mon, Oct 24, 2011 at 12:41 PM, Denia Bouhired
> <(spam-protected) <mailto:(spam-protected)>> wrote:
>
>     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
>
>
>
>
>
>     --
>     Olsr-users mailing list
>     (spam-protected) <mailto:(spam-protected)>
>     https://lists.olsr.org/mailman/listinfo/olsr-users
>
>


-- 
Dr Dénia Bouhired, Postdoctoral researcher

EPFL - École Polytechnique Fédéral de Lausanne
Laboratoire de Communications Mobiles
INR-139, Station 14
CH-1015 Lausanne, Switzerland
Tel.: +41 (0) 21 693 81 11
e-mail: (spam-protected)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20111024/e6069190/attachment.html>