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
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
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 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
* add a register value for the R92C_FPGA0_POWER_SAVE register
* add the field names and mask
* add a mask for the 40MHz upper/lower bits in R92C_RMRR; I think
I need to debug and overhaul the 20/40MHz config path to get 40MHz
working right.
Local testing:
* rtl8188eu, sta mode
* rtl8192cu, sta mode
* RX frames with short-GI can be either HT or VHT
* Add placeholders for RX VHT rate, PHY type, etc
Differential Revision: https://reviews.freebsd.org/D47902
After discussion with the rtlwifi maintainers, it looks like this
path isn't even used.
(And it's part of the firmware rate control path which we currently
don't enable for other reasons.)
Differential Revision: https://reviews.freebsd.org/D47938
This is needed to be able to successfully transmit VHT frames.
Locally tested:
* RTL8821AU, STA mode (with the rest of VHT work to actually test VHT)
Differential Revision: https://reviews.freebsd.org/D47899
The VHT rate power array wasn't populated, and it needs to be in order
to use VHT rates.
The vendor driver reuses the HT40 values for VHT rates.
Differential Revision: https://reviews.freebsd.org/D47898
In preparation for the VHT TX power programming, refactor out the
CCK, OFDM and HT programming into their own routines.
Locally tested:
* RTL8821AU, STA mode
* expand the ridx field all the way through 4x4 11n (MCS0..MCS31)
* and then expand it through VHT 4x4 (MCS0..9 for each stream)
* add accessor macros to check if the rate is HT, VHT
* use accessor macros to check if the rate is HT rather than
comparing it against OFDM54 or RIDX_HT_MCS(0); the values
aobve HT MCS will be VHT, and we don't want to trigger on those!
* add a couple of appropriate TODO VHT bits in the TX path
Locally tested:
* RTL8192CU, STA mode
* RTL8188EU, STA mode
* RTL8821AU, STA mode
* RTL8192EU, STA mode
Differential Revision: https://reviews.freebsd.org/D47896
Some chipsets (such as the RTL8188E) have firmware which supports
a second kind of TX report - instead of a per-packet TX report,
it can generate a per-MACID summary of packet success/failure counters.
This would be helpful for those chips to cut back on the USB traffic
to get rate control feedback for the driver based rate control we're
currently using.
This is a no-op; it just gets the pieces in place for future work.
Differential Revision: https://reviews.freebsd.org/D47894
HT40 works fine in 2GHz and 5GHz modes in both 1 and 2 stream
scenarios, so just enable it here.
Differential Revision: https://reviews.freebsd.org/D47874
Using ieee80211_ht_check_tx_ht40() means that not only the
bss and node channel are checked, but the ni_chw value is also
now correctly checked.
Differential Revision: https://reviews.freebsd.org/D47862
The TSF64 extension involves at least 3 reads from TSF registers
(R92C_TSFTR(0), R92C_TSFTR(1), R92C_TSFTR(2)) which are 4 byte
control transfers. They take up valuable USB link time.
It's likely much less expensive for PCIe adapters. At some point
it may be worthwhile enabling it by default just for those.
With this disabled, the only USB traffic that I see during
normal data operation are bulk TX/RX data transfers for 802.11
packets, and on NICs w/ net80211 rate control, the control register
space read/writes for TX completion. (And that will also need
addressing.)
This is the difference between 15mbit TCP RX and 30mbit TCP RX
on the 11n NICs, and around 40 to 50mbit TCP RX on the 11ac NICs
in HT40 and VHT80.
Locally tested:
* RTL8188EU, STA mode
* RTL8192CU, STA mode
* RTL8192EU, STA mode
* RTL8811AU, STA mode
* RTL8821AU, STA mode
Differential Revision: https://reviews.freebsd.org/D47861
This option stems from a bunch of issues a long time ago where HT40
support on some NICs is unstable - likely because we're not setting
up the RF/baseband correctly.
In any case, it doesn't need to be conditionally compiled anymore.
Leave it in, leave it off by default, and various chipset initialisation
paths can decide whether to enable it themselves.
Reviewed by: emaste
All of the supported NICs should support this.
Locally tested:
* RTL8192CU, STA mode
* RTL8192EU, STA mode
* RTL8821AU, STA mode
* RTL8812AU, STA mode
Differential Revision: https://reviews.freebsd.org/D47776
I noticed that on RTL8812AU/RTL8821AU receiving VHT frames that
I'd occasionally see frames missing the last 4 bytes. I can
easily reproduce it with a ping sweep and fast (10ms) between frames.
There's also a report of an earlier NIC (RTL8188EU) doing the same
thing with HT frames but not with OFDM (11g) frames.
After a bunch of poking, it turns out a driver where things DID work
properly for the other report kept FCS enabled, and trimmed it from
the frame before pushing it up to the network layer.
I did the same and it also worked fine.
The other solution was to disable PHYSTATUS notifications, but then
we'd get no per packet RX notifications (RX rate, RSSI, etc.)
Locally tested:
* RTL8192EU, STA mode (HT)
* RTL8812AU, STA mode (HT, VHT)
* RTL8821AU, STA mode (HT, VHT)
Differential Revision: https://reviews.freebsd.org/D47775
* Add support for 80MHz channels during IQ calibration
* Correct the RAID flags for 1 and 2 stream VHT - the later ones
are for 2GHz VHT and then 3/4 stream VHT
* Add VHT to the RAID calculation for when we eventually transmit
VHT rates.
Obtained from: Linux rtw88 (https://github.com/lwfinger/rtw88)
Differential Revision: https://reviews.freebsd.org/D47774
* use ieee80211_ht_get_node_ampdu_density() now instead of the
vap->iv_ampdu_density, so the correct density is used in AP/IBSS/mesh
modes.
* MAX_AGG controls how many frames are to be sent in an A-MPDU.
It maps to ((MAX_AGG * 2) + 1) == npackets. 0x1f (31) means
64 packets. So, instead of hard-coding 0x1f, use the negotiated
block-ack window size.
Differential Revision: https://reviews.freebsd.org/D47766
Use the new net80211 routines rather than rolling our own.
(The first version of this diff landed a previous version of what was
reviewed, so this brings it up to what was finally accepted in the
review.)
Differential Revision: https://reviews.freebsd.org/D47751
Reviewed by: bz
I found I was getting constant device timeouts when doing anything
more complicated than a single SSH on laptop with RTL8811AU.
After digging into it, i found a variety of fun situations, including
traffic stalls that would recover w/ a shorter (1 second) USB transfer
timeout. However, the big one is a straight up hang of any TX endpoint
until the NIC was reset. The RX side kept going just fine; only the
TX endpoints would hang.
Reproducing it was easy - just start up a couple of traffic streams
on different WME AC's - eg a best effort + bulk transfer, like
browsing the web and doing an ssh clone - throw in a ping -i 0.1
to your gateway, and it would very quickly hit device timeouts every
couple of seconds.
I put everything into a single TX EP and the hangs went away.
Well, mostly.
So after some MORE digging, I found that this driver isn't checking
if the transfers are going into the correct EPs for the packet
WME access category / 802.11 TID; and would frequently be able
to schedule multiple transfers into the same endpoint.
Then there's a second problem - there's an array of endpoints
used for setting up the USB device, with .endpoint = UE_ADDR_ANY,
however they're also being setup with the same endpoint configured
in multiple transfer configs. Eg, a NIC with 3 or 4 bulk TX endpoints
will configure the BK and BE endpoints with the same physical endpoint
ID. This also leads to timed out transfers.
My /guess/ was that the firmware isn't happy with one or both of the
above, and so I solved both.
* drop the USB transfer timeout to 1 second, not 5 seconds -
that way we'll either get a 1 second traffic pause and USB transfer
failure, or a 5 second device timeout. Having both the TX timeout
and the USB transfer timeout made recovery from a USB transfer
timeout (without a NIC reset) almost impossible.
* enforce one transfer per endpoint;
* separate pending/active buffer tracking per endpoint;
* each endpoint now has its own TX callback to make sure the queue /
end point ID is known;
* and only frames from a given endpoint pending queue is going
into the active queue and into that endpoint.
* Finally, create a local wme2qid array and populate it with the
endpoint mapping that ensures unique physical endpoint use.
Locally tested:
* rtl8812AU, 11n STA mode
* rtl8192EU, 11n STA mode (with diffs to fix the channel config / power
timeouts.)
Differential Revision: https://reviews.freebsd.org/D47522
Don't schedule work during reset / abort. For USB NICs, work
must not be scheduled during a call to rtwn_usb_abort_xfers(),
as then it'll cause the call to usbd_transfer_drain() to hang.
This fixes a hang I've been seeing where the NIC hits a TX timeout
and then the reset/re-init path is called. If data is scheduled
to be transmitted in that window, the call to usbd_transfer_drain()
would hang and require a hard reboot to recover.
Differential Revision: https://reviews.freebsd.org/D47479
The way that net80211 and drivers are checking for the /type/ of key
is to check if it's in the vap WEP key array and if so, it's a group
key. If not, it's a unicast key.
That's not only kind of terrible, but it's also going to be
problematic with future 802.11 support (for multiple unicast keys
and IGTK keys for management frame protection.)
So as part of this, remove the places where this is done and
instead use a pair inline functions - ieee80211_is_key_global() and
ieee80211_is_key_unicast(). They currenly still use the same logic
but the drivers and net80211 stack isn't doing it itself.
There are still open questions about why keys are not being
correctly tagged as GROUP, GTK, PTK, etc. That will be investigated
and addressed in follow-up work as a pre-cursor to MFP, IGTK, etc.
as mentioned above.
Testing:
* iwn, rtwn - STA mode
Differential Revision: https://reviews.freebsd.org/D45516
Since 5efea30f03 we can possibly lose a state transition which can
cause trouble further down the road.
The reproducer from 643d6dce6c can trigger these for example.
Drivers for firmware based wireless cards have worked around some of
this (and other) problems in the past.
Add an array of tasks rather than a single one as we would simply
get npending > 1 and lose order with other tasks. Try to keep state
changes updated as queued in case we end up with more than one at a
time. While this is not ideal either (call it a hack) it will sort
the problem for now.
We will queue in ieee80211_new_state_locked() and do checks there
and dequeue in ieee80211_newstate_cb().
If we still overrun the (currently) 8 slots we will drop the state
change rather than overwrite the last one.
When dequeing we will update iv_nstate and keep it around for historic
reasons for the moment.
The longer term we should make the callers of
ieee80211_new_state[_locked]() actually use the returned errors
and act appropriately but that will touch a lot more places and
drivers (possibly incl. changed behaviour for ioctls).
rtwn(4) and rum(4) should probably be revisted and net80211 internals
removed (for rum(4) at least the current logic still seems prone to
races).
PR: 271979, 271988, 275255, 263613, 274003
Sponsored by: The FreeBSD Foundation (in 2023)
MFC after: 3 days
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43389
This reverts commit b65f813c1a.
As a side effect this also seems to fix wtap which seems to have
lost the epoch over the input path in between.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.
Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/
Sponsored by: Netflix
Both rwlwifi in Linux and rtwn in OpenBSD restore this register,
and the existing code was saving the value and not using it.
Reported by: -Wunused-but-set-variable
Reviewed by: imp
Obtained from: OpenBSD
Differential Revision: https://reviews.freebsd.org/D34838
