netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arturo Borrero Gonzalez <arturo@debian.org>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Netfilter Development Mailing list
	<netfilter-devel@vger.kernel.org>,
	Shivani Bhardwaj <shivanib134@gmail.com>
Subject: Re: [RFC nft PATCH] tests: shell: add a basic scapy test
Date: Thu, 1 Dec 2016 16:05:07 +0100	[thread overview]
Message-ID: <CAOkSjBjnKTk14-32+5faKsJG3CMARrywZ2814o1L2cC5Mj2TOQ@mail.gmail.com> (raw)
In-Reply-To: <20161201104535.GA13152@salvia>

On 1 December 2016 at 11:45, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> I mean, it would be good if you place as much common code as possible
> in the runner script, so individual unit tests don't result in too
> much copy and paste.
>

Ok, I understand.

Actually, as you know I'm just experimenting with this.

Anyway the problem I see is that we could end losing a lot of flexibility.
The current py testsuite is only able to perform one kind of tests
because of this approach.
In the other hand, the shell testsuite is able to perform almost any
kind of tests because it only executes arbitrary binaries.

So perhaps we could take an intermediate approach:
 * scapy tests are executed by the shell testsuite runner (they are
standalone scripts)
 * we develop a common lib of functions inside
tests/shell/testcases/scapy/ (for example common.py)
 * then, each scapy test load that common lib which includes most of
the factorised code

Common functions would be something like this:

* configure(): we do the scapy configuration, network config, or whatever
* load_ruleset): we pass a nft ruleset (a string) and load it using nft -f
* check_result(): we grep the ruleset counters, or whatever

I'm thinking of some tests we could have using this approach:

* atomic replacement of ruleset during a network transfer
* conntrack modifications (using the conntrack-tools binaries)
* packet mangling, NAT, etc

In any case, I think we should retain the ability to load nft rules,
send/recv scapy packets and check for nft counters at any time during
the execution.

  parent reply	other threads:[~2016-12-01 15:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-30  9:39 [RFC nft PATCH] tests: shell: add a basic scapy test Arturo Borrero Gonzalez
2016-11-30 18:27 ` Pablo Neira Ayuso
2016-11-30 18:28   ` Pablo Neira Ayuso
2016-12-01  8:10     ` Arturo Borrero Gonzalez
2016-12-01 10:45       ` Pablo Neira Ayuso
2016-12-01 11:04         ` Vadim Kochan
2016-12-01 15:05         ` Arturo Borrero Gonzalez [this message]
2016-12-01 16:52           ` Pablo Neira Ayuso

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=CAOkSjBjnKTk14-32+5faKsJG3CMARrywZ2814o1L2cC5Mj2TOQ@mail.gmail.com \
    --to=arturo@debian.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=shivanib134@gmail.com \
    /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).