On Wed, Sep 18, 2024 at 10:42:25PM +0100, Antonio Ojea wrote:
> On Wed, 18 Sept 2024 at 21:53, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> >
> > On Tue, Sep 17, 2024 at 11:01:31PM +0100, Antonio Ojea wrote:
> > > On Fri, 13 Sept 2024 at 07:24, Antonio Ojea
> > > <antonio.ojea.garcia@xxxxxxxxx> wrote:
> > > >
> > > > On Thu, 12 Sept 2024 at 20:58, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> > > > >
> > > > > 368982cd7d1b ("netfilter: nfnetlink_queue: resolve clash for unconfirmed
> > > > > conntracks") adjusts NAT again in case that packet loses race to confirm
> > > > > the conntrack entry.
> > > > >
> > > > > The reinject path triggers a route lookup again for the output hook, but
> > > > > not for the postrouting hook where queue to userspace is also possible.
> > > > >
> > > > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > > > Reported-by: Antonio Ojea <antonio.ojea.garcia@xxxxxxxxx>
> > > > > Signed-off-by: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
> > > > > ---
> > > > > I tried but I am not managing to make a selftest that runs reliable.
> > > > > I can reproduce it manually and validate that this works.
> > > > >
> > > > > ./nft_queue -d 1000 helps by introducing a delay of 1000ms in the
> > > > > userspace queue processing which helps trigger the race more easily,
> > > > > socat needs to send several packets in the same UDP flow.
> > > > >
> > > > > @Antonio: Could you try this patch meanwhile there is a testcase for
> > > > > this.
> > > >
> > > > Let me test it and report back
> > > >
> > >
> > > Ok, I finally managed to get this tested, and it does not seem to
> > > solve the problem, it keeps dnating twice after the packet is enqueued
> > > by nfqueue
> >
> > I really don't understand why my patch did not work.
> >
> > In this new test run you have use postrouting/filter chain, but it
> > does not call nf_reroute as in the previous trace.
> >
> > Does program issues the NF_STOP verdict instead?
> >
>
> The program is the same and the environment the same, I just change
> the kernel of the VM.
> I have observed different drops reasons, see my original comment
> https://bugzilla.netfilter.org/show_bug.cgi?id=1766#c0 has
> SKB_DROP_REASON_IP_RPFILTER and SKB_DROP_REASON_NEIGH_FAILED, and in
> this trace we have SKB_DROP_REASON_OTHERHOST ... , can it be possible
> you fixed one scenario with your patch but not the others?
It could be different scenario. I was expecting consistency in UDP packet
distribution is a requirement, but I understood goal at this stage is
to ensure packets are not dropped while dealing with clash resolution.
I have applied Florian's patch to nf.git, thanks.
