[Olsr-users] Problem with establishing robust relaying in OLSRD
Michael Rack
(spam-protected)
Thu Oct 27 11:41:09 CEST 2011
Hi Guys,
i'm not sure, but i think i've noticed the same problem but on a
ethernet-link running olsr.
> [Olsr-users] route discovery perform not that well | loosing routes
> Am 16.10.2011 16:26, schrieb Michael Rack:
>
> /-- link1 -- (C)
> / |
> (A) -- vpn -- (B) - link2
> \ |
> \-- link3 -- (D)
All links / routes are up and running. But when i drop OLSR-Packets on
Node (D) for "link3 (B<->D)" Node (A) is not able to see (D).
The really strange behavior is, that Node (D) can see all other Nodes
and can communicate with each other except Node (A). After restarting
OLSR on Node (B), Node (A) can reach (D) and vice versa.
i am using LinkQualityAlgorithm=etx_ff; Willingness=3; LinkQualityLevel=2
Liebe Grüße aus Freilassing,
Michael Rack
RSM Freilassing
--
RSM Freilassing Tel.: +49 8654 607110
Nocksteinstr. 13 Fax.: +49 8654 670438
D-83395 Freilassing www.rsm-freilassing.de
Am 27.10.2011 10:46, schrieb Denia Bouhired:
> Hello Markus,
>
> Thank you for your advice, and sorry for the belated reply as we are
> at our wits-end trying to debug this problem.
> Actually you were right it seems it has nothing to do with OLSRD, as
> the link seems to have the same behaviour without olsrd runnning.
> Also note that in the original long description, the effect didn't
> seem to be symmetrical, so basically if A is taken away from the
> network, the same effect would not be seen between C and B.
> We think it has something to do with the WiFi dongles we're using
> which have a WPS (Wifi Protected Setup) capability, which may (or may
> not) be causing the problem.I know WPS isn't supposed to be active in
> adhoc mode, but it seems like somehow the driver is setting one dongle
> as a master (AP like device) without which the network seems to fall
> apart, the network is re-established when it comes nearer again.
>
> Have you got any ideas about this (although I know it's outside the
> scope of this mailing list)?
> Many thanks and regards,
> Denia
>
>
> On 10/24/2011 03:42 PM, Markus Kittenberger wrote:
>> 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) <mailto:(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) <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 <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/20111027/ad775a84/attachment.html>
More information about the Olsr-users
mailing list