<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 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></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 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 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>
</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 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>
</div></div></div>
</blockquote></div><br>