> -Original Message-
> From: Phil Sutter [mailto:p...@nwl.cc]
> Sent: Monday, December 19, 2016 4:49 PM
> To: maowenan
> Cc: netfilter-devel@vger.kernel.org
> Subject: Re: libmnl compile failure.
>
> Hi,
>
> On Fri, Dec 16, 2016 at 08:54:59AM +0800, maowenan wrote:
> > There is somethin
2016-12-20 23:16 GMT+08:00 Tom Hacohen :
> On Sat, Dec 17, 2016 at 2:18 PM, Liping Zhang wrote:
>> According to the explanations in nftables wifi:
>> https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT)
>>
>> You should add the following nft rules(I agree
udplite was copied from udp, they are virtually 100% identical.
This adds udplite tracker to udp instead, removes udplite module,
and then makes the udplite tracker builtin.
udplite will then simply re-use udp timeout settings.
It makes little sense to add separate sysctls, nowadays we have
fine-
udplite nat was copied from udp nat, they are virtually 100% identical.
Not really surprising given udplite is just udp with partial csum coverage.
old:
textdata bss dec hex filename
116061457 210 1327333d9 nf_nat.ko
330 0 2 332 14c nf_nat
Most of the code is copy&paste from the udp one; most of the udp
functions can also be used for udplite.
include/net/netfilter/ipv4/nf_conntrack_ipv4.h |1
include/net/netfilter/ipv6/nf_conntrack_ipv6.h |1
include/net/netns/conntrack.h | 16 -
net/netfilter/Makefile
Hi!
The Netfilter project proudly presents:
nftables 0.7
This release contains many accumulated bug fixes and new features
available up to the (upcoming) Linux 4.10-rc1 kernel release.
* Facilitate migration from iptables to nftables:
At compilation time, you have to pass this option
On Mon, Dec 19, 2016 at 07:11:04PM -0300, Elise Lennion wrote:
> so the user know how we express it.
>
> The base was added to all symbol tables, which are associated with
> datatype->sym_tbl, so they are displayed in the right base.
Applied, thanks Elise.
--
To unsubscribe from this list: send t
Phil:
Yes, I certainly hope that the netfilter interface is byte level
backwards compatible from the netfilter calls upwards, but there is a
chance that compatibility
is only from userspace libmnl and upwards.
If that is the case, what kernel version release can I expect the
current netfilter mes
Hi Mark,
On Tue, Dec 20, 2016 at 10:27:45AM -0600, mark diener wrote:
> Will the V8 NFT have byte level protocol compatibility with current
> linux kernel versions?
We were talking about nft manpage (which happens to live in section 8,
hence why I referred to it as 'nft.8'), not some version 8 (w
Will the V8 NFT have byte level protocol compatibility with current
linux kernel versions?
I am deployed on kernel 4.4.0-53-generic and would like to know when
structural defines like RTM_NEWADDR,NLM_F_REQUEST, etc become updated
or obsoleted.
As you can likely tell, I am not using libmnl or lib
On Sat, Dec 17, 2016 at 2:18 PM, Liping Zhang wrote:
> According to the explanations in nftables wifi:
> https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT)
>
> You should add the following nft rules(I agree this is tricky and
> unfriendly for the end use
To make the code clearer, use rb_entry() instead of container_of() to
deal with rbtree.
Signed-off-by: Geliang Tang
---
net/netfilter/xt_connlimit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/xt_connlimit.c b/net/netfilter/xt_connlimit.c
index 2aff2b7..
This machinery was introduced to avoid sudden compilation breakage of
old nftables releases. With the upcoming release of 0.7 (and 0.6 which
is now 6 months old) this is not required anymore. Moreover, users gain
nothing from older releases since they are half-boiled and buggy.
So let's get rid of
Do not use obsolete definitions in libnftnl.
Signed-off-by: Pablo Neira Ayuso
---
src/xt.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/xt.c b/src/xt.c
index c4b76c731bef..e24b0af05bab 100644
--- a/src/xt.c
+++ b/src/xt.c
@@ -201,19 +201,19 @@ void netlink
On 20 December 2016 at 12:24, Llorente Santos Jesus
wrote:
> Hi,
>
> I have been playing quite a bit with iptables lately. Ever since the ipset
> was updated to support hash:ip,mark sets, there has been the potential to
> apply efficient matching on packet marks.
> Does it make any sense to you
Hi,
I was trying to build an iptables extension that mangles IPv4 / UDP packets. I
want to create a stateless NAT mechanism to mangle either source or destination
similar to RAWDNAT/RAWSNAT targets of xtables-addons
(http://manpages.ubuntu.com/manpages/precise/man8/xtables-addons.8.html)
Howev
Hi,
I have been playing quite a bit with iptables lately. Ever since the ipset was
updated to support hash:ip,mark sets, there has been the potential to apply
efficient matching on packet marks.
Does it make any sense to you to develop a new extension that following U32 and
MARK syntax would al
Now when adding an ipt_CLUSTERIP rule, it only checks duplicate config in
clusterip_config_find_get(). But after that, there may be still another
thread to insert a config with the same ip, then it leaves proc_create_data
to do duplicate check.
It's more reasonable to check duplicate config by ipt
On Tue, Dec 20, 2016 at 8:48 AM, Pablo Neira Ayuso wrote:
> On Thu, Dec 15, 2016 at 12:31:40PM +0800, Xin Long wrote:
>> @@ -185,6 +186,17 @@ clusterip_config_init(const struct
>> ipt_clusterip_tgt_info *i, __be32 ip,
>> atomic_set(&c->refcount, 1);
>> atomic_set(&c->entries, 1);
>>
>
19 matches
Mail list logo