Hi Duncan, thank you for your reply.
On Sat 19/Aug/2023 03:46:06 +0200 Duncan Roe wrote:
On Fri, Aug 18, 2023 at 12:56:38PM +0200, Alessandro Vesely wrote:
I have an old program (ipqbdb) which filters IPv4 packets using
libnetfilter_queue. I want to extend it to also filter IPv6, now that at
last I can use some of those addresses. [...]
There is a big DEPRECATED in the documentation, and the generated doc for
nfq_bind_pf() parameters says "This call is obsolete, Linux kernels from 3.8
onwards ignore it" (which is obviously false).
https://netfilter.org/projects/libnetfilter_queue/doxygen/
So, the first question: Can I keep using these functions? What is the alternative?
Second question: Is there a "mixed mode" parameter, besides PF_INET and
PF_INET6, that allows to capture both types? In that case, can a queue
receive either packet?
There are 2 separate APIs in libnetfilter_queue, examplified by
utils/nfqnl_test.c (your program) and examples/nf-queue.c (newer, has functions
for packet mangling).
Only the latter is included in the Debian package.
DEPRECATED was an unfortunate choice of label for the older API: the functions
are not deprecated but the underlying library that they currently use is
deprecated. In answer to your questions:
In fact it still works.
1a Can I keep using these functions?: Certainly.
1b What is the alternative?: No need to change if your current program does all
you need. I assume here that you don't access the IPv4 header fields: the new
API has functions for that (and IPv6) but the old API has nothing of that
nature.
I have nfq_set_mode(qh, NFQNL_COPY_PACKET, 20), where a copy_range of 20 is
enough to see the IP addresses —which is what it filters.
I think I'll go for the alternative anyway.
2 ...can a queue receive either packet?: Yes. utils/nfqnl_test.c works fine
with IPv6. nfq_bind_pf() really *is* obsolete - I'll explain:
In libnetfilter_queue:
In libnetfilter_queue.c:
493 int nfq_bind_pf(struct nfq_handle *h, uint16_t pf)
494 {
495 return __build_send_cfg_msg(h, NFQNL_CFG_CMD_PF_BIND, 0, pf);
496 }
In Linux kernel:
In net/netfilter/nfnetlink_queue.c
1380 case NFQNL_CFG_CMD_PF_BIND:
1381 case NFQNL_CFG_CMD_PF_UNBIND:
1382 break;
1383 default:
1384 ret = -ENOTSUPP;
1385 goto err_out_unlock;
Heck, I see. In particular, the cmd->pf argument is never used. That means
that the type of packet a filter receives only depends on what iptables of nft
are shoving at its queue, irrespective of compile and runtime config. Correct?
Best
Ale
--
