Re: [PATCH v3 0/2] netfilter: nfqueue: incorrect sctp checksum

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

On Tue, May 21, 2024 at 02:48:50PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > > userspace, my proposal:
> > > > 
> > > >               if (!skb_is_gso(skb) || ((queue->flags & NFQA_CFG_F_GSO) && !skb_is_gso_sctp(skb)))
> > > >                         return __nfqnl_enqueue_packet(net, queue, entry);
> > > 
> > > This disables F_GSO with sctp packets, is sctp incompatible with nfqueue?
> > 
> > This will send a big SCTP payload to userspace (larger than mtu),
> > then, userspace will send the such big SCTP payload to kernelspace via
> > nf_reinject().
> 
> I'm not following.
> 
>   if (!skb_is_gso(skb) || ((queue->flags & NFQA_CFG_F_GSO) && !skb_is_gso_sctp(skb)))
>      return __nfqnl_enqueue_packet(net, queue, entry);
> 
> Means:
> 1. skb isn't gso -> queue, OR
> 2. Userspace can cope with large packets AND packet is not sctp-gso

Yes, this is implicit case: skb is gso. This is adding an exception
for sctp-gso.

> -> queue
> 
> -> sctp gso packets are fully software-segmented in kernel, and
> we queue n packets instead of 1 superpacket.
> 
> Apparently GSO SCTP is incompatible resp. skb_zerocopy() lacks
> GSO_BY_FRAGS support.
> 
> Too bad.

Then, either extend skb_zerocopy() to deal with GSO_BY_FRAGS or poor
man approach as above: enqueue n packets until that is supported.

By reading this, my understanding is that you prefer to extend
skb_zerocopy(), I pick up from Antonio's work and send a patch.

> > Can kernel deal with SCTP packets larger than MTU?
> 
> As far as I can see the gso helpers used in fwd and output
> path handle this transparently, i.e., yes.