netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mikhail Sennikovsky <mikhail.sennikovskii@cloud.ionos.com>
To: netfilter-devel@vger.kernel.org
Cc: Mikhail Sennikovsky <mikhail.sennikovskii@cloud.ionos.com>
Subject: [PATCH 0/8] Fast bulk transfers of large sets of ct entries
Date: Fri, 25 Sep 2020 14:49:11 +0200	[thread overview]
Message-ID: <20200925124919.9389-1-mikhail.sennikovskii@cloud.ionos.com> (raw)

Hi Fellows,

This is a set of patches to the conntrack tool that I think 
might be interesting to the community.

The PATCH 1 and PATCH 2 represent a fix to the icmp ct entry creation 
(a test case and a fix respectively).

The remaining patches represent an extension to the conntrack tool
functionality that enables fast bulk transfers of large sets of ct 
entries, which includes creating a large set of ct entries with
a single conntrack tool invocation by passing ct entry parameters
on stdin and making conntrack be able to dump ct entries in a new
"opts" format that could be later fed back to the conntrack.

To demonstrate the overall idea, this functionality makes it possible 
to e.g. copy all ct entries from one ct zone (15) to another (9915) 
with the following command:

  conntrack -L -w 15 -o opts | sed 's/-w 15/-w 9915/g' | conntrack -I -


In addition to this I have a question about the behavioural change
of the "conntrack -L" done after conntrack v1.4.5.
With the conntrack v1.4.5 used on Debian Buster the "conntrack -L"
dumps both ipv4 and ipv6 ct entries, while with the current master, 
presumably starting with the commit 2bcbae4c14b253176d7570e6f6acc56e521ceb5e 
"conntrack -L"  only dumps ipv4 entries.

So is this really the desired behavior? 
(I see the manual page was always saying it should be like that,
but since it behaved differently there might be multiple appliances 
out there relying on the "old" behavior).

And if the "new" behavior is desired, would it make sense to add a new 
-f option value, e.g. "any", that would actually explicitly allow the 
"old" behaviour, i.e. dump both ipv4 and ipv6 entries with one go?
If yes - I could create a small patch for that as well.

Thanks & Regards,
Mikhail

Mikhail Sennikovsky (8):
  tests: icmp entry create/delete
  conntrack: fix icmp entry creation
  conntrack: accept parameters from stdin
  conntrack.8: man update for stdin params support
  tests: conntrack parameters from stdin
  conntrack: implement options output format
  conntrack.8: man update for opts format support
  tests: dumping ct entries in opts format

 conntrack.8                         |  13 +-
 extensions/libct_proto_dccp.c       |  24 ++
 extensions/libct_proto_gre.c        |  16 +
 extensions/libct_proto_icmp.c       |  33 ++
 extensions/libct_proto_icmpv6.c     |  33 ++
 extensions/libct_proto_sctp.c       |  19 ++
 extensions/libct_proto_tcp.c        |  17 ++
 extensions/libct_proto_udp.c        |  16 +
 extensions/libct_proto_udplite.c    |  16 +
 include/conntrack.h                 |  38 +++
 src/conntrack.c                     | 457 +++++++++++++++++++++++++---
 tests/conntrack/test-conntrack.c    |  84 ++++-
 tests/conntrack/testsuite/00create  |   4 +
 tests/conntrack/testsuite/08stdin   |  62 ++++
 tests/conntrack/testsuite/09dumpopt |  77 +++++
 15 files changed, 857 insertions(+), 52 deletions(-)
 create mode 100644 tests/conntrack/testsuite/08stdin
 create mode 100644 tests/conntrack/testsuite/09dumpopt

-- 
2.25.1


             reply	other threads:[~2020-09-25 12:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-25 12:49 Mikhail Sennikovsky [this message]
2020-09-25 12:49 ` [PATCH 1/8] tests: icmp entry create/delete Mikhail Sennikovsky
2020-10-13 18:28   ` Pablo Neira Ayuso
2020-09-25 12:49 ` [PATCH 2/8] conntrack: fix icmp entry creation Mikhail Sennikovsky
2020-10-13 18:29   ` Pablo Neira Ayuso
2020-09-25 12:49 ` [PATCH 3/8] conntrack: accept parameters from stdin Mikhail Sennikovsky
2020-11-04 13:56   ` Pablo Neira Ayuso
2020-09-25 12:49 ` [PATCH 4/8] conntrack.8: man update for stdin params support Mikhail Sennikovsky
2020-09-25 12:49 ` [PATCH 5/8] tests: conntrack parameters from stdin Mikhail Sennikovsky
2020-09-25 12:49 ` [PATCH 6/8] conntrack: implement options output format Mikhail Sennikovsky
2020-10-22 12:36   ` Pablo Neira Ayuso
2020-10-22 12:37     ` Pablo Neira Ayuso
2020-10-23 11:07       ` Mikhail Sennikovsky
2020-09-25 12:49 ` [PATCH 7/8] conntrack.8: man update for opts format support Mikhail Sennikovsky
2020-09-25 12:49 ` [PATCH 8/8] tests: dumping ct entries in opts format Mikhail Sennikovsky
2020-09-25 13:28 ` [PATCH 0/8] Fast bulk transfers of large sets of ct entries Florian Westphal
2020-09-26 18:19   ` Pablo Neira Ayuso
2020-09-29 11:20     ` [PATCH 0/2] conntrack: -L/-D both ipv4/6 if no family is given Mikhail Sennikovsky
2020-09-29 11:20       ` [PATCH 1/2] " Mikhail Sennikovsky
2020-09-29 11:20       ` [PATCH 2/2] tests: conntrack -L/-D ip family filtering Mikhail Sennikovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200925124919.9389-1-mikhail.sennikovskii@cloud.ionos.com \
    --to=mikhail.sennikovskii@cloud.ionos.com \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).