[Olsr-users] Problem with establishing robust relaying in OLSRD
Markus Kittenberger
(spam-protected)
Thu Oct 27 12:09:03 CEST 2011
On Thu, Oct 27, 2011 at 11:41 AM, Michael Rack <
(spam-protected)> wrote:
> 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).
>
how long did u wait?
and what are u hello intervals/timeouts on node B and 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)>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)
>>
>>
>
>
> --
> 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)
>
>
>
>
> --
> Olsr-users mailing list
> (spam-protected)
> https://lists.olsr.org/mailman/listinfo/olsr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20111027/e0780f2e/attachment.html>
More information about the Olsr-users
mailing list