Problem: Adding entry to NdiscCache in AODV Ipv6 implementation

127 views
Skip to first unread message

Shashidhar B.L

unread,
Mar 30, 2015, 6:15:28 AM3/30/15
to ns-3-...@googlegroups.com
Hi,
To add an entry to the ARP cache in AODV, one can use AddArpCache which gets the pointer to the ArpCache of corresponding Ipv4Interface. Now to do the same functionality in Ipv6interface, i added a function: AddNdiscCache. 

AddNdiscCache (Ptr<NdiscCache> a)
{
  m_ndCache.push_back (a);
}

So basically, when passing the arguments, I need to pass a pointer to the NdiscCache (please correct me if i am wrong). 

Now, in the object NotifyInterfaceUp, I have to perform the function of adding an entry to the NdiscCache. In ipv4, there is this part of a functionality

if (l3->GetInterface (i)->GetArpCache ())
    {
      m_nb.AddArpCache (l3->GetInterface (i)->GetArpCache ());
    }

As i understand, the l3 is layer3 protocol, i is an index using which one can obtain an interface. 
Summary: for the l3 protocol get an interface and get its corresponding arp cache and add an entry to the cache. (please correct me if i am wrong).

So for similar functionality i added, 

if (l3->GetInterface (i)->GetNdiscCache ())
    {
      m_nb.AddNdiscCache (l3->GetInterface (i)->GetNdiscCache ());
    }


Now when i do this i get an error stating

Description                                                                                      Resource Path                  Location    Type
cannot convert ‘ns3::Ipv6Interface*’ to ‘ns3::NdiscCache*’ in initialization ptr.h        /AODV/build/ns3   line 746     C/C++ Problem

In my understanding, it is unable to obtain a ptr to NdiscCache, and the definition in ptr.h has a different type or/and size i.e. it is because of difference in type of arpcache and ndisccahe.

It would be of great help if someone can point out a solution to this, or if my understanding is wrong then please correct me and point me to right direction.

Thanks in advance
Regards
Shashidhar B.L

Tommaso Pecorella

unread,
Mar 30, 2015, 6:51:36 AM3/30/15
to ns-3-...@googlegroups.com
Hi,

the specific error seems more like a wrong parenthesis. The functions should return ann NdiscCache pointer, so the error is puzzling.

In a more general sense, I totally disagree with the approach. I mean, I know it's in the original AODV source code, but it's still completely wrong.
AODV should't "hard-link" to the NDISC (or ARP) cache pointer. Moreover, it is assuming everywhere that the MAC is a Mac48 (which isn't always true).

I totally know that this has been done to avoid to touch the IP interfaces, but this is a workaround, not a solution.
The "right" could be to ask the IP interfaces for the neighbour status, and defer to them the responsibility for handling everything.

