Merge the PCM_READ|WRITE_* macros defined in pcm/pcm.h, as well as the
intpcm_read|write_* macros defined in pcm/feeder_format.c, into six
inline functions: pcm_sample_read|write[_norm|calc](). The absence of
macro magic makes the code significantly easier to read, use and modify.
Since these functions take the input/output format as a parameter, get
rid of the read() and write() function pointers defined in struct
feed_format_info, as well as the feeder_format_read|write_op()
functions, and use the new read/write functions directly.
Sponsored by: The FreeBSD Fondation
MFC after: 1 week
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D47932
This combination doesn't make any sense. This socket option makes sense
only on a socket that is going to be a listening one. There are two
options here: refuse connect(2) on a socket that has the option set
previously, or ignore (and clear) the option. After some discussion on
phabricator, we have chosen the former, for safety and consistency
reasons. Any programmer that runs this sequence is doing something wrong
and should be informed of that with appropriate error code.
Since connect(2) is a SUS API that has a defined set of error codes, none
of which corresponds to "a socket has non-standard incompatible socket
option set", we decided to return the same error that an already listening
socket would return.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D49150
While here, add one additional IPv4 link-local address to test_46_nofilter
to cover the IPv4 RT_SCOPE_LINK case.
Reviewed by: melifaro, #network
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D49226
This test starts two threads to verify that two concurrent threads
cannot enter the kernel loop on the same netmap context. The test
even has a comment about a potential race condition where the first
thread enters the loop and is stopped before the second thread tries
to enter the loop. It claims it is fixed by the use of a semaphore.
Unfortunately, the semaphore doesn't close the race.
In the CI setup for CHERI, we run the testsuite once a week against
various architectures using single CPU QEMU instances. Across
multiple recent runs of the plain "aarch64" test the job ran for an
entire day before QEMU was killed by a timeout. The last messages
logged were from this test:
734.881045 [1182] generic_netmap_attach Emulated adapter for tap3312 created (prev was NULL)
734.882340 [ 321] generic_netmap_register Emulated adapter for tap3312 activated
734.882675 [2224] netmap_csb_validate csb_init for kring tap3312 RX0: head 0, cur 0, hwcur 0, hwtail 0
734.883042 [2224] netmap_csb_validate csb_init for kring tap3312 TX0: head 0, cur 0, hwcur 0, hwtail 1023
734.915397 [ 820] netmap_sync_kloop kloop busy_wait 1, direct_tx 0, direct_rx 0, na_could_sleep 0
736.901945 [ 820] netmap_sync_kloop kloop busy_wait 1, direct_tx 0, direct_rx 0, na_could_sleep 0
From the timestamps, the synchronous kloop was entered twice 2 seconds
apart. This corresponds to the 2 second timeout on the semaphore in
the test. What appears to have happened is that th1 started and
entered the kernel where it spun in an endless busy loop. This
starves th2 so it _never_ runs. Once the semaphore times out, th1 is
preempted to run the main thread which invokes the ioctl to stop the
busy loop. th1 then exits the loop and returns to userland to exit.
Only after this point does th2 actually run and execute the ioctl to
enter the kernel. Since th1 has already exited, th2 doesn't error and
enters its own happy spin loop. The main thread hangs forever in
pthread_join, and the process is unkillable (the busy loop in the
kernel doesn't check for any pending signals so kill -9 is ignored and
ineffective).
I don't see a way to fix this test, so I've just disabled it. There
is no good way to ensurce concurrency on a single CPU system when one
thread wants to sit in a spin loop. Someone should fix the netmap
kloop to respond to kill -9 in which case kyua could perhaps at least
timeout the individual test process and kill it.
Reviewed by: vmaffione
Obtained from: CheriBSD
Sponsored by: AFRL, DARPA
Differential Revision: https://reviews.freebsd.org/D49220
Fix more incorrect use of the iih pointer, this time causing corruption in nat64
translated ICMP error messages.
Extend the relevant test case to catch this bug.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D49231
Ensure that when we translate an ICMPv4 to ICMPv6 message we set the correct
source IP address.
PR: 284944
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D49144
IPv4 packets can be routed via an IPv6 nexthop, so the handling of the
parsed address family is more strict than it needs to be. If we have a
valid header that matches a known peer, then we have no reason to
decline the packet.
Convert it to an assertion that it matches the destination as viewed by
the stack below it, instead. `dst` may be the gateway instead of the
destination in the case of a nexthop, so the `af` assignment must be
switched to use the destination in all cases.
Add a test case that approximates a setup like in the PR and
demonstrates the issue.
PR: 284857
Reviewed by: markj (earlier version), zlei
Differential Revision: https://reviews.freebsd.org/D49172
python3 is a symbolic link that points to the current python 3.X
version.
It is possible for a system to have python (python 3.X) without the
python3 (symlink) package.
Test scripts that use Scapy are invoked using python3, so add it as a
required program.
Reviewed by: ngie, asomers
Approved by: emaste (mentor)
Differential Revision: https://reviews.freebsd.org/D49007
Currently af-to works only on inbound interface by creating a reversed
NAT state key which is used to match traffic returning on the outbound
interface.
Such limitation is not necessary. When an af-to state is created
for an outbound rule do not reverse the NAT state key, making it work
just like if it was created for a normal NAT rule. Depending on firewall
design it might be easier and more natural to use af-to on the outbound
interface.
Reviewed by: kp
Approved by: kp (mentor)
Sponsored by: InnoGames GmbH
Differential Revision: https://reviews.freebsd.org/D49122
It's possible for an IPv4 next hop to be specified as an IPv6 address. This
broke pf's route lookup in pf_route(), which is required for nat64.
Handle this case just like ip_tryforward(): use the struct sockaddr from the
struct nhop_object, and mark a struct route to indicate if_output() has to use
the gateway.
Add a test case for this.
PR: 284946
Reviewed by: zlei
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D49095
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
This finally allows to use source-hash for dynamic loadbalancing, eg.
"rdr-to <hosts> source-hash", instead of just round-robin and least-states.
An older pre-siphash version of this diff was tested by many people.
OK tedu@ benno@
Obtained from: OpenBSD, reyk <reyk@openbsd.org>, 252a05523f
Sponsored by: Rubicon Communications, LLC ("Netgate")
When we receive an ICMP packet containing another ICMP packet we look up the
original ICMP state. This is done through a second struct pf_pdesc ('pd2'),
containing relevant information (i.e. addresses, type, id, ..).
pd2 did not contain the network interface ('kif'), leading to state lookup
failures. This only affected if-bound mode, because floating states match all
interfaces.
Set kif in pd2.
Extend the icmp.py:test_fragmentation_needed test case to use if-bound mode. It
already checked that we handled icmp-in-icmp correctly.
PR: 284866
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
In some situations the feeders in the sound module lower the pcm sample
resolution through a downshift of the sample value. The pcm_read_write
test implements this operation with an arithmetic division to avoid
implementation defined or architecture specific behavior. Due to
different rounding, the test produced marginally different sample
values, which made the test fail on 32 bit architectures. Correct this.
Reported by: CI
Fixes: 27ef5d48c7 ("sound: Unit test the pcm sample read and write macros")
MFC after: 1 week
Reviewed by: christos, markj
Differential revision: https://reviews.freebsd.org/D48926
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.
Scapy is not needed to run this test. Remove it from the required
programs list.
Reviewed by: kp
Approved by: emaste (mentor)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D49006
The ra.py script requires Scapy. Invoke it using the python3 symlink.
While technically, at the moment, python points to python3, and python3
points to the current version of python, it is recommended to use
python3. No functional change intended.
Add the Scapy requirement in the header of each test that makes use of
it.
Reviewed by: kp
Approved by: emaste (mentor)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D49005
The utils.subr file includes a couple of subroutines
(ping_dummy_check_request and ping_server_check_reply) that require
Scapy.
Add this requirement in the header of each test that makes use of them.
Reported by: Jenkins
Reviewed by: kp
Approved by: emaste (mentor)
Fixes: 07e070ef08 ("pf: Add support for multiple source node types")
Differential Revision: https://reviews.freebsd.org/D49004
When a packet matches a binat/nat/rdr rule, pf logs the match. The log
metadata includes the rule's action on the packet, e.g., PF_PASS. NAT
rules have their own actions: PF_BINAT, PF_NAT, PF_RDR.
Before commit 948e8413ab ("pflog: pass the action to pflog directly"),
pflog_packet() would obtain the action from the rule definition, whereas
after that commit the action is passed as a parameter. When a NAT rule
matches, we want to log the rule action, but after that commit, PF_PASS
is hard-coded. Restore the previous behaviour.
Add a regression test which installs a redirect, logs packets matching
the redirect rule, and verifies that the corresponding pflog entry
includes the correct action.
Reviewed by: kp
Fixes: 948e8413ab ("pflog: pass the action to pflog directly")
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: OPNsense
Differential Revision: https://reviews.freebsd.org/D48911
For every state pf creates up to two source nodes: a limiting one
struct pf_kstate -> src_node and a NAT one struct pf_kstate -> nat_src_node.
The limiting source node is tracking information needed for limits using
max-src-states and max-src-nodes and the NAT source node is tracking NAT
rules only.
On closer inspection some issues emerge:
- For route-to rules the redirection decision is stored in the limiting source
node. Thus sticky-address and source limiting can't be used separately.
- Global source tracking, as promised in the man page, is totally absent from
the code. Pfctl is capable of setting flags PFRULE_SRCTRACK (enable source
tracking) and PFRULE_RULESRCTRACK (make source tracking per rule). The kernel
code checks PFRULE_SRCTRACK but ignores PFRULE_RULESRCTRACK. That makes
source tracking work per-rule only.
This patch is based on OpenBSD approach where source nodes have a type and each
state has an array of source node pointers indexed by source node type
instead of just two pointers. The conditions for limiting are applied
only to source nodes of PF_SN_LIMIT type. For global limit tracking
source nodes are attached to the default rule.
Reviewed by: kp
Approved by: kp (mentor)
Sponsored by: InnoGames GmbH
Differential Revision: https://reviews.freebsd.org/D39880
Two test cases in table.sh didn't call pft_init and thus didn't skip if pf is
not loaded.
The fragmentation_pass:v6_route_to test had the test body in the cleanup
function, so got run even when pf was not loaded.
Sponsored by: Rubicon Communications, LLC ("Netgate")
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
The utils.subr file includes a couple of subroutines
(ping_dummy_check_request and ping_server_check_reply) that require
scapy.
Add this requirement in the header of each test that makes use of them.
Reported by: Jenkins
Reviewed by: kp, ngie
Approved by: emaste (mentor)
Differential Revision: https://reviews.freebsd.org/D48917
Add more test cases for pf fragment hole counter. Also look into
final fragment of echo reply and check total length of IP packet.
MFC after: 1 week
Obtained from: OpenBSD, bluhm <bluhm@openbsd.org>, 640736615b
Sponsored by: Rubicon Communications, LLC ("Netgate")
If vmm.ko is loaded but fails initialization, it doesn't get
automatically unloaded, so the tests will not skip themselves and will
instead fail outright.
MFC after: 1 week
Verify that we can set-tos on pass rules, and that this still works even if a
'scrub' option is present on the pass rule.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Just like we do for IPv6, generate an ICMP fragmentation needed packet if we're
going to need fragmenation for IPv4 as well (i.e. DF is set). Do so before full
processing, so we generate it with pre-NAT addreses, just as we do for IPv6.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D48805
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
Just like route-to reply-to is problematic when used in combination with nat64.
In the normal (i.e. without nat64) flow we return immediately from pf_route().
However, with nat64 we need to continue and do a route lookup. In that case
we should not make the extra pf_test(PF_OUT) call to remain similar to the
non-nat64 flow.
We also have to fix the interface binding. We can only bind to the interface
after we've done the route lookup, not before.
Add a funcional test case, and a test for pfctl's rule printing.
Sponsored by: Rubicon Communications, LLC ("Netgate")
af-to uses pf_route() and pf_route6(), which caused issues when af-to and
route-to were combined in a single rule.
Extend the relevant functions to cope with this and add test cases.
Sponsored by: Rubicon Communications, LLC ("Netgate")
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
