Re: Problem with conntrack, all packet are marked as invalid.

[Tien-Ren Chen <trchen1033@gmail.com>]

Baake, Matthias wrote:

>Hi
>
>if you have a static ip situation i would use the snat target, thats not the problem but just noticed..
>please post your iptables startup script or the output of iptables-save.
>one thing i've never seen before is the "ctstate" output anybody any idea?!
>
>greets matthias
>  
>
Thank you for the SNAT target suggestion.

And I've already solved my problem by downgrading my kernel to 2.6.11.
It seems like a bug in the bridge netfilter code in 2.6.12.

I first tried to use iptables with LOG target to find where the 
connection tracking info disappeared.
Even after processed by the NF_IP_PRE_ROUTING filters the packets seemed ok,
but when they went to the NF_IP_FORWARD/NF_IP_PRI_MANGLE, their ctstate 
became INVALID.
Then I added some printk in the kernel sources, found the packets are 
still ok even when they went to beginning of NF_IP_FORWARD hooks,
however, when they finally came to ctstate match, skb->nfct was already 
cleaned with 0 (skb->nfctinfo still held correct value).
Then I examined the bridge netfilter code, I was suprised that it 
blocked the packets with NF_STOP -- how did the packets go to the 
NF_IP_PRI_MANGLE hook?
I tried to find document explaining what the NF_STOP does, but got 
nothing except that it's something new in the 2.6.12 kernel.
At last I tried to downgrade by kernel to 2.6.11, it worked, and the 
story ends.

I think the netfilter Hacking HOWTO should be updated to meet the change.
And I'm wondering what's the use of NF_STOP?
It seems little difference between NF_STOP and NF_STOLEN, but what's the 
essential?
--
Tien-Ren Chen, 2005/08/26.