Changing the bridge MTU will now also change all of the member interface
MTUs. Test this.
Reviewed by: donner
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31289
Only lists the states relevant to the connection we're killing.
Sometimes there are IPv6 related states (due to the usual IPv6
background traffic of router solicitations, DAD, ...) that causes us to
think we failed to kill the state, which in turn caused the test to fail
intermittently.
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC ("Netgate")
Use dhclient with its 'vlan-pcp' option to set a VLAN PCP value and
verify that it actually gets set.
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31276
Fairly basic test case for using gif(4)'s ability to tunnel Ethernet
traffic between bridges.
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Add a label to md devices created by this test. The next time this
test leaks md devices, finding the culprit will be much easier.
Thanks to: sobomax, for adding labels in r322969
MFC after: 1 week
Sponsored by: Dell EMC Isilon
readlink does not NUL-terminate the output buffer. This led to spurious
failures to destroy the md device because the unit number was garbage.
NUL-terminate the output buffer.
Reported by: ASLR
MFC after: 1 week
Sponsored by: Dell EMC Isilon
ATF cleanup functions cannot use functions such as ATF_REQUIRE
and atf_tc_fail. These functions assert that a test case is
currently running, which is not true during cleanup, so the
process aborts. Change the cleanup function to simply print
to stderr and return.
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Test that with syncookies enabled pf does not create state for
connections before the remote peer has replied to the SYN|ACK message.
MFC after: 1 week
Sponsored by: Modirum MDPay
Differential Revision: https://reviews.freebsd.org/D31142
Test syncookies on a forwarding host. That is, in a setup where the
machine (or vnet) running pf is not the same as the machine (or vnet)
running the server it's protecting.
MFC after: 1 week
Sponsored by: Modirum MDPay
Differential Revision: https://reviews.freebsd.org/D31141
The new match keyword can currently only assign queues, so we can only
test it with ALTQ.
Set up a basic scenario where we use 'match' to assign ICMP traffic to a
slow queue, and confirm that it's really getting slowed down.
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31116
One is allowed to use LIO_NOWAIT without specifying a sigevent. In this
case, lj->lioj_signal is left uninitialized, but several code paths
examine liov_signal.sigev_notify to figure out which notification to
post. Unconditionally initialize that field to SIGEV_NONE.
Add a dumb test case which triggers the bug.
Reported by: KMSAN+syzkaller
Reviewed by: asomers
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31197
Create and retrieve 20.000 states. There have been issues with nvlists
causing very slow state retrieval. We don't impose a specific limit on
the time required to retrieve the states, but do log it. In excessive
cases the Kyua timeout will fail this test.
Reviewed by: donner
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D30943
During FUSE_SETLK, the owner field should uniquely identify the calling
process. The fusefs module now sets it to the process's pid.
Previously, it expected the calling process to set it directly, which
was wrong.
libfuse also apparently expects the owner field to be set during
FUSE_GETLK, though I'm not sure why.
PR: 256005
Reported by: Agata <chogata@moosefs.pro>
MFC after: 2 weeks
Reviewed by: pfg
Differential Revision: https://reviews.freebsd.org/D30622
Every FUSE operation has a unique value in its header. As the name
implies, these values are supposed to be unique among all outstanding
operations. And since FUSE_INTERRUPT is asynchronous and racy, it is
desirable that the unique values be unique among all operations that are
"close in time".
Ensure that they are actually unique by incrementing them whenever we
reuse a fuse_dispatcher object, for example during fsync, write, and
listextattr.
PR: 244686
MFC after: 2 weeks
Reviewed by: pfg
Differential Revision: https://reviews.freebsd.org/D30810
/dev/fuse is always ready for writing, so it's kind of dumb to poll it.
But some applications do it anyway. Better to return ready than EINVAL.
MFC after: 2 weeks
Reviewed by: emaste, pfg
Differential Revision: https://reviews.freebsd.org/D30784
Add tests to check for renaming issues reported in PR241954 and solved
in D30110.
MFC: Together with D30629
Differential Revision: https://reviews.freebsd.org/D30713
During D30699 the existing basic tests were missed. Furthermore
debugging output was still in the code, which is removed now.
MFC: together with D30699
Differential Revision: https://reviews.freebsd.org/D30714
Test functionality of ng_vlan_rotate(4):
- Rotate 1 to 9 stagged vlans in any possible direction and length
- Rotate random combinations of ethertypes (8100, 88a8, 9100)
- Automatic reverse rotating for backward data flow
- Test too many and to few vlans
Reviewed by: kp (earlier version)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30670
Test functionality of ng_hub(4):
- replicting traffic to anything but the sending hook
- persistence
- an unrestricted loop
- implementation limits with many hooks.
Reviewed by: kp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30633
Factor out the data counter helpers for other tests to use.
Reviewed by: kp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30699
Errors raised in the common util functions should raise the location
of their caller to be useful and include the errno description.
Reviewed by: kp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30671
Test functionality of ng_bridge(4):
- replicating traffic to anything but the sending hook
- persistence
- detect loops
- unicast to only one link of many
- stretch to implementation limits on broadcast
Reviewed by: kp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30647
Add msg_handler in order to receive messages from netgraph nodes to be
tested.
Reviewed by: kp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30657
Provide a framework of functions to test various netgraph modules.
Tests contain:
- creating, renaming, and destroying nodes
- connecting and removing hooks
- sending and receiving data
- sending ASCII messages
- errors can be passed for indiviual inspection or fail the test
Reviewed by: kp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30629
The killstate:match test starts nc as a background process. There was no
guarantee that the nc process would have connected by the time we check
for states, so this test occasionally failed without good reason.
Teach the test to wait for at least some states to turn up before
executing the critical checks.
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC ("Netgate")
Test dummynet pipes (i.e. bandwidth limitation) with ipfw. This is put
in the common tests because we hope to add dummynet support to pf in the
near future.
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D30380
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
