<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>