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
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
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->
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
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
>
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.
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])
> +
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
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
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&
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
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
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
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.
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
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
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
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
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,
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
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
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
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
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
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
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
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 +++
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
>> @@
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
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
>
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
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
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
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
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
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:)
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
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
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
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
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
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>
---
..
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
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
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
}
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
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>
---
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
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:
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
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
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
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
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
>
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
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,
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
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
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
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
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
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 =
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
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
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
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
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 |
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
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&
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
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
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
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;&
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
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;&
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 !
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
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
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
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
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
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
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
[ 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:
>>
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
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
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
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 /
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
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
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
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(+)
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
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
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
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
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
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
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
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 <
101 - 200 of 307 matches
Mail list logo