Disable the dummynet tests when running the ci tests. This avoids
running into the panic described in https://reviews.freebsd.org/D33064
(where an interface is removed but a dummynet queued packet still has a
pointer to it).
These tests can be re-enabled when the work in
https://reviews.freebsd.org/D33267 lands.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Add a somewhat more extensive pfsync defer mode test. Ensure that pfsync
actually delays the state creating packet until after it has sent the
pfsync update and given the peer time to create the state.
Ideally the test should validate the pfsync state update and generate an
ack message, but to keep the test simple we rely on the timeout of the
deferred packet instead.
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D33245
We didn't populate dyncnt/tblcnt, so `pfctl -sr -vv` might not have the
table element count.
PR: 259689
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32893
Ensure that NAT still works as expected when combined with dummynet.
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32666
Ensure that the ICMP error is returned with the correct
source and destination addresses.
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32572
Test the $nr expansion in labels is correct, even if the optimiser
reduces the rule count.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D32489
Now that pf can also use dummynet we should extend the existing dummynet
tests to also test it when used with pf.
Reviewed by: donner
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31905
Test syn-proxying a connection to the local host.
Sponsored by: Modirum MDPay
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31854
Same as the v4 test, but with IPv6.
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31789
Test prioritisation and dummynet queues.
We need to give the pipe sufficient bandwidth for dummynet to work.
Given that we can't rely on the TCP connection failing alltogether, but
we can measure the effect of dummynet by imposing a time limit on a
larger data transfer.
If TCP is prioritised it'll get most of the pipe bandwidth and easily
manage to transfer the data in 3 seconds or less. When not prioritised
this will not succeed.
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31788
Check that the bridge module is loaded before running this test.
It likely will be (as a result of running the bridge tests), but if it's
not we'll get spurious failures.
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC ("Netgate")
Test that ALTQ can prioritise one type of traffic over another. Do this
by establishing a slow link and saturating it with ICMP echos.
When prioritised TCP connections reliably go through. When not
prioritised TCP connections reliably fail.
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
The main purpose of this test is to verify that we can use ALTQ on top
of if_vlan, but while we're here we also exercise the CBQ code. There's
already a basis test for HFSC, so it makes sense to test another
algorithm while we test if_vlan.
Reviewed by: donner
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31649
Extend the existing set-tos keyword to also be able to set traffic class
on IPv6 traffic.
Add tests for this as well.
Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D31564
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
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
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
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
Test the specific case reported in PR 255852. Clearing the skip flag
on groups was broken because pfctl couldn't work out if a kif was a
group or not, because the kernel no longer set the pfik_group pointer.
PR: 255852
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30285
Since 2.4.5 scapy started issuing warnings about a few different
configurations during our tests. These are harmless, but they generate
stderr output, which upsets atf_check.
Configure scapy to only log critical errors (and thus not warnings) to
fix these tests.
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
There's a problem with pf's reassembly code where it produces incorrect
checksums when reassembling across interfaces with different MTUs.
Test this.
PR: 255432
Reviewed by: donner
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D30013
Add a test case where the pfctl optimizer will generate a table
automatically. These tables have long names, which we accidentally broke
in the nvlist ADDRULE ioctl.
Reviewed by: melifaro
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D29989
Now that we support having multiple labels on a rule ensure that we can
use each rule label to kill states.
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D29938
This was briefly broken, so ensure that we can read and clear rules
counters.
MFC after: 4 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D29728
MAP-E (RFC 7597) requires special care for selecting source ports
in NAT operation on the Customer Edge because a part of bits of the port
numbers are used by the Border Relay to distinguish another side of the
IPv4-over-IPv6 tunnel.
PR: 254577
Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D29468
This replicates an issue observed on pfSense: https://redmine.pfsense.org/issues/11436
In essence, reply-to is needed to ensure that connections always leave
the WAN interface they came in on, but this confused the state tracking.
MFC after: 2 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
tests/sys/netfil/pf/synproxy fails if inetd has been running
outside of the jail because pidfile_open() fails with EEXIST.
tests/sys/netfil/pf/nat has the same problem but the test succeeds
because whether inetd is running is not so important.
Fix the problem by changing the pidfile path from the default
location.
Reviewed by: kp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D29622
