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

[Markus Kittenberger]

arping -c 10 -b -I eth1 193.238.156.158
ARPING to 193.238.156.158 from 193.238.159.57 via eth1
Unicast reply from 193.238.156.158 [0:15:6d:8a:ef:c9] 3.530ms
Unicast reply from 193.238.156.158 [0:15:6d:8a:ef:c9] 3.059ms
Unicast reply from 193.238.156.158 [0:15:6d:8a:ef:c9] 5.067ms
Unicast reply from 193.238.156.158 [0:15:6d:8a:ef:c9] 2.032ms
Unicast reply from 193.238.156.158 [0:15:6d:8a:ef:c9] 3.358ms
Unicast reply from 193.238.156.158 [0:15:6d:8a:ef:c9] 1.960ms
Sent 10 probes (10 broadcast(s))
Received 6 replies

-> nlq of 0.6

as u get unicast replies (with retransmits), but send out broadcasts, u can
measure #1 outgoing link-quality (NLQ) quite accuretely this way.

to measure both directions, run it own both sides.


Markus

#1 without olsrd, or "any" requirements on the neighbours node.

On Mon, Oct 24, 2011 at 2:45 PM, Denia Bouhired <(spam-protected)>wrote:

>  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)>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)>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)
>>> 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)
>>
>>
>
>
> --
> 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/8776bc64/attachment.html>