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
net80211 node ni_chw currently encodes the channel width as Mhz number.
LinuxKPI 802.11 uses enum ieee80211_sta_rx_bw for the same.
Rather than keeping the "20" and "40" throughout the code (eventually
expanded to 80/160/320) switch them over to use the enum throughout
and add a print mask for debug output. While designed as bitmask it
is not supposed to be used as such; the bitmask is only used to be
able to use %b with a print mask.
Once we get to 320Mhz channel widths we would otherwise also need to
extend the uint8_t in struct ieee80211_node; making
enum ieee80211_sta_rx_bw __packed allows us for three more channel
widths without breaking the KBI (if we were not to use %b with a
print_mask but use a lookup function for the string we could extend
it for a long time).
Sponsored by: The FreeBSD Foundation
MFC after: 14 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D47891
Now that net80211 has this code, just leverage it instead of rolling
our own.
Differential Revision: https://reviews.freebsd.org/D47748
Reviewed by: bz
This will be useful when fixing up the sequence number generation
and checks, as the rules around how sequence numbers are generated
have been clarified in 802.11-2016 and later. QoS-NULL frames are
explicitly marked as "any sequence number".
But for now, just create a macro and use it in the one place
it's currently being used as a check - ath(4).
* Add IEEE80211_IS_QOS_NULL().
* Change the "will this frame go into the TX block-ack window" check
in the ath(4) transmit path. Note this changes the check to be
more specific, but both paths already had previous checks to ensure
they're QoS data frames.
Locally tested:
* ath(4), AR9380, STA mode w/ AMPDU TX/RX enabled and negotiated
Differential Revision: https://reviews.freebsd.org/D47645
* Add macros for the management and control frame type checks that
I've come across in the drivers.
* Delete some now old code (eg ath's ieee80211_is_action()) as there's now
a macro for it.
Local testing:
* not yet, I have a lot of wifi devices to find and test against
Differential Revision: https://reviews.freebsd.org/D47500
This fixes a clang 19 warning:
sys/dev/ath/ath_hal/ar9002/ar9285_btcoex.c:57:32: error: comparison of different enumeration types ('HAL_BOOL' and 'HAL_ANT_SETTING') [-Werror,-Wenum-compare]
57 | (AH5212(ah)->ah_diversity != HAL_ANT_VARIABLE)) {
| ~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~
The `ah_diversity` field of `struct ath_hal_5212` is of type `HAL_BOOL`,
not the enum type `HAL_ANT_SETTING`. In other code, `ah_diversity` is
set to `AH_TRUE` whenever the related field `ah_antControl` is set to
`HAL_ANT_VARIABLE`.
It is not entirely clear to me what the intended statement is here: the
test as it is written now compares the enum value 0 to `ah_diversity`,
so in effect it enables the following block whenever `ah_diversity` is
`AH_TRUE`. Write it like that, to avoid the compiler warning.
MFC after: 3 days
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
Enabling 11n for ath(4) so far was handled by a kernel option, which
was only enabled for certain kernel configurations.
In order to allow loading ath(4) as a module with 11n support on
all platforms, remove the kernel option and unconditionally enable
11n in ath(4).
Reported by: pkubaj
Discussed with: adrian in D43549.
Reviewed by: adrian, imp
Differential Revision: https://reviews.freebsd.org/D43964
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
ieee80211_node_incref() is the FreeBSD implementation of
ieee80211_ref_node(). Not being interested in the node returned
it was used as a shortcut in 3 drivers (ath, uath, wpi).
Replace the call with the public KPI of ieee80211_ref_node() and
ignore the result.
This leaves us with the single internal call going
ieee80211_ref_node() -> ieee80211_node_incref() and that should
help increasing portability but also limiting the places to trace
for node reference operations.
Sponsored by: The FreeBSD Foundation
MFC after: 4 weeks
All of these are obsoleted by the general removal of MIPS support.
Actually, corresponding to the removed AH_SUPPORT_x, there is more
superfluous support sprinkled across the HAL source. However, that
code is left in place for now in order to ease a sync to NetBSD.
Reviewed by: emaste (w/ man page fix)
Approved by: adrian
Differential Revision: https://reviews.freebsd.org/D41355
Following the removal of general MIPS support, there's no longer a need
to have the AHB bus-frontend in place, which according to Linux sources
also isn't used with any non-MIPS SoCs. For simplicity, PCI bus support
is only made conditional on the main one again, i. e. device ath_pci is
removed, and built into the main module, i. e. if_ath_pci.ko obsoleted,
respectively.
Effectively, this reverts the following commits and associated changes:
dba9c85977e849bb3ecb
Approved by: adrian
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D41354
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
It turns out that, silly adrian, setting it to 64 means only two
AMPDU frames of 32 subframes each. Thus, whilst those are in-flight,
any subsequent queues frames to that node get dropped.
This ends up being pretty no bueno for performance if any receive
is also going on at that point.
Instead, set it to 128 for the time being to ensure that SOME
frames get queued in the meantime. This results in some frames
being immediately available in the software queue for transmit
when the two existing A-MPDU frames have been completely sent,
rather than the queue remaining empty until at least one is sent.
It's not the best solution - I still think I'm scheduling receive
far more often than giving time to schedule transmit work -
but at least now I'm not starving the transmit side.
Before this, a bidirectional iperf would show receive at ~ 150mbit/sec.
but the transmit side at like 10kbit/sec. With it set to 128 it's
now 150mbit/sec receive, and ~ 10mbit receive. It's better than 10kbit/sec,
but still not as far as I'd like it to be.
Tested:
* AR9380/QCA934x (TL-WDR4300 AP), Macbook pro test STA + AR9380 test STA
I've been using STA+AP modes at home for a couple years now
and I've been finding and fixing a lot of weird corner cases.
This is the eventual patchset I've landed on.
* Don't force beacon resync in STA mode if we're using sw beacon tracking.
This stops a variety of stomping issues when the STA VAP is reconfigured;
the AP hardware beacons were being stomped on!
* Use the first AP VAP to configure beacons on, rather than the first VAP.
This prevents weird behaviour in ath_beacon_config() when the hardware
is being reconfigured and the STA VAP was the first one created.
* Ensure the beacon interval / timing programming is within the AR9300
HAL bounds by masking off any flags that may have been there before
shifting the value up to 1/8 TUs rather than the 1 TU resolution the
previous chips used.
Now I don't get weird beacon reprogramming during startup, STA state
changes and hardware recovery which showed up as HI-LARIOUS beacon
configurations and STAs that would just disconnect from the AP very
frequently.
Tested:
* AR9344/AR9380, STA and AP and STA+AP modes
The NAV (network allocation vector) register reflects the current MAC
tracking of NAV - when it will stay quiet before transmitting.
Other devices transmit their frame durations in their 802.11 PHY headers
and all devices that hear a frame - even if it's one in an encoding
they don't understand - will understand the low bitrate PHY header that
includes the frame duration. So, they'll set NAV to this value so
they'll stay quiet until the transmit completes.
Anyway, sometimes the PHY NAV header is garbled and sometimes, notably
older broadcom devices, will fake a long NAV so they can get "cleaner" air
for local calibration. When this happens, the hardware will stay quiet
for quite some time and this can lead to missed/stuck beacons, or
(for Very Large Values) a MAC hang.
This code just adds the ability to get/set the NAV; the driver will
need to take care of using it during transmit hangs and beacon misses
to see if it's due to a trash looking NAV.
TSFOOR happens if a beacon with a given TSF isn't received within the
programmed/expected TSF value, plus/minus a fudge range. (OOR == out of range.)
If this happens then it could be because the baseband/mac is stuck, or
the baseband is deaf. So, do a cold reset and resync the beacon to
try and unstick the hardware.
It also happens when a bad AP decides to err, slew its TSF because they
themselves are resetting and they don't preserve the TSF "well."
This has fixed a bunch of weird corner cases on my 2GHz AP radio upstairs
here where it occasionally goes deaf due to how much 2GHz noise is up
here (and ANI gets a little sideways) and this unsticks the station
VAP.
For AP modes a hung baseband/mac usually ends up as a stuck beacon
and those have been addressed for a long time by just resetting the
hardware. But similar hangs in station mode didn't have a similar
recovery mechanism.
Tested:
* AR9380, STA mode, 2GHz/5GHz
* AR9580, STA mode, 5GHz
* QCA9344 SoC w/ on-board wifi (TL-WDR4300/3600 devices); 2GHz
STA mode
Right now ts_antenna is either 0 or 1 in each supported HAL so
this is purely a sanity check.
Later on if I ever get magical free time I may add some extensions
for the NICs that can have slightly more complicated antenna switches
for transmit and I'd like this to not bust memory.
ath_hal is compiled into the kernel by default and so always prints a
message to dmesg even when the system has no ath hardware.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Replace some hard-coded magic values in the ioctl stats struct with
#defines. I'm going to follow up with some more sanity checking in
the receive path that also use these values so we don't do bad
things if the hardware is (more) confused.
We have (two versions) of MS() and SM() macros which we use throughout
the wireless code. Change all but three places (ath_hal, rtwn, and rsu)
to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK()
macros. Also change one internal case using both _S and _M instead of
just _S away from _M (one of the reasons rtwn and rsu were not changed).
This was done semi-mechanically. No functional changes intended.
Requested by: gnn (D26091)
Reviewed by: adrian (pre line wrap)
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision: https://reviews.freebsd.org/D26539
In r178354 with the introduction of multi-bss ("vap") support factoring
out started and with r193340 ieee80211_media_change() no longer returned
ENETRESET but only 0 or error.
As ieee80211(9) tells the ieee80211_media_change() function should not
be called directly but is registered with ieee80211_vap_attach() instead.
Some drivers have not been fully converted. After fixing the return
checking some of these functions were simply wrappers between
ieee80211_vap_attach() and ieee80211_media_change(), so remove the extra
function, where possible as well.
PR: 248955
Submitted by: Tong Zhang (ztong0001 gmail.com) (original)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
This is a flag from the MAC that says the received packet didn't match
a keycache slot. This isn't technically a problem as WEP keys don't
match keycache slots (they're "global" keys), but it could be useful
for tracking down CCMP decryption failures.
Right now it's a no-op - it mirrors what the AR9300 HAL does and it
just increments a counter. But, hey, maybe one day I'll use it for
diagnosing keycache/CCMP decrypt issues.
This logic is running the beacon receive bits in STA+AP mode on both the
STA and AP side. The STA side sees its beacons from the BSS fine; the
AP side is seeing other beacons on the same channel but with the BSS
node for some odd reason. (I think it's a valid reason, but I currently
forget what that valid reason is.)
So, just to be cleaner about things, don't run the nexttbtt/etc bits
at all if we're in hostap mode. If I ever get mesh working then maybe
I'll make sure it works right on mesh+ap and mesh+sta modes.
Whilst here, log the VAP i'm being called on to make it clearer what
is going on. I may end up adding a VAP dprintf version of this at
some point.
Tested:
* AR9380, STA (DWDS client) + hostap on the same NIC
This is something I added a few years ago to handle resyncing the beacon if
we miss a beacon or need to sync after association/reassociation/powersave.
However, if we're doing STA+AP mode (eg DWDS) then we don't want
to reprogram the beacons here; this may upset normal AP operation.
I missed checking for the sc->sc_swbmiss flag so I was reinitialising
the beacon timers after every beacon miss / TSFOOR option, and
that isn't likely good.
This plus ensuring that STA's are created with "-beacon" to disable
BMISS/TSFOOR processing will hopefully quieten some of the issues
I've seen with missed beacons / TSFOOR (out of range) interrupts
coming in when operating in STA mode.
Tested:
* AR9380/AR9580, STA+AP modes
Until net80211 grows a specific ticks type that matches the system,
manually use the same type as the kernel/net80211 'ticks' type
(signed int.)
Tested:
* AR9380, STA mode
Although I added the reset type field to ath_hal_reset() years ago,
I never finished adding it both throughout the HALs and in if_ath.c.
This will eventually deprecate the ath_hal force_full_reset option
because it can be requested at the driver layer.
So:
* Teach ar5416ChipReset() and ar9300_chip_reset() about the HAL type
* Use it in ar5416Reset() and ar9300_reset() when doing a full chip reset
* Extend ath_reset() to include the HAL_RESET_TYPE parameter added in the above functions
* Use HAL_RESET_NORMAL in most calls to ath_reset()
* .. but use HAL_RESET_BBPANIC for the BB panics, and HAL_RESET_FORCE_COLD during fatal, beacon miss and other hardware related hangs.
This should be a glorified no-op outside of actual hardware issues.
I've tested things with ath_hal force_full_reset set to 1 for years now,
so I know that feature and a full reset works (albeit much slower than
a warm reset!) and it does unwedge hardware.
The eventual aim is to use this for all the places where the driver
detects a potential hang as well as if long calibration - ie, noise floor
calibration - fails to complete. That's one of the big hardware related
things that causes station mode operation to hang without easy recovery.
Differential Revision: https://reviews.freebsd.org/D24981
This is all very long-standing bug stuff that is touchy and still poorly
documented. Ok, here goes.
The basic bug:
* deleting a VAP causes the RX path (and TX path too) to be restarted
without a full chip reset, which causes RX hangs on the AR9380 and later.
(ie, the ones with the newer DMA engine.)
The basic fix:
* do an RX flush when stopping RX in ath_vap_delete() to match what happens
when RX is stopped elsewhere. This ensures any pending frames are completed
and we restart at the right spot; it also ensures we don't push new RX buffers
into the hardware if we're stopping receive.
The other issues I found:
* Don't bother checking the RX packet ring in the deferred read taskqueue;
that's specifically supposed to be for completing frames rather than
just yanking them off the receive ring.
* Cancel/drain any pending deferred read taskqueue. This isn't done inside
any locks so we should be super careful here. This stops the hardware
being reprogrammed at the same time in another thread/CPU whilst we're
stopping RX.
* .. (yes, this should be better serialised, but that's for another day. maybe.)
* Add more debugging to trace what's going on here.
And the fun bit:
* Reinitialise the RX FIFO ONLY if we've been reset or stopped, rather than just
reset. I noticed that after all the above was done I was STILL seeing RXEOL.
RXEOL isn't enabled on the AR9380 so I'd only see it if I was sending TX frames
(ie a ping where it'd be transmitted but never received) so I was not being
spammed by RXEOL. So, as long as stuff is stopped, restart it.
This seems to be doing the right thing in both AP and STA modes.
What I should do next, if I ever get time:
* as I said above, serialise the receive stop/start to include taskqueues
* monitor RXEOL on the AR9380 and I keep seeing it spammed / lockups, just
go do a full chip reset to get things back on track. It sucks, but it
is better than nothing.
Tested:
* AR9380 AP/STA mode, adding/deleting a hostap VAP to trigger the TX/RX
queue stop/start; whilst also running an iperf through it. Lots of times.
Lots. Of.. Times.
