For some NICs (notably the rtl8192cu that I'm working on) the
firmware rate adaptation requires beacon processing to be enabled.
Instead of making assumptions in the if_rtwn beacon routines (and
honestly all of that should be in the HAL too), create a HAL method
for enabling/disabling beacon processing specifically in STA mode.
Since this isn't necessarily required for all NICs (notably the RTL8188E
NICs, where some will do firmware rate control and some will require
driver rate control), only enable it for the RTL8192CU and RT8192EU.
The RTL8188E and RTL8812/RTL8821 just have no-op routines for now.
Locally tested:
* RTL8192CU, STA mode
Differential Revision: https://reviews.freebsd.org/D48066
Reviewed by: bz
Flags should not propagate from the lower fs. Behavior for the upper fs
is determined by flags from its mount point structure. When lower fs
acts according to its mount configuration, it is reported up as VOP
errors.
PR: 283425
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D48150
Add the missing bus_add_child DEVMETHOD. This is needed for the RPi5
running with a MMCCAM kernel and the worproject/rpi5-uefi to avoid a
kernel panic on boot when SDIO tries to attach to a 'Intel Bay Trail'
controller.
Reviewed by: imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D48152
When null_add_child() panics add the bus device name/unit and the new
unit as this will immediately reveal the parent missing the
DEVMETHOD(bus_add_child, ...)
entry.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D48151
The original commit was missing a space between two words due to
uncareful string line wrapping; let the string run beyond the 80 char
limit in order to also make it grep-able [1].
Reported by: jrtc27, Chris Torek (chris.torek gmail.com)
Suggested by: emaste, imp [1]
Sponsored by: The FreeBSD Foundation
Fixes: 87e140a5c6 avoid (hard) hang on loading module
MFC after: 3 days
X-MFC with: 87e140a5c6
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D48155
The FUSE_NO_OPEN_SUPPORT and FUSE_NO_OPENDIR_SUPPORT flags
are only meant to indicate kernel features, and should be ignored
if they appear in the FUSE_INIT reply flags.
Also fix the corresponding test cases.
MFC after: 2 weeks
Reviewed by: Alan Somers <asomers@FreeBSD.org>
Signed-off-by: CismonX <admin@cismon.net>
Pull Request: https://github.com/freebsd/freebsd-src/pull/1509
The rate control message was doing 11g+11n without 11b rates, but
the TX descriptor setup supports also falling back on 11b rates
when doing multi-rate retry / per-descriptor rate control.
So, line them up. They're not exactly the same as the TX path
supports pure-N and pure-G modes which the rate control configuration
does not, but there'll need to be a lot more work on supporting
those operating modes anyway (around things like self-generated
frame rate control/masks, beacon config, RTS/CTS selection, etc.)
Locally tested:
* RTL8192CU, STA mode
Differential Revision: https://reviews.freebsd.org/D48081
Reviewed by: bz
I'm unable to reproduce the original problem with my RTL8192CU USB
devices with the current codebase and I can't find any reference
to what this power register is doing - I see it defined in drivers,
but it's not described or used anywhere.
This reverts 7f74097165 -
rtwn_usb(4): fix Tx instability with RTL8192CU chipsets
In any case being able to do higher rate RTS/CTS is beneficial.
Local testing:
* rtl8192cu, STA mode, TX/RX testing
PR: 233949
Differential Revision: https://reviews.freebsd.org/D48026
Reviewed by: imp
I noticed during testing that the MAC was generating MCS7 ACKs and
MCS7 block-ACK frames in response to MCS frames from its peer.
This is very suboptimal - it means that unless you're very close
to your peer (in this case a 2GHz AP), you'll end up failing a lot
of ACKs.
Linux faced the opposite problem in rtl8xxxu - the rate set being
programmed in here included a lot MORE rates, including MCS 0->7
and OFDM 6M->54M. This meant that they were INTENTIONALLY telling
the hardware to transmit at higher rates, and their fix was to
mask out the higher rates so self-generated frames don't try the
high rates at all.
Now, I am not sure why I'm not seeing any OFDM or HT basic rates.
We don't mark any OFDM / HT rates as basic in net80211 (in
ieee80211_phy.c) so I'm going to need to go and do a review of the
standard to see what's up. Additionally, the HT rate set that we
populate isn't tagging any of the HT rates as IEEE80211_RATE_BASIC,
so the code I added for now is a no-op.
So:
* Extend rtwn_get_rates() and its consumers to populate the HT rateset
with basic rates if they're provided
* Add a default 2GHz / 5GHz mask, inspired by linux, applied over the
basic rates provided.
* Make sure there's at least an OFDM rate (for 2G/5G) rate available if
the peer node is HT, which avoids the MAC defaulting to MCS7 when
generating ACK/block-ACK.
* Add register definitions for INIDATA/INIRTS, which set the default
data rate when the driver doesn't specify the initial data / RTS/CTS
rates in the TX descriptor.
* Leave a comment about why I've modified the mask from Linux.
Locally tested:
* RTL8192CU, STA mode
* RTL8188EU, STA mode
* RTL8192EU, STA mode
* RTL8812AU, STA mode
Differential Revision: https://reviews.freebsd.org/D48019
Reviewed by: bz
Maintain lock ordering in ip_fw2.c by tracking any nested locking
using a flag, and then executing the locking in the correct order.
Reported by: Jimmy Zhang
Obtained from: Jimmy Zhang
Sponsored by: NetApp, Inc.
Reviewed By: glebius, ae
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D48069
Driver defined all flow context actions in MLX5_FLOW_CONTEXT_ACTION_*,
no need to duplicate them with mlx5_rule_fwd_action.
Sponsored by: NVidia networking
MFC after: 1 week
The 32 bit bitmap is enough for CCK/OFDM rates and MCS0..15, but
won't work for > MCS15, nor VHT rates.
So, break out the legacy rates and HT rates.
* break the rates and htrates out
* document which calls are looking up basic rates and which care
about the rates themselves
* ensure the rate bitmap passed into the rate control firmware call
(which isn't enabled yet!) is capped at 28 bits so they don't
set the mode field.
Differential Revision: https://reviews.freebsd.org/D47993
Reviewed by: bz, imp
This should be a *9 rather than a *10 so higher stream MCS rates
(eg comparing MCS0 and MCS8) that have slightly longer average transmit
times (but better burst transmit times) get considered.
This mirrors what the later code does when considering if a rate
change is needed.
Locally tested:
* AR9280, AP mode
* AR9380, AP mode
Differential Revision: https://reviews.freebsd.org/D47988
Reviewed by: imp
This is an attempt to reverse engineer what the actual transmit power
calculations are doing and apply net80211 limits on them. It doesn't
look as simple as just applying the check at the end - there are plenty
of places where offsets are calculated between different PHY modes and
1 / 2 antenna MCS transmit rates.
There are also some places where the offset being added is negative,
so handle the potential underflow so when things hit 0, they don't
just wrap and cause the maximum transmit power into the registers.
This is being done to aide in power/performance debugging - if there
are issues with the transmit power being wrongly calculated and are too
high, the output waveform will be distorted and it will effect performance.
Being able to drop the transmit power by a few dB here and there can
quickly identify if this is happening (because suddenly higher MCS
rates / OFDM rates suddenly work better!)
I've tested each NIC through the transmit power values from 0 dBm
to 30dBm via ifconfig (and they're all capped far before that,
normally around 20-25dBm) and they're not underflowing.
Locally tested:
* RTL8192CU, STA
* RTL8192EU, STA
* RTL8188EU, STA
Differential Revision: https://reviews.freebsd.org/D47987
Reviewed by: bz, imp
* Refactor out the TX power register register dump - it's done in
a couple places and it makes sense to refactor it.
* Condense the output into a few lines per transmit chain. It's
very long with the 8 and 16 MCS rates, and it made it difficult
to eyeball what's going on when tweaking TX power.
Differential Revision: https://reviews.freebsd.org/D47986
Reviewed by: bz, imp
The RTL8188/RTL8192/RTL8821/RTL8812 NICs all seem happy to have
their transmit power changed at runtime - and it does seem to do
what's expected - the transmit power level does change.
So, add the API call here, even though it's all currently no-ops.
A follow-up commit will land changes for the chipsets to both
limit transmit power to the configured / regulatory limit AND
allow reconfiguration at runtime.
Differential Revision: https://reviews.freebsd.org/D47979
Reviewed by: bz, imp
This apparently kicks off TX power level self-calibration, which
can't hurt.
Locally tested:
* RTL8812AU, STA
* RTL8821AU, STA
Obtained from: Linux rtw88
Differential Revision: https://reviews.freebsd.org/D47978
Reviewed by: bz, imp
When a DCO client reconnects (e.g. on server restart) OpenVPN may create a new
socket rather than reusing the existing one. This used to be rejected because we
expect all peers to use the same socket. However, if there are no peers it's
safe to release the previous socket and install the tunnel function on the new
one.
See also: https://redmine.pfsense.org/issues/15928
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
It is not implemented, and most likely cannot be, in a robust manner.
Reviewed by: Ariel Ehrenberg <aehrenberg@nvidia.com>, slavash
Sponsored by: NVidia networking
Otherwise this matches any two-character status except for ok.
Fixes: e5e94d2de9 ("Expand OpenFirmware API with ofw_bus_node_status_okay method")
MFC after: 1 week
As per RFC (RFC4960 section 3.3.7) an ABORT terminates the connection fully. We
should mode the state to CLOSED rather than CLOSING.
Suggested by: Oliver Thomas
See also: https://redmine.pfsense.org/issues/15924
Sponsored by: Rubicon Communications, LLC ("Netgate")
In 371bd29d4b we fixed a state key leak, but unintentionally introduced a double free.
We pass through the relevant code twice, first for PF_SK_WIRE, then for
PF_SK_STACK. If we fail to attach on the second pass we have a more complex
cleanup job, handled by pf_detach_state(). We must only free the state keys
manually on the first pass, on the second one pf_detach_state() takes care of
everything.
Tested by: yds <yds@Necessitu.de>
Fixes: 371bd29d4b
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
In the time these have lingered in my tree, we've started to drop the
__FBSDID tags. Make sure we're using SPDX tags (and the correct one)
as well.
Reported by: mhorne
This macro has not been in use since commit "inline atomics and allow tied
modules to inline locks" (r335873, f4b3640475).
Reviewed by: markj, kib, emaste, imp
MFC after: 5 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48061
grant_supplementary_group_from_flags() had been used in previous
versions of the recent changes, but recently has not been needed
anymore. It has been kept around just in case deliberately, by analogy
with grant_primary_group_from_flags() (this one still being used).
Some limited support for later multi-die SoC is included, but not at all
tested and not expected to be functional yet. kevans needs to finish
getting his serial boards constructed, as the beefiest AS machine that
actually has multiple die to support in his fleet is currently a
dedicated serial console.
Reviewed by: andrew
Co-authored-by: Andrew Turner <andrew@FreeBSD.org>
Co-authored-by: Mike Karels <karels@FreeBSD.org>
Differential Revision: https://reviews.freebsd.org/D48079
Ensure it's disarmed upon attach, provide basic reset functionality.
Register definitions/usage obtained from OpenBSD.
Reviewed by: ray
Differential Revision: https://reviews.freebsd.org/D39824
Add reset controller driver for Eswin EIC7700.
This one has two reset cells in FDT, which is unusual, so provide a
custom hwreset_map method.
Tested on SiFive Premier P550.
Reviewed by: mhorne, jrtc27
Differential Revision: https://reviews.freebsd.org/D47853
Eswin EIC7700 has non-coherent DMAs but predate the standard RISC-V Zicbom
extension, so we need to use the SiFive CCache controller for non-standard
cache management operations.
Tested on SiFive Premier P550.
Reviewed by: mhorne, jrtc27
Differential Revision: https://reviews.freebsd.org/D47831
Check if RISC-V SSTC is available and advertise to the guest.
This is needed for Eswin EIC7700 that does not include SSTC.
As we don't have a mechanism for reporting extension presence
from the kernel to userspace, then use vm_cap_type for now.
Reviewed by: mhorne, markj
Differential Revision: https://reviews.freebsd.org/D48058
For IPv4 it's valid for a UDP checksum to be 0 (i.e. no checksum). This isn't
the case for IPv6, so if we translate a UDP packet from IPv4 to IPv6 we need to
ensure that the checksum is calculated.
Add a test case to verify this. Rework the server jail so it can listen for TCP
and UDP packets at the same time.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Pass the new address family rather than the incoming one. In most (i.e. all but
nat64) that's the same, but for nat64 we want the new address family instead.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Apply the fixes from c6f1116357 and b8ef285f6c 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")
We do multiple lookups during the nat64 process, some of which will fail due
to address family mismatches. Do not reset the lookup offset so we actually use
different addresses from the table.
Sponsored by: Rubicon Communications, LLC ("Netgate")
When translating packets from one address family to another, pass the
TOS/Traffic Class field of the original packet. Discussed with mikeb@
Obtained from: OpenBSD, jca <jca@openbsd.org>, fd92f2bb4f
Sponsored by: Rubicon Communications, LLC ("Netgate")
When we reassemble IPv4 packets tag them just like we tag the IPv6 reassembled
packtes. Use this information as the basis for refragmenting the IPv6 packet.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D47804
Ensure that the packet length we track in struct pf_pdesc matches the
reassembled packet size.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D47803
Just as with reply-to rules we don't know what interface we will send this out
of until we create the state. Create new nat64 rules as floating, but bind them
to the appropriate interface on the first pf_route(), when we do know.
Set state policy if-bound for the nat64 tests to validate this.
See also: 6460322a0
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D47801
The general syntax is:
pass in inet from any to 192.168.1.1 af-to inet6 from 2001::1 to 2001::2
In the NAT64 case the "to" is not needed in af-to and the IP is extraced
from the IPv6 dst (assuming a /64 prefix).
Again most work by sperreault@, mikeb@ and reyk@
OK mcbride@, put it in deraadt@
Obtained from: OpenBSD, claudio <claudio@openbsd.org>, 0cde32ce3f
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D47790
If we can't map ICMPv4 onto ICMPv6 or vice versa drop the packet rather than
continuing with an untranslated packet.
Sponsored by: Rubicon Communications, LLC ("Netgate")
