Re: [PATCH nf v2] netfilter: conntrack: refine gc worker heuristics, redux

[Denys Fedoryshchenko]

On 2017-01-18 03:01, Florian Westphal wrote:

This further refines the changes made to conntrack gc_worker in
commit e0df8cae6c16 ("netfilter: conntrack: refine gc worker 
heuristics").


The main idea of that change was to reduce the scan interval when 
evictions

take place.

However, on the reporters' setup, there are 1-2 million conntrack 
entries

in total and roughly 8k new (and closing) connections per second.

In this case we'll always evict at least one entry per gc cycle and 
scan

interval is always at 1 jiffy because of this test:

 } else if (expired_count) {
 gc_work->next_gc_run /= 2U;
 next_run = msecs_to_jiffies(1);

being true almost all the time.

Given we scan ~10k entries per run its clearly wrong to reduce interval
based on nonzero eviction count, it will only waste cpu cycles since a 
vast

majorities of conntracks are not timed out.

Thus only look at the ratio (scanned entries vs. evicted entries) to 
make

a decision on whether to reduce or not.

Because evictor is supposed to only kick in when system turns idle 
after

a busy period, pick a high ratio -- this makes it 50%.  We thus keep
the idea of increasing scan rate when its likely that table contains 
many

expired entries.

In order to not let timed-out entries hang around for too long
(important when using event logging, in which case we want to timely
destroy events), we now scan the full table within at most
GC_MAX_SCAN_JIFFIES (16 seconds) even in worst-case scenario where all
timed-out entries sit in same slot.

I tested this with a vm under synflood (with
sysctl net.netfilter.nf_conntrack_tcp_timeout_syn_recv=3).

While flood is ongoing, interval now stays at its max rate
(GC_MAX_SCAN_JIFFIES / GC_MAX_BUCKETS_DIV -> 125ms).

With feedback from Nicolas Dichtel.

Reported-by: Denys Fedoryshchenko 
Cc: Nicolas Dichtel 
Fixes: b87a2f9199ea82eaadc ("netfilter: conntrack: add gc worker to
remove timed-out entries")
Signed-off-by: Florian Westphal 
---
this is on top of
https://patchwork.ozlabs.org/patch/715850/
('netfilter: conntrack: remove GC_MAX_EVICTS break').

Nicolas, this is almost the same patch that you already tested, i
did some renames and changed the minimum interval to 
HZ/GC_MAX_BUCKETS_DIV

everywhere for consistency.

Denys, I am sure this fixes the gc_work cpu hogging you reported,
ntl, it would be great if you could test this.

I will try to test tonight this patch
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-01-17 21:34, Richard Guy Briggs wrote:
> On 2017-01-17 15:17, Paul Moore wrote:
> > On Tue, Jan 17, 2017 at 11:12 AM, Richard Guy Briggs  
> > wrote:
> > > On 2017-01-17 08:55, Steve Grubb wrote:
> > >> On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote:
> > 
> > ...
> > 
> > >> > Ones that are not so straightforward:
> > >> > - "secmark" depends on a kernel config setting, so should it always be
> > >> >   present but "(none)" if that kernel feature is compiled out?
> > >>
> > >> If this is selinux related, I'd treat it the same way that we do subj
> > >> everywhere else.
> > >
> > > Ok.
> > 
> > To be clear, a packet's secmark should be recorded via a dedicated
> > field, e.g. "secmark", and not use the "subj" field (it isn't a
> > subject label in the traditional sense).
> 
> I think Steve was talking about if, when or where to include that field,
> not what its label is.

In this case it is an "obj=" field, but since it is part of the LSM,
each one has its own fields.

> > paul moore
> 
> - RGB

- RGB

--
Richard Guy Briggs 
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-01-17 15:17, Paul Moore wrote:
> On Tue, Jan 17, 2017 at 11:12 AM, Richard Guy Briggs  wrote:
> > On 2017-01-17 08:55, Steve Grubb wrote:
> >> On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote:
> 
> ...
> 
> >> > Ones that are not so straightforward:
> >> > - "secmark" depends on a kernel config setting, so should it always be
> >> >   present but "(none)" if that kernel feature is compiled out?
> >>
> >> If this is selinux related, I'd treat it the same way that we do subj
> >> everywhere else.
> >
> > Ok.
> 
> To be clear, a packet's secmark should be recorded via a dedicated
> field, e.g. "secmark", and not use the "subj" field (it isn't a
> subject label in the traditional sense).

I think Steve was talking about if, when or where to include that field,
not what its label is.

> paul moore

- RGB

--
Richard Guy Briggs 
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH nf v2] netfilter: conntrack: refine gc worker heuristics, redux

[Florian Westphal]

This further refines the changes made to conntrack gc_worker in
commit e0df8cae6c16 ("netfilter: conntrack: refine gc worker heuristics").

The main idea of that change was to reduce the scan interval when evictions
take place.

However, on the reporters' setup, there are 1-2 million conntrack entries
in total and roughly 8k new (and closing) connections per second.

In this case we'll always evict at least one entry per gc cycle and scan
interval is always at 1 jiffy because of this test:

 } else if (expired_count) {
 gc_work->next_gc_run /= 2U;
 next_run = msecs_to_jiffies(1);

being true almost all the time.

Given we scan ~10k entries per run its clearly wrong to reduce interval
based on nonzero eviction count, it will only waste cpu cycles since a vast
majorities of conntracks are not timed out.

Thus only look at the ratio (scanned entries vs. evicted entries) to make
a decision on whether to reduce or not.

Because evictor is supposed to only kick in when system turns idle after
a busy period, pick a high ratio -- this makes it 50%.  We thus keep
the idea of increasing scan rate when its likely that table contains many
expired entries.

In order to not let timed-out entries hang around for too long
(important when using event logging, in which case we want to timely
destroy events), we now scan the full table within at most
GC_MAX_SCAN_JIFFIES (16 seconds) even in worst-case scenario where all
timed-out entries sit in same slot.

I tested this with a vm under synflood (with
sysctl net.netfilter.nf_conntrack_tcp_timeout_syn_recv=3).

While flood is ongoing, interval now stays at its max rate
(GC_MAX_SCAN_JIFFIES / GC_MAX_BUCKETS_DIV -> 125ms).

With feedback from Nicolas Dichtel.

Reported-by: Denys Fedoryshchenko 
Cc: Nicolas Dichtel 
Fixes: b87a2f9199ea82eaadc ("netfilter: conntrack: add gc worker to remove 
timed-out entries")
Signed-off-by: Florian Westphal 
---
this is on top of
https://patchwork.ozlabs.org/patch/715850/
('netfilter: conntrack: remove GC_MAX_EVICTS break').

Nicolas, this is almost the same patch that you already tested, i
did some renames and changed the minimum interval to HZ/GC_MAX_BUCKETS_DIV
everywhere for consistency.

Denys, I am sure this fixes the gc_work cpu hogging you reported,
ntl, it would be great if you could test this.

 net/netfilter/nf_conntrack_core.c | 39 ---
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/net/netfilter/nf_conntrack_core.c 
b/net/netfilter/nf_conntrack_core.c
index 6feb5d370319..4e8083c5e01d 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -85,9 +85,11 @@ static __read_mostly 
DEFINE_SPINLOCK(nf_conntrack_locks_all_lock);
 static __read_mostly bool nf_conntrack_locks_all;
 
 /* every gc cycle scans at most 1/GC_MAX_BUCKETS_DIV part of table */
-#define GC_MAX_BUCKETS_DIV 64u
-/* upper bound of scan intervals */
-#define GC_INTERVAL_MAX(2 * HZ)
+#define GC_MAX_BUCKETS_DIV 128u
+/* upper bound of full table scan */
+#define GC_MAX_SCAN_JIFFIES(16u * HZ)
+/* desired ratio of entries found to be expired */
+#define GC_EVICT_RATIO 50u
 
 static struct conntrack_gc_work conntrack_gc_work;
 
@@ -936,6 +938,7 @@ static noinline int early_drop(struct net *net, unsigned 
int _hash)
 
 static void gc_worker(struct work_struct *work)
 {
+   unsigned int min_interval = max(HZ / GC_MAX_BUCKETS_DIV, 1u);
unsigned int i, goal, buckets = 0, expired_count = 0;
struct conntrack_gc_work *gc_work;
unsigned int ratio, scanned = 0;
@@ -994,27 +997,25 @@ static void gc_worker(struct work_struct *work)
 * 1. Minimize time until we notice a stale entry
 * 2. Maximize scan intervals to not waste cycles
 *
-* Normally, expired_count will be 0, this increases the next_run time
-* to priorize 2) above.
+* Normally, expire ratio will be close to 0.
 *
-* As soon as a timed-out entry is found, move towards 1) and increase
-* the scan frequency.
-* In case we have lots of evictions next scan is done immediately.
+* As soon as a sizeable fraction of the entries have expired
+* increase scan frequency.
 */
ratio = scanned ? expired_count * 100 / scanned : 0;
-   if (ratio >= 90) {
-   gc_work->next_gc_run = 0;
-   next_run = 0;
-   } else if (expired_count) {
-   gc_work->next_gc_run /= 2U;
-   next_run = msecs_to_jiffies(1);
+   if (ratio > GC_EVICT_RATIO) {
+   gc_work->next_gc_run = min_interval;
} else {
-   if (gc_work->next_gc_run < GC_INTERVAL_MAX)
-   gc_work->next_gc_run += msecs_to_jiffies(1);
+   unsigned int max = GC_MAX_SCAN_JIFFIES / GC_MAX_BUCKETS_DIV;
 
-   next_run = gc_work->next_gc_run;
+ 

Re: tcp state in conntrack destroy events

[Florian Westphal]

Jarno Rajahalme  wrote:
> 
> > On Jan 17, 2017, at 1:28 PM, Florian Westphal  wrote:
> > 
> > Victor Julien  wrote:
> >> I was hoping to get the last TCP state in a conntrack destroy event,
> >> however it seems to be unavailable.
> >> 
> >> Through libnetfilter_conntrack the value retrieved at ATTR_TCP_STATE is
> >> always 0.
> >> 
> >> Using the conntrack command I see the same behavior:
> >> 
> >> destroy doesn't have it (conntrack -E -e destroy -p tcp):
> >> 
> >> [DESTROY] tcp  6 src=218.65.30.38 dst=192.168.178.254 sport=61063
> >> dport=22 packets=11 bytes=820 src=192.168.0.123 dst=218.65.30.38
> >> sport=22 dport=61063 packets=8 bytes=424 [ASSURED] mark=3 delta-time=77
> >> 
> >> update does (conntrack -E -e updates -p tcp):
> >> 
> >> [UPDATE] tcp  6 120 FIN_WAIT src=192.168.0.53 dst=x.x.x.x
> >> sport=52958 dport=443 src=x.x.x.x dst=192.168.178.254 sport=443
> >> dport=52958 [ASSURED] mark=3
> >> 
> >> Is this intentional? My goal is to create connection log that includes a
> >> hint about why the connection is gone.
> > 
> > Yes, its intentional, see
> > net/netfilter/nf_conntrack_netlink.c, there is a check for DESTROY
> > that supresses most of the extra info:
> > 
> > 682 if (events & (1 << IPCT_DESTROY)) {
> > 683if (ctnetlink_dump_acct(skb, ct, type) < 0 ||
> > 684ctnetlink_dump_timestamp(skb, ct) < 0)
> > 685   goto nla_put_failure;
> > 686} else {
> > ..
> > /* IPCT_PROTOINFO */
> > 
> > Pablo made this change in 7b621c1ea64a54f77b8a841b16dc4c9fee3ecf48,
> > i guess the rationale was that clients aren't interested in this
> > on DESTROY.
> > 
> > Would be easy to change this.
> 
> I have a use case where we want to log terminating connections, but only if a 
> specific label bit is set. To do this, we currently have to listen to both 
> create and destroy events and keep track of all the connections in the 
> userspace to be able to correlate destroy event to the connection and from 
> there to the labels. Would be nice if the destroy event included labels, so 
> that we would not have to listen to create events nor keep a duplicate 
> connection tracking table in userspace.

Pablo isn't to blame, that was me :)

When I added label support I simply did not consider this and only placed
this in the non-destroy path.

I have no objections to includte labels unconditionally, might as well
also move secmark too.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: tcp state in conntrack destroy events

[Jarno Rajahalme]

> On Jan 17, 2017, at 1:28 PM, Florian Westphal  wrote:
> 
> Victor Julien  wrote:
>> I was hoping to get the last TCP state in a conntrack destroy event,
>> however it seems to be unavailable.
>> 
>> Through libnetfilter_conntrack the value retrieved at ATTR_TCP_STATE is
>> always 0.
>> 
>> Using the conntrack command I see the same behavior:
>> 
>> destroy doesn't have it (conntrack -E -e destroy -p tcp):
>> 
>> [DESTROY] tcp  6 src=218.65.30.38 dst=192.168.178.254 sport=61063
>> dport=22 packets=11 bytes=820 src=192.168.0.123 dst=218.65.30.38
>> sport=22 dport=61063 packets=8 bytes=424 [ASSURED] mark=3 delta-time=77
>> 
>> update does (conntrack -E -e updates -p tcp):
>> 
>> [UPDATE] tcp  6 120 FIN_WAIT src=192.168.0.53 dst=x.x.x.x
>> sport=52958 dport=443 src=x.x.x.x dst=192.168.178.254 sport=443
>> dport=52958 [ASSURED] mark=3
>> 
>> Is this intentional? My goal is to create connection log that includes a
>> hint about why the connection is gone.
> 
> Yes, its intentional, see
> net/netfilter/nf_conntrack_netlink.c, there is a check for DESTROY
> that supresses most of the extra info:
> 
> 682 if (events & (1 << IPCT_DESTROY)) {
> 683if (ctnetlink_dump_acct(skb, ct, type) < 0 ||
> 684ctnetlink_dump_timestamp(skb, ct) < 0)
> 685   goto nla_put_failure;
> 686} else {
> ..
>   /* IPCT_PROTOINFO */
> 
> Pablo made this change in 7b621c1ea64a54f77b8a841b16dc4c9fee3ecf48,
> i guess the rationale was that clients aren't interested in this
> on DESTROY.
> 
> Would be easy to change this.

I have a use case where we want to log terminating connections, but only if a 
specific label bit is set. To do this, we currently have to listen to both 
create and destroy events and keep track of all the connections in the 
userspace to be able to correlate destroy event to the connection and from 
there to the labels. Would be nice if the destroy event included labels, so 
that we would not have to listen to create events nor keep a duplicate 
connection tracking table in userspace.

  Jarno

> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[nft PATCH 2/3] exthdr: Add support for exthdr specific flags

[Phil Sutter]

Signed-off-by: Phil Sutter 
---
 include/expression.h  | 1 +
 src/exthdr.c  | 4 +++-
 src/netlink_delinearize.c | 4 +++-
 src/netlink_linearize.c   | 1 +
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/expression.h b/include/expression.h
index fa1587639621e..67c046e23de1f 100644
--- a/include/expression.h
+++ b/include/expression.h
@@ -288,6 +288,7 @@ struct expr {
const struct exthdr_desc*desc;
const struct proto_hdr_template *tmpl;
unsigned intoffset;
+   unsigned intflags;
} exthdr;
struct {
/* EXPR_META */
diff --git a/src/exthdr.c b/src/exthdr.c
index c641d4a398ad2..32bf3558115c5 100644
--- a/src/exthdr.c
+++ b/src/exthdr.c
@@ -30,7 +30,8 @@ static void exthdr_expr_print(const struct expr *expr)
 static bool exthdr_expr_cmp(const struct expr *e1, const struct expr *e2)
 {
return e1->exthdr.desc == e2->exthdr.desc &&
-  e1->exthdr.tmpl == e2->exthdr.tmpl;
+  e1->exthdr.tmpl == e2->exthdr.tmpl &&
+  e1->exthdr.flags == e2->exthdr.flags;
 }
 
 static void exthdr_expr_clone(struct expr *new, const struct expr *expr)
@@ -38,6 +39,7 @@ static void exthdr_expr_clone(struct expr *new, const struct 
expr *expr)
new->exthdr.desc = expr->exthdr.desc;
new->exthdr.tmpl = expr->exthdr.tmpl;
new->exthdr.offset = expr->exthdr.offset;
+   new->exthdr.flags = expr->exthdr.flags;
 }
 
 static const struct expr_ops exthdr_expr_ops = {
diff --git a/src/netlink_delinearize.c b/src/netlink_delinearize.c
index 06823de24d0e7..1d2a50abb5473 100644
--- a/src/netlink_delinearize.c
+++ b/src/netlink_delinearize.c
@@ -504,16 +504,18 @@ static void netlink_parse_exthdr(struct netlink_parse_ctx 
*ctx,
 const struct nftnl_expr *nle)
 {
enum nft_registers dreg;
-   uint32_t offset, len;
+   uint32_t offset, len, flags;
uint8_t type;
struct expr *expr;
 
type   = nftnl_expr_get_u8(nle, NFTNL_EXPR_EXTHDR_TYPE);
offset = nftnl_expr_get_u32(nle, NFTNL_EXPR_EXTHDR_OFFSET) * 
BITS_PER_BYTE;
len= nftnl_expr_get_u32(nle, NFTNL_EXPR_EXTHDR_LEN) * BITS_PER_BYTE;
+   flags  = nftnl_expr_get_u32(nle, NFTNL_EXPR_EXTHDR_FLAGS);
 
expr = exthdr_expr_alloc(loc, NULL, 0);
exthdr_init_raw(expr, type, offset, len);
+   expr->exthdr.flags = flags;
 
dreg = netlink_parse_register(nle, NFTNL_EXPR_EXTHDR_DREG);
netlink_set_register(ctx, dreg, expr);
diff --git a/src/netlink_linearize.c b/src/netlink_linearize.c
index aff4f04a36db9..f2560ece066a1 100644
--- a/src/netlink_linearize.c
+++ b/src/netlink_linearize.c
@@ -172,6 +172,7 @@ static void netlink_gen_exthdr(struct netlink_linearize_ctx 
*ctx,
   expr->exthdr.tmpl->offset / BITS_PER_BYTE);
nftnl_expr_set_u32(nle, NFTNL_EXPR_EXTHDR_LEN,
   div_round_up(expr->len, BITS_PER_BYTE));
+   nftnl_expr_set_u32(nle, NFTNL_EXPR_EXTHDR_FLAGS, expr->exthdr.flags);
nftnl_rule_add_expr(ctx->nlr, nle);
 }
 
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[nft PATCH 1/3] Implement boolean comparison in relational expression

[Phil Sutter]

This works by introducing OP_BOOL which allows to properly display the
boolean statement when listing rules. Apart from that, in kernel space
it is this way possible to optimize the comparison instead of having to
live with EQ/NEQ zero checks.

Signed-off-by: Phil Sutter 
---
 include/expression.h|  9 +
 include/linux/netfilter/nf_tables.h |  1 +
 include/netlink.h   |  2 ++
 src/evaluate.c  | 13 +
 src/expression.c| 38 +
 src/netlink.c   | 20 +++
 src/netlink_delinearize.c   |  8 +++-
 src/netlink_linearize.c |  3 +++
 src/parser_bison.y  | 18 ++
 src/scanner.l   |  5 +
 10 files changed, 116 insertions(+), 1 deletion(-)

diff --git a/include/expression.h b/include/expression.h
index ec90265b5f926..fa1587639621e 100644
--- a/include/expression.h
+++ b/include/expression.h
@@ -62,6 +62,7 @@ enum expr_types {
EXPR_HASH,
EXPR_RT,
EXPR_FIB,
+   EXPR_BOOLEAN,
 };
 
 enum ops {
@@ -89,6 +90,8 @@ enum ops {
OP_FLAGCMP,
/* Set lookup */
OP_LOOKUP,
+   /* boolean comparison */
+   OP_BOOL,
__OP_MAX
 };
 #define OP_MAX (__OP_MAX - 1)
@@ -217,6 +220,10 @@ struct expr {
enum opsop;
union {
struct {
+   /* EXPR_BOOLEAN */
+   boolboolean;
+   };
+   struct {
/* EXPR_SYMBOL */
const struct scope  *scope;
const char  *identifier;
@@ -421,4 +428,6 @@ extern struct expr *set_elem_expr_alloc(const struct 
location *loc,
 extern void range_expr_value_low(mpz_t rop, const struct expr *expr);
 extern void range_expr_value_high(mpz_t rop, const struct expr *expr);
 
+extern struct expr *boolean_expr_alloc(const struct location *loc,
+  bool val);
 #endif /* NFTABLES_EXPRESSION_H */
diff --git a/include/linux/netfilter/nf_tables.h 
b/include/linux/netfilter/nf_tables.h
index b00a05d1ee566..075894657aecd 100644
--- a/include/linux/netfilter/nf_tables.h
+++ b/include/linux/netfilter/nf_tables.h
@@ -543,6 +543,7 @@ enum nft_cmp_ops {
NFT_CMP_LTE,
NFT_CMP_GT,
NFT_CMP_GTE,
+   NFT_CMP_BOOL,
 };
 
 /**
diff --git a/include/netlink.h b/include/netlink.h
index 450aba571a979..6b0a72a846d59 100644
--- a/include/netlink.h
+++ b/include/netlink.h
@@ -94,6 +94,8 @@ extern struct expr *netlink_alloc_value(const struct location 
*loc,
 extern struct expr *netlink_alloc_data(const struct location *loc,
   const struct nft_data_delinearize *nld,
   enum nft_registers dreg);
+extern struct expr *netlink_alloc_boolean(const struct location *loc,
+ const struct nft_data_delinearize 
*nld);
 
 extern void netlink_linearize_rule(struct netlink_ctx *ctx,
   struct nftnl_rule *nlr,
diff --git a/src/evaluate.c b/src/evaluate.c
index bcbced1e3dfa6..6a65ec16c36f3 100644
--- a/src/evaluate.c
+++ b/src/evaluate.c
@@ -1444,6 +1444,9 @@ static int expr_evaluate_relational(struct eval_ctx *ctx, 
struct expr **expr)
case EXPR_LIST:
rel->op = OP_FLAGCMP;
break;
+   case EXPR_BOOLEAN:
+   rel->op = OP_BOOL;
+   break;
default:
if (right->dtype->basetype != NULL &&
right->dtype->basetype->type == TYPE_BITMASK)
@@ -1605,6 +1608,8 @@ range:
if (byteorder_conversion(ctx, >right, 
BYTEORDER_BIG_ENDIAN) < 0)
return -1;
break;
+   case OP_BOOL:
+   break;
default:
BUG("invalid relational operation %u\n", rel->op);
}
@@ -1615,6 +1620,12 @@ range:
return 0;
 }
 
+static int expr_evaluate_boolean(struct eval_ctx *ctx, struct expr **expr)
+{
+   (*expr)->len = ctx->ectx.len;
+   return 0;
+}
+
 static int expr_evaluate(struct eval_ctx *ctx, struct expr **expr)
 {
 #ifdef DEBUG
@@ -1671,6 +1682,8 @@ static int expr_evaluate(struct eval_ctx *ctx, struct 
expr **expr)
return expr_evaluate_numgen(ctx, expr);
case EXPR_HASH:
return expr_evaluate_hash(ctx, expr);
+   case EXPR_BOOLEAN:
+   return expr_evaluate_boolean(ctx, expr);
default:
BUG("unknown expression type %s\n", (*expr)->ops->name);
}
diff --git a/src/expression.c b/src/expression.c
index 1567870c631b6..8842a7836fc07 100644
--- a/src/expression.c
+++ b/src/expression.c
@@ -456,6 +456,7 

[nft PATCH 3/3] exthdr: Implement exthdr existence check

[Phil Sutter]

This is meant to be used as LHS of a boolean relational expression, like
the following example matching on fragment header presence:

| exthdr frag exists

Signed-off-by: Phil Sutter 
---
 include/exthdr.h   |  4 
 src/expression.c   |  1 +
 src/exthdr.c   |  6 +-
 src/parser_bison.y | 24 
 src/scanner.l  |  2 ++
 5 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/include/exthdr.h b/include/exthdr.h
index d17841bc46159..f45cdf9b1886a 100644
--- a/include/exthdr.h
+++ b/include/exthdr.h
@@ -85,4 +85,8 @@ extern const struct exthdr_desc exthdr_frag;
 extern const struct exthdr_desc exthdr_dst;
 extern const struct exthdr_desc exthdr_mh;
 
+enum nft_exthdr_flags {
+   NFT_EXTHDR_F_PRESENT = (1 << 0),
+};
+
 #endif /* NFTABLES_EXTHDR_H */
diff --git a/src/expression.c b/src/expression.c
index 8842a7836fc07..9034420ae0db4 100644
--- a/src/expression.c
+++ b/src/expression.c
@@ -1002,6 +1002,7 @@ static void boolean_expr_print(const struct expr *expr)
switch (expr->dtype->type) {
case TYPE_FIB_ADDR: /* fib expr */
case TYPE_IFINDEX:  /* fib expr */
+   case TYPE_INET_PROTOCOL:/* exthdr exists expr */
printf(expr->boolean ? "exists" : "missing");
break;
default:
diff --git a/src/exthdr.c b/src/exthdr.c
index 32bf3558115c5..37d7700f328c8 100644
--- a/src/exthdr.c
+++ b/src/exthdr.c
@@ -24,7 +24,11 @@
 
 static void exthdr_expr_print(const struct expr *expr)
 {
-   printf("%s %s", expr->exthdr.desc->name, expr->exthdr.tmpl->token);
+   if (expr->exthdr.flags & NFT_EXTHDR_F_PRESENT)
+   printf("exthdr %s", expr->exthdr.desc->name);
+   else
+   printf("%s %s", expr->exthdr.desc->name,
+   expr->exthdr.tmpl->token);
 }
 
 static bool exthdr_expr_cmp(const struct expr *e1, const struct expr *e2)
diff --git a/src/parser_bison.y b/src/parser_bison.y
index 3205cc407ffa8..e819affadbf05 100644
--- a/src/parser_bison.y
+++ b/src/parser_bison.y
@@ -139,6 +139,7 @@ static void location_update(struct location *loc, struct 
location *rhs, int n)
const struct datatype   *datatype;
struct handle_spec  handle_spec;
struct position_specposition_spec;
+   const struct exthdr_desc *exthdr_desc;
 }
 
 %token TOKEN_EOF 0 "end of file"
@@ -431,6 +432,8 @@ static void location_update(struct location *loc, struct 
location *rhs, int n)
 %token TRUE"true"
 %token FALSE   "false"
 
+%token EXTHDR  "exthdr"
+
 %type boolean_spec
 %typeboolean_expr
 %destructor { expr_free($$); } boolean_expr
@@ -633,6 +636,10 @@ static void location_update(struct location *loc, struct 
location *rhs, int n)
 %type   quota_config
 %destructor { xfree($$); } quota_config
 
+%typeexthdr_exists_expr
+%destructor { expr_free($$); } exthdr_exists_expr
+%type exthdr_spec
+
 %%
 
 input  :   /* empty */
@@ -2260,6 +2267,7 @@ primary_expr  :   symbol_expr 
{ $$ = $1; }
|   integer_expr{ $$ = $1; }
|   payload_expr{ $$ = $1; }
|   exthdr_expr { $$ = $1; }
+   |   exthdr_exists_expr  { $$ = $1; }
|   meta_expr   { $$ = $1; }
|   rt_expr { $$ = $1; }
|   ct_expr { $$ = $1; }
@@ -3316,4 +3324,20 @@ mh_hdr_field :   NEXTHDR { $$ = 
MHHDR_NEXTHDR; }
|   CHECKSUM{ $$ = MHHDR_CHECKSUM; }
;
 
+exthdr_exists_expr :   EXTHDR  exthdr_spec
+   {
+   /* Assume that NEXTHDR template is always
+* the fist one in list of templates.
+*/
+   $$ = exthdr_expr_alloc(&@$, $2, 1);
+   $$->exthdr.flags = NFT_EXTHDR_F_PRESENT;
+   }
+   ;
+
+exthdr_spec:   HBH { $$ = _hbh; }
+   |   RT  { $$ = _rt; }
+   |   FRAG{ $$ = _frag; }
+   |   DST { $$ = _dst; }
+   |   MH  { $$ = _mh; }
+   ;
 %%
diff --git a/src/scanner.l b/src/scanner.l
index debc18fad37ef..bd6edaac1224b 100644
--- a/src/scanner.l
+++ b/src/scanner.l
@@ -487,6 +487,8 @@ addrstring  ({macaddr}|{ip4addr}|{ip6addr})
 "true" { return TRUE; }
 "false"{ 

[nft PATCH 0/3] Boolean comparison and exthdr existence match support

[Phil Sutter]

The following series adds two distinct features to nftables, though
since the second one depends on presence of the first one this is
submitted as a series.

Patch 1 adds support for a boolean variant of relational expression.
It's OP is strictly implicit and determined by RHS being a boolean
expression. It depends on a related kernel patch adding support for
NFT_CMP_BOOL to nft_cmp.c.

Patch 2 extends exthdr expression by a private flags field which will be
used in patch 3. It depends on a related patch for libnftnl to handle
the new field.

Patch 3 then adds support for checking extension header presence to
exthdr expression by making use of the previously introduced exthdr flag
NFT_EXTHDR_F_PRESENT. It's ideally used together with a boolean
relational expression for a syntax of e.g.:

| exthdr hbh exists

to match on hop-by-hop options presence or:

| exthdr frag missing

to match on packets without fragmentation header present.

Phil Sutter (3):
  Implement boolean comparison in relational expression
  exthdr: Add support for exthdr specific flags
  exthdr: Implement exthdr existence check

 include/expression.h| 10 +
 include/exthdr.h|  4 
 include/linux/netfilter/nf_tables.h |  1 +
 include/netlink.h   |  2 ++
 src/evaluate.c  | 13 
 src/expression.c| 39 ++
 src/exthdr.c| 10 +++--
 src/netlink.c   | 20 ++
 src/netlink_delinearize.c   | 12 +--
 src/netlink_linearize.c |  4 
 src/parser_bison.y  | 42 +
 src/scanner.l   |  7 +++
 12 files changed, 160 insertions(+), 4 deletions(-)

-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: tcp state in conntrack destroy events

[Florian Westphal]

Victor Julien  wrote:
> I was hoping to get the last TCP state in a conntrack destroy event,
> however it seems to be unavailable.
> 
> Through libnetfilter_conntrack the value retrieved at ATTR_TCP_STATE is
> always 0.
> 
> Using the conntrack command I see the same behavior:
> 
> destroy doesn't have it (conntrack -E -e destroy -p tcp):
> 
> [DESTROY] tcp  6 src=218.65.30.38 dst=192.168.178.254 sport=61063
> dport=22 packets=11 bytes=820 src=192.168.0.123 dst=218.65.30.38
> sport=22 dport=61063 packets=8 bytes=424 [ASSURED] mark=3 delta-time=77
> 
> update does (conntrack -E -e updates -p tcp):
> 
>  [UPDATE] tcp  6 120 FIN_WAIT src=192.168.0.53 dst=x.x.x.x
> sport=52958 dport=443 src=x.x.x.x dst=192.168.178.254 sport=443
> dport=52958 [ASSURED] mark=3
> 
> Is this intentional? My goal is to create connection log that includes a
> hint about why the connection is gone.

Yes, its intentional, see
net/netfilter/nf_conntrack_netlink.c, there is a check for DESTROY
that supresses most of the extra info:

682 if (events & (1 << IPCT_DESTROY)) {
683if (ctnetlink_dump_acct(skb, ct, type) < 0 ||
684ctnetlink_dump_timestamp(skb, ct) < 0)
685   goto nla_put_failure;
686} else {
..
/* IPCT_PROTOINFO */

Pablo made this change in 7b621c1ea64a54f77b8a841b16dc4c9fee3ecf48,
i guess the rationale was that clients aren't interested in this
on DESTROY.

Would be easy to change this.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[nf-next PATCH] netfilter: nf_tables: exthdr: Add support for existence check

[Phil Sutter]

If NFT_EXTHDR_F_PRESENT is set, exthdr will not copy any header field
data into *dest, but instead set it to 1 if the header is found and 0
otherwise.

Signed-off-by: Phil Sutter 
---
 include/uapi/linux/netfilter/nf_tables.h |  6 ++
 net/netfilter/nft_exthdr.c   | 14 --
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/netfilter/nf_tables.h 
b/include/uapi/linux/netfilter/nf_tables.h
index b00a05d1ee566..f15696af168ac 100644
--- a/include/uapi/linux/netfilter/nf_tables.h
+++ b/include/uapi/linux/netfilter/nf_tables.h
@@ -704,6 +704,10 @@ enum nft_payload_attributes {
 };
 #define NFTA_PAYLOAD_MAX   (__NFTA_PAYLOAD_MAX - 1)
 
+enum nft_exthdr_flags {
+   NFT_EXTHDR_F_PRESENT = (1 << 0),
+};
+
 /**
  * enum nft_exthdr_attributes - nf_tables IPv6 extension header expression 
netlink attributes
  *
@@ -711,6 +715,7 @@ enum nft_payload_attributes {
  * @NFTA_EXTHDR_TYPE: extension header type (NLA_U8)
  * @NFTA_EXTHDR_OFFSET: extension header offset (NLA_U32)
  * @NFTA_EXTHDR_LEN: extension header length (NLA_U32)
+ * @NFTA_EXTHDR_FLAGS: extension header flags (NLA_U32)
  */
 enum nft_exthdr_attributes {
NFTA_EXTHDR_UNSPEC,
@@ -718,6 +723,7 @@ enum nft_exthdr_attributes {
NFTA_EXTHDR_TYPE,
NFTA_EXTHDR_OFFSET,
NFTA_EXTHDR_LEN,
+   NFTA_EXTHDR_FLAGS,
__NFTA_EXTHDR_MAX
 };
 #define NFTA_EXTHDR_MAX(__NFTA_EXTHDR_MAX - 1)
diff --git a/net/netfilter/nft_exthdr.c b/net/netfilter/nft_exthdr.c
index 47beb3abcc9da..b5b37f211c417 100644
--- a/net/netfilter/nft_exthdr.c
+++ b/net/netfilter/nft_exthdr.c
@@ -23,6 +23,7 @@ struct nft_exthdr {
u8  offset;
u8  len;
enum nft_registers  dreg:8;
+   u32 flags;
 };
 
 static void nft_exthdr_eval(const struct nft_expr *expr,
@@ -35,8 +36,12 @@ static void nft_exthdr_eval(const struct nft_expr *expr,
int err;
 
err = ipv6_find_hdr(pkt->skb, , priv->type, NULL, NULL);
-   if (err < 0)
+   if (priv->flags & NFT_EXTHDR_F_PRESENT) {
+   *dest = (err >= 0);
+   return;
+   } else if (err < 0) {
goto err;
+   }
offset += priv->offset;
 
dest[priv->len / NFT_REG32_SIZE] = 0;
@@ -52,6 +57,7 @@ static const struct nla_policy 
nft_exthdr_policy[NFTA_EXTHDR_MAX + 1] = {
[NFTA_EXTHDR_TYPE]  = { .type = NLA_U8 },
[NFTA_EXTHDR_OFFSET]= { .type = NLA_U32 },
[NFTA_EXTHDR_LEN]   = { .type = NLA_U32 },
+   [NFTA_EXTHDR_FLAGS] = { .type = NLA_U32 },
 };
 
 static int nft_exthdr_init(const struct nft_ctx *ctx,
@@ -65,7 +71,8 @@ static int nft_exthdr_init(const struct nft_ctx *ctx,
if (tb[NFTA_EXTHDR_DREG] == NULL ||
tb[NFTA_EXTHDR_TYPE] == NULL ||
tb[NFTA_EXTHDR_OFFSET] == NULL ||
-   tb[NFTA_EXTHDR_LEN] == NULL)
+   tb[NFTA_EXTHDR_LEN] == NULL ||
+   tb[NFTA_EXTHDR_FLAGS] == NULL)
return -EINVAL;
 
err = nft_parse_u32_check(tb[NFTA_EXTHDR_OFFSET], U8_MAX, );
@@ -80,6 +87,7 @@ static int nft_exthdr_init(const struct nft_ctx *ctx,
priv->offset = offset;
priv->len= len;
priv->dreg   = nft_parse_register(tb[NFTA_EXTHDR_DREG]);
+   priv->flags  = ntohl(nla_get_u32(tb[NFTA_EXTHDR_FLAGS]));
 
return nft_validate_register_store(ctx, priv->dreg, NULL,
   NFT_DATA_VALUE, priv->len);
@@ -97,6 +105,8 @@ static int nft_exthdr_dump(struct sk_buff *skb, const struct 
nft_expr *expr)
goto nla_put_failure;
if (nla_put_be32(skb, NFTA_EXTHDR_LEN, htonl(priv->len)))
goto nla_put_failure;
+   if (nla_put_be32(skb, NFTA_EXTHDR_FLAGS, htonl(priv->flags)))
+   goto nla_put_failure;
return 0;
 
 nla_put_failure:
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[libnftnl PATCH] exthdr: Add support for exthdr flags

[Phil Sutter]

Along with the actual support for exthdr expression specific flags, this
also declares NFT_EXTHDR_F_PRESENT used for exthdr existence match.

Signed-off-by: Phil Sutter 
---
 include/libnftnl/expr.h |  1 +
 include/linux/netfilter/nf_tables.h |  6 ++
 src/expr/exthdr.c   | 21 +
 3 files changed, 28 insertions(+)

diff --git a/include/libnftnl/expr.h b/include/libnftnl/expr.h
index 74e986de6b4b2..654d2bb95142c 100644
--- a/include/libnftnl/expr.h
+++ b/include/libnftnl/expr.h
@@ -156,6 +156,7 @@ enum {
NFTNL_EXPR_EXTHDR_TYPE,
NFTNL_EXPR_EXTHDR_OFFSET,
NFTNL_EXPR_EXTHDR_LEN,
+   NFTNL_EXPR_EXTHDR_FLAGS,
 };
 
 enum {
diff --git a/include/linux/netfilter/nf_tables.h 
b/include/linux/netfilter/nf_tables.h
index 881d49e945696..787955c7d5ed5 100644
--- a/include/linux/netfilter/nf_tables.h
+++ b/include/linux/netfilter/nf_tables.h
@@ -704,6 +704,10 @@ enum nft_payload_attributes {
 };
 #define NFTA_PAYLOAD_MAX   (__NFTA_PAYLOAD_MAX - 1)
 
+enum nft_exthdr_flags {
+   NFT_EXTHDR_F_PRESENT = (1 << 0),
+};
+
 /**
  * enum nft_exthdr_attributes - nf_tables IPv6 extension header expression 
netlink attributes
  *
@@ -711,6 +715,7 @@ enum nft_payload_attributes {
  * @NFTA_EXTHDR_TYPE: extension header type (NLA_U8)
  * @NFTA_EXTHDR_OFFSET: extension header offset (NLA_U32)
  * @NFTA_EXTHDR_LEN: extension header length (NLA_U32)
+ * @NFTA_EXTHDR_FLAGS: extension header flags (NLA_U32)
  */
 enum nft_exthdr_attributes {
NFTA_EXTHDR_UNSPEC,
@@ -718,6 +723,7 @@ enum nft_exthdr_attributes {
NFTA_EXTHDR_TYPE,
NFTA_EXTHDR_OFFSET,
NFTA_EXTHDR_LEN,
+   NFTA_EXTHDR_FLAGS,
__NFTA_EXTHDR_MAX
 };
 #define NFTA_EXTHDR_MAX(__NFTA_EXTHDR_MAX - 1)
diff --git a/src/expr/exthdr.c b/src/expr/exthdr.c
index b164e3fba3de4..90362a54554d0 100644
--- a/src/expr/exthdr.c
+++ b/src/expr/exthdr.c
@@ -33,6 +33,7 @@ struct nftnl_expr_exthdr {
uint32_toffset;
uint32_tlen;
uint8_t type;
+   uint32_tflags;
 };
 
 static int
@@ -54,6 +55,9 @@ nftnl_expr_exthdr_set(struct nftnl_expr *e, uint16_t type,
case NFTNL_EXPR_EXTHDR_LEN:
exthdr->len = *((uint32_t *)data);
break;
+   case NFTNL_EXPR_EXTHDR_FLAGS:
+   exthdr->flags = *((uint32_t *)data);
+   break;
default:
return -1;
}
@@ -79,6 +83,9 @@ nftnl_expr_exthdr_get(const struct nftnl_expr *e, uint16_t 
type,
case NFTNL_EXPR_EXTHDR_LEN:
*data_len = sizeof(exthdr->len);
return >len;
+   case NFTNL_EXPR_EXTHDR_FLAGS:
+   *data_len = sizeof(exthdr->flags);
+   return >flags;
}
return NULL;
 }
@@ -99,6 +106,7 @@ static int nftnl_expr_exthdr_cb(const struct nlattr *attr, 
void *data)
case NFTA_EXTHDR_DREG:
case NFTA_EXTHDR_OFFSET:
case NFTA_EXTHDR_LEN:
+   case NFTA_EXTHDR_FLAGS:
if (mnl_attr_validate(attr, MNL_TYPE_U32) < 0)
abi_breakage();
break;
@@ -121,6 +129,8 @@ nftnl_expr_exthdr_build(struct nlmsghdr *nlh, const struct 
nftnl_expr *e)
mnl_attr_put_u32(nlh, NFTA_EXTHDR_OFFSET, 
htonl(exthdr->offset));
if (e->flags & (1 << NFTNL_EXPR_EXTHDR_LEN))
mnl_attr_put_u32(nlh, NFTA_EXTHDR_LEN, htonl(exthdr->len));
+   if (e->flags & (1 << NFTNL_EXPR_EXTHDR_FLAGS))
+   mnl_attr_put_u32(nlh, NFTA_EXTHDR_FLAGS, htonl(exthdr->flags));
 }
 
 static int
@@ -148,6 +158,10 @@ nftnl_expr_exthdr_parse(struct nftnl_expr *e, struct 
nlattr *attr)
exthdr->len = ntohl(mnl_attr_get_u32(tb[NFTA_EXTHDR_LEN]));
e->flags |= (1 << NFTNL_EXPR_EXTHDR_LEN);
}
+   if (tb[NFTA_EXTHDR_FLAGS]) {
+   exthdr->flags = ntohl(mnl_attr_get_u32(tb[NFTA_EXTHDR_FLAGS]));
+   e->flags |= (1 << NFTNL_EXPR_EXTHDR_FLAGS);
+   }
 
return 0;
 }
@@ -214,6 +228,9 @@ nftnl_expr_exthdr_json_parse(struct nftnl_expr *e, json_t 
*root,
if (nftnl_jansson_parse_val(root, "len", NFTNL_TYPE_U32, , err) 
== 0)
nftnl_expr_set_u32(e, NFTNL_EXPR_EXTHDR_LEN, uval32);
 
+   if (nftnl_jansson_parse_val(root, "flags", NFTNL_TYPE_U32, , 
err) == 0)
+   nftnl_expr_set_u32(e, NFTNL_EXPR_EXTHDR_FLAGS, uval32);
+
return 0;
 #else
errno = EOPNOTSUPP;
@@ -235,6 +252,8 @@ static int nftnl_expr_exthdr_export(char *buf, size_t len,
nftnl_buf_u32(, type, exthdr->offset, OFFSET);
if (e->flags & (1 << NFTNL_EXPR_EXTHDR_LEN))
nftnl_buf_u32(, type, exthdr->len, LEN);
+   if (e->flags & (1 << NFTNL_EXPR_EXTHDR_FLAGS))
+   nftnl_buf_u32(, type, exthdr->flags, FLAGS);
 
return nftnl_buf_done();
 }
@@ -280,6 +299,8 @@ static 

[nf-next PATCH] netfilter: nf_tables: cmp: support boolean operation

[Phil Sutter]

Signed-off-by: Phil Sutter 
---
 include/uapi/linux/netfilter/nf_tables.h |  2 ++
 net/netfilter/nft_cmp.c  | 12 +++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/netfilter/nf_tables.h 
b/include/uapi/linux/netfilter/nf_tables.h
index b00a05d1ee566..77e318e6ff9d2 100644
--- a/include/uapi/linux/netfilter/nf_tables.h
+++ b/include/uapi/linux/netfilter/nf_tables.h
@@ -535,6 +535,7 @@ enum nft_byteorder_attributes {
  * @NFT_CMP_LTE: less than or equal to
  * @NFT_CMP_GT: greater than
  * @NFT_CMP_GTE: greater than or equal to
+ * @NFT_CMP_BOOL: boolean comparison
  */
 enum nft_cmp_ops {
NFT_CMP_EQ,
@@ -543,6 +544,7 @@ enum nft_cmp_ops {
NFT_CMP_LTE,
NFT_CMP_GT,
NFT_CMP_GTE,
+   NFT_CMP_BOOL,
 };
 
 /**
diff --git a/net/netfilter/nft_cmp.c b/net/netfilter/nft_cmp.c
index 2b96effeadc1b..addf75739367e 100644
--- a/net/netfilter/nft_cmp.c
+++ b/net/netfilter/nft_cmp.c
@@ -29,9 +29,14 @@ static void nft_cmp_eval(const struct nft_expr *expr,
 const struct nft_pktinfo *pkt)
 {
const struct nft_cmp_expr *priv = nft_expr_priv(expr);
+   static const u32 nulldata[4] = { 0 };
+   const void *data = >data;
int d;
 
-   d = memcmp(>data[priv->sreg], >data, priv->len);
+   if (priv->op == NFT_CMP_BOOL)
+   data = nulldata;
+
+   d = memcmp(>data[priv->sreg], data, priv->len);
switch (priv->op) {
case NFT_CMP_EQ:
if (d != 0)
@@ -55,6 +60,10 @@ static void nft_cmp_eval(const struct nft_expr *expr,
if (d < 0)
goto mismatch;
break;
+   case NFT_CMP_BOOL:
+   if (!!priv->data.data[0] ^ !!d)
+   goto mismatch;
+   break;
}
return;
 
@@ -191,6 +200,7 @@ nft_cmp_select_ops(const struct nft_ctx *ctx, const struct 
nlattr * const tb[])
case NFT_CMP_LTE:
case NFT_CMP_GT:
case NFT_CMP_GTE:
+   case NFT_CMP_BOOL:
break;
default:
return ERR_PTR(-EINVAL);
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

tcp state in conntrack destroy events

[Victor Julien]

Hi all,

I was hoping to get the last TCP state in a conntrack destroy event,
however it seems to be unavailable.

Through libnetfilter_conntrack the value retrieved at ATTR_TCP_STATE is
always 0.

Using the conntrack command I see the same behavior:

destroy doesn't have it (conntrack -E -e destroy -p tcp):

[DESTROY] tcp  6 src=218.65.30.38 dst=192.168.178.254 sport=61063
dport=22 packets=11 bytes=820 src=192.168.0.123 dst=218.65.30.38
sport=22 dport=61063 packets=8 bytes=424 [ASSURED] mark=3 delta-time=77

update does (conntrack -E -e updates -p tcp):

 [UPDATE] tcp  6 120 FIN_WAIT src=192.168.0.53 dst=x.x.x.x
sport=52958 dport=443 src=x.x.x.x dst=192.168.178.254 sport=443
dport=52958 [ASSURED] mark=3

Is this intentional? My goal is to create connection log that includes a
hint about why the connection is gone.

-- 
-
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
-

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AUDIT_NETFILTER_PKT message format

[Paul Moore]

On Tue, Jan 17, 2017 at 11:12 AM, Richard Guy Briggs  wrote:
> On 2017-01-17 08:55, Steve Grubb wrote:
>> On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote:

...

>> > Ones that are not so straightforward:
>> > - "secmark" depends on a kernel config setting, so should it always be
>> >   present but "(none)" if that kernel feature is compiled out?
>>
>> If this is selinux related, I'd treat it the same way that we do subj
>> everywhere else.
>
> Ok.

To be clear, a packet's secmark should be recorded via a dedicated
field, e.g. "secmark", and not use the "subj" field (it isn't a
subject label in the traditional sense).

-- 
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AUDIT_NETFILTER_PKT message format

[Steve Grubb]

On Tuesday, January 17, 2017 11:29:43 AM EST Richard Guy Briggs wrote:
> On 2017-01-17 11:12, Richard Guy Briggs wrote:
> > On 2017-01-17 08:55, Steve Grubb wrote:
> > > On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote:
> > > > I'm just starting to look at the normalization of AUDIT_NETFILTER_PKT
> > > > event messages and it is not quite as straightforward as I had
> > > > expected.
> > > > 
> > > > It is being tracked here:
> > > > https://github.com/linux-audit/audit-kernel/issues/11
> > > > 
> > > > and refers to a previous posting from Mr. Dash Four from four years
> > > > ago
> > > > to which there was no reply.
> > > > 
> > > > The example given in the tracker above for "frag=" is fairly
> > > > straightforward, but digging more, there are a number of others that
> > > > are
> > > > not quite so obvious.
> > > > 
> > > > How many different combinations of fields is acceptable?  Can we
> > > > create
> > > > new message types for each one, or is there a preferred way to
> > > > indicate
> > > > which sub-type it is other than implicit from the arguments given?
> > > 
> > > That would be preferential to swinging fields in and out. But we also
> > > don't
> > > want to add too many new types. If two protocols look almost identical,
> > > I'd
> > > try to coerce them to be the same. If adding 2 new types solves the
> > > problem
> > > just do it. If it takes 10, then maybe we should understand why.
> > 
> > Ok, I'll have a go at mapping some out and see where we end up...
> > 
> > > > Others that are straightforward:
> > > > - The first "truncated=" gets pulled in with "0".
> > > > 
> > > > - "mark=" gets pulled in with "0".
> > > > 
> > > > Ones that are not so straightforward:
> > > > - "secmark" depends on a kernel config setting, so should it always be
> > > > 
> > > >   present but "(none)" if that kernel feature is compiled out?
> > > 
> > > If this is selinux related, I'd treat it the same way that we do subj
> > > everywhere else.
> > 
> > Ok.
> > 
> > > > - ARPHRD_ETHER pulls in 3 fields, I would pull them all in and set
> > > > them
> > > > 
> > > >   to "(none)" to indicate that type isn't present.
> > > 
> > > "(none)" is for character fields that have nothing. Typically we set -1
> > > for
> > > numeric fields that are unset. If numbers are expected, its going to get
> > > the strtol() treatment and "(none)" will cause a conversion error.
> > 
> > Ah, ok.  I certainly don't want to break the parser, so I'll use -1 or
> > find another way to indicate it.
> > 
> > > > - audit_ip4() and audit_ip6 share "saddr=", "daddr=", proto=", but ip4
> > > > 
> > > >   adds "ipid=", which would be set to "(none)" for ip6.
> 
> I assume that v4, v6 and mac address fields count as text?

Yes. We also use '?' in places where there is no value if that looks better.

-Steve

> > > That is numeric. -1?
> > 
> > Yup, 16-bit.  I'll make it -1.
> > 
> > > -Steve
> > > 
> > > > - audit_proto() pulls in "truncated=" again, then either "sport=" and
> > > > 
> > > >   "dport=" OR "icmptype=" and "icmpcode=".
> > > > 
> > > > If all fields are pulled in, we end up adding 10 fields beyond a
> > > > standard well-formed packet, and 15 beyond a truncated packet.
> > > > 
> > > > Note: In the cases of "mark" and "secmark" both are unions.  In the
> > > > case of
> > > > "mark", I don't see a problem since it isn't conditionally compiled
> > > > out
> > > > and won't be mis-interpreted.  In the case of "secmark=", it could be
> > > > mis-interpreted as offload_fwd_mark if that field is even compiled in,
> > > > but that would be addressed in the compiler directive...
> > > > 
> > > > 
> > > > One last question: Does anyone have a test suite that can generate any
> > > > or all of these types of packets?
> > > > 
> > > > 
> > > > Thanks!
> > > > 
> > > > 
> > > > - RGB
> > 
> > - RGB
> > 
> > --
> > Richard Guy Briggs 
> > Kernel Security Engineering, Base Operating Systems, Red Hat
> > Remote, Ottawa, Canada
> > Voice: +1.647.777.2635, Internal: (81) 32635
> 
> - RGB
> 
> --
> Richard Guy Briggs 
> Kernel Security Engineering, Base Operating Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635


--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-01-17 11:12, Richard Guy Briggs wrote:
> On 2017-01-17 08:55, Steve Grubb wrote:
> > On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote:
> > > I'm just starting to look at the normalization of AUDIT_NETFILTER_PKT
> > > event messages and it is not quite as straightforward as I had expected.
> > > 
> > > It is being tracked here:
> > >   https://github.com/linux-audit/audit-kernel/issues/11
> > > and refers to a previous posting from Mr. Dash Four from four years ago
> > > to which there was no reply.
> > > 
> > > The example given in the tracker above for "frag=" is fairly
> > > straightforward, but digging more, there are a number of others that are
> > > not quite so obvious.
> > > 
> > > How many different combinations of fields is acceptable?  Can we create
> > > new message types for each one, or is there a preferred way to indicate
> > > which sub-type it is other than implicit from the arguments given?
> > 
> > That would be preferential to swinging fields in and out. But we also don't 
> > want to add too many new types. If two protocols look almost identical, I'd 
> > try to coerce them to be the same. If adding 2 new types solves the problem 
> > just do it. If it takes 10, then maybe we should understand why.
> 
> Ok, I'll have a go at mapping some out and see where we end up...
> 
> > > Others that are straightforward:
> > > - The first "truncated=" gets pulled in with "0".
> > > 
> > > - "mark=" gets pulled in with "0".
> > > 
> > > Ones that are not so straightforward:
> > > - "secmark" depends on a kernel config setting, so should it always be
> > >   present but "(none)" if that kernel feature is compiled out?
> > 
> > If this is selinux related, I'd treat it the same way that we do subj 
> > everywhere else.
> 
> Ok.
> 
> > > - ARPHRD_ETHER pulls in 3 fields, I would pull them all in and set them
> > >   to "(none)" to indicate that type isn't present.
> > 
> > "(none)" is for character fields that have nothing. Typically we set -1 for 
> > numeric fields that are unset. If numbers are expected, its going to get 
> > the 
> > strtol() treatment and "(none)" will cause a conversion error.
> 
> Ah, ok.  I certainly don't want to break the parser, so I'll use -1 or
> find another way to indicate it.
> 
> > > - audit_ip4() and audit_ip6 share "saddr=", "daddr=", proto=", but ip4
> > >   adds "ipid=", which would be set to "(none)" for ip6.

I assume that v4, v6 and mac address fields count as text?

> > That is numeric. -1?
> 
> Yup, 16-bit.  I'll make it -1.
> 
> > -Steve
> > 
> > > - audit_proto() pulls in "truncated=" again, then either "sport=" and
> > >   "dport=" OR "icmptype=" and "icmpcode=".
> > > 
> > > If all fields are pulled in, we end up adding 10 fields beyond a
> > > standard well-formed packet, and 15 beyond a truncated packet.
> > > 
> > > Note: In the cases of "mark" and "secmark" both are unions.  In the case 
> > > of
> > > "mark", I don't see a problem since it isn't conditionally compiled out
> > > and won't be mis-interpreted.  In the case of "secmark=", it could be
> > > mis-interpreted as offload_fwd_mark if that field is even compiled in,
> > > but that would be addressed in the compiler directive...
> > > 
> > > 
> > > One last question: Does anyone have a test suite that can generate any
> > > or all of these types of packets?
> > > 
> > > 
> > > Thanks!
> > > 
> > > 
> > > - RGB
> 
> - RGB
> 
> --
> Richard Guy Briggs 
> Kernel Security Engineering, Base Operating Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635

- RGB

--
Richard Guy Briggs 
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-01-17 08:55, Steve Grubb wrote:
> On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote:
> > I'm just starting to look at the normalization of AUDIT_NETFILTER_PKT
> > event messages and it is not quite as straightforward as I had expected.
> > 
> > It is being tracked here:
> > https://github.com/linux-audit/audit-kernel/issues/11
> > and refers to a previous posting from Mr. Dash Four from four years ago
> > to which there was no reply.
> > 
> > The example given in the tracker above for "frag=" is fairly
> > straightforward, but digging more, there are a number of others that are
> > not quite so obvious.
> > 
> > How many different combinations of fields is acceptable?  Can we create
> > new message types for each one, or is there a preferred way to indicate
> > which sub-type it is other than implicit from the arguments given?
> 
> That would be preferential to swinging fields in and out. But we also don't 
> want to add too many new types. If two protocols look almost identical, I'd 
> try to coerce them to be the same. If adding 2 new types solves the problem 
> just do it. If it takes 10, then maybe we should understand why.

Ok, I'll have a go at mapping some out and see where we end up...

> > Others that are straightforward:
> > - The first "truncated=" gets pulled in with "0".
> > 
> > - "mark=" gets pulled in with "0".
> > 
> > Ones that are not so straightforward:
> > - "secmark" depends on a kernel config setting, so should it always be
> >   present but "(none)" if that kernel feature is compiled out?
> 
> If this is selinux related, I'd treat it the same way that we do subj 
> everywhere else.

Ok.

> > - ARPHRD_ETHER pulls in 3 fields, I would pull them all in and set them
> >   to "(none)" to indicate that type isn't present.
> 
> "(none)" is for character fields that have nothing. Typically we set -1 for 
> numeric fields that are unset. If numbers are expected, its going to get the 
> strtol() treatment and "(none)" will cause a conversion error.

Ah, ok.  I certainly don't want to break the parser, so I'll use -1 or
find another way to indicate it.

> > - audit_ip4() and audit_ip6 share "saddr=", "daddr=", proto=", but ip4
> >   adds "ipid=", which would be set to "(none)" for ip6.
> 
> That is numeric. -1?

Yup, 16-bit.  I'll make it -1.

> -Steve
> 
> > - audit_proto() pulls in "truncated=" again, then either "sport=" and
> >   "dport=" OR "icmptype=" and "icmpcode=".
> > 
> > If all fields are pulled in, we end up adding 10 fields beyond a
> > standard well-formed packet, and 15 beyond a truncated packet.
> > 
> > Note: In the cases of "mark" and "secmark" both are unions.  In the case of
> > "mark", I don't see a problem since it isn't conditionally compiled out
> > and won't be mis-interpreted.  In the case of "secmark=", it could be
> > mis-interpreted as offload_fwd_mark if that field is even compiled in,
> > but that would be addressed in the compiler directive...
> > 
> > 
> > One last question: Does anyone have a test suite that can generate any
> > or all of these types of packets?
> > 
> > 
> > Thanks!
> > 
> > 
> > - RGB

- RGB

--
Richard Guy Briggs 
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH nft 2/2] tests: py: Use stateless option on tests

[Elise Lennion]

To don't trigger false errors because of unrelated traffic on the
tested machine.

Tests, which have rules with counter and 'ok' result, are updated to
avoid new Warnings.

Signed-off-by: Elise Lennion 
---
 tests/py/ip/flowtable.t   | 2 +-
 tests/py/ip/flowtable.t.payload   | 2 +-
 tests/py/ip/masquerade.t  | 2 +-
 tests/py/ip/masquerade.t.payload  | 2 +-
 tests/py/ip/redirect.t| 2 +-
 tests/py/ip/redirect.t.payload| 2 +-
 tests/py/ip6/flowtable.t  | 4 ++--
 tests/py/ip6/masquerade.t | 2 +-
 tests/py/ip6/masquerade.t.payload.ip6 | 2 +-
 tests/py/ip6/redirect.t   | 4 ++--
 tests/py/ip6/redirect.t.payload.ip6   | 4 ++--
 tests/py/nft-test.py  | 2 +-
 12 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/tests/py/ip/flowtable.t b/tests/py/ip/flowtable.t
index aea57c3..41d5d3b 100644
--- a/tests/py/ip/flowtable.t
+++ b/tests/py/ip/flowtable.t
@@ -2,4 +2,4 @@
 
 *ip;test-ip;input
 
-flow table xyz { ip saddr timeout 30s counter packets 0 bytes 0};ok
+flow table xyz { ip saddr timeout 30s counter};ok
diff --git a/tests/py/ip/flowtable.t.payload b/tests/py/ip/flowtable.t.payload
index ffadfd2..591abf2 100644
--- a/tests/py/ip/flowtable.t.payload
+++ b/tests/py/ip/flowtable.t.payload
@@ -1,4 +1,4 @@
-# flow table xyz { ip saddr timeout 30s counter packets 0 bytes 0}
+# flow table xyz { ip saddr timeout 30s counter}
 xyz test-ip 31
 xyz test-ip 0
 ip test-ip input 
diff --git a/tests/py/ip/masquerade.t b/tests/py/ip/masquerade.t
index cee6e0e..26c3704 100644
--- a/tests/py/ip/masquerade.t
+++ b/tests/py/ip/masquerade.t
@@ -26,5 +26,5 @@ ip saddr 10.1.1.1 masquerade drop;fail
 
 # masquerade with sets
 tcp dport { 1,2,3,4,5,6,7,8,101,202,303,1001,2002,3003} masquerade;ok
-ip daddr 10.0.0.0-10.2.3.4 udp dport 53 counter packets 0 bytes 0 masquerade;ok
+ip daddr 10.0.0.0-10.2.3.4 udp dport 53 counter masquerade;ok
 iifname eth0 ct state new,established tcp dport vmap {22 : drop, 222 : drop } 
masquerade;ok
diff --git a/tests/py/ip/masquerade.t.payload b/tests/py/ip/masquerade.t.payload
index f4bbe99..ad0ea51 100644
--- a/tests/py/ip/masquerade.t.payload
+++ b/tests/py/ip/masquerade.t.payload
@@ -97,7 +97,7 @@ ip test-ip4 postrouting
   [ lookup reg 1 set __set%d ]
   [ masq ]
 
-# ip daddr 10.0.0.0-10.2.3.4 udp dport 53 counter packets 0 bytes 0 masquerade
+# ip daddr 10.0.0.0-10.2.3.4 udp dport 53 counter masquerade
 ip test-ip4 postrouting
   [ payload load 4b @ network header + 16 => reg 1 ]
   [ cmp gte reg 1 0x000a ]
diff --git a/tests/py/ip/redirect.t b/tests/py/ip/redirect.t
index f6ddfc0..7932361 100644
--- a/tests/py/ip/redirect.t
+++ b/tests/py/ip/redirect.t
@@ -43,7 +43,7 @@ ip saddr 10.1.1.1 redirect drop;fail
 
 # redirect with sets
 tcp dport { 1, 2, 3, 4, 5, 6, 7, 8, 101, 202, 303, 1001, 2002, 3003} 
redirect;ok
-ip daddr 10.0.0.0-10.2.3.4 udp dport 53 counter packets 0 bytes 0 redirect;ok
+ip daddr 10.0.0.0-10.2.3.4 udp dport 53 counter redirect;ok
 iifname eth0 ct state new,established tcp dport vmap {22 : drop, 222 : drop } 
redirect;ok
 
 # redirect with maps
diff --git a/tests/py/ip/redirect.t.payload b/tests/py/ip/redirect.t.payload
index dfb5a3b..1f050bf 100644
--- a/tests/py/ip/redirect.t.payload
+++ b/tests/py/ip/redirect.t.payload
@@ -179,7 +179,7 @@ ip test-ip4 output
   [ lookup reg 1 set __set%d ]
   [ redir ]
 
-# ip daddr 10.0.0.0-10.2.3.4 udp dport 53 counter packets 0 bytes 0 redirect
+# ip daddr 10.0.0.0-10.2.3.4 udp dport 53 counter redirect
 ip test-ip4 output
   [ payload load 4b @ network header + 16 => reg 1 ]
   [ cmp gte reg 1 0x000a ]
diff --git a/tests/py/ip6/flowtable.t b/tests/py/ip6/flowtable.t
index ae408b7..cf0a606 100644
--- a/tests/py/ip6/flowtable.t
+++ b/tests/py/ip6/flowtable.t
@@ -2,5 +2,5 @@
 
 *ip6;test-ip6;input
 
-flow table acct_out { meta iif . ip6 saddr timeout 600s counter };ok;flow 
table acct_out { iif . ip6 saddr timeout 10m counter packets 0 bytes 0}
-flow table acct_out { ip6 saddr . meta iif timeout 600s counter };ok;flow 
table acct_out { ip6 saddr . iif timeout 10m counter packets 0 bytes 0}
+flow table acct_out { meta iif . ip6 saddr timeout 600s counter };ok;flow 
table acct_out { iif . ip6 saddr timeout 10m counter}
+flow table acct_out { ip6 saddr . meta iif timeout 600s counter };ok;flow 
table acct_out { ip6 saddr . iif timeout 10m counter}
diff --git a/tests/py/ip6/masquerade.t b/tests/py/ip6/masquerade.t
index d36ff76..fea7391 100644
--- a/tests/py/ip6/masquerade.t
+++ b/tests/py/ip6/masquerade.t
@@ -26,5 +26,5 @@ ip6 saddr ::1 masquerade drop;fail
 
 # masquerade with sets
 tcp dport { 1,2,3,4,5,6,7,8,101,202,303,1001,2002,3003} masquerade;ok
-ip6 daddr fe00::1-fe00::200 udp dport 53 counter packets 0 bytes 0 
masquerade;ok
+ip6 daddr fe00::1-fe00::200 udp dport 53 counter masquerade;ok
 iifname eth0 ct state new,established tcp dport vmap {22 : drop, 222 : drop } 
masquerade;ok
diff --git 

[PATCH nft 1/2] doc: Include stateless option

[Elise Lennion]

Signed-off-by: Elise Lennion 
---
 doc/nft.xml | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/doc/nft.xml b/doc/nft.xml
index a421278..78e112f 100644
--- a/doc/nft.xml
+++ b/doc/nft.xml
@@ -49,6 +49,9 @@ vi:ts=4 sw=4
-n | --numeric


+   -s | --stateless
+   
+   
[-I | --includepath]
directory

@@ -119,6 +122,14 @@ vi:ts=4 sw=4



+   -s, --stateless
+   
+   
+   Omit stateful information of 
rules and stateful objects.
+   
+   
+   
+   
-N


-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AUDIT_NETFILTER_PKT message format

[Steve Grubb]

On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote:
> I'm just starting to look at the normalization of AUDIT_NETFILTER_PKT
> event messages and it is not quite as straightforward as I had expected.
> 
> It is being tracked here:
>   https://github.com/linux-audit/audit-kernel/issues/11
> and refers to a previous posting from Mr. Dash Four from four years ago
> to which there was no reply.
> 
> The example given in the tracker above for "frag=" is fairly
> straightforward, but digging more, there are a number of others that are
> not quite so obvious.
> 
> How many different combinations of fields is acceptable?  Can we create
> new message types for each one, or is there a preferred way to indicate
> which sub-type it is other than implicit from the arguments given?

That would be preferential to swinging fields in and out. But we also don't 
want to add too many new types. If two protocols look almost identical, I'd 
try to coerce them to be the same. If adding 2 new types solves the problem 
just do it. If it takes 10, then maybe we should understand why.

> Others that are straightforward:
> - The first "truncated=" gets pulled in with "0".
> 
> - "mark=" gets pulled in with "0".
> 
> Ones that are not so straightforward:
> - "secmark" depends on a kernel config setting, so should it always be
>   present but "(none)" if that kernel feature is compiled out?

If this is selinux related, I'd treat it the same way that we do subj 
everywhere else.

> - ARPHRD_ETHER pulls in 3 fields, I would pull them all in and set them
>   to "(none)" to indicate that type isn't present.

"(none)" is for character fields that have nothing. Typically we set -1 for 
numeric fields that are unset. If numbers are expected, its going to get the 
strtol() treatment and "(none)" will cause a conversion error.

> - audit_ip4() and audit_ip6 share "saddr=", "daddr=", proto=", but ip4
>   adds "ipid=", which would be set to "(none)" for ip6.

That is numeric. -1?

-Steve

> - audit_proto() pulls in "truncated=" again, then either "sport=" and
>   "dport=" OR "icmptype=" and "icmpcode=".
> 
> If all fields are pulled in, we end up adding 10 fields beyond a
> standard well-formed packet, and 15 beyond a truncated packet.
> 
> Note: In the cases of "mark" and "secmark" both are unions.  In the case of
> "mark", I don't see a problem since it isn't conditionally compiled out
> and won't be mis-interpreted.  In the case of "secmark=", it could be
> mis-interpreted as offload_fwd_mark if that field is even compiled in,
> but that would be addressed in the compiler directive...
> 
> 
> One last question: Does anyone have a test suite that can generate any
> or all of these types of packets?
> 
> 
> Thanks!
> 
> 
> - RGB
> 
> --
> Richard Guy Briggs 
> Kernel Security Engineering, Base Operating Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635


--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [stable] bridge: netfilter: Fix dropping packets that moving through bridge interface

[Greg Kroah-Hartman]

On Mon, Jan 16, 2017 at 09:08:54PM +0100, Pablo Neira Ayuso wrote:
> Cc'ing Greg.
> 
> On Mon, Jan 16, 2017 at 09:44:10PM +0300, Artur Molchanov wrote:
> > commit 14221cc45caad2fcab3a8543234bb7eda9b540d5 upstream.
> > 
> > Please apply this commit to fix bug that makes impossible to use local
> > Docker containers with bridge network.
> > 
> > Cc:  # 4.9.x
> 
> Greg, please, cherry-pick this commit to -stable 4.9.x.

Now done, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH nf] netfilter: conntrack: remove GC_MAX_EVICTS break

[Nicolas Dichtel]

Le 16/01/2017 à 18:24, Florian Westphal a écrit :
> Instead of breaking loop and instant resched, don't bother checking
> this in first place (the loop calls cond_resched for every bucket anyway).
> 
> Suggested-by: Nicolas Dichtel 
> Signed-off-by: Florian Westphal 
Acked-by: Nicolas Dichtel 
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html