You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Several tests will work with slirp, but not the UDP test as it stands, because it has an IPv6 part, and there doesn't seem to be a way to forward ports to IPv6 addresses with slirp. For example, hostfwd=udp::4242-:4242 forwards traffic to IPv4 addresses, has no effect on IPv6. See more details here: includeos/vmrunner#31
Ideally we'd find a way to run all the current networking tests with userspace networking, but if not, a subset would be a great start. The value of this would be that we would not require any sudo setup before running a reasonable test suite. If this would let us run tests in e.g. github actions, that's a great benefit. If we still have to maintain our own CI servers, maybe less important, but still nice to not require sudo.
A third alternative is to use the IncludeOS userspace mode to run tests. This will be a great way to test the IP stack against itself, but it won't stress tests the x86 hardware platform, which is hard to get right. So I don't see userspace tests ever displacing tests running in an actual VM (emulated or not).
Acceptance criteria:
At least TCP, UDP is tested over IPv4
Some aspects of IPv6 is tested
No sudo is required either for setup or running of the tests.
QUICK_SMOKE=1 ./test.sh will run only network tests that pass in usermode.
The text was updated successfully, but these errors were encountered:
Several tests will work with slirp, but not the UDP test as it stands, because it has an IPv6 part, and there doesn't seem to be a way to forward ports to IPv6 addresses with slirp. For example,
hostfwd=udp::4242-:4242
forwards traffic to IPv4 addresses, has no effect on IPv6. See more details here: includeos/vmrunner#31Ideally we'd find a way to run all the current networking tests with userspace networking, but if not, a subset would be a great start. The value of this would be that we would not require any sudo setup before running a reasonable test suite. If this would let us run tests in e.g. github actions, that's a great benefit. If we still have to maintain our own CI servers, maybe less important, but still nice to not require sudo.
A third alternative is to use the IncludeOS userspace mode to run tests. This will be a great way to test the IP stack against itself, but it won't stress tests the x86 hardware platform, which is hard to get right. So I don't see userspace tests ever displacing tests running in an actual VM (emulated or not).
Acceptance criteria:
QUICK_SMOKE=1 ./test.sh
will run only network tests that pass in usermode.The text was updated successfully, but these errors were encountered: