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

[Denia Bouhired]

Thank you for your response. Would you be able to give me more detailed
instructions on using arp for link sensing as we are not too sure on how
to do that.
Denia


On 10/24/2011 02:39 PM, Markus Kittenberger wrote:
> in a topology that small (3 nodes) fisheye makes no difference,..
>
> also rooting loops do not affect the link-sensing,..
>
> so there must be another (very likely not olsrd related) reason to
> explain why the linkcsot between stationary nodes A and B change when
> C moves away,..
>
> Markus
>
> p.s. maybe try to do your own linksensing,. to exclude your wireless
> links really works.
>
> e.g. arping (with broadcasts) on both of your the links in both directions
>
> On Mon, Oct 24, 2011 at 1:58 PM, Denia Bouhired
> <(spam-protected) <mailto:(spam-protected)>> wrote:
>
>
>     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 <tel:%2B41%20%280%29%2021%20693%2081%2011>
>     e-mail: (spam-protected) <mailto:(spam-protected)>
>
>


-- 
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/713ae95a/attachment.html>