Herbert Xu wrote:
On Sun, Nov 20, 2005 at 04:31:36PM +0000, Patrick McHardy wrote:@@ -145,7 +149,17 @@ int xfrm4_rcv_encap(struct sk_buff *skb, netif_rx(skb); return 0; } else { +#ifdef CONFIG_NETFILTER + __skb_push(skb, skb->data - skb->nh.raw); + skb->nh.iph->tot_len = htons(skb->len); + ip_send_check(skb->nh.iph); + + NF_HOOK(PF_INET, NF_IP_PRE_ROUTING, skb, skb->dev, NULL, + ip_xfrm_transport_hook); + return 0; +#else return -skb->nh.iph->protocol; +#endifI'm worried about this bit. This looks like it'll go back to the top of the IP stack with the existing call chain. So could grow as the number of transforms increase.
Its not so bad. It adds ip_xfrm_transport_hook and ip_local_deliver_finish to the call stack, but since two subsequent transport mode SAs are always processed at once it can't take this path again without calling netif_rx in between.
Perhaps we need to play a dst_input/netif_rx trick here. Actually, was there a problem with your original netif_rx approach apart from the issue with double counting?
Besides the double counting, packets also appear on the packet sockets after transport mode decapsulation with the original approach. For IPv6 there's also the double-parsing of extension header issue. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
