[olsr-dev] MRP selection (all OLSRd versions)

[Andreas Tønnesen]

Sven-Ola,

So what you are saying is that the scenario you described is actually not
only a transitional state(which I assumed in my previous mail) in you
network but a permanent state which does not change? If so, this is indeed
a bug.

- Andreas

> Thomas,
>
> thanks for that longer answer (aka "private lesson"). The critical
> sentence
> is: "if X sees nodes that Y does not see itself, Y should also select X as
> an MPR". Which is inherently true for 2 interfaces on one node. I need to
> recheck with the concrete implementation / installation / configuration
> and
> make pretty *sure* nothing is misconfigured or otherwise weird before
> complaining further ;) Yesterday I've seen a single "bus error" statement
> in
> the syslog - which by chance is the kasus knaxus here...
>
> LG
> Sven-Ola
>
> "Thomas Lopatic" <(spam-protected)> schrieb im Newsbeitrag
> news:(spam-protected)
>> Hey Sven-Ola,
>>
>>> (Mail with pdf attachment obviously halted. PDF is here:
>>> http://styx.commando.de/sven-ola/mprcoverage.pdf )
>>
>> Hmmm. Wait a second. .1 sees .2, .3, and .4, and says in its LQ HELLOs
>> that it sees these nodes. .5 sees .6, .7, and .8, and also says in its
>> LQ HELLOs that it sees these nodes.
>>
>> So, as long as, for example, .1 sees .5's LQ HELLOs, it should know that
>> .5 sees nodes that it does not see itself, namely .6, .7, and .8. Which
>> in turn should make .1 select .5 as an MPR.
>>
>> Analogously, if .5 sees .1's LQ HELLOs, it should know that .1 sees
>> nodes that it does not see itself, namely .2, .3, and .4. So, .5 should
>> also select .1 as an MPR.
>>
>> This assumes that .2, .3, and .4 do not see .6, .7, and .8, which seems
>> to be the case in the illustration.
>>
>> So, I am not sure whether forcing one MPR per interface would change
>> anything and solve this particular problem. If there's a node at any
>> interface that sees nodes that I do not see, I make this node an MPR for
>> me. Hmmm. That should do the job, shouldn't it?
>>
>> So, my guess would be that we've discovered a bug in the olsrd
>> implementation here and not a design error. Or am I missing something
>> here?
>>
>> It's pretty weird that .1 and .5 see each other but do not mutually
>> select themselves as MPRs.
>>
>> -Thomas
>>
>> _______________________________________________
>> olsr-dev mailing list
>> (spam-protected)
>> https://www.olsr.org/mailman/listinfo/olsr-dev
>
>
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev
>