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