One last comment. I don't know enough AODV to say, but it seems that the MAC hardware address is used only to purge the neighbour in case of a particular failure type.
I'm not even sure that this is correct from a logical point of view. I mean, if the neighbour can't be reached anymore (or it's disconnected from an AP), its Arp cache should be purged, but the routing protocol should react to the ARP cache entry gone missing, not to the original signal...

Summarizing, I'd strongly suggest to think to what you're doing and to not "inherit" in your code also the bad things from the old one. When you need/have to "fix" something, write down what you did so to enhance the IPv4 AODV code as well. The goal should be to have a better code, not just a port of something.

Cheers,

T.

Shashidhar B.L

unread,
Mar 30, 2015, 7:50:17 AM3/30/15
to ns-3-...@googlegroups.com
Hi,
It is not a parenthesis error, that is for sure. Am confused about the reason for error too. That is my last build error and am stuck. 

As for you general comments, I agree with you. At this point of my project, unfortunately, i cannot focus on having an optimized code, i need to get the functionalities done and an AODV ipv6 up and running to a satisfactory level. I can focus on making the code better at a later part of time. 

Am still unable to find the reason for that error though. Could you please tell me if you think it perhaps has something to do with the ptr types. As it says "cannot convert ‘ns3::Ipv6Interface*’ to ‘ns3::NdiscCache*’ in initialization".

Regards
Shashidhar B.L

--
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/mtetYLTBd-I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

Shashidhar B.L

unread,
Mar 30, 2015, 8:44:22 AM3/30/15
to ns-3-...@googlegroups.com
Hi,
I would like to show you this piece of code, where it is pointing out as an error from ptr.h

template <typename T>
template <typename U>
Ptr<T>::Ptr (Ptr<U> const &o)
  : m_ptr (PeekPointer (o))
{
  Acquire ();
}

The bold line specifically. 

Thank you
Regards
Shashidhar B.L

Tommaso Pecorella

unread,
Mar 30, 2015, 8:54:04 AM3/30/15
to ns-3-...@googlegroups.com
Hi,

the problem is in the calling function. Use the backtrace and find out what is the line of code in your AODV that triggers the problem.

Cheers,

T.

Shashidhar B.L

unread,
Mar 30, 2015, 8:59:23 AM3/30/15
to ns-3-...@googlegroups.com
Hi,
I did that already, it points to this piece of code i have added. Specifically the line inside the if condition. In my knowledge it is totally valid, that is the reason am confused.

if (l3->GetInterface (i)->GetArpCache ())
    {
      m_nb.AddArpCache (l3->GetInterface (i)->GetArpCache ());
    }

Please let me know if this helps.

Thank you for your patience
Regards
Shashidhar B.L

Tommaso Pecorella

unread,
Mar 30, 2015, 10:02:21 AM3/30/15
to ns-3-...@googlegroups.com
Hi,

it should be valid. Feel free to send the code (the module and one example).

Cheers,

T.

Shashidhar B.L

unread,
Mar 30, 2015, 10:24:37 AM3/30/15
to ns-3-...@googlegroups.com
Hi,
I think there was some issue with eclipse, which am not sure of. I built it using waf on ubuntu terminal, it showed some dependencies, upon clearing them, i got a clean build.

thank you tommaso for your quick responses.
Cheers

Gonçalo Atanásio

unread,
Jun 27, 2016, 5:04:19 PM6/27/16
to ns-3-users
Hi Tommaso,

I'm having the same problem with DSDV, but there is no AddArpCache or something like that in DSDV, so I can't adapt from Ipv4 to Ipv6 in that aspect. So, when I send a packet, the DSDV returns the right route, but then, when the netdevice asks for ARP and tries to do the NDISC the DSDV receives a normal packet and tries to return the route (of course, it does not exist). Do you have any suggestion where can I add the entries to the NDISC table and make this work?

Best Regards

Tommaso Pecorella

unread,
Jun 27, 2016, 7:09:34 PM6/27/16
to ns-3-users
Hi,

AODV uses ARP to store the IP/MAC pair for its neighbors. DSDV doesn't do that, and it doesn't need any support from the node's NDISC cache.
Moreover, the NetDevice wouldn't ask for the NDISC cache anyway, because NetDevices are independent from the IP layer. SixLowPan *is* dependent on the IP layer, but it doesn't use the NDISC cache.
Last but not least, Multicast addresses are translated into special MAC addresses (usually). At the moment the lr-wpan model is not totally RFC-compliant on this. I opened a ticket for this.

T.

Gonçalo Atanásio

unread,
Jun 27, 2016, 7:22:48 PM6/27/16
to ns-3-users
Ok, but in Ipv6Interface in the function Send it calls NeedsArp() (if (m_device->NeedsArp ())). And then the lr-wpan netdevice returns always true! So I just change it to false? I tried that, but then the routing tables stopped being filled.

I was thinking about putting a condition in function routeinput from DSDV to always send up packets from NDISC, but is not really a good solution.

Best Regards

Tommaso Pecorella

unread,
Jun 27, 2016, 7:51:24 PM6/27/16
to ns-3-users
I think you're misunderstanding what is happening in your protocol.
As far as I know DSDV uses broadcast messages in IPv4. These should be translated to multicast messages, and these will not use NDISC entries.
The NeedsArp function (which is both for ARP and NDISC) only says if the interface needs a probe (i.e., ARP or NDISC) to map IP to MAC and viceversa, but NDISC is not used for multicast (of corse).
My best guess is that you're looking at the wrong packets. I.e., NS/ND generated for other reasons.

T.

Gonçalo Atanásio

unread,
Jun 27, 2016, 7:56:25 PM6/27/16
to ns-3-users
Yes, you are absolutely right! I don't know why, but icmpv6 is sending NDISC messages. Why can that be happening?
Reply all
Reply to author
Forward
0 new messages