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
In order to compare upcoming changes for their effectivness, measure
performance by counting opertions and the runtime of each operation
over the time. Accumulate all tests in a single instance, so make it
complicated over the time. If you wait long enough, you will notice
the expiry of old flows.
Reviewed by: kp (earlier version)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30379
Testing LibAliasOut functionality. This concentrates the typical use
case of initiating data transfers from the inside. Provide a
exhaustive test for the data structure in order to check for
performance improvements.
Reviewed by: kp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30335
In order to modify libalias for performance, the existing
functionality must not change. Enforce this.
Reviewed by: kp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30307
Teach poll(2) to support Linux-style POLLRDHUP events for sockets, if
requested. Triggered when the remote peer shuts down writing or closes
its end.
Reviewed by: kib
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D29757
After length decisions, we've decided that the if_wg(4) driver and
related work is not yet ready to live in the tree. This driver has
larger security implications than many, and thus will be held to
more scrutiny than other drivers.
Please also see the related message sent to the freebsd-hackers@
and freebsd-arch@ lists by Kyle Evans <kevans@FreeBSD.org> on
2021/03/16, with the subject line "Removing WireGuard Support From Base"
for additional context.
This is the culmination of about a week of work from three developers to
fix a number of functional and security issues. This patch consists of
work done by the following folks:
- Jason A. Donenfeld <Jason@zx2c4.com>
- Matt Dunwoodie <ncon@noconroy.net>
- Kyle Evans <kevans@FreeBSD.org>
Notable changes include:
- Packets are now correctly staged for processing once the handshake has
completed, resulting in less packet loss in the interim.
- Various race conditions have been resolved, particularly w.r.t. socket
and packet lifetime (panics)
- Various tests have been added to assure correct functionality and
tooling conformance
- Many security issues have been addressed
- if_wg now maintains jail-friendly semantics: sockets are created in
the interface's home vnet so that it can act as the sole network
connection for a jail
- if_wg no longer fails to remove peer allowed-ips of 0.0.0.0/0
- if_wg now exports via ioctl a format that is future proof and
complete. It is additionally supported by the upstream
wireguard-tools (which we plan to merge in to base soon)
- if_wg now conforms to the WireGuard protocol and is more closely
aligned with security auditing guidelines
Note that the driver has been rebased away from using iflib. iflib
poses a number of challenges for a cloned device trying to operate in a
vnet that are non-trivial to solve and adds complexity to the
implementation for little gain.
The crypto implementation that was previously added to the tree was a
super complex integration of what previously appeared in an old out of
tree Linux module, which has been reduced to crypto.c containing simple
boring reference implementations. This is part of a near-to-mid term
goal to work with FreeBSD kernel crypto folks and take advantage of or
improve accelerated crypto already offered elsewhere.
There's additional test suite effort underway out-of-tree taking
advantage of the aforementioned jail-friendly semantics to test a number
of real-world topologies, based on netns.sh.
Also note that this is still a work in progress; work going further will
be much smaller in nature.
MFC after: 1 month (maybe)
Repeating the default WARNS here makes it slightly more difficult to
experiment with default WARNS changes, e.g. if we did something absolutely
bananas and introduced a WARNS=7 and wanted to try lifting the default to
that.
Drop most of them; there is one in the blake2 kernel module, but I suspect
it should be dropped -- the default WARNS in the rest of the build doesn't
currently apply to kernel modules, and I haven't put too much thought into
whether it makes sense to make it so.
many sockets in TIME_WAIT state at the end of the test.
PR: 249885
Reviewed by: markj
Approved by: markj
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D26549
Fix the netinet/netinet6 divert tests falsely reporting 'ipdivert module is
not loaded' when the divert module is built into the kernel
Sponsored by: Axiado
Differential Revision: https://reviews.freebsd.org/D25026
Set up three vnet jails, bridged together. Run carp between two of them.
Attempt to provoke locking / epoch issues.
Reviewed by: mav (previous version), melifaro, asomers
Differential Revision: https://reviews.freebsd.org/D24303
Change type of variable used in setsocketopt so correct size of
option is passed.
Test failure was identified when running the test on PowerPC64,
and the following error message was seen:
"bind () failed: Address already in use"
Submitted by: Fernando Valle <fernando.valle@eldorado.org.br>
Reviewed by: melifaro, adalava
Approved by: jhibbits (mentor)
Sponsored by: Eldorado Research Institute (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D24164
