RE: [PATCH nf-next] netfilter: tcp: Use TCP_MAX_WSCALE instead of literal 14

> From: Eric Dumazet [mailto:eric.duma...@gmail.com] > On Thu, 2017-04-20 at 08:44 +0800, Gao Feng wrote: > > > On Wed, Apr 19, 2017 at 09:57:55PM +0200, Pablo Neira Ayuso wrote: > > > > On Wed, Apr 19, 2017 at 09:22:08AM -0700, Eric Dumazet wrote: > > > > > On Wed, 2017-04-19 at 17:58 +0200,

Re: [PATCH nf-next] netfilter: tcp: Use TCP_MAX_WSCALE instead of literal 14

On Thu, 2017-04-20 at 08:44 +0800, Gao Feng wrote: > > On Wed, Apr 19, 2017 at 09:57:55PM +0200, Pablo Neira Ayuso wrote: > > > On Wed, Apr 19, 2017 at 09:22:08AM -0700, Eric Dumazet wrote: > > > > On Wed, 2017-04-19 at 17:58 +0200, Pablo Neira Ayuso wrote: > > > > > On Wed, Apr 19, 2017 at

[PATCH] ipvs: explicitly forbid ipv6 service/dest creation if ipv6 mod is disabled

When creating a new ipvs service, ipv6 addresses are always accepted if CONFIG_IP_VS_IPV6 is enabled. On dest creation the address family is not explicitly checked. This allows the user-space to configure ipvs services even if the system is booted with ipv6.disable=1. On specific configuration,

[PATCH] netfilter: Wrong icmp6 checksum for ICMPV6_TIME_EXCEED in reverse SNATv6 path

When recalculating the outer ICMPv6 checksum for a reverse path NATv6 such as ICMPV6_TIME_EXCEED nf_nat_icmpv6_reply_translation() was accessing data beyond the headlen of the skb for non-linear skb. This resulted in incorrect ICMPv6 checksum as garbage data was used. Signed-off-by: Dave

Re: nfqueue buf size for recv()

On Wed, Apr 19, 2017 at 11:45:21PM +0200, Florian Westphal wrote: > Oleg wrote: > > Can anybody tell me how can i determine a right buf size for recv() > > in libnetfilter_queue program. > > > >

[PATCH nf] MAINTAINERS: add Florian Westphal as netfilter maintainer

Signed-off-by: Florian Westphal --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 676c139bc883..a2ba438cdfe8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8687,6 +8687,7 @@ F:drivers/net/ethernet/neterion/ NETFILTER M:

[PATCH v2 nf-next 0/3] netfilter: conntrack: removal prealloc support

The prealloc flag is only used for the nat extension (and that extension is not even needed anymore in some cases). This removes prealloc, marks all extension structs as const and then also simplifies the initial extension allocation. Currently (default settings), each conntrack will use 64

[PATCH v2 nf-next 1/3] netfilter: conntrack: remove prealloc support

It was used by the nat extension, but since commit 7c9664351980 ("netfilter: move nat hlist_head to nf_conn") its only needed for connections that use MASQUERADE target or a nat helper. Also it seems a lot easier to preallocate a fixed size instead. With default settings, conntrack first adds

[PATCH v2 nf-next 3/3] netfilter: conntrack: handle initial extension alloc via krealloc

krealloc(NULL, ..) is same as kmalloc(), so we can avoid special-casing the initial allocation after the prealloc removal (we had to use ->alloc_len as the initial allocation size). This also means we do not zero the preallocated memory anymore; only offsets[]. Existing code makes sure the new

[PATCH v2 nf-next 2/3] netfilter: conntrack: mark extension structs as const

Signed-off-by: Florian Westphal --- No changes since v1. include/net/netfilter/nf_conntrack_extend.h | 4 ++-- net/netfilter/nf_conntrack_acct.c | 2 +- net/netfilter/nf_conntrack_ecache.c | 2 +- net/netfilter/nf_conntrack_extend.c | 4 ++--

[PATCH nf-next 0/3] netfilter: extensions: don't add nat by default

The nat extension only holds information needed by pptp and the masquerade target (and in the latter case its not essential), so no need to attach it by default. First two patches add the nat extension in masquerade and pptp case, 3rd patch gets rid of the default-add. This saves 8 bytes in the

[PATCH nf-next 2/3] netfilter: pptp: attach nat extension when needed

