A question about reinjecting packets

A question about reinjecting packets

[Paul Tipper]

Greetings, 

I'm working on an implementation of an IPv4 to IPv6 bump in the stack (yes
I admit it, I'm a student) and while doing this I've gotten stuck at the
stage of reinjecting packets into the network.  The model I'm working with
is a little kludgey but in short translates v6 addresses to Class E v4
addresses so that they can be consistently addressed.

I've written a module that hooks into NF_IP_LOCAL_OUT and intercepts
outgoing v4 packets, checks to see if there is a v6 mapping and if there
is translates the packet to v6.

Currently this translation consists of using skb_unshare() on the packet
to ensure its not a clone, then skb_copy_expand() to create an entirely
new copy of the packet including its data.

The sk_buff->protocol field is changed and the new struct ipv6hdr is
constructed (with the local v6 address in the saddr and the destination
the 240.x.x.x address maps onto in the daddr field.  Finally the new
sk_buff has its ->nh changed to point at the new ipv6hdr and the csum is
recalculated.

So as far as I can see I've modified everything I need to change to make
this v4 sk_buff into a v6 one, the problem I then run into is I can find
no way of getting it successfully out onto the network.

I've tried using ip6_xmit() (for which I constructed a struct flowi).
When I couldn't get that work I prodded about some more and tried to use
the NF_HOOK macro to send it out on PF_INET6, NF_IP6_POST_ROUTING, however
the packet never seems to make it out onto the network and just vanishes
without a trace, which leads me to believe I've not converted it properly
and some nice peice of code further down the line is dropping it for
safety reasons.

Is anyone feeling generous enough to make a stab at what I must have
missed?  Or point me in the right direction?


-- 
   /\   Paul Tipper -- Code Monkey & Caffeine Junky
  /<>\   Email: tipper at wintermute dot me dot uk
 /____\   WWW: http://www.wintermute.me.uk/

Re: A question about reinjecting packets

[Henrik Nordstrom]

On Wed, 11 Feb 2004, Paul Tipper wrote:

> I'm working on an implementation of an IPv4 to IPv6 bump in the stack (yes
> I admit it, I'm a student) and while doing this I've gotten stuck at the
> stage of reinjecting packets into the network.  The model I'm working with
> is a little kludgey but in short translates v6 addresses to Class E v4
> addresses so that they can be consistently addressed.

For various compliated reasons I would recommend such transitions to occur
via a virtual network device rather than rewriting the packet within the 
stack. This to ensure correct operation with conntrack etc. But that is 
another story.

> So as far as I can see I've modified everything I need to change to make
> this v4 sk_buff into a v6 one, the problem I then run into is I can find
> no way of getting it successfully out onto the network.

Is there an IPv6 stack enabled on this server?

> I've tried using ip6_xmit() (for which I constructed a struct flowi).

Should work I think, but I am not sure.

ipv6_rcv() is a safer bet I think. Also has the benefit that the IPv6 
packet will be routed and forwarded like normal requiring much less setup, 
and plays better with netfilter conntrack.

Regards
Henrik

Re: A question about reinjecting packets

[Unit Zero]

I actually have been wondering about reinjecting packets for some time... 
I've written some test code but had limited success in actually getting 
the packets out onto the wire. My issue is this: I want to steal outbound 
packets before they hit the net and use add_timer() to schedule a callback 
which sends the packet out after a certain delay. (To implement 
rate-limiting that dosen't drop packets, but delays them when they exceed 
a certain throughput.)

I assume that I should be hooking into LOCAL_OUTPUT, and returning 
NF_STOLEN (??) for packets that I snatch. But I have the same problem as 
Paul... what kernel routine do I use in the timer function to send the 
packet onto the network?

I think I've gotten some code which I hacked from the ipt_ROUTE target to 
steal packets from netfilter and send them directly using ip_direct_send()
from the ipt_ROUTE code, but they seem to re-enter netfilter and go 
through the chains again, which causes an infinite loop when they get to
the ip_direct_send() in the rule with my target again. So, basically, how 
do I inject a packet AFTER the netfilter processing?

- V. M. Condino

On Wed, 11 Feb 2004, Paul Tipper wrote:

> I've tried using ip6_xmit() (for which I constructed a struct flowi).
> When I couldn't get that work I prodded about some more and tried to use
> the NF_HOOK macro to send it out on PF_INET6, NF_IP6_POST_ROUTING, however
> the packet never seems to make it out onto the network and just vanishes
> without a trace, which leads me to believe I've not converted it properly
> and some nice peice of code further down the line is dropping it for
> safety reasons.

Re: A question about reinjecting packets

[Patrick McHardy]

Unit Zero wrote:
> I actually have been wondering about reinjecting packets for some time... 
> I've written some test code but had limited success in actually getting 
> the packets out onto the wire. My issue is this: I want to steal outbound 
> packets before they hit the net and use add_timer() to schedule a callback 
> which sends the packet out after a certain delay. (To implement 
> rate-limiting that dosen't drop packets, but delays them when they exceed 
> a certain throughput.)

This is not possible. If you rate-limit packets you have to drop them
at some point if the input rate constantly exceeds the service rate.
Besides, there is not much use in sending packets that have long been
retransmitted.

> 
> I assume that I should be hooking into LOCAL_OUTPUT, and returning 
> NF_STOLEN (??) for packets that I snatch. But I have the same problem as 
> Paul... what kernel routine do I use in the timer function to send the 
> packet onto the network?

Why don't you build into the qos subsystem ? It has all the
infrastructure you need.

Regards,
Patrick

> 
> I think I've gotten some code which I hacked from the ipt_ROUTE target to 
> steal packets from netfilter and send them directly using ip_direct_send()
> from the ipt_ROUTE code, but they seem to re-enter netfilter and go 
> through the chains again, which causes an infinite loop when they get to
> the ip_direct_send() in the rule with my target again. So, basically, how 
> do I inject a packet AFTER the netfilter processing?
> 
> - V. M. Condino
> 
> On Wed, 11 Feb 2004, Paul Tipper wrote:
> 
> 
>>I've tried using ip6_xmit() (for which I constructed a struct flowi).
>>When I couldn't get that work I prodded about some more and tried to use
>>the NF_HOOK macro to send it out on PF_INET6, NF_IP6_POST_ROUTING, however
>>the packet never seems to make it out onto the network and just vanishes
>>without a trace, which leads me to believe I've not converted it properly
>>and some nice peice of code further down the line is dropping it for
>>safety reasons.

Re: A question about reinjecting packets

[Unit Zero]

On Thu, 12 Feb 2004, Patrick McHardy wrote:

> Unit Zero wrote:
> > I actually have been wondering about reinjecting packets for some
> > time...  I've written some test code but had limited success in
> > actually getting the packets out onto the wire. My issue is this: I
> > want to steal outbound packets before they hit the net and use
> > add_timer() to schedule a callback which sends the packet out after a
> > certain delay. (To implement rate-limiting that dosen't drop packets,
> > but delays them when they exceed a certain throughput.)
> 
> This is not possible. If you rate-limit packets you have to drop them at
> some point if the input rate constantly exceeds the service rate.
> Besides, there is not much use in sending packets that have long been
> retransmitted.

Well, the idea would be to delay the next packet of a connection, and drop 
any subsequent packets in that connection that arrive before the first 
packet is finally sent.

Since tcp has flow-control (ACK), there shouldn't 
be more packets coming in until each packet is recieved and a an ACK sent 
back, so delaying a packet would hold up sending more packets while 
waiting for the ACK from the packet which has been delayed, am I wrong? 
Obviously this wouldn't work for UDP.

The effect would be like connecting over a network with really bad lag.

> Why don't you build into the qos subsystem ? It has all the
> infrastructure you need.

That had occurred to me, and I've been trying to find some time to take a 
look at QOS, as I've never actually even used it. I'll take your advice 
and check it out.

Thanks - V. M. Condino