Aodv Ipv6: problem in processing hello message

[Shashidhar B.L]

Hi,

I have setup a basic 3 node topology for Aodv Ipv6 routing. 

Src--------NodeA--------Dst

All the nodes configured as routers. 

All the nodes are successfully sending Hello messages to their immediate neighbours and the packets are also received, Src and Dst nodes process NodeA's hello message and make an entry to the routing table, but NodeA is processing only Src node's hello packet and not Dst node's Hello packet.(I dont understand why, could someone please explain?)

Src node sends a route request for Dst node. NodeA sends it to Dst. Now Dst figures out that the request was meant for it and sends a SendReply packet and NodeA receives it. Theoretically, NodeA should just lookup for a route to Src (which it already has in its routing table), but it isnt processing this packet at all. To be more specific, the RecvReply isnt called. As i see from the Log, after MAC processing at NodeA, it sends NS (Neighbour Solicitation) to Dst and Dst replies with NA (Neighbour Advertisement), following which NodeA wants to send some IP packet (I dont know what packet and why it has to send) to Dst node, but it doesnt have a routing table entry because it did not process the hello packet :( so in the ICMP message, it says destination unreachable. 

I enabled the UdpL4Protocol and Ipv6EndPointDemux logs to see why the hello messages are not processed and found out few things.

1. The  UdpL4Protocol::Receive is called by L3 protocol. In this Receive, it calls Ipv6EndPointDemux::LookUp to make sure that a matching EndPoint tuple is obtained. If a matching tuple not found, then it says "RX_ENDPOINT_UNREACH"

2. Now on digging into Ipv6EndPointDemux::LookUp there are plenty of match cases to check for. The reason which I think is responsible for the packet not being processed is that it just cant find any matches at all for every endpoint in the 'for' loop. 

3. I did compare with the logs of hello packets which were processed and found that it is sufficient if a match case is obtained for the criteria "Only local port matches exactly".

4. In my case, for an EndPoint created at NodeA for link between NodeA and Dst the basic criteria of a "localAddressMatchesWildCard" doesnt pass. 

(Please note: I have used the exact object names to make it easy to track my problem and reproduce the path, I hope this helps)

Please let me know if am looking at the right point as my problem, if you think otherwise, please point me in the right direction. 

I had observed same behaviour in a larger network consisting of 6 nodes.

In summary: The nodes are able to listen to broadcast packets on only one of their interfaces and fail to process packets directed to their LinkLocalAddress. The problem could also be that am not binding the sockets appropriately. 

If you had the patience to read all the way till here, am sure you are capable of helping me out :)

Thank you for your time.

Regards

Shashidhar B.L

[Tommaso Pecorella]

Hi,

yes, I did read. No, I can't help for real. But I can give you some hints to check.

1) How many interfaces are on the middle node ?

Routing protocols should be robust and use gracefully multiple interfaces, but AODV should be able to use just one. It's a multi hop ad-hoc protocol after all.

2) IP addresses... triple check 'em.

3) Are you sure the sockets are bound ? A common issue is to fail to initialize them properly...

Anyway, RipNg uses multiple interfaces. Check its code and believe me: all the sockets it's using are totally necessary. 

Sorry if I can't help more, but without the code it's hard to say why a noce doesn't receive packets.

Cheers,

T.

[Shashidhar B.L]

Hi,

Thank you for your the response, it was helpful indeed. The problem was at the interfaces, I was using more than one interface. I rectified it and works pretty well except for one issue. 

Now in the same topology, the dst node sends the route reply message because the request was meant for itself. The immediate neighbour receives this packet (i can see it both from the logs and by sniffing the wire using wireshark). The NodeA should now recognize that it is a routereply packet and must call recvreply (aodv function), unfortunately this does not happen. 

What its actually doing is: 

-The packet is received and processed at Ipv6L3Protocol::Receive

-Then this asks the Ipv6ListRouting::RouteInput to find an associated callback to handle this packet. 

-Now Ipv6ListRouting figures out that it is a message meant for itself, because the destination addresses matches, thus it calls the lcb (LocalDeliverCallback)

-Now the control is transferred to Ipv6L3Protocol::LocalDeliver

-Here IpL4Protocol::RxStatus is checked and the status matches the switch case RX_OK

-Then lcb is finished, control transferred to Ipv6ListRouting::RouteInput, where immediately after calling lcb, it returns true

-Now control back at Ipv6L3Protocol::Receive, where it actually ends. 

Now at which part should the control be transferred to the routing protocol (I think it should) ? What am I missing?

Is something wrong in the arguments to lcb (p,header,iif), which I think are correct, else the status wouldnt be RX_OK.

Please let me know about your thoughts.

