| Age | Commit message (Collapse) | Author |
|---|
|
Migrate to the ieee80211_crypto_key_*() routines.
Should be no functional change.
Locally tested:
* RTL8821AU, STA mode
Differential Revision: https://reviews.freebsd.org/D52712
|
|
the firmware should be sending these.
Differential Revision: https://reviews.freebsd.org/D52298
Reviewed by: bz
Locally tested:
* rtl8821/rtl8812au (STA)
|
|
This should both enable the sequence number offloading and disable
the net80211 TX lock from being acquired/released/checked.
Locally tested:
* RTL8812AU, STA mode
Reviewed by: bz
Differential Revision: https://reviews.freebsd.org/D52301
Differential Revision: https://reviews.freebsd.org/D50693
|
|
The initial thought of migrating the LinuxKPI 802.11 enum into net80211
for shared use did not work out well. Currently in the need for yet
another adjustment, I decided to undo/de-couple net80211 and
LinuxKPI 802.11 again.
The enum name now gets used in LinuxKPI based wifi drivers and it
turns out it is spelt differntly than what I used initially.
This creates a conflict.
net80211 still in the need to be able to express BW_320 in an uint8_t
will likely be fine with the current solution as well. Rename the
enum and prefixes in net80211 to "net80211" instead of "ieee80211".
Apart from the names/prefix we leave the values the same.
In LinuxKPI add the enum with the expected name and use it there
throughout to make modern versions of LinuxKPI based wifi drivers
compile.
Sponsored by: The FreeBSD Foundation
Fixes: ca389486a9599, 2c8b0d6205f6f
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D52064
|
|
We can and do receive > 4 KiB frames in the RX path (A-MSDU frames
can be up to 11KiB.) At least one user has reported seeing this
and having it break their traffic flows.
Use m_get3() to try and grab an mbuf jumbo cluster.
This may not be the best permanent solution, but it at least will
fail for frame sizes we expect to see up and including the largest
A-MPDU frame (11Kib) and keep a counter if it can't allocate, versus
just returning NULL because it's too large (and not keeping counters.)
Differential Revision: https://reviews.freebsd.org/D50049
PR: kern/286366
Reviewed by: bz
|
|
jrtc27@freebsd.org reported that DHCP wasn't working on some
networks. She dug into it and found that the RTL8812AU/RTL8812AU
NICs seem to be failing UDP frames w/ a zero checksum, which is
a valid "there's no checksum" checksum.
So, just pass those frames up the stack and let the IP stack
deal with it. If the hardware claims the frames did pass TCP/UDP
checksum then still mark those frames with the checksum offload
bits.
PR: kern/285387
Differential Revision: https://reviews.freebsd.org/D49628
|
|
The RX filter wasn't enabling BAR frames, so we weren't receiving them
during normal operation.
Jessica noticed we WERE getting BAR frames, but only when promisc mode
is active. Which is a different set of bugs, but it did highlight
the differences here.
Differential Revision: https://reviews.freebsd.org/D49596
PR: kern/285822
|
|
I'm testing this with rtwn(4) NICs right now, so enable it here.
Locally tested:
* RTL8812AU / RTL8821AU, STA mode (with some wpa_supplicant.conf
shenanigans to force GCMP as the pairwise key to an OpenWRT AP
configured to use GCMP but without requiring MFP.)
Differential Revision: https://reviews.freebsd.org/D49190
Reviewed by: bz
|
|
Migrate the transmit path to use ieee80211_node_get_txrate(), and handle
VHT rates.
Nothing is currently setting VHT rates, but the driver should now
be ready.
Differential Revision: https://reviews.freebsd.org/D48606
Reviewed by: bz
|
|
This just mechanically converts things.
* For linuxkpi, it was just used for display.
* For uath, it was just used for display, as firmware
doesn't report it up.
Differential Revision: https://reviews.freebsd.org/D48602
Reviewed by: bz, thj
|
|
It /looks/ like there's some weirdness in initial frame send after
the chip programming / channel change. Linux rtl8xxxu has no sleeps
here, instead it just retries the auth frame a few times.
My guess is there's some sequencing going on here between finishing
the programming, doing a calibration run and then sending the initial
frame.
Instead of doing sleeps on every write during the RF channel change,
this 10ms sleep at the end is enough to reliably associate in my
test environment (12-core intel laptop, USB-3 port.) It's not
required for an earlier 2-core haswell laptop w/ USB-3.
See the PR for more information.
PR: kern/247528
Differential Revision: https://reviews.freebsd.org/D48517
|
|
The Linux rtl8xxxu driver has more delays in the RF read and write
path.
It looks like for writes it's ensuring the hardware is out of
power save and that the transition has properly occured.
And it looks for reads that it wants a delay after some bit setting,
likely some shifting into the RF register space is occuring with
a bit set/clear to trigger a load.
See rtl8xxxu_write_rfreg() and rtl8xxxu_read_rfreg() for more
information.
Differential Revision: https://reviews.freebsd.org/D48512
Obtained from: Linux rtl8xxxu
|
|
The RTL8192EU NIC (on older USB 2/USB 3 ports, not on newer
USB 3 ports, that still needs to be fixed!) will attach, scan,
associate fine. However, restarting wpa_supplicant results in the
NIC hanging until you disconnect it.
It turns out early in the power_on sequence - BUT only after a
power_off - the NIC would suddenly stop responding to any USB
transfers. It doesn't require the MCU to be available for USB
transfers - the hardware itself does that - so something had to be
going very sideways.
I traced it down to these steps during the power_off sequence.
They don't exist in the Linux rtl8xxxu driver, and there are commits
earlier in their RTL8192EU bring-up that suggest the author was
facing similar power sequencing / re-sequencing issues.
This likely won't fix the actual channel programming /
power sequencing / deafness issues on later USB-3 ports.
There are other commits / fixes in the rtl8xxxu driver related to
RTL8192EU bring-up that we don't have.
Differential Revision: https://reviews.freebsd.org/D48428
Obtained from: Linux rtl8xxxu driver
|
|
Although there's no RTS/CTS rate control available yet, the support
is enough to enable firmware rate control for experimenting.
This won't be enabled by default - users will need to set a tunable
before loading the driver (eg kenv dev.rtwn.0.ratectl=2) but it is
enough for experimentation, feedback and continued work.
Locally tested:
* RTL8192CU, STA mode
Differential Revision: https://reviews.freebsd.org/D48143
Reviewed by: bz, emaste
|
|
* refactor out the r92c path protection (RTS/CTS) decision
* handle firmware rate control being enabled - if DRVRATE isn't
set then the RTSRATE field is ignored and instead RRSR/INIRTS
registers are used (and the firmware/hardware will do RTS
rate adaptation / retry.)
* when making protection decisions with firmware rate control,
default to the channel mode rather than rate index.
This works on RTL8192CU both with firmware rate control and driver
rate control.
Locally tested:
* RTL8192CU, STA - firmware and net80211 rate control
Differential Revision: https://reviews.freebsd.org/D48142
|
|
Refactor out the datarate setup and short preamble setup.
These will eventually be slightly different based on whether
firmware rate control is being performed or not.
Locally tested:
* RTL8192CU, STA mode
Differential Revision: https://reviews.freebsd.org/D48141
|
|
The NIC/firmware initialises the initial RTS/CTS rate to something
high, like OFDM48. That's not going to be very reliable.
It's not a problem right now as we program in the RTS/CTS value
to use in the TX descriptor setup path based on the control rate
for the given frame TX rate, and like the INIDATA/driver rate
stuff in the TX descriptor, the TX descriptor RTS/CTS rate overrides
the INIRTS rate.
However when it's time to flip on firmware based rate control,
the initial rate needs to not be OFDM48. Yes, the firmware and
hardware does have some rate retry schedule for RTS/CTS frames,
but there's no point in wasting short retries trying to do OFDM48
based RTS/CTS setup.
Add some warning logging if there are no basic or RTS/CTS rates
available, and leave things at default. If this happens in
production for someone then it would be good to know and what
the rate mask was.
Locally tested:
* RTL8192CU, STA mode (with/without firmware rate control enabled locally)
Differential Revision: https://reviews.freebsd.org/D48140
|
|
Add parenthesis as appropriate. Oops!
|
|
Although the transmit path doesn't yet support VHT rates (because
the rate control and rate representation in net80211 doesn't yet
know about VHT rates) the NIC will receive VHT frames but only
transmit HT frames.
Locally tested:
* RTL8812AU, STA mode
Differential Revision: https://reviews.freebsd.org/D48103
|
|
Add a separate function and path for VHT 20/40/80MHz bandwidth
transmission.
Differential Revision: https://reviews.freebsd.org/D48102
|
|
The vendor driver sets it to 64k or 128k depending upon chipset,
along with bit 31 being set in hal/rtl8812a_hal_init.c:SetHwReg8812A().
Differential Revision: https://reviews.freebsd.org/D48118
Obtained from: https://github.com/lwfinger/rtl8812au
Reviewed by: bz
|
|
According to the rtl8812au reference driver, this seems to control
the bandwidth used by lower-bandwidth frames when transmitted in
a higher bandwidth channel. For example, transmitting a 20MHz frame
on an 80MHz channel (eg in hostap mode) is doable, but you may want
to at least duplicate the RTS/CTS exchange across all four 20MHz
subchannels, AND perhaps duplicate the 20MHz frame.
I haven't fired this up with a spectrum analyser to see what the
result is.
The vendor driver doesn't bother with this and it doesn't change
performance. My guess is that for modes like AP mode we MAY wantto
be able to control the RTS/CTS bandwidth choices rather than letting
the firmare do it, but we're not there yet.
The rtl8812au code in hal/rtl8812a_xmit.c:SCMapping_8812() has
the gory details, but then the one place it's used just has it
commented out and 0 (ie "do not care") is always programmed in.
Differential Revision: https://reviews.freebsd.org/D48113
Obtained from: https://github.com/lwfinger/rtl8812au
Reviewed by: bz
|
|
If the passed in rate is a VHT rate, use rtwn_ctl_vhtrate() to
find a suitable rate for RTS/CTS.
Differential Revision: https://reviews.freebsd.org/D48295
Reviewed by: bz, cy, emaste
|
|
When doing firmware rate control there will be situations where
the rate being passed in needs to actually override the rate
control selection. So add a flag to the descriptor setup path
to indicate that indeed this particular rate should be forced,
rather than rely on the firmware rate control.
This is currently a no-op as firmware rate control isn't working
in-tree, but it is working for me locally with other changes.
Without this, there's no way to force low rates for management,
DHCP traffic, and to allow fixed rate via "ifconfig wlanX ucastrate Y"
to function.
Locally tested:
* RTL8192CU, STA mode (firmware and driver/net80211 rate control)
Differential Revision: https://reviews.freebsd.org/D48100
Reviewed by: bz, gavin
|
|
If the driver attach path adds the VHT flag then add the 20/40/80 MHz
VHT channels.
This is a no-op right now as nothing is enabling it.
Differential Revision: https://reviews.freebsd.org/D48097
Reviewed by: bz
|
|
The powerpcspe build is spitting out uint64_t != unsigned long, so this
fails. Comment out the logging for now to unbreak the build.
|
|
The firmware version isn't enough; different firmware is loaded
for different revisions of a given chip. So print out the file too;
it'll make handling reports much easier.
Differential Revision: https://reviews.freebsd.org/D48067
Reviewed by: emaste
|
|
* remove the hard-coded ridx values in rate2ridx(), use the RIDX
defines for CCK/OFDM rates
* Add a placeholder rtwn_ctl_vhtrate() which returns the dot11rate
control rate to use for the given VHT rate index. Since net80211
currently doesn't have any VHT PHY tables, there's no mapping for
us to leverage so just return OFDM 12M for now.
* Use the new macro to convert rate index to MCS rate
* Add a printf() in rate2ridx if it's passed a HT/VHT rate.
Differential Revision: https://reviews.freebsd.org/D48098
Reviewed by: bz
|
|
This register (array) controls the initial rate to use for each
MACID. There's no need to set it if firmware rate control is enabled -
it'll actually be under firmware control (and we can read it back to
see what choices the firmware is making.)
Locally tested:
* RTL8188EU, STA
* RTL8192CU, STA
* RTL8192EU, STA
Differential Revision: https://reviews.freebsd.org/D48094
Reviewed by: bz
|
|
The RTL8188E firmware doesn't have the "full" offload firmware
rate control. Instead, the vendor driver has a bunch of logic
in the driver for rate probing and selection.
Part of this is the periodic TX report - which uploads a summary
of multi-rate retries and drops per MAC. Using it drastically
cuts down on the TX notifications - it's fired from a timer
(defaulting to ~ 1.6 seconds) and is a single receive frame in
the normal bulk RX path.
I've not ported / reimplemented the whole vendor driver rate adaption
code - instead, I'm just using the normal net80211 rate control APIs.
It seems to behave OK - I get 25-30mbit down and 20mbit up using TCP/
speedtest.
Locally tested:
* RTL8188EU, STA mode
Differential Revision: https://reviews.freebsd.org/D48088
Reviewed by: fuz, bz
Obtained from: https://github.com/lwfinger/rtl8188eu/blob/master/hal/Hal8188ERateAdaptive.c
|
|
Add support to read/write the MAC/PHY registers.
Hide it behind RTWN_DEBUG.
This doesn't cover the RF registers as they require a different
IO path, but I haven't yet debugged the RF paths.
Locally tested:
* RTL8192CU, STA
* RTL8188EU, STA
* RTL8812AU / RTL8821AU, STA
Differential Revision: https://reviews.freebsd.org/D48084
Reviewed by: bz
|
|
I've reviewed all of the linux vendor and upstream drivers.
This SEQ_SEL field isn't a mask and doesn't ever look like it
it was; instead this bit is set to tag QoS data frames.
In fact, it effectively was set to 0 for STA frames and potentially 1
for broadcast/multicast frames as the STA macid of 0 and broadcast/
multicast macid of 1 maps to that. In AP modes it would be tagged
based on bit 0.
So, bring it in line with the vendor and linux drivers.
Locally tested:
* RTL8192CU, STA, hostap
* RTL8188EU, STA
* RTL8192EU, STA
Differential Revision: https://reviews.freebsd.org/D48092
|
|
My previous commit meant that APPFCS wasn't enabled during monitor
mode and likely other corner cases.
Ensure it stays on at all times.
This, amusingly, fixes monitor mode in RTL8812AU/RTL8821AU - without it,
I don't see HT/VHT frames in monitor mode but I can still receive them
in normal STA mode.
Differential Revision: https://reviews.freebsd.org/D48112
|
|
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 7f740971658d71c1ee95ee68032b4696c1684845 -
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
|
|
Enable the short-GI flag configuring the rate mask.
Obtained from:
* Realtek vendor driver, rtl8192cu
Differential Revision: https://reviews.freebsd.org/D48013
Reviewed by: bz, imp
|
|
This is straight from all the drivers, linux and vendor.
Differential Revision: https://reviews.freebsd.org/D48004
Reviewed by: bz, imp
|
|
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
|
|
We should just keep the RX pipeline busy.
Differential Revision: https://reviews.freebsd.org/D47990
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
|
|
* 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
|
|
* add VHT80 channel programming
* add VHT80 spur management, sync with Linux rtw88
Obtained from: Linux rtw88
Differential Revision: https://reviews.freebsd.org/D47901
|
|
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
|
|
Since we're not doing 80+80 yet, this is easy - just use
the freq1 centre.
Differential Revision: https://reviews.freebsd.org/D47900
|
