Hi Bram,
The crashing is worrying; it's almost something in netfilter,
being the new kid on the block. ip-in-ip tunnelling could easily
screw up my conntrack code, which stores the connection pointer in the
skb; once the skb is tunnelled of course, this pointer is
wrong... Hmm...
> Furthermore, using ipip tunnels on 2.3.25/26 produce tons of kernel
> messages when data is sent over them. Here's sample output:
>
> ---8<---
> Nov 18 02:51:52 mp3 kernel: nf_hook: hook 0 already set.
> Nov 18 02:51:52 mp3 kernel: skb: pf=2 (unowned) dev=tunl0 len=52
> Nov 18 02:51:52 mp3 kernel: PROTO=6 192.168.142.2:57707 192.168.3.2:1263 L=52
S=0x10 I=22534 F=0x4000 T=63
> Nov 18 02:51:52 mp3 kernel: ip_finish_output: bad unowned skb = c135c0e0: PRE
_ROUTING LOCAL_IN FORWARD POST_ROUTING
This debugging message is the result of an ipip tunnel it
seems; the *same* skb has gone through PRE_ROUTING, LOCAL_IN, then
gets tunnelled through FORWARD and POST_ROUTING. The code which
checks where a packet has gone doesn't like this. Does this fix it?
--- linux-2.3/net/ipv4/ipip.c.~1~ Thu Nov 4 17:33:57 1999
+++ linux-2.3/net/ipv4/ipip.c Thu Nov 18 16:58:55 1999
@@ -483,6 +483,10 @@
skb->dev = tunnel->dev;
dst_release(skb->dst);
skb->dst = NULL;
+#ifdef CONFIG_NETFILTER_DEBUG
+ /* Same SKB getting re-receved by tunnel; reset hooks */
+ skb->nf_debug = 0;
+#endif
netif_rx(skb);
read_unlock(&ipip_lock);
return 0;
Rusty.
-- Hacking time.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/