libnetfilter_queue patch ping

libnetfilter_queue patch ping

[Duncan Roe]

There is a libnetfilter_queue patch of mine from the March 2022 that is still
under review in Patchwork:

https://patchwork.ozlabs.org/project/netfilter-devel/patch/20220328024821.9927-1-duncan_roe@optusnet.com.au/

I tested recently with 63KB packets: overall CPU decrease 20%, user CPU decrease
50%.

This patch could open an avenue to having libnetfilter_queue handle tunneling.
E.g. for tcp over udp, you could have 2 pktbuff structs (because the data area
can be anywhere, rather than residing after the pktbuff head).

It would be great to get a yes / no / please do xxx.

Cheers ... Duncan.

Re: libnetfilter_queue patch ping

[Pablo Neira Ayuso]

On Sat, Aug 19, 2023 at 12:55:03PM +1000, Duncan Roe wrote:
> There is a libnetfilter_queue patch of mine from the March 2022 that is still
> under review in Patchwork:
> 
> https://patchwork.ozlabs.org/project/netfilter-devel/patch/20220328024821.9927-1-duncan_roe@optusnet.com.au/
> 
> I tested recently with 63KB packets: overall CPU decrease 20%, user CPU decrease
> 50%.

I just took the bare minimum of this patch to provide more control on
memory management as you request, it is here:

http://git.netfilter.org/libnetfilter_queue/commit/?id=91d2c947b473b3540be5474c7128a5fa4ce60934

I have removed the extra callback wrapper which does not provide much
but an extra layer to the user.

> This patch could open an avenue to having libnetfilter_queue handle tunneling.
> E.g. for tcp over udp, you could have 2 pktbuff structs (because the data area
> can be anywhere, rather than residing after the pktbuff head).

Please, do not pursue this approach, this pkt_buff structure is
mocking the sk_buff API in the kernel in a very simplistic way. You
can still implement such tunnel handling in your application.

Thanks.

Re: libnetfilter_queue patch ping

[Duncan Roe]

On Sun, Aug 20, 2023 at 11:34:34PM +0200, Pablo Neira Ayuso wrote:
> On Sat, Aug 19, 2023 at 12:55:03PM +1000, Duncan Roe wrote:
> > There is a libnetfilter_queue patch of mine from the March 2022 that is still
> > under review in Patchwork:
> >
> > https://patchwork.ozlabs.org/project/netfilter-devel/patch/20220328024821.9927-1-duncan_roe@optusnet.com.au/
> >
> > I tested recently with 63KB packets: overall CPU decrease 20%, user CPU decrease
> > 50%.
>
> I just took the bare minimum of this patch to provide more control on
> memory management as you request, it is here:
>
> http://git.netfilter.org/libnetfilter_queue/commit/?id=91d2c947b473b3540be5474c7128a5fa4ce60934
>
> I have removed the extra callback wrapper which does not provide much
> but an extra layer to the user.
>
> > This patch could open an avenue to having libnetfilter_queue handle tunneling.
> > E.g. for tcp over udp, you could have 2 pktbuff structs (because the data area
> > can be anywhere, rather than residing after the pktbuff head).
>
> Please, do not pursue this approach, this pkt_buff structure is
> mocking the sk_buff API in the kernel in a very simplistic way. You
> can still implement such tunnel handling in your application.
>
> Thanks.

Thanks - I'll try it.

libnetfilter_queue patch ping

[Duncan Roe]

Hi Pablo,

There is a libnetfilter_queue patch of mine from December 2023 to add
nfq_socket_sendto() that is still under review in Patchwork:

https://patchwork.ozlabs.org/project/netfilter-devel/patch/20231211005635.7566-2-duncan_roe@optusnet.com.au/

Would you prefer a v2 with the code snippet actually verifying that errno is
EOPNOTSUPP?

Alternatively would you prefer to keep using mnl_socket_sendto() and have a
supplementary call (e.g. nfq_socket_query()) to check the result? (i.e. after
nfq_nlmsg_put2() with NLM_F_ACK). That's how I'm doing it in the libmnl-only
libnetfilter_queue enhancement (I only thought of the nfq_socket_sendto()
composite later).

It would be nice to get a yes / no / please do xxx.

Cheers ... Duncan.

libnetfilter_queue patch ping

[Duncan Roe]

Hi Pablo,

I sent
https://patchwork.ozlabs.org/project/netfilter-devel/patch/20240506231719.9589-1-duncan_roe@optusnet.com.au/
to the list.

Did you see it? Patchwork picked it up, but I never saw it from the list.

It's a small and surely uncontroversial fix of a memory leak in nfq_close().

Cheers ... Duncan.