[Olsr-users] Incorrect topology output from netjsoninfo (v0.14.1)

[Michele Segata]

Hi Henning,

thanks for the answer. Yes, this sounds like a reasonable cause. What is 
the best option to disable the MPR selection algorithm? Remove "mpr" 
from the cmake configuration file (and recompile), or simply change the 
olsr configuration? We have seen that 'mpr' appears in multiple sections 
of the configuration (nhdp and domain).

Thanks
Michele

On 19/09/2017 08:29, Henning Rogge wrote:
> Hi,
> 
> most likely you run Olsrd2 with the MPR plugin (which is active by
> default), which job is reducing the topology to the links you need for
> the optimal paths to the targets.
> 
> If MPR is running (check by running "<olsrd2-executable> --version")
> you can expect only seeing the reduced topology, because netjsoninfo
> is only outputting the local knowledge.
> 
> version 0.13.0 did not have the MPR plugin by default.
> 
> Could this be the reason for the observed behavior?
> 
> Henning
> 
> On Tue, Sep 19, 2017 at 7:29 AM, Michele Segata <(spam-protected)> wrote:
>> Dear all,
>>
>> we found a problem with the output of netjsoninfo on OLSRv2, version
>> 0.14.1. We are running OLSR on a full mesh testbed composed of roughly
>> 40 nodes and we discovered that netjsoninfo is outputting a wrong
>> topology. The routing table of the nodes correctly includes all
>> destinations in the testbed as singe hops. However, when we ask
>> netjsoninfo to give us the topology, the outcome is wrong.
>> In particular, the topology is not a full mesh, and only the node on
>> which we invoke netjsoninfo filter graph has the correct degree. As an
>> example, computing the node degree for the node with the ip 10.1.0.1
>> gives the following result
>>
>> id_10.1.0.33: 2
>> id_10.1.0.2: 2
>> id_10.1.0.1: 41
>>
>> All the other nodes have degree 1.
>> Similar result for another node (ip 10.1.0.24):
>>
>> id_10.1.0.10: 2
>> id_10.1.0.2: 2
>> id_10.1.0.14: 3
>> id_10.1.0.23: 3
>> id_10.1.0.8: 3
>> id_10.1.0.24: 41
>> and the others have degree 1.
>>
>> This clearly after waiting enough time for convergence.
>> I'm attaching the routing tables of the aforementioned nodes, as well as
>> the topology file obtained from netjsoninfo and the olsr configuration file.
>>
>> The problem did not occur with the same testbed and version 0.13.0. Does
>> any of you know if this is a bug?
>>
>> Thanks in advance
>> Best,
>> Michele
>>
>> --
>> Michele Segata, PhD
>> Department of Information Engineering and Computer Science
>> University of Trento, Italy
>> https://ans.disi.unitn.it/~segata
>>
>> --
>> Olsr-users mailing list
>> (spam-protected)
>> https://lists.olsr.org/mailman/listinfo/olsr-users

-- 
Michele Segata, PhD
Department of Information Engineering and Computer Science
University of Trento, Italy
https://ans.disi.unitn.it/~segata/