updating header information in RouteOutput

[Deepa Phanish]

Hi,

Is it possible to change/update the header information in RouteOutput() of routing protocol?

I am trying to update an original destination address in RouteOutput() of aodv using header.SetDestination but the address is still not updated when this packet is received by other nodes in RouteInput. The header input of RouteOutput is defined const.

What would be the right way of doing this?

Many Thanks,
Deepa

[Tommaso Pecorella]

Hi,

please look at the documentation and the code. RouteOutput returns a route toward the selected destination. It can not change the destination. By the way, RouteOutput is called many times before the actual Send, e.g., it is called by UDP *and* by IP, or the very same packet. The reasons for this are many, and they have been discussed in the past.

Now, about the question (how to change the destination), you can't do it in this way. Also because you'll have to store the original destination somewhere.

I'd strongly suggest to clarify the intended behaviour. As you describe it, it's missing some relevant parts, and the "solution" for changing the destination address may be completely useless once you do the second step.

Cheers,

T

[Deepa]

Hi Tommaso,

  Many thanks for the reply.
 
  In my case, the destination is not known a priori and it is discovered within the routing protocol in stage 1. In stage2, I want to send application packets to this destination. I was trying to test it quickly by sending a dummy address from application and then update it when the packet goes through RouteOutput().

 I guess the right way to do this is to probably implement a callback function to share the destination address with higher layers.

Regards,
Deepa

[Tommaso Pecorella]

Hi Deepa,

what you're describing seems to be a semantic routing system. However you' will face a deadlock if you keep on like this.

Your app will have to decide the destination, and the destination is known by its IP address. As a consequence, your statement "the destination is not known a priori and it is discovered within the routing protocol in stage 1" is misleading.

You will have to tell the routing protocol what is the intended destination in one way or another.

The only case where your statement may hold is for anycast addresses, but anycast isn't defined in IPv4. And even if it was, the anycast routing handling is not performed changing the intended destination address.

Anyway, your protocol, your model, your design, your problems. I only wanted to point out that what you're trying to do will cause you problems soon™.

Good luck,

T.

[Deepa]

  I have implemented the setup process with its own packets to discover destination and route in the routing protocol.  It shouldn't be a deadlock if only I can share this address back to the application for further packets from app. It would have been easier to tag a packet from app and set destination address in routing protocol.