<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 06/09/2014 02:11 PM, Henning Rogge
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAGnRvuoPOHK8b42OD59wd1-TNKYM=XoTf=Op-HHUHAKzKUSCLQ@mail.gmail.com"
      type="cite">
      <pre wrap="">I wrote a patch to include the MPRs into the "nhdp neighbor" telnet
command of OLSRd2, but I don't have  a testing setup at home.

If you want you can test it.</pre>
    </blockquote>
    <br>
    Thanks for your quick reply and the patch was very helpful.<br>
    <br>
    Below is the output of running the "nhdp neighbor" on all the
    routers.<br>
    <br>
    <b>On R1<br>
      =====<br>
    </b><br>
    Neighbor: symmetric flood-MPR=yes flood-MPRS=no<br>
        Metric 'mpr' (0): routing-MPR=yes, routing-MPR=no<br>
        Address: 10.1.2.1<br>
        Address: 10.1.2.2<br>
    <br>
    What I understand from the above is, R2 is selected as a Flooding as
    well as Routing MPR for R1. However, R2 hasn't selected R1 as
    routing or flooding MPR.<br>
    <br>
    <b>On R2<br>
      =====<br>
    </b><br>
    Neighbor: symmetric flood-MPR=no flood-MPRS=yes<br>
        Metric 'mpr' (0): routing-MPR=no, routing-MPR=yes<br>
        Address: 10.1.1.1<br>
    Neighbor: symmetric flood-MPR=yes flood-MPRS=no<br>
        Metric 'mpr' (0): routing-MPR=yes, routing-MPR=yes<br>
        Address: 10.1.3.1<br>
        Address: 10.1.3.2<br>
    <br>
    Here the additional information is, R3 is selected as a Flooding as
    well as routing MPR for R2. <b>However, R3 selected R2 only as
      routing MPR; not as flooding MPR</b>. I think, this is the
    problem.<br>
    <br>
    <b>On R3<br>
      =====<br>
    </b><br>
    Neighbor: symmetric flood-MPR=no flood-MPRS=yes<br>
        Metric 'mpr' (0): routing-MPR=yes, routing-MPR=yes<br>
        Address: 10.1.2.1<br>
        Address: 10.1.2.2<br>
    Neighbor: symmetric flood-MPR=no flood-MPRS=no<br>
        Metric 'mpr' (0): routing-MPR=no, routing-MPR=yes<br>
        Address: 10.1.4.1<br>
        Address: 10.1.4.2<br>
    <br>
    Here, the additional information is, R4 is not selected as a
    Flooding or Routing MPR for R3. However, R4 selected R3 as its
    Routing MPR; not flooding MPR. I think, this is fine (as R4 doesn't
    have to create TC to be forwarded).<br>
    <br>
    <b>On R4<br>
      =====<br>
    </b><br>
    Neighbor: symmetric flood-MPR=no flood-MPRS=no<br>
        Metric 'mpr' (0): routing-MPR=yes, routing-MPR=no<br>
        Address: 10.1.3.1<br>
        Address: 10.1.3.2<br>
    <br>
    Nothing new here.<br>
    <br>
    <br>
    Regards,<br>
    Vignesh<br>
    <br>
    <blockquote
cite="mid:CAGnRvuoPOHK8b42OD59wd1-TNKYM=XoTf=Op-HHUHAKzKUSCLQ@mail.gmail.com"
      type="cite">
      <pre wrap="">

Henning

On Mon, Jun 9, 2014 at 8:49 AM, Vigneswaran R <a class="moz-txt-link-rfc2396E" href="mailto:vignesh@atc.tcs.com"><vignesh@atc.tcs.com></a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">On 06/09/2014 12:09 PM, Henning Rogge wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">
Just a thought I had,

did you try to use the "MPR plugin" ? I ask because its quite new and
needs a lot more testing.
</pre>
        </blockquote>
        <pre wrap="">

No. I haven't.

Also, I verified the logs and couldn't find any TC messages (Message type:
1) generated by R1 or R4 (the end nodes).

Is there any way to query the olsrd2 daemon about MPR related information?


Regards,
Vignesh


</pre>
        <blockquote type="cite">
          <pre wrap="">Henning

