ilninno | 1 Feb 2009 03:18
Picon

Solved: Kernel Crashed when using NF_REPEAT

Hi again,

I updated kernel version and now all is working fine, sorry for any
inconvenience, I'm finishing my project and I am a little nervious.

Thanks for your time, this library is very strange and your answers
helped me a lot :)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Pete Whiting | 1 Feb 2009 05:47

trying to test libnetfilter_queue on openwrt kamikaze_RC2 - failing with "connection refused"

I am trying to build/test libnetfilter_queue for a user-space app
running on openwrt. Compile failed in the utils subdirectory until I
modified Makefile.in to include libnfnetlink.so:

--- original-libnetfilter_queue-0.0.16/utils/Makefile.in	2008-06-27
04:07:44.000000000 -0600
+++ libnetfilter_queue-0.0.16/utils/Makefile.in	2009-01-31
18:29:03.000000000 -0700
 <at>  <at>  -48,7 +48,7  <at>  <at>  nfqnl_test_OBJECTS = $(am_nfqnl_test_OBJ
 nfqnl_test_DEPENDENCIES = ../src/libnetfilter_queue.la
 nfqnl_test_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
 	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
-	$(nfqnl_test_LDFLAGS) $(LDFLAGS) -o $ <at> 
+	$(nfqnl_test_LDFLAGS) $(LDFLAGS) -o $ <at>  libnfnetlink.so
 DEFAULT_INCLUDES = -I. <at> am__isrc <at> 
 depcomp = $(SHELL) $(top_srcdir)/depcomp
 am__depfiles_maybe = depfiles

I'm sure there is a better way to do this.

Once built and installed I tried running nfqnl_test as root:
root <at> Kamikaze_RC2:~# ./nfqnl_test
opening library handle
unbinding existing nf_queue handler for AF_INET (if any)
nfnl_talk: sendmsg(netlink) Connection refused
error during nfq_unbind_pf()

I verified that xt_NFQUEUE is installed:
root <at> Kamikaze_RC2:~# lsmod | grep QUEUE
xt_NFQUEUE               672  0
(Continue reading)

David Miller | 1 Feb 2009 10:14
Favicon

Re: [PATCH] sctp: chunkmap size is too large

From: Olivier MATZ <olivier.matz <at> 6wind.com>
Date: Fri, 30 Jan 2009 16:43:07 +0100

> I think that the chunkmap field in struct xt_sctp_info is
> too large: we have 256 chunk types and it's a bitfield,
> so the table should be 256 bits (8 uint32_t) instead
> of 64 uint32_t.
> 
> I updated the size of the table, and I did some cosmetic
> changes in SCTP_CHUNKMAP_* macros (use a mask instead of
> a modulo).
> 
>   netfilter/xt_sctp.h       |   30 ++++++++++++++++--------------
>   netfilter_ipv4/ipt_sctp.h |   30 ++++++++++++++++--------------
>   2 files changed, 32 insertions(+), 28 deletions(-)
> 
> Can someone have a look at it ? Please CC me for any replies
> as I'm not on the list.

Patrick, I assume you got this?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Eric Leblond | 1 Feb 2009 12:29
Picon
Gravatar

Re: trying to test libnetfilter_queue on openwrt kamikaze_RC2 - failing with "connection refused"


Hi,

Pete Whiting a écrit :
> I am trying to build/test libnetfilter_queue for a user-space app
> running on openwrt. Compile failed in the utils subdirectory until I
> modified Makefile.in to include libnfnetlink.so:
> 
> 
> I verified that xt_NFQUEUE is installed:
> root <at> Kamikaze_RC2:~# lsmod | grep QUEUE
> xt_NFQUEUE               672  0
> x_tables                8976  16
> xt_NFQUEUE,ipt_ULOG,xt_string,xt_layer7,ipt_ipp2p,ipt_MASQUERADE,iptable_nat,xt_state,ipt_REJECT,xt_TCPMSS,ipt_LOG,xt_multiport,xt_mac,xt_limit,ip_tables,xt_tcpudp

It seems the nfnetlink_queue module is missing. It should not be on that
list because of your grep but it could be a good explanation (your
strace seems to confirm this).

If this is not the case, please apply the joined patch and let us know.

By the way, please tell us your kernel version. It seems this problem is
specific to some version.

BR,
--
Eric Leblond <eric <at> inl.fr>
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/
(Continue reading)

Pete Whiting | 1 Feb 2009 13:38

Re: trying to test libnetfilter_queue on openwrt kamikaze_RC2 - failing with "connection refused"

you were correct - I had the wrong kernel modules loaded. Once built
and installed the error went away. Patch to ignore return code was not
needed.

sorry for the noise.

kernel version 2.6.25.17

2009/2/1 Eric Leblond <eric <at> inl.fr>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> Pete Whiting a écrit :
>> I am trying to build/test libnetfilter_queue for a user-space app
>> running on openwrt. Compile failed in the utils subdirectory until I
>> modified Makefile.in to include libnfnetlink.so:
>>
>>
>> I verified that xt_NFQUEUE is installed:
>> root <at> Kamikaze_RC2:~# lsmod | grep QUEUE
>> xt_NFQUEUE               672  0
>> x_tables                8976  16
>> xt_NFQUEUE,ipt_ULOG,xt_string,xt_layer7,ipt_ipp2p,ipt_MASQUERADE,iptable_nat,xt_state,ipt_REJECT,xt_TCPMSS,ipt_LOG,xt_multiport,xt_mac,xt_limit,ip_tables,xt_tcpudp
>
> It seems the nfnetlink_queue module is missing. It should not be on that
> list because of your grep but it could be a good explanation (your
> strace seems to confirm this).
>
(Continue reading)

Pablo Neira Ayuso | 1 Feb 2009 14:33
Favicon

[RFC] netlink broadcast return value

Currently, and according to my interpretation of the source code,
netlink_broadcast() return-value reports errors to the caller if no
messages at all were delivered:

1) If, at least, one message has been delivered correctly, returns 0.
2) Otherwise, if no messages at all were delivered due to skb_clone()
failure, return -ENOBUFS.
3) Otherwise, if there are no listeners, return -ESRCH.

