<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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 class="moz-txt-link-abbreviated" href="mailto:denia.bouhired@epfl.ch">denia.bouhired@epfl.ch</a></pre>
</body>
</html>