Re: (re-send): Convert libnetfilter_queue to not need libnfnetlink]

[Duncan Roe <duncan_roe@optusnet.com.au>]

Hi Pablo,

On Fri, Mar 29, 2024 at 11:01:56PM +0100, Pablo Neira Ayuso wrote:
> Hi Duncan,
>
[SNIP]
>
> This update is large ...

Yes it's too large. It's actually 2 separate patchsets run together:
 1. Eliminate libnfnetlink calls & headers from libnetfilter_queue (11 patches)
 2. Add all the nlif_* functions from libnfnetlink (21 patches)

> ... I see chances
> that existing applications might break with this "transparent"
> approach ...

Did you have anything specific in mind?

After I gdb-stepped through patched and unpatched code, all I could find was
nfq_open_nfnl() is missing its EBUSY check - easily fixed. Oh and internal
buffers are dimensioned MNL_SOCKET_BUFFER_SIZE (min of architecture page size
and 8192) where they used to be NFNL_BUFFSIZE (always 8192).

Patches 01/32-03/32 assure that existing old-API programs can continue to use
direct libnfnetlink calls:

Patch 01/32: Convert nfq_open() adds code taken from libnfnetlink to create a
fully populated struct nfnl_handle. This enables other functions to continue to
use libnfnetlink calls.

Patch 02/32: Convert nfq_open_nfnl() is far larger than it needs to be. It
converts the code added in patch 01/32 into a static function (which is how I
missed the EBUSY check) - I'll put the static function in patch 01/32 next time.
Other than that patch 02/32 sets up a struct mnl_socket from the data in the
struct nfnl_handle.

Patch 03/32: Convert nfq_close() calls mnl_socket_close() and adds code taken
from libnfnetlink to dispose of the struct nfnl_handle.

How about if I submit a v2 with only patches 01 - 11? That's enough so a
libnetfilter_queue build no longer needs libnfnetlink.

Cheers ... Duncan.