Bug 1634 - NdiscCache use slightly bugged...
NdiscCache use slightly bugged...
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: ipv6
ns-3-dev
All All
: P5 normal
Assigned To: Tommaso Pecorella
:
Depends on:
Blocks: 1646
  Show dependency treegraph
 
Reported: 2013-04-19 18:26 UTC by Tommaso Pecorella
Modified: 2013-05-17 07:42 UTC (History)
1 user (show)

See Also:


Attachments
patch (527 bytes, application/octet-stream)
2013-04-19 18:26 UTC, Tommaso Pecorella
Details
This is the right patch. Sorry (527 bytes, patch)
2013-04-26 03:47 UTC, Tommaso Pecorella
Details | Diff
Another try... (1.61 KB, patch)
2013-04-26 03:51 UTC, Tommaso Pecorella
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tommaso Pecorella 2013-04-19 18:26:27 UTC
Created attachment 1566 [details]
patch

Nothing big, however...
1) It is created also for No-Arp interfaces, which is a resource waste,
2) Icmpv6L4Protocol isn't checking for its existence when performing a lookup, and
3) Icmpv6L4Protocol::Lookup doesn't return the Mac Address in some cases.

All the 3 points are fixed in the patch.
Comment 1 Tommaso Pecorella 2013-04-26 03:47:04 UTC
Created attachment 1568 [details]
This is the right patch. Sorry
Comment 2 Tommaso Pecorella 2013-04-26 03:51:40 UTC
Created attachment 1569 [details]
Another try...

Bugzilla seems to cut the patch file. Or it's my Mac ?
Comment 3 Tommaso Pecorella 2013-04-26 03:58:36 UTC
By the way, the rationale of this patch is this: there are some cases where the NdicCache is not created (i,e., for the loopback). Hence it's mandatory to check the cache existence, otherwise a dumb user (me) could try to look for it on the wrong interfaces.
This greatly simplifies the code and makes it easier to check for an NDISC entry on an unknown interface.
Comment 4 Tommaso Pecorella 2013-05-17 07:42:31 UTC
Fixed in changeset 9760 - 858d18e11e11