Re: [PATCH nf 1/2] netfilter: nft_set_bitmap: fetch the element key based on the set->klen

2017-03-06 Thread Liping Zhang
Hi Pablo, 2017-03-06 20:01 GMT+08:00 Pablo Neira Ayuso : [...] > Right, the userdata case is not handled properly. And in this case we > have no specific flag at set creation, so element comments may come > without previous notice via set flags. > > I think we have to keep a

[PATCH nf-next] netfilter: nf_tables: validate the expr explicitly after init successfully

2017-03-05 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> When we want to validate the expr's dependency or hooks, we must do two things to accomplish it. First, write a X_validate callback function and point ->validate to it. Second, call X_validate in init routine. This is very common, such as fib, na

[PATCH nf 2/2] netfilter: nft_set_bitmap: fix memory leak

2017-03-05 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> Unlike other set types, we will not link struct nft_set_ext into our internal structure, so we need to free it after activation, otherwise the nft_set_ext's memory will be leaked forever. Also move nf_tables_setelem_notify() to the front of ops->

[PATCH nf 1/2] netfilter: nft_set_bitmap: fetch the element key based on the set->klen

2017-03-05 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> Currently we just assume the element key as a u32 integer, regardless of the set key length. This is incorrect, for example, the tcp port number is only 16 bits. So when we use the nft_payload expr to get the tcp dport and store it to dreg, the

Re: [PATCH nf 1/1] netfilter: h323,sip: Fix possible dead loop in nat_rtp_rtcp and nf_nat_sdp_media

2017-03-02 Thread Liping Zhang
Hi, 2017-03-02 18:18 GMT+08:00 Gao Feng : [...] > The expect class is NF_CT_EXPECT_CLASS_DEFAULT, and proto is > IPPROTO_UDP at the function "expect_rtp_rtcp", > And it makes sure the port is even number. > > But look at the process_gcf, the port is got from the packet data at >

Re: [PATCH nf 1/1] netfilter: h323,sip: Fix possible dead loop in nat_rtp_rtcp and nf_nat_sdp_media

2017-03-02 Thread Liping Zhang
Hi, 2017-03-02 15:57 GMT+08:00 : > From: Gao Feng > > When h323 and sip try to insert expect nodes, they would increase > the port by 2 for loop, and the loop condition is that "port != 0". > So when the start port is odd number, port never increases to zero.

Re: [PATCH nf-next v2 2/2] netfilter: nft_hash: support of symmetric hash

