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.
