The tests previously expected the invoker to pass a list of FIBs to use.
However, they now run in separate VNET jails, so we can simply expand
the FIB array as needed in each test. Modify each test to simply set
net.fibs as needed and grab FIB numbers starting at 1.
A number of tests were also broken by commit 9206c7996198
("usr.bin/netstat: -n should not print symbolic names"), so fix those.
Reviewed by: asomers
Fixes: 9206c7996198 ("usr.bin/netstat: -n should not print symbolic names")
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D48585
(cherry picked from commit 81b076e43aa63ac255996093233ab3560a23977e)
Note, the netstat-related changes described above are not merged.
In the current test case unicast_v4, host one acts as a router, but it
uses if_bridge(4) to verify the reachability to CARP master.
Unfortunately, if_bridge(4) brings the two CARP hosts into the same
broadcast domain, thus with an unusual (undocumented) setup, one host
is in unicast mode but another one in multicast, or two hosts are both
in multicast mode, the test case can falsely report success.
Fix that by propagating route via routed(8).
PR 284872 shows that CARP(4) happens to send packets with multicast
destination when the unicast peer address is in the range x.x.x.224 ~
x.x.x.239. Update the peer address in test case to catch that bug.
PR: 284872
Reviewed by: kp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D49076
(cherry picked from commit 93fbdef51a13b8facac3633f55804a59ca27f635)
Otherwise gcc warns about the (intentionall) truncated value and raises
an error.
Fixes: 7034563f8ef3 ("tests: Add some FIB multibind test cases")
(cherry picked from commit 400ce6248be986d52b3944c1ed01db3b26243454)
See commit 4f02a7d739b3 for more background.
I cannot see a good reason to continue ignoring mismatching UIDs when
binding to INADDR_ANY. Looking at the sdr.V2.4a7n sources (mentioned in
bugzilla PR 7713), there is a CANT_MCAST_BIND hack wherein the
application binds to INADDR_ANY instead of a multicast address, but
CANT_MCAST_BIND isn't defined for FreeBSD builds.
It seems unlikely that we still have a use-case for allowing sockets
from different UIDs to bind to the same port when binding to the
unspecified address. And, as noted in D47832, applications like sdr
would have been broken by the inverted SO_REUSEPORT check removed in
that revision, apparently without any bug reports. Let's break
compatibility and simply disallow this case outright.
Also, add some comments, remove a hack in a regression test which tests
this funtionality, and add a new regression test to exercise the
remaining checks that were added in commit 4658dc8325.
MFC after: 1 month
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D47870
(cherry picked from commit c9756953bded0d8428027fa3e812c9bdac069252)
This check for SO_REUSEPORT was added way back in commit 52b65dbe85.
Per the commit log, this commit restricted this port-stealing check to
unicast addresses, and then only if the existing socket does not have
SO_REUSEPORT set. In other words, if there exists a socket bound to
INADDR_ANY, and we bind a socket to INADDR_ANY with the same port, then
the two sockets need not be owned by the same user if the existing
socket has SO_REUSEPORT set.
This is a surprising semantic; bugzilla PR 7713 gives some additional
context. That PR makes a case for the behaviour described above when
binding to a multicast address. But, the SO_REUSEPORT check is only
applied when binding to a non-multicast address, so it doesn't really
make sense. In the PR the committer notes that "unicast applications
don't set SO_REUSEPORT", which makes some sense, but also refers to
"multicast applications that bind to INADDR_ANY", which sounds a bit
suspicious.
OpenBSD performs the multicast check, but not the SO_REUSEPORT check.
DragonflyBSD removed the SO_REUSEPORT (and INADDR_ANY) checks back in
2014 (commit 0323d5fde12a4). NetBSD explicitly copied our logic and
still has it.
The plot thickens: 20 years later, SO_REUSEPORT_LB was ported from
DragonflyBSD: this option provides similar semantics to SO_REUSEPORT,
but for unicast addresses it causes incoming connections/datagrams to be
distributed among all sockets in the group. This commit (1a43cff92a)
inverted the check for SO_REUSEPORT while adding one for
SO_REUSEPORT_LB; this appears to have been inadvertent. However:
- apparently no one has noticed that the semantics were changed;
- sockets belonging to different users can now be bound to the same port
so long as they belong to a single lbgroup bound to INADDR_ANY, which
is not correct.
Simply remove the SO_REUSEPORT(_LB) checks, as their original
justification was dubious and their current implementation is wrong; add
some tests.
Reviewed by: glebius
MFC after: 1 month
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D47832
(cherry picked from commit 4f02a7d739b354eef38e19b25866f64842d69414)
These tests assume exclusive use of one or more FIBs and so can't be run
in parallel. Running them in a VNET jail sidesteps this problem.
MFC after: 1 week
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
(cherry picked from commit a079f2b52aae74b5469f18dcbef1aff680b80282)
Many of the modified tests add epair interfaces to the host, though most
of the tests themselves run in a VNET jail. scapy in particular becomes
unhappy when the list of interfaces changes as it is running, so, to
improve reliability of parallel test runs, isolate tests which add
epairs to the host.
Also serialize arp tests, as they examine the dmesg as part of the test.
The list of modified tests is not exhaustive, it was determined by
running the test suite with parallelization enabled and looking at
failures. It may be easier to just automatically enable VNET jailing of
all netinet tests, but let's be more particular for now.
Reviewed by: kp
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D46606
(cherry picked from commit b103fc49ae160fdce221c2fffa98dde9bc0ff3b0)
Approved by: kp (mentor), markj (mentor)
A number of tests create a bridge, but did not check if if_bridge.ko is loaded.
We usually get away with that, because `ifconfig bridge create` autoloads the
module, but if we run the tests in a jail (e.g. because of kyua's upcoming
execenv.jail.params feature) we can't load the module and these tests can fail.
Check if the module is loaded, skip the test if it is not.
Reviewed by: markj
MFC after: 1 week
Event: Kitchener-Waterloo Hackathon 202406
Differential Revision: https://reviews.freebsd.org/D45487
(cherry picked from commit 480ad4055314efbfff7eedbb34272031d836ba89)
Otherwise we get spurious test failures when running tests in parallel.
The intent here was to name jails after the tests, but this was done
incorrectly in a couple of places.
MFC after: 1 week
(cherry picked from commit 001c48b4139ff6f07de70a16518161dcea5598b9)
This provides a regression test for commit abca3ae7734f.
Add it to the existing v4-mapped address test file, and rename
accordingly.
Reviewed by: tuexen, karels, rrs
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39216
(cherry picked from commit ae5c3dfd3e75bb287984947359d4f958aea505ec)
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
Rename the jails used in the unicast_ll_v6 test, to ensure the jail
names are unique to this test.
That is one of the requirements for running these tests in parallel.
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
Ensure that (multicast) CARP packets are sent with the expected source
MAC address.
Reviewed by: melifaro
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D39454
Test the new unicast carp mode for IPv6.
There's a routing hop between the peers, to ensure that the TTL check is
correctly disabled for unicast carp.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D38942
Test the new unicast carp mode for IPv4.
There's a routing hop between the peers, to ensure that the TTL check is
correctly disabled for unicast carp.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D38941
There's been at least one issue where we failed to correctly enter
NET_EPOCH that was triggered in this scenario.
Add a test case for it to make it easier to detect issues like this in
the future.
Reviewed by: zlei
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D39115
This makes diffs when adding or removing tests easier to read.
While here, sort the list of tests.
Reviewed by: kevans, melifaro, asomers, markj, emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36908
Test fix in 637f317c6d, verifying that when ports run out, we get
an EADDRNOTAVAIL error from bind() rather than an EADDRINUSE error
from connect(). Use small port range to exhaust ports and see which
error happens.
Reviewed by: tuexen, glebius, melifaro
Differential Revision: https://reviews.freebsd.org/D36056
MFC after: 3 days (with 637f317c6d)
Add tests for TCP_MD5 getsockopt for ipv6 and ipv4. These will only run
when the kernel module is loaded, but will be in place if further
regressions are found.
Reviewed by: rscheff
MFC after: 3 days
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D35532
Both struct ip and struct udphdr both have an aligment of 2, but the
cast from struct ip to a uint32_t pointer confused GCC 9 into raising
the required alignment to 4 and then raising a
-Waddress-of-packed-member error when casting to struct udphdr.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D31941
Test ranges of allowed ports for aliasing.
- Explicit default like ipfw(8) is doing
- Regular range
- Exhausting a very small range
- Recovery
Includes a fix of an utility macro, which was not used before.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31012
In C, plain inline functions should never be used: they should be
declared either static inline or extern inline. In this case, they are
clearly meant to be static inline.
MFC after: 3 days
This has been known to trigger panics. It currently doesn't, but we may
as well have a test for it.
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Add port forwardings to the performance tests. This will cause random
incoming packets to match the random port forwardings opends beforehand.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30443
gettimeofday(3) is almost as expensive as the calls to libalias.
So the call frequency for this call is reduced by a factor of 1000 in
order to neglect it's influence.
Using NAT entries became more realistic: A communication of a random
length of up to 150 packets (10% outgoing, 90% incoming) is applied
for each entry.
Precision of the execution time is raised to see the trends better.
Reviewed by: kp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30405
Extend the test suite for libalias(3) to incoming connections.
Test the various types of redirections.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30408
Rework the tests to check the correct layer in a single test.
Factor out tests for reuse in other modules.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30412
