Add basic tests for IPDIVERT write functionality.

[melifaro]

Summary

Add basic ipdivert tests, checking:

• IPv4 writes to remote destination
• IPv6 writes to remote destination
• IPv4 writes to local system (based on IP address).

Note that the tests require ipdivert kernel module, which depends on ipfw kernel module.
Blindly loading ipdivert results in all connectivity being lost.
Given that, all these tests have side effect of setting net.inet.ip.fw.default_to_accept=1 loader tunable and loading ipfw and ipdivert modules (if not already).

[lwhsu]

While other test cases haven't done this yet, but I'd like to see the new tests can restore the system as much as they can, if it doesn't bring too much complexity:

1. Can ipfw and ipdivert be unloaded safely after test?
2. Can net.inet.ip.fw.default_to_accept be set to the original value after the test has complete?

If it is too complex, we probably need atf_set "require.config" "allow_sysctl_side_effects" in the test case. The ci.freebsd.org runs tests with test_suites.FreeBSD.allow_sysctl_side_effects = '1' in kyua.con so it should be fine.

tests/sys/netinet6/divert.sh

115 ↗

(On Diff #67144)

Does this part belong to other file? There are functions with the same name make this file looks odd.

[kp]

In D23316#512620, @lwhsu wrote:

While other test cases haven't done this yet, but I'd like to see the new tests can restore the system as much as they can, if it doesn't bring too much complexity:

1. Can ipfw and ipdivert be unloaded safely after test?

Unloading the IPFW module seems like a bad idea. The netpfil/common tests rely on the module being loaded to run IPFW tests.
I believe the module is loaded because the test/build scripts explicitly load it, just like pf.

2. Can net.inet.ip.fw.default_to_accept be set to the original value after the test has complete?

Similarly, here. The default is set because otherwise merely loading IPFW kills all network connectivity. Happily this setting only applies to IPFW, so it's very unlikely to affect anything other than the firewall.

I'd suggest that this test should check if the values are set as expected (and the expected modules are loaded) and skip if they are not.

[melifaro]

In D23316#512732, @kp wrote:

In D23316#512620, @lwhsu wrote:

While other test cases haven't done this yet, but I'd like to see the new tests can restore the system as much as they can, if it doesn't bring too much complexity:

1. Can ipfw and ipdivert be unloaded safely after test?

Unloading the IPFW module seems like a bad idea. The netpfil/common tests rely on the module being loaded to run IPFW tests.
I believe the module is loaded because the test/build scripts explicitly load it, just like pf.

2. Can net.inet.ip.fw.default_to_accept be set to the original value after the test has complete?

Similarly, here. The default is set because otherwise merely loading IPFW kills all network connectivity. Happily this setting only applies to IPFW, so it's very unlikely to affect anything other than the firewall.

I'd suggest that this test should check if the values are set as expected (and the expected modules are loaded) and skip if they are not.

Yeah, this looks like a better approach. There will be no side effects within test itself and there will be much less potential clashes with other tests due to the modules loading/unloading.

However, I'm not sure what is the best way of telling the framework/wrapper that ipfw/ipdivert has to be loaded in advance, so we actually run these tests :-)

[melifaro]

Fix netinet6/divert.sh
Update pre-test logic to skip tests if the divert module is not loaded.

[kp]

In D23316#512773, @melifaro wrote:

However, I'm not sure what is the best way of telling the framework/wrapper that ipfw/ipdivert has to be loaded in advance, so we actually run these tests :-)

The test framework doesn't do that, instead we have the build script that sets up the test machine do it. Here's an example:

https://github.com/freebsd/freebsd-ci/pull/27/commits/4b46bdfdc2b89df50dc69c6fc2b077f208312608

[lwhsu]

Looks good to me basically. (I didn't go through the detail implementation of the tests body.)

Now I'm starting thinking if this is sane to load all the required modules at the boot time, especially different firewalls. I am worry the cross interference will be an issue in the future. Perhaps we should think about dividing the tests into different VMs and run separately, for isolation and speed.

Thanks for adding more tests!