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.