I would need to know if the caller has failed delivering any of the
messages to the listeners as follows:

1) If it fails to deliver any message (for whatever reason), return
-ENOBUFS.
2) If all messages were delivered OK, returns 0.
3) If no listeners, return -ESRCH.

In the current ctnetlink code and in Netfilter in general, we can add
reliable logging and connection tracking event delivery by dropping the
packets whose events were not successfully delivered over Netlink. Of
course, this option would be settable via /proc as this approach reduces
performance (in terms of filtered connections per seconds by a stateful
firewall) but providing reliable logging and event delivery (for
conntrackd) in return.

I have check the whole kernel code to look for current users of
netlink_broadcast() to see how they are handling errors reported and how
a change in the return value would affect them. Here it follows a short
summary:

(Continue reading)

Pablo Neira Ayuso | 1 Feb 2009 21:52
Favicon

Re: libxtables: prefix names and order it #1

Jan Engelhardt wrote:
> As previously mentioned, libxtables needs some goodtime cleanup first.
> Now let me throw patches (unspecified number as of yet) at it-

Applied. Thanks. I have added a comment telling that this patch is
intended to fix Jamal's tc ipt dependencies with iptables.

--

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Pablo Neira Ayuso | 1 Feb 2009 21:56
Favicon

Re: libxtables: prefix names and order it #2

Jan Engelhardt wrote:
> diff --git a/ip6tables-restore.c b/ip6tables-restore.c
> index a84c2e3..097711f 100644
> --- a/ip6tables-restore.c
> +++ b/ip6tables-restore.c
>  <at>  <at>  -12,6 +12,7  <at>  <at> 
>  
>  #include <getopt.h>
>  #include <sys/errno.h>
> +#include <stdbool.h>
>  #include <string.h>
>  #include <stdio.h>
>  #include <stdlib.h>

Aie. I was reverting this C99-specific thing but then I have noticed
that there's already one reference to it in the tree. I'm going to
revert it.

This break the compilation in many existing setups (like some of mine)
that don't have the stdbool.h header. BTW, iptables is being compiled
with gcc89 dialect, at least by now.

--

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Pablo Neira Ayuso | 1 Feb 2009 22:17
Favicon

Re: libxtables: prefix names and order it #1

Jan Engelhardt wrote:
> On Tuesday 2009-01-27 15:29, jamal wrote:
>> On Tue, 2009-01-27 at 09:19 -0500, jamal wrote:
>>
>>> Ok, no problem - let me know when you are done.
>> BTW, it would be nice if you commit those patches to the git tree and i
>> pull them.
> 
> The proposed changes are at
> 
> 	git://dev.medozas.de/iptables master
> 
> 	92 files changed, 1063 insertions(+), 1135 deletions(-)
> 
> They are pretty broad, but repetitive.
> 
> There are a few functions left. Like exit_error, which still has ties
> to the origin program (iptables, ip6tables), to do option freeing for
> example. Have not yet thought of how to resolve that. Ideas welcome.

I think that you can move functions that are common to iptables and
ip6tables like exit_error(), merge_options(), ... and so on to
libxtables. I think that the purpose of this libxtables library should be:

1) To provide an API for jamal's tc ipt and your xtables-addon thing
(anyone willing to compile their .so files without recompiling iptables).
2) To factorize some code which is common to iptables and ip6tables.

--

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers
(Continue reading)

Pablo Neira Ayuso | 1 Feb 2009 22:38
Favicon

Re: libxtables: prefix names and order it #2

Pablo Neira Ayuso wrote:
> Jan Engelhardt wrote:
>> diff --git a/ip6tables-restore.c b/ip6tables-restore.c
>> index a84c2e3..097711f 100644
>> --- a/ip6tables-restore.c
>> +++ b/ip6tables-restore.c
>>  <at>  <at>  -12,6 +12,7  <at>  <at> 
>>  
>>  #include <getopt.h>
>>  #include <sys/errno.h>
>> +#include <stdbool.h>
>>  #include <string.h>
>>  #include <stdio.h>
>>  #include <stdlib.h>
> 
> Aie. I was reverting this C99-specific thing but then I have noticed
> that there's already one reference to it in the tree. I'm going to
> revert it.
> 
> This break the compilation in many existing setups (like some of mine)
> that don't have the stdbool.h header. BTW, iptables is being compiled
> with gcc89 dialect, at least by now.

Forget this. gnu89 contains some c99 extensions like bool so this is
fine. I was confused by one problem spot in the compilation of iptables
in my setup. I have applied this patch. Thanks Jan.

--

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers
--
(Continue reading)


Gmane