Re: [regression] Completely editing packet should be allowed.

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Mon, Nov 09, 2026 at 11:25:34AM +0100, Pablo Neira Ayuso wrote:
> On Sat, Nov 07, 2026 at 04:04:49PM +0800, allfox wy wrote:
> > Thank you for explanation. I did a test. It is indeed the protocol
> > number change in homebrew causing the block.
> > 
> > However, calling nf_reset_ct(e->skb) would still result in packet
> > being dropped. I didn't do a precise diagnose to find out where it got
> > dropped. But replacing nf_reset_ct(e->skb) with "return true" would
> > result in a working system.
> > 
> > My deduction: in the system's NAT table there is MASQUERADE in
> > POSTROUTING. As my understanding, MASQUERADE requires CONNTRACK
> > information to work. When the outgoing packet going through MANGLE
> > table and got nf_reset_ct(e->skb), later MASQUERADE in NAT table might
> > dropped it.
> > 
> > Is there a function that recalculate the CONNTRACK info rather than
> > deleting it please?
> 
> That would entirely conntrack lookup.

I meant to say: That would require a mistream conntrack re-lookup.

> I think your software should be doing this packet mangling from the
> prerouting hook *before* the conntrack hook, so you have a chance to
> create a conntrack object that really represents the flows after your
> mangling.
>