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 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">
<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></div><div class="h5"><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 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 href="mailto:Olsr-users@lists.olsr.org" target="_blank">Olsr-users@lists.olsr.org</a><br>
<a 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 href="tel:%2B41%20%280%29%2021%20693%2081%2011" value="+41216938111" target="_blank">+41 (0) 21 693 81 11</a>
e-mail: <a href="mailto:denia.bouhired@epfl.ch" target="_blank">denia.bouhired@epfl.ch</a></pre>
</font></div>
</blockquote></div><br></div>