libnetfilter_queue and libnetfilter_log

libnetfilter_queue and libnetfilter_log

[Martin MAURER]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

Hi,

In one of my software projects (fireflier - interactive firewall) I have
been using QUEUE and ULOG for quite a while now. 
When I recently decided to spend more work on fireflier again, I
remembered that those two systems are deprecated meanwhile. Looking at
the subversion archives I realized, that there is quite little
development going on there for the new ones (at least for NFQUEUE, which
I concentrated on so far).
So before spending too much time on switching to those libs I first
wanted to ask, if it comes still true, that those are the ones to use
for now. (Or should I switch later and encourage users to use ULOG and
QUEUE for now?)

During my experiments I realized, that there seems to be a problem in
libipq_compat.c(ipq_read). This function never returns positive for me
(which the former implementation did on new packets. 
I guess it might have to do something with ipq_netlink_recvfrom being
commented out?

greetings
Martin



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: libnetfilter_queue and libnetfilter_log

[Patrick McHardy]

Martin MAURER wrote:
> Hi,
> 
> In one of my software projects (fireflier - interactive firewall) I have
> been using QUEUE and ULOG for quite a while now. 
> When I recently decided to spend more work on fireflier again, I
> remembered that those two systems are deprecated meanwhile. Looking at
> the subversion archives I realized, that there is quite little
> development going on there for the new ones (at least for NFQUEUE, which
> I concentrated on so far).
> So before spending too much time on switching to those libs I first
> wanted to ask, if it comes still true, that those are the ones to use
> for now. (Or should I switch later and encourage users to use ULOG and
> QUEUE for now?)
> 
> During my experiments I realized, that there seems to be a problem in
> libipq_compat.c(ipq_read). This function never returns positive for me
> (which the former implementation did on new packets. 
> I guess it might have to do something with ipq_netlink_recvfrom being
> commented out?

Yes, it was never finished and it pretty useless currently.
nfnetlink_log and nfnetlink_queue are the future and provide
a few benefits over the old implementation (easily extendable,
multiple queue instances, address family agnostic). The downside
is that if your application should also run on old kernels you
need to support both implementations (compatibility in the
other direction would be more useful IMO, so you could use the
nfnetlink_queue API with both the old and new implementation).

Re: libnetfilter_queue and libnetfilter_log

[Martin MAURER]

[-- Attachment #1: Type: text/plain, Size: 956 bytes --]

On Fri, 2006-12-15 at 11:00 +0100, Patrick McHardy wrote:
> Martin MAURER wrote:
> > Hi,
> > ...
> > libipq_compat.c(ipq_read). This function never returns positive for me
> > (which the former implementation did on new packets. 
> > I guess it might have to do something with ipq_netlink_recvfrom being
> > commented out?
> 
> Yes, it was never finished and it pretty useless currently.
> nfnetlink_log and nfnetlink_queue are the future and provide
> a few benefits over the old implementation (easily extendable,
> multiple queue instances, address family agnostic). The downside
> is that if your application should also run on old kernels you
> need to support both implementations (compatibility in the
> other direction would be more useful IMO, so you could use the
> nfnetlink_queue API with both the old and new implementation).
> 
ok. so I will go for supporting both APIs. Thanks for your information.

greetings
Martin


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]