Thanks in advance

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/pPrtjuSVfgI/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.

[Tommaso Pecorella]

Hi,

lc should find a socket opened and ready to receive the packet. I guess that it doesn't find it (and this is the problem).

Just remember that a routing protocol is made by two parts: one is the RouteInput / RouteOutput, and is responsible for forwarding the packets and sending them in the net. The other one is a "normal" applications, with its sockets opened and receiving data. This part is responsible for keeping updated the routing table.

An AODV RREQ / RREP packet will pass through RouteOutput and RouteInput, just like any other packet, but it will be received by an opened socket, much like any application.

Hope this helps,

T.

[Shashidhar B.L]

Hi,

I just need a small confirmation please. When I check in wireshark, the routereply message is received over the aodv udp port 654. Doesn't this mean the socket is open and bound to the right address?

Regards

Shashidhar B.L

[Tommaso Pecorella]

actually what you see in wireshark is what you send, not what you receive...

T.

[Shashidhar B.L]

So it means that am sending the packet over the right socket, but the listener isn't actually listening on that socket, so, the concerned callback isnt called for a received aodv packet. Is this what you mean to say, is the problem?

[Shashidhar B.L]

I ask, because i did not understand what you exactly meant by an "opened" socket.

[Tommaso Pecorella]

Most probably this is the problem.

T.

[Shashidhar B.L]

There is only one listen socket and it is bound to AnyIpv6Address over the udp 654 port and the callback set is RecvAodv. So basically if it receives packet from any address over port 654 it is bound to listen and make the call back. 

So i dont understand why it cant listen to the packet. 

[Tommaso Pecorella]

No idea... send me the code (all of it).

Cheers,

T.

[Shashidhar B.L]

Hi,

I resolved the issue. It was a trial and error method, but I dont understand how it works. Could you please explain the reasons based on my explanation? Am starving to know this because it has put a big bug on my sockets understanding. 

Here it goes. 

I created two sockets for every node. 

One configured to send packets bound to the Ipv6 address and a UDP port (AODV 654)

Inet6SocketAddress local = Inet6SocketAddress (address.GetAddress (), AODV_PORT);

socket->Bind (local);

Another to listen packets on UDP port (AODV 654) bound to any Ipv6 address.

Inet6SocketAddress local = Inet6SocketAddress (Ipv6Address::GetAny (), AODV_PORT);

m_recvSocket->Bind (local);

For the listen socket I had setrecvcallback as 

m_recvSocket->SetRecvCallback (MakeCallback (&RoutingProtocol6::RecvAodv, this));

based on my understanding, this socket was suppose to listen to packets addressed to any Ipv6 address and make the callback when data available on the port.

But the unicast packets were not processed. So what I had to do was to set a receive callback to the on the first socket as well. 

socket->SetRecvCallback (MakeCallback (&RoutingProtocol6::RecvAodv, this));

Now I dont understand, why it did not make a callback to the packet received on listen socket bound to any Ipv6 address. 

It would be really helpful if you could explain this. 

Regards

Shashidhar B.L

[Tommaso Pecorella]

Ok, I have found what's going on.

The answer is quite technical and relevant for the future, so I'll explain here.

When you create sockets, they are put in a list in Ipv6EndPointDemux (or Ipv4EndPointDemux, it works in the same way).

When a packet arrives, the socket list is scanned for matches, and all the sockets matching the packet will receive it. Right ? WRONG.

The sockets are first checked for a match, then they are divided in 4 precedence classes:

1) the socket matching all attributes (src addr, dst addr, src port, dat port)

2) the sockets matching all but the local address (i.e., local address is any)

3) the sockets matching only local port and local address (other is zero or any)

4) only the local port matches (other is any or zero)

The sockets in the highest precedence list are called, the others are ignored.

This allows you to define two sockets, one more "specific" and one more generic, and have the generic one receiving all the packets, except the ones handled by the specific socket.

Problem. Maybe the "generic" socket was meant to be the receiving socket and the specific one was there only to send stuff ?

Just like in Shashidhar's case. Crap.

There is a workaround (or a bug fix), but I'll have to think about it.

In the meantime... you know what's happening (at least). Just avoid to have a "specific" socket with an unbound receive callback, as it will sink packets.

Have fun,

T.

[Shashidhar B.L]

Hi,

My colleague and I were discussing on the very similar lines of explanation, but you, a genius, put it right out there even before we could even make conclusions. 

Many thanks Tommaso.

Regards

Shashidhar B.L 

[Tommaso Pecorella]

Hi Shashidhar,

I'm not a genius. I just wrote part of that code... and I spent some time on the other parts. I wish to be a genus, but I only have knowledge :)

Cheers,

T.