Discussion:
Missing routes and unexpected routes reg.
Vigneswaran R
2014-06-06 07:11:24 UTC
Permalink
Hello,

I am running olsrd2 on four (qemu) virtual machines connected linearly.

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

What I observed is,

1. R1 is not getting the route for R4 (however, R4 establishes route to R1).
-- If I add one more machine R5 (to R4), R1 and R2 are not getting
route for R5. However, R5 is getting route for both.
-- So, it seems, only the last three routers are having routes to all
the other routers.

2. On R2, I am getting a routing entry similar to the following which is
inappropriate, because the target IP is its own IP.

$R2_IP2 via $R3_IP1 dev eth1 proto 100 src $R2_IP1 metric 2 onlink

Similar routing entries are there in R3, R4 also. I am using latest
OLSRd2 (olsrd2 commit 85492, oonf_api commit 2bdf9).

Could you please help in debugging these problems? Thanks.

Regards,
Vignesh
--
Olsr-dev mailing list
Olsr-***@lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Bastian Bittorf
2014-06-06 07:39:01 UTC
Permalink
Post by Vigneswaran R
Could you please help in debugging these problems? Thanks.
can you show is you commandline or config? bye, bastian
--
Olsr-dev mailing list
Olsr-***@lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Henning Rogge
2014-06-06 07:31:35 UTC
Permalink
Post by Bastian Bittorf
Post by Vigneswaran R
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.

Henning
--
Olsr-dev mailing list
Olsr-***@lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Vigneswaran R
2014-06-06 08:53:37 UTC
Permalink
Post by Henning Rogge
Post by Bastian Bittorf
Post by Vigneswaran R
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.


