Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
