NON constant packet capture to edit it

[David Hudec]

Hello,

in my code, I have a Tx/Rx CallBack:

void ipv4_tx(string path, Ptr<Packet const> packet, Ptr<Ipv4> ipv4, unsigned int unusedInt)

triggered by:

Config::Connect("/NodeList/1/$ns3::Ipv4L3Protocol/Tx", MakeCallback(&ipv4_tx));

The trouble is the pointer to the packet is const, thus I cannot modify it. I need to examine the source IP address in IP header and change it eventually, which I can't do with const.

How can I capture sent/received packet in a way that allows me to modify it?

Thanks for any help, David.

[Tommaso Pecorella]

Please clarify the issue. You can copy a const packet and operate on the copy, isn't it ? Hence, what is the problem ?

Sorry, but I'm sick of half-described problems. You're only one of the (too many) people that don't want to exactly explain what is the problem they are facing, and we have to figure out the other half. This is tiring and, to be honest, it makes me extremely upset.

T.

[David Hudec]

There's no need to be sick, don't :). The querier might be willing to simplify the problem so that the others don't have to bother reading so much. Can get too far, though.

Surely I can copy the packet, examine the copy and alter it the way I want, but that won't change the original packet that I need to be changed. Is there a Config::Connect version of Rx/Tx events that does not require the packet to be constant, so it can be modified? What is it - how to change header data in an existing packet?

[Konstantinos]

Hi David,

The point of having 'const' in the trace sources is exactly that. The user should not be able to change the packet in this case, since the packet has already been passed to the next layer.

If you want to modify the packet, you should not think with trace sources. You would need to create a shim layer below IP that would receive those packets and then send them to the netdevice, or alter the IP layer to add this capability.

[David Hudec]

Oh Thanks Konstantinos,

at least now I understand, why it can't be done the way I was pushing it. But damn, what you have described looks very difficult. Could you please provide a reference as where to study how to add a shim layer or edit the existing IP layer, or a code example to speed my learning? I'm stucked and time pressed, I'm afraid.

Thanks for sharing your experience.

David.

[Tommaso Pecorella]

Hi,

sixlowpan is an example of shim layer. Also the mesh module uses the same concept, although in a different way.

The problem is (perhaps) that you could not need it at all.

Case 1: you're in the source node. In this case it's the node's responsibility to send the packet - no need to modify it, it's YOUR packet !

Case 2: you're an intermediate node and you need to forward the packet - modify it in RouteInput or in the UnicastForward function. If I remember right the packet isn't const there :)

Cheers,

T.

[Konstantinos]

Hi,

The easiest but dirtiest method would be to open the Ipv4L3Protocol.cc and search where the Tx trace source is fired (it will be more than one place). These would be be places where you would like to call your method. However, this would affect all nodes. So, using some attributes you can control which one would be 'affected', also you can provide dynamically the attacker/spoof addresses.

Regards,

K.

[David Hudec]

@Konstantinos, @Tommaso,

thank you. It was your advice that made me grasp what a beast ns-3 is. 

[Nat P]

Hi,

we are working on a traffic control layer, it's matter of months.  Then, you can write your scheduler, which can modify / reorder packets.

Nat

[David Hudec]

I don't understand what is that you are trying to say. You want to help me? You want to be helped?