2017-02-28 Thread Liping Zhang
Hi, 2017-03-01 1:38 GMT+08:00 Laura Garcia Liebana : [...] > +static const struct nft_expr_ops * > +nft_hash_select_ops(const struct nft_ctx *ctx, > + const struct nlattr * const tb[]) > +{ > + u32 type; > + > + if (!tb[NFTA_HASH_TYPE]) > +

Re: [PATCH iptables] xtables: Remove unused macro

2017-02-27 Thread Liping Zhang
Hi, 2017-02-28 4:33 GMT+08:00 Subash Abhinov Kasiviswanathan : > Minor change to remove the unused macro added as part of commit > e8f857a5a1514c3e7d0d8ea0f7d2d571f0e37bd1 ("xtables: Add an interval > option for xtables lock wait") [...] > -#define BASE_MICROSECONDS

[PATCH nf-next] netfilter: nfnetlink: remove static declaration from err_list

2017-02-17 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> Otherwise, different subsys will race to access the err_list, with holding the different nfnl_lock(subsys_id). But this will not happen now, since ->call_batch is only implemented by nftables, so the err_list is protected by nfnl_lock(NFNL_SUBSYS

[PATCH iptables V2 2/2] xshared: using the blocking file lock request when we wait indefinitely

2017-02-06 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> When using "-w" to avoid concurrent instances, we try to do flock() every one second until it success. But one second maybe too long in some situations, and it's hard to select a suitable interval time. So when using "iptables -w&

[PATCH iptables 2/2] xshared: using the blocking file lock request when we wait indefinitely

2017-02-05 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> When using "-w" to avoid concurrent instances, we try to do flock() every one second until it success. But one second maybe too long in some situations, and it's hard to select a suitable interval time. So when using "iptables

[PATCH nf] netfilter: nft_log: restrict the log prefix length to 127

2017-01-22 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> First, log prefix will be truncated to NF_LOG_PREFIXLEN-1, i.e. 127, at nf_log_packet(), so the extra part is useless. Second, after adding a log rule with a very very long prefix, we will fail to dump the nft rules after this _special_ one, but acc

[PATCH nf V2] netfilter: nf_tables: validate the name size when possible

2017-01-20 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> Currently, if the user add a stateful object with the name size exceed NFT_OBJ_MAXNAMELEN - 1 (i.e. 31), we truncate it down to 31 silently. This is not friendly, furthermore, this will cause duplicated stateful objects when the first 31 char

Re: [PATCH nf-next v2 1/1] netfilter: nf_tables: Eliminate duplicated codes in nf_tables_table_enable

2017-01-20 Thread Liping Zhang
2017-01-20 15:42 GMT+08:00 Feng Gao : [...] > In v2 patch, I copied your recommend codes "if (cnt && --cnt == 0)". > Today I think it is not right to use "--cnt", it should use "cnt--". > Because when the cnt is 1, the "--cnt" would break directly. > So I send the v3 patch.

[PATCH nf] netfilter: nf_tables: report error if stateful obj's name is truncated

2017-01-19 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> Currently, if the user add a stateful object with the name size exceed NFT_OBJ_MAXNAMELEN - 1 (i.e. 31), we truncate it down to 31 silently. This is not friendly, furthermore, this will cause duplicated stateful objects when the first 31 char

Re: [PATCH nf] netfilter: nf_tables: report error if stateful obj's name is truncated

2017-01-19 Thread Liping Zhang
2017-01-19 22:09 GMT+08:00 Pablo Neira Ayuso <pa...@netfilter.org>: > On Thu, Jan 19, 2017 at 10:00:20PM +0800, Liping Zhang wrote: >> From: Liping Zhang <zlpnob...@gmail.com> >> >> Currently, if the user add a stateful object with the name size exceed >&g

[PATCH nf-next 1/2] netfilter: pkttype: unnecessary to check ipv6 multicast address

2017-01-07 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> Since there's no broadcast address in IPV6, so in ipv6 family, the PACKET_LOOPBACK must be multicast packets, there's no need to check it again. Signed-off-by: Liping Zhang <zlpnob...@gmail.com> --- net/netfilter/nft_meta.c | 5 + n

[PATCH nf] netfilter: nf_tables: fix possible oops when dumping stateful objects

2017-01-07 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> When dumping nft stateful objects, if NFTA_OBJ_TABLE and NFTA_OBJ_TYPE attributes are not specified either, filter will become NULL, so oops will happen(actually nft utility will always set NFTA_OBJ_TABLE attr, so I write a test program to make this

[PATCH nf] netfilter: rpfilter: fix incorrect loopback packet judgment

2017-01-07 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> Currently, we check the existing rtable in PREROUTING hook, if RTCF_LOCAL is set, we assume that the packet is loopback. But this assumption is incorrect, for example, a packet encapsulated in ipsec transport mode was received and routed to local,

[PATCH iptables] extensions: libxt_connbytes: Add translation to nft

2016-12-25 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> For example: # iptables-translate -A OUTPUT -m connbytes --connbytes 200 \ --connbytes-dir original --connbytes-mode packets nft add rule ip filter OUTPUT ct original packets ge 200 counter # iptables-translate -A OUTPUT -m connbytes ! --con

[PATCH nft] ct: add average bytes per packet counter support

2016-12-25 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> Similar to connbytes extension in iptables, now you can use it to match average bytes per packet a connection has transferred so far. For example, match avgpkt in "BOTH" diretion: # nft add rule x y ct avgpkt \> 100 Match avgpkt

[PATCH libnftnl] src: ct: add average bytes per packet counter support

2016-12-25 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> Similar to ct packets/bytes ... Signed-off-by: Liping Zhang <zlpnob...@gmail.com> --- include/linux/netfilter/nf_tables.h | 5 + src/expr/ct.c | 3 ++- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/i

[PATCH nf-next 2/2] netfilter: nft_ct: add average bytes per packet support

2016-12-25 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> Similar to xt_connbytes, user can match how many average bytes per packet a connection has transferred so far. Signed-off-by: Liping Zhang <zlpnob...@gmail.com> --- include/uapi/linux/netfilter/nf_tables.h | 2 ++ net/netfil

[PATCH nf-next 1/2] netfilter: nf_tables: add missing descriptions in nft_ct_keys

2016-12-25 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> We missed to add descriptions about NFT_CT_LABELS, NFT_CT_PKTS and NFT_CT_BYTES, now add it. Signed-off-by: Liping Zhang <zlpnob...@gmail.com> --- include/uapi/linux/netfilter/nf_tables.h | 3 +++ 1 file changed, 3 insertions(+) diff --g

Re: nftables: masquerade sets wrong source address

2016-12-18 Thread Liping Zhang
2016-12-17 22:18 GMT+08:00 Liping Zhang <zlpnob...@gmail.com>: > > For loopback connection, the request packets will traverse: > OUTPUT->POSTROUTING->PREROUTING->INPUT > and the source ip will be modified in nat POSTROUTING hook. > > Meanwhile the reply pac

Re: nftables: masquerade sets wrong source address

2016-12-17 Thread Liping Zhang
Hi Tom, 2016-12-13 21:28 GMT+08:00 Tom Hacohen : > Hi, > > I've recently migrated from iptables (no modules loaded anymore) to > nftables and came across a weird situation that looks like a bug to > me. > > When using "masquerade" it always sets the ip address to that of one > of

[PATCH nf-next] netfilter: rpfilter: bypass ipv4 lbcast packets with zeronet source

2016-12-03 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> Otherwise, DHCP Discover packets(0.0.0.0->255.255.255.255) may be dropped incorrectly. Signed-off-by: Liping Zhang <zlpnob...@gmail.com> --- net/ipv4/netfilter/ipt_rpfilter.c | 8 +--- net/ipv4/netfilter/nft_fib_ipv4.c | 13 +++

Re: [PATCH nf-next] netfilter: nft_fib: store loopback interface to dreg when rt is local

2016-11-30 Thread Liping Zhang
Hi Florian, 2016-11-28 20:25 GMT+08:00 Florian Westphal : [...] >> diff --git a/net/ipv4/netfilter/nft_fib_ipv4.c >> b/net/ipv4/netfilter/nft_fib_ipv4.c >> index 2581363..2107775 100644 >> --- a/net/ipv4/netfilter/nft_fib_ipv4.c >> +++ b/net/ipv4/netfilter/nft_fib_ipv4.c >> @@

[PATCH iptables] extensions: LOG: add log flags translation to nft

2016-11-27 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> For example: # iptables-translate -A OUTPUT -j LOG --log-uid nft add rule ip filter OUTPUT counter log flags skuid # iptables-translate -A OUTPUT -j LOG --log-tcp-sequence \ --log-tcp-options nft add rule ip filter OUTPUT counter log fla

Re: [PATCH nf-next] netfilter: nft_fib: store loopback interface to dreg when rt is local

2016-11-25 Thread Liping Zhang
At 2016-11-24 22:48:59, "Florian Westphal" <f...@strlen.de> wrote: >Liping Zhang <zlpnob...@163.com> wrote: [...] >"1" should only appear if lookup-up address is configured on this machine. >For saddr, I don't think its good idea, because it will pass >

Re: [PATCH nf-next] netfilter: nft_fib: store loopback interface to dreg when rt is local

2016-11-24 Thread Liping Zhang
Hi Florian, At 2016-11-24 21:50:14, "Florian Westphal" <f...@strlen.de> wrote: >Liping Zhang <zlpnob...@163.com> wrote: >> In general, we haven't do routing lookup in PREROUTING hook, so it's >> very likely that fib4/6_is_local will not be met. > >loopb

[PATCH nf-next] netfilter: nft_fib: store loopback interface to dreg when rt is local

2016-11-24 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> In general, we haven't do routing lookup in PREROUTING hook, so it's very likely that fib4/6_is_local will not be met. Then the *dest will be set to 0 because we do nothing when the fib result is RTN_LOCAL. So if the user want to drop all packets

[PATCH nf] netfilter: nft_range: add the missing NULL pointer check

2016-11-21 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> Otherwise, kernel panic will happen if the user does not specify the related attributes. Fixes: 0f3cd9b36977 ("netfilter: nf_tables: add range expression") Signed-off-by: Liping Zhang <zlpnob...@gmail.com> --- net/netfilter/nft_rang

Re: [PATCH nf] netfilter: nf_tables: fix inconsistent element expiration calculation

2016-11-21 Thread Liping Zhang
Hi Anders, 2016-11-21 16:57 GMT+08:00 Anders K. Pedersen | Cohaesio : [...] >> nla[NFTA_SET_TIMEOUT] should be kept indent consistent with >> be64_to_cpu. >> You can add some spaces after tab. > > The indentation is deliberate, because I don't want to give the > impression that

Re: [PATCH nf] netfilter: nf_tables: fix inconsistent element expiration calculation

2016-11-20 Thread Liping Zhang
2016-11-21 0:38 GMT+08:00 Anders K. Pedersen | Cohaesio <a...@cohaesio.com>: > From: Anders K. Pedersen <a...@cohaesio.com> > > As Liping Zhang reports, after commit a8b1e36d0d1d ("netfilter: nft_dynset: > fix element timeout for HZ != 1000"), priv->timeo

Re: [PATCH nf] netfilter: nft_dynset: fix incorrect element expiration calculation

2016-11-20 Thread Liping Zhang
2016-11-20 17:38 GMT+08:00 Anders K. Pedersen | Cohaesio : [...] > I believe that updating elements in dynsets can happen much more > frequently than interactions with userspace. One of my own use cases is Make sense. Considering the performance cost, your patch looks better:)

[PATCH nf] netfilter: nft_dynset: fix incorrect element expiration calculation

2016-11-19 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> After commit a8b1e36d0d1d ("netfilter: nft_dynset: fix element timeout for HZ != 1000"), priv->timeout was stored in jiffies, while set->timeout was stored in milliseconds. This is inconsistent and incorrect. Firstly, we already

[PATCH nft V2] src: add log flags syntax support

2016-11-19 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> Now NF_LOG_XXX is exposed to the userspace, we can set it explicitly. Like iptables LOG target, we can log TCP sequence numbers, TCP options, IP options, UID owning local socket and decode MAC header. Note the log flags are mutually exclusive with

Re: [PATCH nft 0/3] src: add nft log flags support

2016-11-15 Thread Liping Zhang
2016-11-15 6:21 GMT+08:00 Pablo Neira Ayuso <pa...@netfilter.org>: > On Sun, Sep 25, 2016 at 05:06:58PM +0800, Liping Zhang wrote: >> From: Liping Zhang <liping.zh...@spreadtrum.com> >> >> After NF_LOG_XXX is exposed to the userspace, we can set log flags to

[PATCH nf-next] netfilter: nfnetlink_log: add "nf-logger-5-1" module alias name

2016-11-14 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> So we can autoload nfnetlink_log.ko when the user adding nft log group X rule in netdev family. Signed-off-by: Liping Zhang <zlpnob...@gmail.com> --- net/netfilter/nfnetlink_log.c | 1 + 1 file changed, 1 insertion(+) diff --git a/n

[PATCH nf-next] netfilter: nf_log: do not assume ethernet header in netdev family

2016-11-14 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> In netdev family, we will handle non ethernet packets, so using eth_hdr(skb)->h_proto is incorrect. Meanwhile, we can use socket(AF_PACKET...) to sending packets, so skb->protocol is not always set in bridge family. Add an ext

[PATCH nft] tests: shell: add test case for inserting element into verdict map

2016-11-08 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> "dalega...@gmail.com" reports that when inserting an element into a verdict map, kernel crash will happen. Now add this test case so we can avoid future regressions fail. Signed-off-by: Liping Zhang <zlpnob...@gmail.com> --- ..

Re: [PATCH nf] netfilter: nf_tables: fix oops when inserting an element into a verdict map

2016-11-07 Thread Liping Zhang
2016-11-07 18:58 GMT+08:00 Arturo Borrero Gonzalez <art...@debian.org>: > On 6 November 2016 at 07:40, Liping Zhang <zlpnob...@163.com> wrote: >> From: Liping Zhang <zlpnob...@gmail.com> >> >> Dalegaard says: >> The following ruleset, when loaded wit

[PATCH nf-next] netfilter: nf_tables: simplify the basic expressions' init routine

2016-11-06 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> Some basic expressions are built into nf_tables.ko, such as nft_cmp, nft_lookup, nft_range and so on. But these basic expressions' init routine is a little ugly, too many goto errX labels, and we forget to call nft_range_module_exit in the exit r

[PATCH nf] netfilter: nf_tables: fix oops when inserting an element into a verdict map

2016-11-06 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> Dalegaard says: The following ruleset, when loaded with 'nft -f bad.txt' snip flush ruleset table ip inlinenat { map sourcemap { type ipv4_addr : verdict; } chain postrouting { ip saddr vmap @sourcemap accept }

[PATCH nft v2] ct: fix "ct l3proto/protocol" syntax broken

2016-10-30 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> "l3proto" and "protocol" are still keywords in our grammer, they are not STRING, so if the user input the following rule, nft will complain that the syntax is error: # nft add t c ct l3proto ipv4 :1:12-18: Error: syntax

[PATCH nft] log: rename the log level "warning" to "warn"

2016-10-30 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> This is to keep compatibility. The original keyword in grammer is "warn" instead of "warning". Fixes: 0423caa91ad2 ("src: don't need keyword for log level") Signed-off-by: Liping Zhang <zlpnob...@gmail.com> ---

[PATCH nft] ct: fix "ct l3proto/protocol" syntax broken

2016-10-30 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> "l3proto" and "protocol" are still keywords in our grammer, they are not STRING, so if the user input the following rule, nft will complain that the syntax is error: # nft add t c ct l3proto ipv4 :1:12-18: Error: syntax

Re: [PATCH nf] netfilter: xt_NFLOG: fix unexpected truncated packet

2016-10-29 Thread Liping Zhang
2016-10-30 3:04 GMT+08:00 Chris Caputo : > Pablo, > > Can we get this patch approved? It is definitely needed for the 4.8.x > tree and 4.9-rcX and mainline. > > Thanks, > Chris > Hi, This patch was already applied, and was upstream to net.git:

[PATCH nf] netfilter: nft_dup: do not use sreg_dev if the user doesn't specify it

2016-10-29 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> The NFTA_DUP_SREG_DEV attribute is not a must option, so we should use it in routing lookup only when the user specify it. Fixes: d877f07112f1 ("netfilter: nf_tables: add nft_dup expression") Signed-off-by: Liping Zhang <zlpnob...@gmail

[PATCH nf] netfilter: nf_tables: destroy the set if fail to add transaction

2016-10-29 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> When the memory is exhausted, then we will fail to add the NFT_MSG_NEWSET transaction. In such case, we should destroy the set before we free it. Fixes: 958bee14d071 ("netfilter: nf_tables: use new transaction infrastructure to handle sets&q

[PATCH nf-next] netfilter: nf_tables: remove useless U8_MAX validation

2016-10-29 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> After call nft_data_init, size is already validated and desc.len will not exceed the sizeof(struct nft_data), i.e. 16 bytes. So it will never exceed U8_MAX. Furthermore, in nft_immediate_init, we forget to call nft_data_uninit when desc.len exceeds

Re: [PATCH nf 1/3] netfilter: nft_dynset: fix panic if NFT_SET_HASH is not enabled

2016-10-26 Thread Liping Zhang
2016-10-25 22:25 GMT+08:00 Liping Zhang <zlpnob...@gmail.com>: > Maybe it's better to treat the NFT_SET_EVAL as features, I will send V2 > latter: > > diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c > index b70d3ea..8a39b2a 100644 > --- a/net/n

Re: [PATCH nf 1/3] netfilter: nft_dynset: fix panic if NFT_SET_HASH is not enabled

2016-10-25 Thread Liping Zhang
2016-10-22 18:51 GMT+08:00 Liping Zhang <zlpnob...@163.com>: > From: Liping Zhang <zlpnob...@gmail.com> > > When CONFIG_NFT_SET_HASH is not enabled and I input the following rule: > "nft add rule filter output flow table test {ip daddr counter }", kernel >

Re: [PATCH v2 nf-next 5/5] netfilter: nft: rt nexthop for inet family

2016-10-22 Thread Liping Zhang
Hi Anders, 2016-10-23 0:08 GMT+08:00 Anders K. Pedersen | Cohaesio : [...] > But ct_expr_update_type is only used during the netlink_delinearize > postprocess step, and that causes problems, when it is used in > combination with flow statements as described in other mail. I

[PATCH nf 0/3] netfilter: nf_tables: fix some bugs related to dynset

2016-10-22 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> Suppose that the user input the following nft rules, then a dynset expr is created: # nft add rule filter output flow table test { ip daddr counter } But actually, there are some bugs exist in kernel: 1. If CONFIG_NFT_SET_HASH is not enabled,

[PATCH nf 2/3] netfilter: nf_tables: fix *leak* when expr clone fail

2016-10-22 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> When nft_expr_clone failed, a series of problems will happen: 1. module refcnt will leak, we call __module_get at the beginning but we forget to put it back if ops->clone returns fail 2. memory will be leaked, if clone fail, we just re

[PATCH nf 1/3] netfilter: nft_dynset: fix panic if NFT_SET_HASH is not enabled

2016-10-22 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> When CONFIG_NFT_SET_HASH is not enabled and I input the following rule: "nft add rule filter output flow table test {ip daddr counter }", kernel panic happened on my system: BUG: unable to handle kernel NULL pointer dereferen

[PATCH nf 3/3] netfilter: nf_tables: fix race when create new element in dynset

2016-10-22 Thread Liping Zhang
From: Liping Zhang <zlpnob...@gmail.com> Packets may race when create the new element in nft_hash_update: CPU0 CPU1 lookup_fast - fail lookup_fast - fail new - ok new - ok insert - ok insert - fail(EEXIST) So when race happen

Re: [PATCH v2 nf-next 5/5] netfilter: nft: rt nexthop for inet family

2016-10-21 Thread Liping Zhang
Hi Pablo, 2016-10-22 0:58 GMT+08:00 Pablo Neira Ayuso : > We still need datatype information for the inet family, from the > netlink_delinearize step, when dumping back the policy to userspace. > Given that we cannot infer the datatype from the data size, as this > would be 16

Re: [PATCH v2 nf-next 5/5] netfilter: nft: rt nexthop for inet family

2016-10-21 Thread Liping Zhang
Hi Anders, 2016-10-21 16:26 GMT+08:00 Anders K. Pedersen | Cohaesio : [...] > I had a look at it. This construct is used for NFT_CT_SRC and > NFT_CT_DST, where the init function just returns the IPv6 length for > the inet family. But I'm not sure how this can work for

Re: [PATCH v3 nf-next 2/5] netfilter: nft: basic routing expression

2016-10-20 Thread Liping Zhang
Hi Anders, 2016-10-21 3:09 GMT+08:00 Anders K. Pedersen | Cohaesio : > +int nft_rt_get_init(const struct nft_ctx *ctx, > + const struct nft_expr *expr, > + const struct nlattr * const tb[]) > +{ > + struct nft_rt *priv =

Re: [PATCH v2 nf-next 5/5] netfilter: nft: rt nexthop for inet family

2016-10-20 Thread Liping Zhang
Hi Anders, 2016-10-20 21:52 GMT+08:00 Anders K. Pedersen | Cohaesio : > > OK, so would it be okay to replace it with > > printk_once(KERN_WARNING KBUILD_MODNAME " Address families do not match\n"); > > ? > To this question, I think it's better to do NFT_BREAK sliently, the

Re: [PATCH v2 nf-next 5/5] netfilter: nft: rt nexthop for inet family

2016-10-20 Thread Liping Zhang
Hi Anders, 2016-10-20 20:36 GMT+08:00 Anders K. Pedersen | Cohaesio : [...] > Well, the suggested userspace implementation doesn't allow a rule that > would hit this warning. It is required to use 'ether type ip ... rt ip > nexthop' or 'ether type ip6 ... rt ip6 nexthop', when

Re: [PATCH v2 nf-next 5/5] netfilter: nft: rt nexthop for inet family

2016-10-20 Thread Liping Zhang
Hi Anders, 2016-10-20 2:41 GMT+08:00 Anders K. Pedersen | Cohaesio : > +static void nft_rt_inet_get_eval(const struct nft_expr *expr, > +struct nft_regs *regs, > +const struct nft_pktinfo *pkt) > +{ > + const

[PATCH nf-next] netfilter: nft_meta: permit pkttype mangling in ip/ip6 prerouting

2016-10-19 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> After supporting this, we can combine it with hash expression to emulate the 'cluster match'. Suggested-by: Pablo Neira Ayuso <pa...@netfilter.org> Signed-off-by: Liping Zhang <liping.zh...@spreadtrum.com> --- net/netfil

[PATCH nf-next] netfilter: nft_numgen: start round robin from zero

2016-10-19 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> Currently we start round robin from 1, but it's better to start round robin from 0. This is to keep consistent with xt_statistic in iptables. Signed-off-by: Liping Zhang <liping.zh...@spreadtrum.com> --- net/netfilter/nft_numgen.c |

Re: [PATCH nf-next,RFC 08/10] netfilter: move NF_QUEUE handling away from core

2016-10-14 Thread Liping Zhang
Hi Pablo, 2016-10-13 20:02 GMT+08:00 Pablo Neira Ayuso : > +int nf_queue(struct sk_buff *skb, const struct nf_hook_state *state, > +unsigned int queuenum, bool bypass) > +{ > + int ret; > + > + ret = __nf_queue(skb, state, queuenum); > + if (ret

[PATCH nf] netfilter: xt_ipcomp: add "ip[6]t_ipcomp" module alias name

2016-10-12 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> Otherwise, user cannot add related rules if xt_ipcomp.ko is not loaded: # iptables -A OUTPUT -p 108 -m ipcomp --ipcompspi 1 iptables: No chain/target/match by that name. Signed-off-by: Liping Zhang <liping.zh...@spreadtrum.com&

[PATCH nf] netfilter: nft_hash: add missing NFTA_HASH_OFFSET's nla_policy

2016-10-12 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> Missing the nla_policy description will also miss the validation check in kernel. Fixes: 70ca767ea1b2 ("netfilter: nft_hash: Add hash offset value") Signed-off-by: Liping Zhang <liping.zh...@spreadtrum.com> --- net/netfilt

Re: [patch] netfilter: nf_tables: underflow in nft_parse_u32_check()

2016-10-12 Thread Liping Zhang
2016-10-12 14:08 GMT+08:00 Dan Carpenter : > We don't want to allow negatives here. > > Fixes: 36b701fae12a ('netfilter: nf_tables: validate maximum value of u32 > netlink attributes') > Signed-off-by: Dan Carpenter > > diff --git

[PATCH ulogd2] ulogd: fix crash when ipv4 packet is truncated

2016-10-11 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> If ipv4 packet is truncated, we should not try to dereference the iph pointer. Otherwise, if the user add such iptables rules "-j NFLOG --nflog-size 0", we will dereference the NULL pointer and crash may happen. Reported-by: Ch

[PATCH nf] netfilter: xt_NFLOG: fix unexpected truncated packet

2016-10-11 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> Justin and Chris spotted that iptables NFLOG target was broken when they upgraded the kernel to 4.8: "ulogd-2.0.5- IPs are no longer logged" or "results in segfaults in ulogd-2.0.5". Because "struct nf_loginfo li;&

[PATCH ulogd2] ulogd: fix crash when ipv4 packet is truncated

2016-10-11 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> If ipv4 packet is truncated, we should not try to dereference the iph pointer. Otherwise, if the user add such iptables rules "-j NFLOG --nflog-size 0", we will dereference the NULL pointer and crash may happen. Reported-by: Ch

[PATCH nf] netfilter: xt_NFLOG: fix unexpected truncated packet

2016-10-11 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> Justin and Chris spotted that iptables NFLOG target was broken when they upgraded the kernel to 4.8: "ulogd-2.0.5- IPs are no longer logged" or "results in segfaults in ulogd-2.0.5". Because "struct nf_loginfo li;&

[PATCH iptables 3/8] extensions: libxt_iprange: handle the invert flag properly in translation

2016-10-07 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> If we specify the invert flag, we should put "!=" after "ip saddr/daddr", so the current translation is wrong: # iptables-translate -A OUTPUT -m iprange ! --dst-range 1.1.1.1-1.1.1.2 nft add rule ip filter OUTPUT !

[PATCH iptables 1/8] extensions: libipt_realm: add a missing space in translation

2016-10-07 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> We missed a blank space when do translate to nft, so if rt_realm can be mapped to name, the result looks ugly: # iptables-translate -A OUTPUT -m realm --realm 0 nft add rule ip filter OUTPUT rtclassidcosmos c

[PATCH iptables 2/8] extensions: libxt_iprange: rename "ip saddr" to "ip6 saddr" in ip6tables-xlate

2016-10-07 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> nft will complain the syntax error if we use "ip saddr" or "ip daddr" in ip6 family, so the current translation is wrong: # ip6tables-translate -A OUTPUT -m iprange --src-range 2003::1-2003::3 nft add rule ip6 filt

[PATCH iptables 6/8] extensions: libxt_quota: add translation to nft

2016-10-07 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> For example: # iptables-translate -A OUTPUT -m quota --quota 111 nft add rule ip filter OUTPUT quota 111 bytes counter # iptables-translate -A OUTPUT -m quota ! --quota 111 nft add rule ip filter OUTPUT quota over 111 bytes counter

[PATCH iptables 5/8] extensions: libxt_ipcomp: add range support in translation

2016-10-07 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> When translate to nft rules, ipcompspi range is not supported, so: # iptables-translate -A OUTPUT -m ipcomp --ipcompspi 1:2 nft add rule ip filter OUTPUT comp cpi 1 counter # iptables-translate -A OUTPUT -m ipcomp ! --ipcompspi 3:30

[PATCH iptables 4/8] extensions: libxt_devgroup: handle the invert flag properly in translation

2016-10-07 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> We forgot to put "!=" when devgroup can be mapped to name, so translation is wrong: # iptables-translate -A OUTPUT -m devgroup ! --dst-group 0 nft add rule ip filter OUTPUT oifgroup default counter Apply this patch: # ip

[PATCH iptables 0/8] iptables-translate: fix some bugs and add more translations to nft

2016-10-07 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> This patch set fixes some bugs related to translation: * libipt_realm: add a missing space * libxt_iprange: ip6tables translation's format is not correct * libxt_iprange & libxt_devgroup: handle the invert flag properly * libxt_i

[PATCH iptables 7/8] extensions: libxt_DSCP: add translation to nft

2016-10-07 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> For example: # iptables-translate -A OUTPUT -j DSCP --set-dscp 1 nft add rule ip filter OUTPUT counter ip dscp set 0x01 # ip6tables-translate -A OUTPUT -j DSCP --set-dscp 6 nft add rule ip6 filter OUTPUT counter ip6 dscp set 0x06

Re: linux-next: manual merge of the netfilter-next tree with the net tree

2016-09-30 Thread Liping Zhang
[ remove other unrelated dev groups ] Hi pablo, 2016-09-29 9:20 GMT+08:00 Stephen Rothwell : > Hi all, > > On Tue, 13 Sep 2016 10:12:50 +1000 Stephen Rothwell > wrote: >> >> Today's linux-next merge of the netfilter-next tree got a conflict in: >>

Re: [PATCH nf-next v2 1/2] netfilter: Fix potential null pointer dereference

2016-09-27 Thread Liping Zhang
2016-09-28 11:08 GMT+08:00 Liping Zhang <zlpnob...@gmail.com>: > Hi Feng, > > 2016-09-28 9:23 GMT+08:00 Feng Gao <gfree.w...@gmail.com>: >> Hi Aaraon, >> >> On Tue, Sep 27, 2016 at 9:38 PM, Aaron Conole <acon...@bytheb.org> wrote: >>> It's

Re: [PATCH] Fix link error in 32bit arch because of 64bit division

2016-09-27 Thread Liping Zhang
Hi Vishwanath Pai, 2016-09-27 15:42 GMT+08:00 Vishwanath Pai : > Fix link error in 32bit arch because of 64bit division This should be "netfilter: xt_hashlimit: fix ... " > > --- a/net/netfilter/xt_hashlimit.c > +++ b/net/netfilter/xt_hashlimit.c > @@ -465,19 +465,20 @@ static

Re: [PATCH nf-next] netfilter: xt_osf: Use explicit member assignment to avoid implicit no padding rule

2016-09-27 Thread Liping Zhang
Hi Feng, 2016-09-27 14:00 GMT+08:00 Gao Feng : > Hi Liping, > >> >> This xt_osf_user_finger{} is carefully designed, no padding now, and >> will not be changed in the future, otherwise backward compatibility will >> be broken. > > Yes, there is no padding now. So it is ok to use

Re: [PATCH v3 2/2] netfilter: Create revision 2 of xt_hashlimit to support higher pps rates

2016-09-26 Thread Liping Zhang
Hi Vishwanath, 2016-09-23 0:43 GMT+08:00 Vishwanath Pai : > > /* Precision saver. */ > -static u32 user2credits(u32 user) > +static u64 user2credits(u64 user, int revision) > { > - /* If multiplying would overflow... */ > - if (user > 0x /

[PATCH nft 2/3] doc: add description about log flags

2016-09-25 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> Update usage description about tcpseq, tcpopt, ipopt, uid and macdecode flags in log statement. Signed-off-by: Liping Zhang <liping.zh...@spreadtrum.com> --- doc/nft.xml | 36 1 file changed, 3

[PATCH nft 1/3] src: add log flags syntax support

2016-09-25 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> Now NF_LOG_XXX is exposed to the userspace, we can set it explicitly. Like iptables LOG target, we can log TCP sequence numbers, TCP options, IP options, UID owning local socket and decode MAC header. Note the log flags are mutually exc

[PATCH libnftnl 3/3] expr: log: complete log flags support

2016-09-25 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> If NFTNL_EXPR_LOG_FLAGS is not set, it's unnecessary to print out the flags value. Furthermore, it's better to print out string message instead of the hex value. Signed-off-by: Liping Zhang <liping.zh...@spreadtrum.com> --- i

[PATCH libnftnl 1/3] expr: log: fix typo in nftnl_expr_log_export

2016-09-25 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> After test NFTNL_EXPR_LOG_FLAGS is set, we should put "log->flags" instead of "log->level". Signed-off-by: Liping Zhang <liping.zh...@spreadtrum.com> --- src/expr/log.c | 2 +- 1 file changed, 1 insertion(+)

[PATCH nf-next 2/2] netfilter: nf_log: get rid of XT_LOG_* macros

2016-09-25 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> nf_log is used by both nftables and iptables, so use XT_LOG_XXX macros here is not appropriate. Replace them with NF_LOG_XXX. Signed-off-by: Liping Zhang <liping.zh...@spreadtrum.com> --- I received the reject msg: "The

[PATCH nf-next 0/2] netfilter: complete nft log flags support

2016-09-25 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> In iptables, user can specify log flags in LOG target, for exmaple: # iptables -A OUTPUT -j LOG --log-uid # iptables -A INPUT -j LOG --log-uid --log-tcp-sequence ... But this is not supported in nft, because related NF_LOG_XXX is not e

[PATCH nf-next 1/2] netfilter: nft_log: complete NFTA_LOG_FLAGS attr support

2016-09-25 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> NFTA_LOG_FLAGS attribute is already supported, but the related NF_LOG_XXX flags are not exposed to the userspace. So we cannot explicitly enable log flags to log uid, tcp sequence, ip options and so on, i.e. such rule "nft add rule fi

[PATCH nft] src: support ct l3proto/protocol without direction syntax

2016-09-22 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> Acctually, ct l3proto and ct protocol are unrelated to direction, so it's unnecessary that we must specify dir if we want to use them. Now add support that we can match ct l3proto/protocol without direction: # nft add rule filter in

[PATCH nft] tests: py: fix numgen case failed due to changes in libnftnl

2016-09-15 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> In nftnl_expr_ng_snprintf_default, format "(%u)" was changed to "mod %u", so numgen test case failed: ... '[ numgen reg 1 = inc(2) ]' mismatches '[ numgen reg 1 = inc mod 2 ]' ... ip/numgen.t: 3 unit tests, 3 er

[PATCH nf-next] netfilter: nf_tables: improve nft payload fast eval

2016-09-15 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> There's an off-by-one issue in nft_payload_fast_eval, skb_tail_pointer and ptr + priv->len all point to the last valid address plus 1. So if they are equal, we can still fetch the valid data. It's unnecessary to fall back to nft_pay

[PATCH nf-next] netfilter: nf_queue: improve queue range support for bridge family

2016-09-15 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> After commit ac2863445686 ("netfilter: bridge: add nf_afinfo to enable queuing to userspace"), we can queue packets to the user space in bridge family. But when the user specify the queue range, packets will be only delivered to the

[PATCH nft] tests: py: add more test cases for queue expr

2016-09-14 Thread Liping Zhang
From: Liping Zhang <liping.zh...@spreadtrum.com> It's necessary to cover more test cases, for example, large queue range 1-65535, error queue number 65536. Also add a space before tailing square brackets, this is updated to keep consistent with other expr. Signed-off-by: Liping Zhang <

<    1   2   3   4   >