Re: traffic shaping & tunneling & 2.3 kernels.

Bram Avontuur (
Thu, 25 Nov 1999 21:14:12 +0100

Paul Rusty Russell wrote:
> In message <> you write:
> > Hi, a few questions:
> >
> > I am running 2.3.26 on a x86 box with 3 NIC's, a VPN (by means of ipip
> > tunnels), masquerading all that leaves the first NIC (eth0), and
> > traffic shaping. eth1&eth2 are LAN nics and cover 192.168.1/24 and
> > 192.168.3/24.
> 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...
I've done some more tests:

Without ipnatctl & iptables rules (i.e. only one NIC configured) and
traffic shaping (cbq) turned on, the system is stable.
With masquerading & forwarding/accounting & traffic shaping (cbq), the system
crashes within a few minutes. The same configuration without traffic shaping
is stable again. Wether ipip-tunneling is used or not does not seem to
change this.
Based on these results one could conclude that the netfilter code clashes
with traffic shaping.

> 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?
[snip patch]
The debug noise is now reduced to a repetitive:
Nov 25 21:13:40 mp3 kernel: nf_hook: hook 4 already set.
Nov 25 21:13:40 mp3 kernel: skb: pf=2 (unowned) dev=eth0 len=252
Nov 25 21:13:40 mp3 kernel: PROTO=4 L=252 S=0x00 I=29729 F=0x0000 T=63

Kernel used was 2.3.26.

Bram Avontuur

(insert witty one-liner here)

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to Please read the FAQ at