|
Bugzilla – Full Text Bug Listing |
| Summary: | OLSR MPR Computation give incorrect result | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Omair <omairabdullah> |
| Component: | routing | Assignee: | ns-bugs <ns-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gjcarneiro |
| Priority: | P5 | ||
| Version: | ns-3.5 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Attachments: |
The script used to get the mentioned results of OLSR
Trace file on running the above script |
||
Created attachment 641 [details]
Trace file on running the above script
Please try ns-3-dev. It should be fixed now. And thanks for the good work providing a test case. changeset: 5471:61831e265e20 tag: tip user: Gustavo J. A. M. Carneiro <gjc@inescporto.pt> date: Sun Nov 01 22:47:04 2009 +0000 summary: Bug 733: OLSR MPR Computation give incorrect result |
Created attachment 640 [details] The script used to get the mentioned results of OLSR In the OLSR Routing Protocol, the MPR set of a node is having more nodes than necessary. /* Topology (Constant Position) * A---D * | / | * C---E * | * F * * F - Node 0 - IP 10.1.1.1 * C - Node 1 - IP 10.1.1.2 * E - Node 2 - IP 10.1.1.3 * A - Node 3 - IP 10.1.1.4 * D - Node 4 - IP 10.1.1.5 * * Trace File Line 47625 says MPR nodes of A are C & D. But it should be only C. * Similarly Line 47521 says MPR nodes of E are C & D. But it should be only C. */ This doesn't follow the algorithm given in the comments of the src/routing/olsr/olsr-routing-protocol.cc or the RFC. I mailed the developer Gustavo Carneiro and quoting the mail: 1. C is the only node that can reach the two-hop neighbor F, so it should be among the first to be selected as MPR; 2. Once C is selected as MPR, C can reach all the other nodes, so no more MPR should be selected. So I agree with you, the MPR set of A should be only C, not C+D. If this does not happen, sounds like a bug.