rtwn: explicitly configure RTS based on basic rates

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 r

rtwn: explicitly configure RTS based on basic rates

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

show more ...

rtwn: announce VHT support for RTL8812AU/RTL8821AU.

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

rtwn: announce VHT support for RTL8812AU/RTL8821AU.

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

show more ...

rtwn: enable VHT if it's configured in the device

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.

Different

rtwn: enable VHT if it's configured in the device

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

show more ...

rtwn: add support for register IO debugging

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

rtwn: add support for register IO debugging

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

show more ...

rtwn: create a new HAL routine for enabling STA mode beacon processing

For some NICs (notably the rtl8192cu that I'm working on) the
firmware rate adaptation requires beacon processing to be enabled

rtwn: create a new HAL routine for enabling STA mode beacon processing

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

show more ...

rtwn: add a default OFDM / CCK rate for self-generated frames

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 i

rtwn: add a default OFDM / CCK rate for self-generated frames

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

show more ...

rtwn: update rtwn_get_rates() to separate out the CCK/OFDM and HT rates

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 leg

rtwn: update rtwn_get_rates() to separate out the CCK/OFDM and HT rates

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

show more ...

rtwn: add APIs for setting transmit power

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 trans

rtwn: add APIs for setting transmit power

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

show more ...

rtwn: add missing iv_ampdu_limit

This explicitly sets it rather than defaulting to the RX value.

Differential Revision: https://reviews.freebsd.org/D47895

rtwn: don't do 64 bit TSF extension by default

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. The

rtwn: don't do 64 bit TSF extension by default

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

show more ...

rtwn: remove the conditional compilation around the sc_ht40 option.

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 se

rtwn: remove the conditional compilation around the sc_ht40 option.

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

show more ...

rtwn: enable receiving AMSDU in AMPDU

All of the supported NICs should support this.

Locally tested:

* RTL8192CU, STA mode
* RTL8192EU, STA mode
* RTL8821AU, STA mode
* RTL8812AU, STA mode

Differ

rtwn: enable receiving AMSDU in AMPDU

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

show more ...

net80211: deal with lost state transitions

Since 5efea30f039c4 we can possibly lose a state transition which can
cause trouble further down the road.
The reproducer from 643d6dce6c1e can trigger the

net80211: deal with lost state transitions

Since 5efea30f039c4 we can possibly lose a state transition which can
cause trouble further down the road.
The reproducer from 643d6dce6c1e 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

show more ...

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

rtwn: clean up empty lines in .c and .h files

MFH

Sponsored by: Rubicon Communications, LLC (netgate.com)

net80211: enhance getflags*() and ieee80211_add_channel*()

For ieee80211_add_channel+*() we are passing in an int flag for
ht40 and in some cases another int flag for vht80 where we'd only
need two

net80211: enhance getflags*() and ieee80211_add_channel*()

For ieee80211_add_channel+*() we are passing in an int flag for
ht40 and in some cases another int flag for vht80 where we'd only
need two bits really.
Convert these variables to a bitflag and fold them together into one.
This also allows for VHT160 and VHT80P80 and whatever may come to
be considered. Define the various options currently needed.

Change the drivers (rtwn and rsu) which actually set this bit to non-0.
For convenience the "1" currently used for HT40 is preserved.

Enahnce getflags_5ghz() to handle the full set of VHT flags based
on the input flags from the the driver.

Update the regdomain implementation as well to make use of the new
flags and deal with higher [V]HT bandwidths.

ieee80211_add_channel() specifically did not take flags so it will
not support naything beyond 20Mhz channels.

Note: I am not entirely happy with the "cbw_flag[s]" name, but we
do use chan_flags elsewhere already.

MFC after: 2 weeks
Reviewed by: adrian, gnn
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential revision: https://reviews.freebsd.org/D26091

show more ...

MFHead@r345275

MFhead@r344996

Fix ieee80211_radiotap(9) usage in wireless drivers:

- Alignment issues:
* Add missing __packed attributes + padding across all drivers; in
most places there was an assumption that padding will be

Fix ieee80211_radiotap(9) usage in wireless drivers:

- Alignment issues:
* Add missing __packed attributes + padding across all drivers; in
most places there was an assumption that padding will be always
minimally suitable; in few places - e.g., in urtw(4) / rtwn(4) -
padding was just missing.
* Add __aligned(8) attribute for all Rx radiotap headers since they can
contain 64-bit TSF timestamp; it cannot appear in Tx radiotap headers, so
just drop the attribute here. Refresh ieee80211_radiotap(9) man page
accordingly.

- Since net80211 automatically updates channel frequency / flags in
ieee80211_radiotap_chan_change() drop duplicate setup for these fields
in drivers.

Tested with Netgear WG111 v3 (urtw(4)), STA mode.

MFC after: 2 weeks

show more ...

Merge ^/head r343320 through r343570.

Remove 2GHz channel list copies from wireless drivers.

Wrap ieee80211_add_channel_list_2ghz into another function
which supplies default (1-14) channel list to it and drop
its copies from drivers.

Remove 2GHz channel list copies from wireless drivers.

Wrap ieee80211_add_channel_list_2ghz into another function
which supplies default (1-14) channel list to it and drop
its copies from drivers.

Checked with RTL8188EE, country US / JP / KR / UA.

MFC after: 2 weeks

show more ...

Merge ^/head r327341 through r327623.

[net80211] convert all of the WME use over to a temporary copy of WME info.

This removes the direct WME info access in the ieee80211com struct and instead
provides a method of fetching the data. Ri

[net80211] convert all of the WME use over to a temporary copy of WME info.

This removes the direct WME info access in the ieee80211com struct and instead
provides a method of fetching the data. Right now it's a no-op but eventually
it'll turn into a per-VAP method for drivers that support it (eg iwn, iwm,
upcoming ath10k work) as things like p2p support require this kind of behaviour.

Tested:

* ath(4), STA and AP mode

TODO:

* yes, this is slightly stack size-y, but it is an important first step
to get drivers migrated over to a sensible WME API. A lot of per-phy things
need to be converted to per-VAP before P2P, 11ac firmware, etc stuff shows up.

show more ...

Merge ^/head r318964 through r319164.