Jozsef Kadlecsik <[email protected]> wrote: > > > > --- a/net/netfilter/core.c > > > > +++ b/net/netfilter/core.c > > > > @@ -375,7 +375,7 @@ void nf_ct_attach(struct sk_buff *new, const struct > > > > sk_buff *skb) > > > > { > > > > void (*attach)(struct sk_buff *, const struct sk_buff *); > > > > > > > > - if (skb_nfct(skb)) { > > > > + if (skb->nfct) { > > > > > > I guess this slipped through accidentally. No need to resent, I can > > > amend it here. > > > > Hmm, let me review this. I thin the skb_nfct() conversion is erroneous. > > (Q: If original is UNTRRACKED, should the reply packet that is being > > attached be UNTRACKED or INVALID?) > > If the packet is UNTRACKED, then how can there be a reply packet from > conntrack point of view? In my opinion it's the user responsibility to > handle both directions.
afaics it would happen with this: -t raw -j UNTRACKED -t filter -j REJECT REJECT target ends up calling nf_ct_attach to associate the rst/icmp packet with original skb->nfct. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
