In D38126#869129, @kp wrote:

I'm certainly seeing the argument for having setup_router_dummy_ipv6 and friends do the test setup.

Re-add the missing part: the setup functions.

I have updated the review to not only add functions for creating routing-based tests but also to make use of them by adding more tests for standard pf.conf syntax. This makes this review not related anymore to D38025.

! In D38126#866510, @kp wrote:

! In D38126#866296, @vegeta_tuxpowered.net wrote:

In D38126#866273, @kp wrote:

There's certainly a lot of repetition in many of the pf (and other firewall) tests.

So far I've chosen to not do anything about that, because it makes each individual test case much easier to understand. Each test case fully describes the setup it operates in, and when someone tries to debug it (or understand it for any other reason) there's no need to go look at other files to work out what the setup actually is.

In D38122#866272, @kp wrote:

This seems mostly good, but I've had to add these changes to avoid a few test failures:
…

Split sniffer.correctPackets change into D38120.

In D38120#866233, @kp wrote:

I think we're missing a change of foundCorrectPacket to correctPackets in pft_ping.py here.

In D38024#863922, @kp wrote:

I'm a little concerned about one end of an epair not getting destroyed if we destroy the other. That's not something I'd want the tests to cope with, that sounds like an issue with if_epair we should look at.

! In D38025#863920, @kp wrote:
Is this against a recent main? Because that has a (much more basic) "match" implementation already.