|
Bugzilla – Full Text Bug Listing |
| Summary: | AODV routing entry set to be VALID mistakenly. | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Yang Chi <yangchi.cn> |
| Component: | aodv | Assignee: | Elena Buchatskaya <sunnmy> |
| Status: | RESOLVED FIXED | ||
| Severity: | trivial | CC: | ns-bugs, tomh |
| Priority: | P5 | ||
| Version: | ns-3.10 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Attachments: | patch to fix | ||
(In reply to comment #0) > In aodv source code of ns-3.10, specifically, in > aodv::RoutingProtocol::UpdateRouteLifeTime(), rt.SetFlag(VALID) is called. But > this will make a IN_SEARCH entry set to VALID without really receiving a valid > aodv reply. Then 102.102.102.102 would be used as a VALID nexthop. > > A quick fix can be something like this; > > if(rt.GetFlag() ==VALID) > rt.SetFlag (VALID); I can confirm this is being called for INVALID routes. I'm not sure of the suggested fix (which appears to be a no-op). Deleting the SetFlag() call does not solve all of AODV's performance problems (bug 1099). Created attachment 1111 [details] patch to fix I tested the attached against the scenario file found in bug 1099 and the patch catches a number of mistakenly validated routes, and improves performance. changeset: 4082270126b5 |
In aodv source code of ns-3.10, specifically, in aodv::RoutingProtocol::UpdateRouteLifeTime(), rt.SetFlag(VALID) is called. But this will make a IN_SEARCH entry set to VALID without really receiving a valid aodv reply. Then 102.102.102.102 would be used as a VALID nexthop. A quick fix can be something like this; if(rt.GetFlag() ==VALID) rt.SetFlag (VALID);