* nfnetlink: This library is not meant as a public API for application developers.
@ 2020-02-13 11:27 Alessandro Vesely
2020-02-13 13:55 ` Pablo Neira Ayuso
2020-04-12 8:21 ` Duncan Roe
0 siblings, 2 replies; 5+ messages in thread
From: Alessandro Vesely @ 2020-02-13 11:27 UTC (permalink / raw)
To: netfilter
Has that disclaimer always been in libnfnetlink home page[*]?
It is the first time I see it.
I have a userspace filter[†] working with it, and it currently works well.
If I remove -lnfnetlink from the link command, I get just one undefined
reference to symbol 'nfnl_rcvbufsiz'. It is used only if there is a command
line option to set the buffer size to a given size, to avoid enobufs. For the
rest, the daemon uses libnetfilter_queue.
Should I rewrite that? How?
Best
Ale
--
[*] https://netfilter.org/projects/libnfnetlink/index.html
[†] https://savannah.nongnu.org/projects/ipqbdb/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: nfnetlink: This library is not meant as a public API for application developers.
2020-02-13 11:27 nfnetlink: This library is not meant as a public API for application developers Alessandro Vesely
@ 2020-02-13 13:55 ` Pablo Neira Ayuso
2020-04-12 8:21 ` Duncan Roe
1 sibling, 0 replies; 5+ messages in thread
From: Pablo Neira Ayuso @ 2020-02-13 13:55 UTC (permalink / raw)
To: Alessandro Vesely; +Cc: netfilter
Hi,
On Thu, Feb 13, 2020 at 12:27:41PM +0100, Alessandro Vesely wrote:
> Has that disclaimer always been in libnfnetlink home page[*]?
>
> It is the first time I see it.
>
> I have a userspace filter[†] working with it, and it currently works well.
>
> If I remove -lnfnetlink from the link command, I get just one undefined
> reference to symbol 'nfnl_rcvbufsiz'. It is used only if there is a command
> line option to set the buffer size to a given size, to avoid enobufs. For the
> rest, the daemon uses libnetfilter_queue.
>
> Should I rewrite that? How?
Probably, we should rewrite that sentence to: "For new software,
please consider using libmnl instead." which is actually the
intention.
libnetfilter_queue also provides an API that combines well with
libmnl.
There is no plans to remove libnfnetlink anytime soon, it's still
being used by netfilter userspace software.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: nfnetlink: This library is not meant as a public API for application developers.
2020-02-13 11:27 nfnetlink: This library is not meant as a public API for application developers Alessandro Vesely
2020-02-13 13:55 ` Pablo Neira Ayuso
@ 2020-04-12 8:21 ` Duncan Roe
2020-04-13 18:46 ` Alessandro Vesely
1 sibling, 1 reply; 5+ messages in thread
From: Duncan Roe @ 2020-04-12 8:21 UTC (permalink / raw)
To: Alessandro Vesely; +Cc: Netfilter
Hi Ale, and sorry for very late reply
On Thu, Feb 13, 2020 at 12:27:41PM +0100, Alessandro Vesely wrote:
> Has that disclaimer always been in libnfnetlink home page[*]?
>
> It is the first time I see it.
>
> I have a userspace filter[???] working with it, and it currently works well.
>
> If I remove -lnfnetlink from the link command, I get just one undefined
> reference to symbol 'nfnl_rcvbufsiz'. It is used only if there is a command
> line option to set the buffer size to a given size, to avoid enobufs. For the
> rest, the daemon uses libnetfilter_queue.
>
> Should I rewrite that? How?
>
>
> Best
> Ale
> --
Yes you can code to avoid using nfnl_rcvbufsiz() from libnfnetlink.
Thre is no libmnl or libnetfilter_queue function to do it at present, but
libmnl/examples/netfilter/nfct-daemon.c has the code.
In case you haven't git cloned libmnl, here is a summary:
> socklen_t buffersize; // Set by your command-line option
Your code likely already has:
> struct mnl_socket *nl;
> nl = mnl_socket_open(NETLINK_NETFILTER);
(after mnl_socket_bind)
> setsockopt(mnl_socket_get_fd(nl), SOL_SOCKET, SO_RCVBUFFORCE, // You should
> &buffersize, sizeof(socklen_t)); // check the return code (not shown)
If you like, you can check how big a buffer the kernel gave you
> socklen_t socklen = sizeof buffersize;
> socklen_t read_size = 0;
> getsockopt(mnl_socket_get_fd(nl), SOL_SOCKET, SO_RCVBUF, &read_size, &socklen);
From testing it seems you get a buffer of twice buffersize bytes.
HTH
Cheers ... Duncan.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: nfnetlink: This library is not meant as a public API for application developers.
2020-04-12 8:21 ` Duncan Roe
@ 2020-04-13 18:46 ` Alessandro Vesely
2020-04-22 1:37 ` Duncan Roe
0 siblings, 1 reply; 5+ messages in thread
From: Alessandro Vesely @ 2020-04-13 18:46 UTC (permalink / raw)
To: Duncan Roe; +Cc: Netfilter
Hi Duncan,
thank you very much for your tips!
On Sun 12/Apr/2020 10:21:53 +0200 Duncan Roe wrote:
> On Thu, Feb 13, 2020 at 12:27:41PM +0100, Alessandro Vesely wrote:
>> Has that disclaimer always been in libnfnetlink home page[*]?
>>
>> It is the first time I see it.
>>
>> I have a userspace filter[???] working with it, and it currently works well.
>>
>> If I remove -lnfnetlink from the link command, I get just one undefined
>> reference to symbol 'nfnl_rcvbufsiz'. It is used only if there is a command
>> line option to set the buffer size to a given size, to avoid enobufs. For the
>> rest, the daemon uses libnetfilter_queue.
>>
>> Should I rewrite that? How?
>>
>
> Yes you can code to avoid using nfnl_rcvbufsiz() from libnfnetlink.
>
> Thre is no libmnl or libnetfilter_queue function to do it at present, but
> libmnl/examples/netfilter/nfct-daemon.c has the code.
> In case you haven't git cloned libmnl, here is a summary:
>
>> socklen_t buffersize; // Set by your command-line option
> Your code likely already has:
>> struct mnl_socket *nl;
>> nl = mnl_socket_open(NETLINK_NETFILTER);
> (after mnl_socket_bind)
I don't have mnl_socket_open(). I have struct nfq_handle *h = nfq_open(); and
then fd = nfq_fd(h);
After replacing the call to nfnl_rcvbufsiz() with setsockopt(), I can actually
link without -lnfnetlink. However, I'm not sure it is sane to fiddle with
configure macros trying to avoid it. On my system I have:
ale@pcale:~$ pkg-config --libs libnetfilter_queue
-lnetfilter_queue -lnfnetlink
ale@pcale:~$ pkg-config --modversion libnetfilter_queue
1.0.2
Should a future version drop that dependency, my code is ready :-)
>> setsockopt(mnl_socket_get_fd(nl), SOL_SOCKET, SO_RCVBUFFORCE, // You should
>> &buffersize, sizeof(socklen_t)); // check the return code (not shown)
> If you like, you can check how big a buffer the kernel gave you
>> socklen_t socklen = sizeof buffersize;
>> socklen_t read_size = 0;
>> getsockopt(mnl_socket_get_fd(nl), SOL_SOCKET, SO_RCVBUF, &read_size, &socklen);
> From testing it seems you get a buffer of twice buffersize bytes.
It's stranger than that. The default value is 0x34000. If I set that same
value or higher, I seem to always get 0x68000. However, if I set 0x33fff I get
0x67ffe, the double, as you say. This strange behavior apparently was the same
when using nfnl_rcvbufsiz().
Best
Ale
--
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: nfnetlink: This library is not meant as a public API for application developers.
2020-04-13 18:46 ` Alessandro Vesely
@ 2020-04-22 1:37 ` Duncan Roe
0 siblings, 0 replies; 5+ messages in thread
From: Duncan Roe @ 2020-04-22 1:37 UTC (permalink / raw)
To: Alessandro Vesely; +Cc: Netfilter, Netfilter Development
Hi Ale,
You raise some interesting points. I'm taking this discussion onto the
netfilter-devel list which I think is more appropriate.
On Mon, Apr 13, 2020 at 08:46:59PM +0200, Alessandro Vesely wrote: [...]
> On Sun 12/Apr/2020 10:21:53 +0200 Duncan Roe wrote:
> > On Thu, Feb 13, 2020 at 12:27:41PM +0100, Alessandro Vesely wrote:
> > > Has that disclaimer always been in libnfnetlink home page[*]?
> > >
> > > It is the first time I see it.
> > >
> > > I have a userspace filter[???] working with it,
> > > and it currently works well.
> > >
> > > If I remove -lnfnetlink from the link command, I get just one undefined
> > > reference to symbol 'nfnl_rcvbufsiz'.
> > > It is used only if there is a command line option
> > > to set the buffer size to a given size, to avoid enobufs.
> > > For the rest, the daemon uses libnetfilter_queue.
This is loader trickery.
You have written your userspace filter using the deprecated interface, which
uses libnfnetlink under the covers.
That's fine - the Library Setup module documents how to use the deprecated
interface. The current functions use libmnl, but documentation for these is
still under development.
> > >
> > > Should I rewrite that? How?
> > >
> >
> > Yes you can code to avoid using nfnl_rcvbufsiz() from libnfnetlink.
> >
> > Thre is no libmnl or libnetfilter_queue function to do it at present, but
> > libmnl/examples/netfilter/nfct-daemon.c has the code.
> > In case you haven't git cloned libmnl, here is a summary:
> >
> > > socklen_t buffersize; // Set by your command-line option
> > Your code likely already has:
> > > struct mnl_socket *nl;
> > > nl = mnl_socket_open(NETLINK_NETFILTER);
> > (after mnl_socket_bind)
>
>
> I don't have mnl_socket_open(). I have struct nfq_handle *h = nfq_open(); and
> then fd = nfq_fd(h);
>
> After replacing the call to nfnl_rcvbufsiz() with setsockopt(), I can actually
> link without -lnfnetlink. However, I'm not sure it is sane to fiddle with
> configure macros trying to avoid it. On my system I have:
>
> ale@pcale:~$ pkg-config --libs libnetfilter_queue
> -lnetfilter_queue -lnfnetlink
> ale@pcale:~$ pkg-config --modversion libnetfilter_queue
> 1.0.2
>
> Should a future version drop that dependency, my code is ready :-)
>
>
> > > setsockopt(mnl_socket_get_fd(nl), SOL_SOCKET, SO_RCVBUFFORCE, // You should
> > > &buffersize, sizeof(socklen_t)); // check the return code (not shown)
> > If you like, you can check how big a buffer the kernel gave you
> > > socklen_t socklen = sizeof buffersize;
> > > socklen_t read_size = 0;
> > > getsockopt(mnl_socket_get_fd(nl), SOL_SOCKET, SO_RCVBUF, &read_size, &socklen);
> > From testing it seems you get a buffer of twice buffersize bytes.
>
>
> It's stranger than that. The default value is 0x34000. If I set that same
> value or higher, I seem to always get 0x68000.
> However, if I set 0x33fff I get 0x67ffe, the double, as you say.
> This strange behavior apparently was the same when using nfnl_rcvbufsiz().
This does look to me like a bug. Perhaps someone on the devel list would have
something to say about it.
Cheers ... Duncan.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-04-22 1:37 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-13 11:27 nfnetlink: This library is not meant as a public API for application developers Alessandro Vesely
2020-02-13 13:55 ` Pablo Neira Ayuso
2020-04-12 8:21 ` Duncan Roe
2020-04-13 18:46 ` Alessandro Vesely
2020-04-22 1:37 ` Duncan Roe
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.