<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body 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.<br>
    <br>
    On 10/24/2011 01:56 PM, Markus Kittenberger wrote:
    <blockquote
cite="mid:CAKNLPNKYge5kN0XW3ZYRBio7F49imeX+o-8R+6ktQ5u0sS4S1A@mail.gmail.com"
      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">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">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>
    <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>