<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Guys,<br>
<br>
i'm not sure, but i think i've noticed the same problem but on a
ethernet-link running olsr.<br>
<br>
<br>
<blockquote type="cite">[Olsr-users] route discovery perform not
that well | loosing routes<br>
Am 16.10.2011 16:26, schrieb Michael Rack:<br>
<br>
/-- link1 -- (C)
<br>
/ |
<br>
(A) -- vpn -- (B) - link2
<br>
\ |
<br>
\-- link3 -- (D)
</blockquote>
<br>
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).<br>
<br>
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.<br>
<br>
i am using LinkQualityAlgorithm=etx_ff; Willingness=3;
LinkQualityLevel=2<br>
<br>
<pre class="moz-signature" cols="72">Liebe Grüße aus Freilassing,
Michael Rack
RSM Freilassing
--
RSM Freilassing Tel.: +49 8654 607110
Nocksteinstr. 13 Fax.: +49 8654 670438
D-83395 Freilassing <a class="moz-txt-link-abbreviated" href="http://www.rsm-freilassing.de">www.rsm-freilassing.de</a> </pre>
<br>
Am 27.10.2011 10:46, schrieb Denia Bouhired:
<blockquote cite="mid:4EA91A7B.9040505@epfl.ch" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hello Markus,<br>
<br>
Thank you for your advice, and sorry for the belated reply as we
are at our wits-end trying to debug this problem.<br>
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. <br>
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.<br>
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.<br>
<br>
Have you got any ideas about this (although I know it's outside
the scope of this mailing list)?<br>
Many thanks and regards,<br>
Denia<br>
<br>
<br>
On 10/24/2011 03:42 PM, Markus Kittenberger wrote:
<blockquote
cite="mid:CAKNLPN+O8x=bxS6pU2gphqKkbFpds=aj+QzVX9HcuT_j5+Odtg@mail.gmail.com"
type="cite">
<div>arping -c 10 -b -I eth1 193.238.156.158</div>
<div>ARPING to 193.238.156.158 from 193.238.159.57 via eth1</div>
<div>Unicast reply from 193.238.156.158 [0:15:6d:8a:ef:c9]
3.530ms</div>
<div>Unicast reply from 193.238.156.158 [0:15:6d:8a:ef:c9]
3.059ms</div>
<div>Unicast reply from 193.238.156.158 [0:15:6d:8a:ef:c9]
5.067ms</div>
<div>Unicast reply from 193.238.156.158 [0:15:6d:8a:ef:c9]
2.032ms</div>
<div>Unicast reply from 193.238.156.158 [0:15:6d:8a:ef:c9]
3.358ms</div>
<div> Unicast reply from 193.238.156.158 [0:15:6d:8a:ef:c9]
1.960ms</div>
<div>Sent 10 probes (10 broadcast(s))</div>
<div>Received 6 replies</div>
<div><br>
</div>
<div>-> nlq of 0.6</div>
<div><br>
</div>
<div>as u get unicast replies (with retransmits), but send out
broadcasts, u can measure #1 outgoing link-quality (NLQ) quite
accuretely this way.</div>
<div><br>
</div>
<div>to measure both directions, run it own both sides.</div>
<div><br>
</div>
<div><br>
</div>
<div>Markus</div>
<div><br>
</div>
<div>#1 without olsrd, or "any" requirements on the neighbours
node.</div>
<br>
<div class="gmail_quote">On Mon, Oct 24, 2011 at 2:45 PM, Denia
Bouhired <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:denia.bouhired@epfl.ch">denia.bouhired@epfl.ch</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#FFFFFF" text="#000000"> 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.<br>
<font color="#888888"> Denia</font>
<div>
<div class="h5"><br>
<br>
<br>
On 10/24/2011 02:39 PM, Markus Kittenberger wrote:
<blockquote type="cite">in a topology that small (3
nodes) fisheye makes no difference,..
<div><br>
</div>
<div>also rooting loops do not affect the
link-sensing,..</div>
<div><br>
</div>
<div>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,..</div>
<div><br>
</div>
<div>Markus</div>
<div><br>
</div>
<div>p.s. maybe try to do your own linksensing,. to
exclude your wireless links really works.</div>
<div><br>
</div>
<div>e.g. arping (with broadcasts) on both of your
the links in both directions<br>
<br>
<div class="gmail_quote">On Mon, Oct 24, 2011 at
1:58 PM, Denia Bouhired <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:denia.bouhired@epfl.ch"
target="_blank">denia.bouhired@epfl.ch</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
Yes absolutely 100%.<br>
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.
<div>
<div><br>
<br>
On 10/24/2011 01:56 PM, Markus
Kittenberger wrote:
<blockquote type="cite">are u sure, your
wireless interfaces are working (in
adhoc mode)?
<div><br>
</div>
<div>Markus<br>
<br>
<div class="gmail_quote">On Mon, Oct
24, 2011 at 12:41 PM, Denia
Bouhired <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:denia.bouhired@epfl.ch"
target="_blank">denia.bouhired@epfl.ch</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">Hello
all,<br>
<br>
Basically we're trying to run
olsrd in embedded devices to
create<br>
dynamic mesh networks. We have
however been facing problems
with olsrd<br>
that we are finding difficult to
understand, let alone fix.<br>
<br>
In a simple 3 node setting with
nodes A B C, we tried to cause
some<br>
relaying to happen from A to C
through B.<br>
<br>
A<--->B<--->C<br>
A<------------>C<br>
<br>
We have tried to do this both
physically by moving nodes A and
C out of<br>
sight of each other and also by
introducing a link multiplyer in<br>
olsrd.conf between A and C. We
tried both etx_ff and etx_fpm
for this,<br>
with little improvement from
both. Find attached the
olsrd.conf file, we<br>
are using olsrd 0.6.3.<br>
<br>
In the case where we tried to
break the link physically
between A and C,<br>
by, say, having A and B fixed
and C moving away from A but
within LOS to<br>
C, such that:<br>
<br>
A<--->B<--->C<br>
A< x >C<br>
<br>
What happens is that the link
between A and B starts to
degrade even<br>
though the two of them haven't
moved and only C has. If C comes
back to<br>
it's original position than the
link between A and B is
re-established<br>
again.<br>
<br>
<br>
In another instance, of what we
think is the same problem, we
manage to<br>
establish a 2-hop link between A
and C by forcing a link
multiplyer<br>
between A and C so for instance<br>
<br>
t1:
A<--------------ETX=4------------->C
#Only two nodes in the<br>
network, only one route exists<br>
t2:
A<---ETX=1--->B<---ETX=1--->C
#Node B inserted, olsrd chooses
lower<br>
cost route through B, ETX=2<br>
<br>
The switch between routes was
seemless as soon as node B is up
in the<br>
network. This result has been
repeatable for any number of
power off and<br>
reboots of node B, the routing
table can switch between direct
and 2-hop<br>
links without any problem. The
problem has manifested itself
when, for<br>
instance, node C is moved away,
then, not only the links from A
to B and<br>
B to C are lost (normal) but
alarmingly the link between A
and C also<br>
disappears from the topology and
then it is impossible to
re-establish<br>
communication between A and C
unless olsrd is restarted.
**Even though<br>
their state hasn't changed.**<br>
<br>
As you can see from the config
file, we have enabled the
fish-eye<br>
algorithm as we thought it might
be a solution, but it hasn't
made any<br>
difference as far as we can
tell.<br>
<br>
This same problem has happend to
us in various settings, but not<br>
consistently, so it has not been
repeatable. I must also say that
most<br>
times this had happened we had
been trying to establish a VoIP
link<br>
between A and C with B relaying
the conversation.<br>
<br>
We are at loss as to what causes
this problem and how to fix it,
I hope<br>
my explanation has been detailed
enough and that you'll be able
to give<br>
me some suggestions.<br>
<br>
Cheers<br>
<font color="#888888">Denia<br>
<br>
<br>
<br>
<br>
</font><br>
--<br>
Olsr-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:Olsr-users@lists.olsr.org"
target="_blank">Olsr-users@lists.olsr.org</a><br>
<a moz-do-not-send="true"
href="https://lists.olsr.org/mailman/listinfo/olsr-users"
target="_blank">https://lists.olsr.org/mailman/listinfo/olsr-users</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<br>
</div>
</div>
<font color="#888888">
<pre cols="72">--
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.: <a moz-do-not-send="true" href="tel:%2B41%20%280%29%2021%20693%2081%2011" value="+41216938111" target="_blank">+41 (0) 21 693 81 11</a>
e-mail: <a moz-do-not-send="true" href="mailto:denia.bouhired@epfl.ch" target="_blank">denia.bouhired@epfl.ch</a></pre>
</font></div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<br>
<pre cols="72">--
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.: <a moz-do-not-send="true" href="tel:%2B41%20%280%29%2021%20693%2081%2011" value="+41216938111" target="_blank">+41 (0) 21 693 81 11</a>
e-mail: <a moz-do-not-send="true" href="mailto:denia.bouhired@epfl.ch" target="_blank">denia.bouhired@epfl.ch</a></pre>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
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: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:denia.bouhired@epfl.ch">denia.bouhired@epfl.ch</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
</body>
</html>