make sure nat extension gets added if the master conntrack is subject to NAT. This will be required once the nat core stops adding it by default. Signed-off-by: Florian Westphal --- net/ipv4/netfilter/nf_nat_pptp.c | 25 +

[PATCH nf-next 1/3] netfilter: masquerade: attach nat extension if not present

Currently the nat extension is always attached as soon as nat module is loaded. However, most NAT uses do not need the nat extension anymore. Prepare to remove the add-nat-by-default by making those places that need it attach it if its not present yet. Signed-off-by: Florian Westphal

[PATCH iptables] iptables: support insisting that the lock is held

Currently, iptables programs will exit with an error if the iptables lock cannot be acquired, but will silently continue if the lock cannot be opened at all. This can cause unexpected failures (with unhelpful error messages) in the presence of concurrent updates. This patch adds a compile-time

Re: [PATCH net] netfilter: xt_TCPMSS: add more sanity tests on tcph->doff

On 2017-04-08 23:24, Pablo Neira Ayuso wrote: On Mon, Apr 03, 2017 at 10:55:11AM -0700, Eric Dumazet wrote: From: Eric Dumazet Denys provided an awesome KASAN report pointing to an use after free in xt_TCPMSS I have provided three patches to fix this issue, either in

[conntrack-tools PATCH] conntrackd: request resync at startup

If a node goes to live, ask the other for resync at startup. This has to be done usually by hand, but I guess is an operation common enough to add some bits to ease people life here. Signed-off-by: Arturo Borrero Gonzalez --- NOTE: this patch belongs to the previous series,

[conntrack-tools PATCH 1/4] conntrackd: factorice tx_queue functions

They are shared by both sync-ftfw and sync-notrack. Signed-off-by: Arturo Borrero Gonzalez --- include/Makefile.am |2 +- include/queue_tx.h |7 ++ src/Makefile.am |2 +- src/queue_tx.c | 60 +++

[conntrack-tools PATCH 2/4] conntrackd: warn users about queue allocation errors

These warnings, if they happen, should help users. Signed-off-by: Arturo Borrero Gonzalez --- src/channel.c |6 +- src/queue_tx.c | 11 +-- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/src/channel.c b/src/channel.c index acbfa7d..b2f114d

[conntrack-tools PATCH 4/4] conntrackd: introduce RequestResync option

In some environments where both nodes of a cluster share all the conntracks, after an initial or manual resync, the conntrack information diverges from node to node. I have observed that this is not due to syncronization problems, given the link between the nodes is very stable and stats show no

[conntrack-tools PATCH 3/4] conntrackd: factorize resync operations

Resync operations factorization. There are two: * resync_send --> conntrackd -B (send bulk resync) * resync_req --> conntrackd -n (request resync) Future patches reuse this factorized code. Signed-off-by: Arturo Borrero Gonzalez --- include/Makefile.am |2 +-

[conntrack-tools PATCH 1/4] conntrackd: factorice tx_queue functions

They are shared by both sync-ftfw and sync-notrack. Signed-off-by: Arturo Borrero Gonzalez --- include/Makefile.am |2 +- include/queue_tx.h |7 ++ src/Makefile.am |2 +- src/queue_tx.c | 60 +++

[conntrack-tools PATCH 3/4] conntrackd: factorize resync operations

Resync operations factorization. There are two: * resync_send --> conntrackd -B (send bulk resync) * resync_req --> conntrackd -n (request resync) Future patches reuse this factorized code. Signed-off-by: Arturo Borrero Gonzalez --- include/Makefile.am |2 +-

[conntrack-tools PATCH 4/4] conntrackd: introduce RequestResync option

In some environments where both nodes of a cluster share all the conntracks, after an initial or manual resync, the conntrack information diverges from node to node. I have observed that this is not due to syncronization problems, given the link between the nodes is very stable and stats show no

[conntrack-tools PATCH 2/4] conntrackd: warn users about queue allocation errors

These warnings, if they happen, should help users. Signed-off-by: Arturo Borrero Gonzalez --- src/channel.c |6 +- src/queue_tx.c | 11 +-- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/src/channel.c b/src/channel.c index acbfa7d..b2f114d

[PATCH nf-next v3] netfilter: SYNPROXY: Return NF_STOLEN instead of NF_DROP during handshaking

From: Gao Feng Current SYNPROXY codes return NF_DROP during normal TCP handshaking, it is not friendly to caller. Because the nf_hook_slow would treat the NF_DROP as an error, and return -EPERM. As a result, it may cause the top caller think it meets one error. For example, the