On Sat, Jun 7, 2014 at 4:02 AM, vignesh <a class="moz-txt-link-rfc2396E" href="mailto:vignesh@atc.tcs.com"><vignesh@atc.tcs.com></a> wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">
On 2014-06-06 18:41, Henning Rogge wrote:
</pre>
            <blockquote type="cite">
              <pre wrap="">
Hi,

just to make sure, you can see all four nodes producing TC messages?
</pre>
            </blockquote>
            <pre wrap="">

I remember only R2 and R3 produced TC. However, I will recheck the logs
on
Monday.
(I have under the impression that only ROUTING MPRs will generate TC, and
in
this topology, R2, R3 may be the MPRs for its neighbours).


</pre>
            <blockquote type="cite">
              <pre wrap="">Maybe I have to replicate this setup when I am back at work on
Tuesday, I have no clue what is going on.
</pre>
            </blockquote>
            <pre wrap="">

Ok. At this point what I suspect is, R3 is not selecting R2 as MPR. So,
the
TC message generated by R3 (which contains information about R4 also) is
not
reaching R1. So, R1 is not getting route for R4. Could you please tell
how
to verify the above from the logs? Esp. how to see information about
MPRs?


R1 <---> R2 <---> R3 <---> R4

If you would like to look into the logs I can compress the logs and send
you. Thanks.

Regards,
Vignesh


</pre>
            <blockquote type="cite">
              <pre wrap="">Henning

On Fri, Jun 6, 2014 at 2:38 PM, Vigneswaran R <a class="moz-txt-link-rfc2396E" href="mailto:vignesh@atc.tcs.com"><vignesh@atc.tcs.com></a>
wrote:
</pre>
              <blockquote type="cite">
                <pre wrap="">
On 06/06/2014 02:58 PM, Vigneswaran R wrote:

On 06/06/2014 02:23 PM, Vigneswaran R wrote:

On 06/06/2014 01:01 PM, Henning Rogge wrote:

On Fri, Jun 6, 2014 at 9:39 AM, Bastian Bittorf
<a class="moz-txt-link-rfc2396E" href="mailto:bittorf@bluebottle.com"><bittorf@bluebottle.com></a>
wrote:

* Vigneswaran R <a class="moz-txt-link-rfc2396E" href="mailto:vignesh@atc.tcs.com"><vignesh@atc.tcs.com></a> [06.06.2014 09:37]:

Could you please help in debugging these problems? Thanks.

can you show is you commandline or config? bye, bastian

The output of "ip addr" on every node would also help.


Command Line:

     ./olsrd2 -l olsrd2.conf

Configuration file contents:

[interface=eth0]
[interface=eth1]

Exception: On R1, only eth1 included.

IP Addr: (pfa the complete output)

R1: eth0: 1.0.0.2/24 (non-olsr), eth1: 10.1.1.1/32
R2: eth0: 10.1.2.1/32, eth1: 10.1.2.2/32
R3: eth0: 10.1.3.1/32, eth1: 10.1.3.2/32
R4: eth0: 10.1.4.1/32, eth1: 10.1.4.2/32

(I am using /32 mask for testing. However, I got the same problem with
/8
mask also).

Please let me know if any other information is required.


PFA the output of the following command on all the nodes. Please see
whether
this helps.

echo "nhdp neighlink" | nc 127.0.0.1 2009


Restarted olsrd2 with debug=all and observed the following from the
collected logs,

1. R1 received TC messages originated from R2 (10.1.2.1) only.
   -- Shouldn't it get TC from 10.1.3.1 also? I think, this is the
reason
why
R1 is not getting route for R4.

2. R2 received TC messages originated from R3 (10.1.3.1) only.
   -- I think, this is fine for the 4 nodes topology.

3. R3 received TC messages originated from R2 (10.1.2.1) only.
   -- this is also fine for the same reason.

4. R4 received TC messages originated from both R2 (10.1.2.1) and R3
(10.1.3.1).

If you want me to post specific portions of the log files, please
suggest.

Regards,
Vignesh



Regards,
Vignesh




--
Olsr-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Olsr-dev@lists.olsr.org">Olsr-dev@lists.olsr.org</a>
<a class="moz-txt-link-freetext" href="https://lists.olsr.org/mailman/listinfo/olsr-dev">https://lists.olsr.org/mailman/listinfo/olsr-dev</a>
</pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
        <pre wrap="">

</pre>
      </blockquote>
    </blockquote>
    <br>
  </body>
</html>