in_pcblisten() moves an inpcb from the per-group list into the array, at
which point it becomes visible to inpcb lookups in the datapath. It
assumes that there is space in the array for this, but that's not
guaranteed, since in_pcbinslbgrouphash() doesn't reserve space in the
array if the inpcb isn't associated with a listening socket.
We could resize the array in in_pcblisten(), but that would introduce a
failure case where there currently is none. Instead, keep track of the
number of pending inpcbs as well, and modify in_pcbinslbgrouphash() to
reserve space for each pending (i.e., not-yet-listening) inpcb.
Add a regression test.
Reviewed by: glebius
Reported by: netchild
Fixes: 7cbb6b6e28 ("inpcb: Close some SO_REUSEPORT_LB races, part 2")
Differential Revision: https://reviews.freebsd.org/D49100
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
1) Set SO_BROADCAST and send to INADDR_BROADCAST.
2) Set SO_BROADCAST, set IP_ONESBCAST and cycle through broadcast capable
interfaces sending a datagram on each.
3) Set SO_BROADCAST and send to local broadcast address.
For each test we bind a second socket to check whether the broadcast
is actually received.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D49040
1) Test that getsockname() on a socket that experienced a sendto(2)
returns allocated port.
2) Same as 1), but jailed. Make sure IP address was also selected.
3) Test that IP_SENDSRCADDR/IP_RECVDSTADDR work.
4) Regression test for bug 274009.
Move the import of 'Sniffer', which depends on scapy into the test so we
don't try (and fail) to import it unless scapy is installed.
Reviewed by: kp, emaste
Approved by: emaste (mentor)
Differential Revision: https://reviews.freebsd.org/D48945
Avoid POLA breakage and preserve output standard that really predates
the FreeBSD project itself. There are scripts in the wild that rely
on the behavior.
Provide option to specify -nn twice to have a completely numeric
output of the routing tables.
Fixes: 9206c79961
This reverts commit e090646d6f.
Reviewed by: zlei, gallatin, melifaro, allanjude, markj, emaste
Differential Revision: https://reviews.freebsd.org/D48729
Suppose a thread is adds a socket to an existing TCP lbgroup that is
actively accepting connections. It has to do the following operations:
1. set SO_REUSEPORT_LB on the socket
2. bind() the socket to the shared address/port
3. call listen()
Step 2 makes the inpcb visible to incoming connection requests.
However, at this point the inpcb cannot accept new connections. If
in_pcblookup() matches it, the remote end will see ECONNREFUSED even
when other listening sockets are present in the lbgroup. This means
that dynamically adding inpcbs to an lbgroup (e.g., by starting up new
workers) can trigger spurious connection failures for no good reason.
(A similar problem exists when removing inpcbs from an lbgroup, but that
is harder to fix and is not addressed by this patch; see the review for
a bit more commentary.)
Fix this by augmenting each lbgroup with a linked list of inpcbs that
are pending a listen() call. When adding an inpcb to an lbgroup, keep
the inpcb on this list if listen() hasn't been called, so it is not yet
visible to the lookup path. Then, add a new in_pcblisten() routine which
makes the inpcb visible within the lbgroup now that it's safe to let it
handle new connections.
Add a regression test which verifies that we don't get spurious
connection errors while adding sockets to an LB group.
Reviewed by: glebius
MFC after: 1 month
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D48544
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 9206c79961
("usr.bin/netstat: -n should not print symbolic names"), so fix those.
Reviewed by: asomers
Fixes: 9206c79961 ("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
Excercise the garp code.
This doesn't actively verify anything, but is sufficient to trigger the
panic reported in PR 284073, so it's a useful test case to keep.
PR: 284073
Sponsored by: Rubicon Communications, LLC ("Netgate")
See commit 4f02a7d739 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
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
Add support for endpoint-independent mapping ("full cone NAT") in
Libalias's UDP NAT.
This conforms to RFC 4787 requirements 1 and 3. All UDP packets sent out from a
particular internal address:port leave via the same NAT address:port,
regardless of their destination.
Add some libalias tests and supporting defines.
Reviewed by: igoro, thj
Differential Revision: https://reviews.freebsd.org/D46689D
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
If during ip_forward() we find a blackhole (or reject) route we should stop
processing and count this in the 'cantforward' counter, just like we already do
for IPv6.
Blackhole routes are set to use the loopback interface, so we don't actually
incorrectly forward traffic, but we do fail to count it as unroutable.
Test this, both for IPv4 and IPv6.
Reviewed by: melifaro
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D47529
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
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
Start a file that would collect tests for I/O functionality of a UDP
socket, targeted on how a socket interacts with userland rather than with
wire side of the protocol.
First version tests that MSG_TRUNC and MSG_PEEK are working correctly.
The TCP implied connect is an artifact left after T/TCP. To my surprise
it still works, hence the existence of this test. Please read this email
first:
https://lists.freebsd.org/pipermail/freebsd-net/2010-August/026311.html
An interesting fact that this test takes 220 - 240 milliseconds to
execute on my Threadripper PRO. Flipping the '#if 0' to '#if 1' in the
test, thus bringing it back to normal connect(2), would speed the test up
a hundred times and I guess all this time is fork+exec of the test.
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
Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.
Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/
Sponsored by: Netflix
This provides a regression test for commit abca3ae773.
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
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
