Re: [PATCH nf v2] selftests: netfilter: add nfqueue test case

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 27, 2019 at 09:25:25PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> > On Wed, Jun 26, 2019 at 09:09:29PM +0200, Pablo Neira Ayuso wrote:
> > > On Wed, Jun 26, 2019 at 09:05:03PM +0200, Pablo Neira Ayuso wrote:
> > > > On Wed, Jun 26, 2019 at 08:56:53PM +0200, Florian Westphal wrote:
> > > > > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> > > > > > On Wed, Jun 26, 2019 at 08:42:34PM +0200, Florian Westphal wrote:
> > > > > > > diff --git a/tools/testing/selftests/netfilter/nf-queue.c b/tools/testing/selftests/netfilter/nf-queue.c
> > > > > > > new file mode 100644
> > > > > > > index 000000000000..897274bd6f4a
> > > > > > > --- /dev/null
> > > > > > > +++ b/tools/testing/selftests/netfilter/nf-queue.c
> > > > > > 
> > > > > > Oh well. Lots of copied and pasted code from the libraries.
> > > > > > 
> > > > > > We'll have to remind to take patches for the example in the library
> > > > > > and the kernel.
> > > > > 
> > > > > Do you have an alternative proposal?
> > > > 
> > > > Probably install this nf-queue tool from libraries? Then, selftest use
> > > > this binary? So we have a single copy of this code :-)
> > > 
> > > Or move this C code to a new git tree under netfilter, eg.
> > > netfilter-tests.git, you may need something similar for
> > > libnetfilter_log I suspect, and so on for other stuff.
> > > 
> > > Such new git tree would compile all testing tools for netfilter and
> > > install them.
> > > 
> > > kselftest depends on external tooling anyway, this should be fine.
> > 
> > You could also integrate the tcpdr tool that Mate was using to test
> > tproxy, there will be a test for tproxy too at some point, right? And
> > you don't want to push that into the kernel?
> 
> Actually ... yes :/
> 
> I had hoped that we could maximize coverage of netfilter core infra
> this way.
> 
> We have an embarassing number of regressions and really stupid bugs.
> Largely because we don't have tests at all, or because they
> live outside of kernel/are not run with a certain config.

I think they cover different aspects, so far we have good coverage
for the control plane, which are the tests you are refering to.

> > Having all this testing tools in the git repository somewhere where it
> > can be collected could be useful. Users could invoke it from command
> > line to collect packets and print them. I mean, add the nfqueue tool,
> > then the nflog tool too, and so on.
> 
> Yes, but that means that anyone running make run_tests will get a 'SKIP'
> for these tests UNLESS they also installed the netfilter-test.git
> tools.

Is there any script that pulls dependencies and install them to run
this kselftests?

> If you think thats fine, I can start accumulating tools in a new repo.

I'm just brainstorming where to go, and see if you think it can be
useful to start collecting testing/debugging tools that might be not
only useful for this test infrastructure, but for general
troubleshooting.

My only concern is that we might end up with a bit of C code spread
over the test tree for all these tooling. Probably these tooling could
reside in the kernel tree if you prefer.



[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux