[Olsr-users] MPR Selection problem

Scoobi Doo (spam-protected)
Fri Oct 24 09:27:22 CEST 2014


Hi Olsr-users,



Recently I've begun to test(simulation) some sort of semi-dynamic scenarios and I've noticed some suspicious results.
The scenario I'm running is as follows:
15 nodes starting in a full-mesh topology - so far so good, then they split into 3 mesh clouds i.e. Cloud A 1-5 Cloud B 6 - 10 Cloud C 11-15.
Clouds A & B are fully-connected so as Clouds B & C, only clouds A & C do not see each other. I hope that i made myself clear...

[1 - 5] <===> [6 - 10] <==> [11 - 15]

What I would expect to see is that cloud A will choose a node from cloud B as his MPR to cloud C, and vice versa for cloud c. Instead, none of the nodes is selected as an MPR and as a result of this the routing table doesn't show routes from A to C and from C to A.

configuration: No ETX, equal Willingness=3 to all nodes, version 0.6.6.2

When i run this scenario with ETX enabled i get good results (MPR selected and correct routes)

I've tried to look into the code of the mpr selection in mpr.c and i made the following change:
in the function olsr_calculate_two_hop_neighbors (line 311), i added a reset to the counters in the end of the main loop:
    a_neighbor->neighbor_2_nocov = n_count;

    /* Add the two hop count */
    sum += count;

  }
  OLSR_FOR_ALL_NBR_ENTRIES_END(a_neighbor);

change to:
    a_neighbor->neighbor_2_nocov = n_count;

    /* Add the two hop count */
    sum += count;
n_count = 0;
count = 0;

  }
  OLSR_FOR_ALL_NBR_ENTRIES_END(a_neighbor);


This change seems to fix the MPR problem in this scenario, my question (finally..) is: What does this function should return (# of strict 2-hop nbrs??)? Is this a bug or am i wrong?

Thanks
btw the olsrd is great!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20141024/6de60c82/attachment.html>


More information about the Olsr-users mailing list