Regards,
Vignesh
Post by Henning Rogge
Henning
Vigneswaran R
2014-06-06 09:28:10 UTC
Permalink
Post by Vigneswaran R
On Fri, Jun 6, 2014 at 9:39 AM, Bastian Bittorf
Post by Bastian Bittorf
Post by Vigneswaran R
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.
./olsrd2 -l olsrd2.conf
[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


Regards,
Vignesh
Vigneswaran R
2014-06-06 12:38:42 UTC
Permalink
Post by Vigneswaran R
Post by Vigneswaran R
On Fri, Jun 6, 2014 at 9:39 AM, Bastian Bittorf
Post by Bastian Bittorf
Post by Vigneswaran R
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.
./olsrd2 -l olsrd2.conf
[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
Post by Vigneswaran R
Regards,
Vignesh
Henning Rogge
2014-06-06 13:11:02 UTC
Permalink
Hi,

just to make sure, you can see all four nodes producing TC messages?

Maybe I have to replicate this setup when I am back at work on
Tuesday, I have no clue what is going on.

Henning
Post by Vigneswaran R
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.
./olsrd2 -l olsrd2.conf
[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
https://lists.olsr.org/mailman/listinfo/olsr-dev
--
Olsr-dev mailing list
Olsr-***@lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
vignesh
2014-06-07 02:02:08 UTC
Permalink
Post by Henning Rogge
Hi,
just to make sure, you can see all four nodes producing TC messages?
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).
Post by Henning Rogge
Maybe I have to replicate this setup when I am back at work on
Tuesday, I have no clue what is going on.
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
Post by Henning Rogge
Henning
On Fri, Jun 6, 2014 at 9:39 AM, Bastian Bittorf
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.
./olsrd2 -l olsrd2.conf
[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
https://lists.olsr.org/mailman/listinfo/olsr-dev
--
Olsr-dev mailing list
Olsr-***@lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Vigneswaran R
2014-06-09 06:49:19 UTC
Permalink
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.
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
Henning
Post by Henning Rogge
Hi,
just to make sure, you can see all four nodes producing TC messages?
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).
Post by Henning Rogge
Maybe I have to replicate this setup when I am back at work on
Tuesday, I have no clue what is going on.
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
Post by Henning Rogge
Henning
Post by Vigneswaran R
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.
./olsrd2 -l olsrd2.conf
[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
https://lists.olsr.org/mailman/listinfo/olsr-dev
--
Olsr-dev mailing list
Olsr-***@lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Henning Rogge
2014-06-09 06:55:15 UTC
Permalink
Okay,

this looks like a bug introduced by the latest "cleanup" of the domain
system... without a MPR algorithm every node should be a MPR, which
means every node should create a TC. Still, even without TCs from 1
and 4, the topology should be connected.

I will try to reproduce the scenario tomorrow at work.

Henning
Post by Vigneswaran R
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.
No. I haven't.
1) generated by R1 or R4 (the end nodes).
Is there any way to query the olsrd2 daemon about MPR related information?
Regards,
Vignesh
Henning
Post by Henning Rogge
Hi,
just to make sure, you can see all four nodes producing TC messages?
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).
Post by Henning Rogge
Maybe I have to replicate this setup when I am back at work on
Tuesday, I have no clue what is going on.
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
Post by Henning Rogge
Henning
On Fri, Jun 6, 2014 at 9:39 AM, Bastian Bittorf
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.
./olsrd2 -l olsrd2.conf
[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
https://lists.olsr.org/mailman/listinfo/olsr-dev
--
Olsr-dev mailing list
Olsr-***@lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Vigneswaran R
2014-06-09 09:32:45 UTC
Permalink
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.
Thanks for your quick reply and the patch was very helpful.

Below is the output of running the "nhdp neighbor" on all the routers.

*On R1
=====
*
Neighbor: symmetric flood-MPR=yes flood-MPRS=no
Metric 'mpr' (0): routing-MPR=yes, routing-MPR=no
Address: 10.1.2.1
Address: 10.1.2.2

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.

*On R2
=====
*
Neighbor: symmetric flood-MPR=no flood-MPRS=yes
Metric 'mpr' (0): routing-MPR=no, routing-MPR=yes
Address: 10.1.1.1
Neighbor: symmetric flood-MPR=yes flood-MPRS=no
Metric 'mpr' (0): routing-MPR=yes, routing-MPR=yes
Address: 10.1.3.1
Address: 10.1.3.2

Here the additional information is, R3 is selected as a Flooding as well
as routing MPR for R2. *However, R3 selected R2 only as routing MPR; not
as flooding MPR*. I think, this is the problem.

*On R3
=====
*
Neighbor: symmetric flood-MPR=no flood-MPRS=yes
Metric 'mpr' (0): routing-MPR=yes, routing-MPR=yes
Address: 10.1.2.1
Address: 10.1.2.2
Neighbor: symmetric flood-MPR=no flood-MPRS=no
Metric 'mpr' (0): routing-MPR=no, routing-MPR=yes
Address: 10.1.4.1
Address: 10.1.4.2

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

*On R4
=====
*
Neighbor: symmetric flood-MPR=no flood-MPRS=no
Metric 'mpr' (0): routing-MPR=yes, routing-MPR=no
Address: 10.1.3.1
Address: 10.1.3.2

Nothing new here.


Regards,
Vignesh
Henning
Post by Vigneswaran R
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.
No. I haven't.
1) generated by R1 or R4 (the end nodes).
Is there any way to query the olsrd2 daemon about MPR related information?
Regards,
Vignesh
Henning
Post by Henning Rogge
Hi,
just to make sure, you can see all four nodes producing TC messages?
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).
Post by Henning Rogge
Maybe I have to replicate this setup when I am back at work on
Tuesday, I have no clue what is going on.
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
Post by Henning Rogge
Henning
On Fri, Jun 6, 2014 at 9:39 AM, Bastian Bittorf
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.
./olsrd2 -l olsrd2.conf
[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
https://lists.olsr.org/mailman/listinfo/olsr-dev
Henning Rogge
2014-06-09 09:40:24 UTC
Permalink
Okay,

I just found the problem... I messed up the merge of the MPR code and
activated it by default.

Please try the most recent commit from the repository (it includes the
/nhdp neighbor update). Now you should NOT get the mpr plugin included
into the executable by default (check with "olsrd2 --version").

Henning
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.
Thanks for your quick reply and the patch was very helpful.
Below is the output of running the "nhdp neighbor" on all the routers.
On R1
=====
Neighbor: symmetric flood-MPR=yes flood-MPRS=no
Metric 'mpr' (0): routing-MPR=yes, routing-MPR=no
Address: 10.1.2.1
Address: 10.1.2.2
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.
On R2
=====
Neighbor: symmetric flood-MPR=no flood-MPRS=yes
Metric 'mpr' (0): routing-MPR=no, routing-MPR=yes
Address: 10.1.1.1
Neighbor: symmetric flood-MPR=yes flood-MPRS=no
Metric 'mpr' (0): routing-MPR=yes, routing-MPR=yes
Address: 10.1.3.1
Address: 10.1.3.2
Here the additional information is, R3 is selected as a Flooding as well as
routing MPR for R2. However, R3 selected R2 only as routing MPR; not as
flooding MPR. I think, this is the problem.
On R3
=====
Neighbor: symmetric flood-MPR=no flood-MPRS=yes
Metric 'mpr' (0): routing-MPR=yes, routing-MPR=yes
Address: 10.1.2.1
Address: 10.1.2.2
Neighbor: symmetric flood-MPR=no flood-MPRS=no
Metric 'mpr' (0): routing-MPR=no, routing-MPR=yes
Address: 10.1.4.1
Address: 10.1.4.2
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).
On R4
=====
Neighbor: symmetric flood-MPR=no flood-MPRS=no
Metric 'mpr' (0): routing-MPR=yes, routing-MPR=no
Address: 10.1.3.1
Address: 10.1.3.2
Nothing new here.
Regards,
Vignesh
Henning
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.
No. I haven't.
1) generated by R1 or R4 (the end nodes).
Is there any way to query the olsrd2 daemon about MPR related information?
Regards,
Vignesh
Henning
Hi,
just to make sure, you can see all four nodes producing TC messages?
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).
Maybe I have to replicate this setup when I am back at work on
Tuesday, I have no clue what is going on.
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
Henning
On Fri, Jun 6, 2014 at 9:39 AM, Bastian Bittorf
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.
./olsrd2 -l olsrd2.conf
[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
https://lists.olsr.org/mailman/listinfo/olsr-dev
--
Olsr-dev mailing list
Olsr-***@lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Vigneswaran R
2014-06-09 10:45:21 UTC
Permalink
Post by Henning Rogge
Okay,
I just found the problem... I messed up the merge of the MPR code and
activated it by default.
Please try the most recent commit from the repository (it includes the
/nhdp neighbor update). Now you should NOT get the mpr plugin included
into the executable by default (check with "olsrd2 --version").
Yeah.. it's working now. Thanks.

After excluding 'mpr' plugin, every node is getting route to the other
nodes. One thing I noticed is, every node is selecting the neighbors as
MPRs. So, I assume that MPR optimization will be done by the 'mpr'
plugin only.

*Note:* I have done the above test with the code committed upto 05th
June (inclusive). If I include the commits from 06th June, I am getting
the following runtime error.

Cannot find loader for parameter 'Debug'
Error, unknown config io '/root/olsrd2.conf'.


Regards,
Vignesh
Post by Henning Rogge
Henning
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.
Thanks for your quick reply and the patch was very helpful.
Below is the output of running the "nhdp neighbor" on all the routers.
On R1
=====
Neighbor: symmetric flood-MPR=yes flood-MPRS=no
Metric 'mpr' (0): routing-MPR=yes, routing-MPR=no
Address: 10.1.2.1
Address: 10.1.2.2
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.
On R2
=====
Neighbor: symmetric flood-MPR=no flood-MPRS=yes
Metric 'mpr' (0): routing-MPR=no, routing-MPR=yes
Address: 10.1.1.1
Neighbor: symmetric flood-MPR=yes flood-MPRS=no
Metric 'mpr' (0): routing-MPR=yes, routing-MPR=yes
Address: 10.1.3.1
Address: 10.1.3.2
Here the additional information is, R3 is selected as a Flooding as well as
routing MPR for R2. However, R3 selected R2 only as routing MPR; not as
flooding MPR. I think, this is the problem.
On R3
=====
Neighbor: symmetric flood-MPR=no flood-MPRS=yes
Metric 'mpr' (0): routing-MPR=yes, routing-MPR=yes
Address: 10.1.2.1
Address: 10.1.2.2
Neighbor: symmetric flood-MPR=no flood-MPRS=no
Metric 'mpr' (0): routing-MPR=no, routing-MPR=yes
Address: 10.1.4.1
Address: 10.1.4.2
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).
On R4
=====
Neighbor: symmetric flood-MPR=no flood-MPRS=no
Metric 'mpr' (0): routing-MPR=yes, routing-MPR=no
Address: 10.1.3.1
Address: 10.1.3.2
Nothing new here.
Regards,
Vignesh
Henning
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.
No. I haven't.
1) generated by R1 or R4 (the end nodes).
Is there any way to query the olsrd2 daemon about MPR related information?
Regards,
Vignesh
Henning
Hi,
just to make sure, you can see all four nodes producing TC messages?
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).
Maybe I have to replicate this setup when I am back at work on
Tuesday, I have no clue what is going on.
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
Henning
On Fri, Jun 6, 2014 at 9:39 AM, Bastian Bittorf
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.
./olsrd2 -l olsrd2.conf
[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
https://lists.olsr.org/mailman/listinfo/olsr-dev
Henning Rogge
2014-06-09 11:00:00 UTC
Permalink
Post by Vigneswaran R
Cannot find loader for parameter 'Debug'
Error, unknown config io '/root/olsrd2.conf'.
Okay, should be fixed now too... too much work on OpenWRT without
checking the native x86 build.

Henning
--
Olsr-dev mailing list
Olsr-***@lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Vigneswaran R
2014-06-09 11:08:37 UTC
Permalink
Post by Henning Rogge
Post by Vigneswaran R
Cannot find loader for parameter 'Debug'
Error, unknown config io '/root/olsrd2.conf'.
Okay, should be fixed now too... too much work on OpenWRT without
checking the native x86 build.
Yes, the latest code is working without the run time error mentioned in
my previous mail. Thanks.

Regards,
Vignesh
--
Olsr-dev mailing list
Olsr-***@lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Henning Rogge
2014-06-09 11:09:55 UTC
Permalink
Yes, the latest code is working without the run time error mentioned in my
previous mail. Thanks.
I am thinking about moving away from the "cached cmake" variables
completely... they are a sneaky way to mess up the build process.

Henning
--
Olsr-dev mailing list
Olsr-***@lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Vigneswaran R
2014-06-09 11:18:06 UTC
Permalink
Post by Henning Rogge
Yes, the latest code is working without the run time error mentioned in my
previous mail. Thanks.
I am thinking about moving away from the "cached cmake" variables
completely... they are a sneaky way to mess up the build process.
I see, Ok..

vignesh
--
Olsr-dev mailing list
Olsr-***@lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Henning Rogge
2014-06-09 06:39:14 UTC
Permalink
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.

Henning
Post by Henning Rogge
Hi,
just to make sure, you can see all four nodes producing TC messages?
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).
Post by Henning Rogge
Maybe I have to replicate this setup when I am back at work on
Tuesday, I have no clue what is going on.
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
Post by Henning Rogge
Henning
Post by Vigneswaran R
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.
./olsrd2 -l olsrd2.conf
[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
https://lists.olsr.org/mailman/listinfo/olsr-dev
--
Olsr-dev mailing list
Olsr-***@lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Loading...