divert: Define semantics for SO_REUSEPORT_LB on divert sockets
Allow SO_REUSEPORT_LB to be set on divert sockets. If set, then bind()
will add the socket to a "load-balancing group". When a divert-to rule
matches a port with an associated group, the corresponding state ID is
used to select a specific socket from the group. Packets without an
associated state are simply forwarded to the first socket in the group.
This implementation is simple but has some caveats, the main one being
that if sockets are added to the group while flows are being processed,
the size of the group will change and this changes the mapping of state
IDs to sockets. So, to get a consistent mapping, the divert socket
application must bind all of its sockets before any traffic is processed
by pf.
ipdivert: Use CK_SLISTs for the divcb hash table
The hash table is accessed in ip_divert_packet(), and there the accesses
are synchronized only by the net epoch, so plain SLIST is not safe.
pf: Rationalize the ip_divert_ptr test
If a rule has a divert port set, then we can reasonably predict that
ipdivert.ko is loaded, and in particular that ip_divert_ptr is set.
Moreover, in this case, if ipdivert.ko is not loaded we should just drop
the packet instead of ignoring the divert rule.
No functional change intended.
ix(4): Add support for debug dump for E610 adapters
This is part 2 of the support for the new Intel Ethernet E610 family of devices.
Intel E610 Ethernet Controller devices feature a debug dump capability
that allows you to capture runtime register values directly from the
hardware, with assistance from the firmware. These registers are
organized into clusters based on their function, enabling targeted
debugging. This information is consolidated into a single dump file,
facilitating the debugging of complex issues encountered in the field.
The debug dump provides a snapshot of the device's current hardware
configuration, including switch tables, transmit scheduler tables, and
other relevant data. It captures the state of specified clusters and
serves as a stateless snapshot of the entire device.
This update introduces ioctl and sysctl support for the debug dump feature.
Signed-off-by: Yogesh Bhosale yogesh.bhosale at intel.com
Co-developed-by: Krzysztof Galazka krzysztof.galazka at intel.com
[7 lines not shown]
igb(4): Fix VLAN support on VFs
Virtual Functions are considered untrusted and have no control
over VLAN filtering configuration in HW. To allow using
VLANs on VF intreface driver has to assume that VLAN HW Filtering
is always enabled and pass requests for adding or removing VLAN
tags to Physical Function driver using Mailbox API.
Signed-off-by: Krzysztof Galazka <krzysztof.galazka at intel.com>
Approved by: kbowling (mentor)
Reviewed by: erj (previous version)
Tested by: gowtham.kumar.ks_intel.com
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D53245
(cherry picked from commit 1839526b7315cae62efbd2d1493e6243439effcb)
pf: handle divert packets
In a divert setup pf_test_state() may return PF_PASS, but not set the state
pointer. We didn't handle that, and as a result crashed immediately afterwards
trying to dereference that NULL state pointer.
Add a test case to provoke the problem.
PR: 260867
MFC after: 2 weeks
Submitted by: Phil Budne <phil.budne at gmail.com>
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit 66f2f1c83247f05a3a599d7e88c7e7efbedd16b5)
if_ovpn: use IFT_TUNNEL
IFT_ENC has special behaviour in pf we don't desire, and this also ensures that
for all interface types there is N:1:1 correspondence between if_type:dlt:header len.
Requested by: glebius
MFC after: 1 week
(cherry picked from commit ff9f76a206c80c263050816735d537a151ee2999)
divert: Define semantics for SO_REUSEPORT_LB on divert sockets
Allow SO_REUSEPORT_LB to be set on divert sockets. If set, then bind()
will add the socket to a "load-balancing group". When a divert-to rule
matches a port with an associated group, the corresponding state ID is
used to select a specific socket from the group. Packets without an
associated state are simply forwarded to the first socket in the group.
This implementation is simple but has some caveats, the main one being
that if sockets are added to the group while flows are being processed,
the size of the group will change and this changes the mapping of state
IDs to sockets. So, to get a consistent mapping, the divert socket
application must bind all of its sockets before any traffic is processed
by pf.
pf: Rationalize the ip_divert_ptr test
If a rule has a divert port set, then we can reasonably predict that
ipdivert.ko is loaded, and in particular that ip_divert_ptr is set.
Moreover, in this case, if ipdivert.ko is not loaded we should just drop
the packet instead of ignoring the divert rule.
No functional change intended.
ipdivert: Use CK_SLISTs for the divcb hash table
The hash table is accessed in ip_divert_packet(), and there the accesses
are synchronized only by the net epoch, so plain SLIST is not safe.
pf: avoid passing through dummynet multiple times
In some setups we end up with multiple states created for a single
packet, which in turn can mean we run the packet through dummynet
multiple times. That's not expected or intended. Mark each packet when
it goes through dummynet, and do not pass packet through dummynet if
they're marked as having already passed through.
See also: https://redmine.pfsense.org/issues/14854
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D44365
pf: fix reply-to after rdr and dummynet
If we redirect a packet to localhost and it gets dummynet'd it may be
re-injected later (e.g. when delayed) which means it will be passed
through ip_input() again. ip_input() will then reject the packet because
it's directed to the loopback address, but did not arrive on a loopback
interface.
Fix this by having pf set the rcvif to V_iflo if we redirect to
loopback.
See also: https://redmine.pfsense.org/issues/15363
Sponsored by: Rubicon Communications, LLC ("Netgate")
pf: fix dummynet + route-to
Ensure that we pick the correct dummynet pipe (i.e. forward vs. reverse
direction) when applying route-to.
We mark the processing as outbound so that dummynet will re-inject in
the correct phase of processing after it's done with the packet, but
that will cause us to pick the wrong pipe number. Reverse them so that
the incorrect decision ends up picking the correct pipe.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D44366
pf: fix dummynet + route-to for IPv6
Apply the fixes from c6f1116357904 and b8ef285f6cc6a to IPv6 as well.
Ensure that when dummynet re-injects it does so in the correct direction, and
uses the correct dummynet pipes.
Sponsored by: Rubicon Communications, LLC ("Netgate")
pf: ensure dummynet gets the correct direction after route-to
If we apply a route-to to an inbound packet pf_route() may hand that
packet over to dummynet. Dummynet may then delay the packet, and later
re-inject it. This re-injection (in dummynet_send()) needs to know
if the packet was inbound or outbound, to call the correct path for
continued processing.
That's done based on the pf_pdesc we pass along (through
pf_dummynet_route() and pf_pdesc_to_dnflow()). In the case of pf_route()
on inbound packets that may be wrong, because we're called in the input
path, and didn't update pf_pdesc->dir.
This can manifest in issues with fragmented packets. For example, a
fragmented packet will be re-fragmented in pf_route(), and if dummynet
makes different decisions for some of the fragments (that is, it delays
some and allows others to pass through directly) this will break.
The packets that pass through dummynet without delay will be transmitted
[15 lines not shown]
Revert "pf: avoid passing through dummynet multiple times"
This reverts commit d8322a6ac465ffe2ef432a4b4d608afdd03150da.
There's no evidence this does anything so leave out changing
pf-dummynet code in this release iteration.
pf: fix reply-to after rdr and dummynet
If we redirect a packet to localhost and it gets dummynet'd it may be
re-injected later (e.g. when delayed) which means it will be passed
through ip_input() again. ip_input() will then reject the packet because
it's directed to the loopback address, but did not arrive on a loopback
interface.
Fix this by having pf set the rcvif to V_iflo if we redirect to
loopback.
See also: https://redmine.pfsense.org/issues/15363
Sponsored by: Rubicon Communications, LLC ("Netgate")
pf: fix dummynet + route-to for IPv6
Apply the fixes from c6f1116357904 and b8ef285f6cc6a to IPv6 as well.
Ensure that when dummynet re-injects it does so in the correct direction, and
uses the correct dummynet pipes.
Sponsored by: Rubicon Communications, LLC ("Netgate")
pf: fix dummynet + route-to
Ensure that we pick the correct dummynet pipe (i.e. forward vs. reverse
direction) when applying route-to.
We mark the processing as outbound so that dummynet will re-inject in
the correct phase of processing after it's done with the packet, but
that will cause us to pick the wrong pipe number. Reverse them so that
the incorrect decision ends up picking the correct pipe.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D44366
pf: ensure dummynet gets the correct direction after route-to
If we apply a route-to to an inbound packet pf_route() may hand that
packet over to dummynet. Dummynet may then delay the packet, and later
re-inject it. This re-injection (in dummynet_send()) needs to know
if the packet was inbound or outbound, to call the correct path for
continued processing.
That's done based on the pf_pdesc we pass along (through
pf_dummynet_route() and pf_pdesc_to_dnflow()). In the case of pf_route()
on inbound packets that may be wrong, because we're called in the input
path, and didn't update pf_pdesc->dir.
This can manifest in issues with fragmented packets. For example, a
fragmented packet will be re-fragmented in pf_route(), and if dummynet
makes different decisions for some of the fragments (that is, it delays
some and allows others to pass through directly) this will break.
The packets that pass through dummynet without delay will be transmitted
[15 lines not shown]
pf: avoid passing through dummynet multiple times
In some setups we end up with multiple states created for a single
packet, which in turn can mean we run the packet through dummynet
multiple times. That's not expected or intended. Mark each packet when
it goes through dummynet, and do not pass packet through dummynet if
they're marked as having already passed through.
See also: https://redmine.pfsense.org/issues/14854
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D44365
pf: fix dummynet + route-to for IPv6
Apply the fixes from c6f1116357904 and b8ef285f6cc6a to IPv6 as well.
Ensure that when dummynet re-injects it does so in the correct direction, and
uses the correct dummynet pipes.
Sponsored by: Rubicon Communications, LLC ("Netgate")
pf: fix dummynet + route-to
Ensure that we pick the correct dummynet pipe (i.e. forward vs. reverse
direction) when applying route-to.
We mark the processing as outbound so that dummynet will re-inject in
the correct phase of processing after it's done with the packet, but
that will cause us to pick the wrong pipe number. Reverse them so that
the incorrect decision ends up picking the correct pipe.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D44366
