LinuxKPI: 802.11: further improve key updates

Make sure the iv_bss noce does not go away in the middle of a key update
given we unlocked. Just as a precaution. No real case has been seen
so far.

LinuxKPI: 802.11: further improve key updates

Make sure the iv_bss noce does not go away in the middle of a key update
given we unlocked. Just as a precaution. No real case has been seen
so far.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Fixes: a6165709e3c8

show more ...

LinuxKPI; 802.11: start filling rxrate statistics

Start collecting rxrate information from the RX statistics which are
passed per packet. Store them in the lsta and upon printing statistics,
if no

LinuxKPI; 802.11: start filling rxrate statistics

Start collecting rxrate information from the RX statistics which are
passed per packet. Store them in the lsta and upon printing statistics,
if no RX_BIRATE is provided copy them over from the lsta.

This allows us to see rate information in both directions on modern
iwlwifi chipsets, which are doing [tx]rate handling in firmware.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

show more ...

LinuxKPI: 802.11: avoid using an mbuf tag for now

We are using an mbuf tag to carry the ni reference in the TX path
from the TX function past the taskq along with the mbuf.
Contrary to initial assum

LinuxKPI: 802.11: avoid using an mbuf tag for now

We are using an mbuf tag to carry the ni reference in the TX path
from the TX function past the taskq along with the mbuf.
Contrary to initial assumptions we only need the ni and no other data
so attach the ni to m->m_pkthdr.PH_loc.ptr avoiding the extra allcation.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

show more ...

LinuxKPI: 802.11: further locking workarounds fro crypto updates

There are cases when net80211 calls into crypto updates with the
ic lock held (not (just) the nt lock). We have to unlock that as
we

LinuxKPI: 802.11: further locking workarounds fro crypto updates

There are cases when net80211 calls into crypto updates with the
ic lock held (not (just) the nt lock). We have to unlock that as
well and track the unlock like we do for the nt to avoid panics
when we later can sleep (on the wiphy [sx] lock).

Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reported by: rm
Tested by: rm
PR: 285729
Fixes: b8dfc3ecf703
Differential Revision: https://reviews.freebsd.org/D49791

show more ...

LinuxKPI: 802.11: add a lchanctx list to lhw

While we are currently only supporting a single VAP (vif) it is
less of a trouble but in order to get locking and rcu accesses
[from drivers] more right

LinuxKPI: 802.11: add a lchanctx list to lhw

While we are currently only supporting a single VAP (vif) it is
less of a trouble but in order to get locking and rcu accesses
[from drivers] more right add a list for all chanctx_conf we have
for one hw. Use that list in the iterator function to avoid
having to lock the vif but not protecting the chanctx list
(against a parallel removal) due to different locking.

Sponsored by: The FreeBSD Foundation
PR: 280546
MFC after: 3 days
Tested by: Oleksandr Kryvulia (shuriku shurik.kiev.ua)
Tested by: Oleg Nauman (oleg.nauman gmail.com) [rtw88]
Differential Revision: https://reviews.freebsd.org/D49734

show more ...

LinuxKPI: 802.11: switch to wiphy_lock

Replace the LKPI_80211_LHW_LOCK (lhw->sx) with the wiphy lock (which
is a Linux mutex, so also an sx lock). Apart from two places the
change was mostly mechan

LinuxKPI: 802.11: switch to wiphy_lock

Replace the LKPI_80211_LHW_LOCK (lhw->sx) with the wiphy lock (which
is a Linux mutex, so also an sx lock). Apart from two places the
change was mostly mechanically.
Further remove the now recursive lock acquisitions.

This lays the ground for us to use more Linux(KPI) 802.11 internal
locking as well as more rcu equivalents, e.g., for the chanctx,
and live better to the synchronisation expectations of the drivers.
[I wish there would be more assertions in the drivers themselves,
especially in the mac80211 ops and the iteration callbacks.]

Sponsored by: The FreeBSD Foundation
PR: 280546
MFC after: 3 days
Tested by: Oleksandr Kryvulia (shuriku shurik.kiev.ua)
Tested by: Oleg Nauman (oleg.nauman gmail.com) [rtw88]
Differential Revision: https://reviews.freebsd.org/D49734

show more ...

LinuxKPI: 802.11: adjust locking around lkpi_remove_chanctx()

With the adjusted locking as a first step and the single code path
into lkpi_80211_mo_unassign_vif_chanctx() we also move the "setting
c

LinuxKPI: 802.11: adjust locking around lkpi_remove_chanctx()

With the adjusted locking as a first step and the single code path
into lkpi_80211_mo_unassign_vif_chanctx() we also move the "setting
chnactx to NULL" into the caller to simplify the code.

Before we can adjust the other places touching vif->bss_conf.chanctx
we need to adjust the overall locking in LinuxKPI 802.11.

Sponsored by: The FreeBSD Foundation
PR: 280546
MFC after: 3 days
Tested by: Oleksandr Kryvulia (shuriku shurik.kiev.ua)
Tested by: Oleg Nauman (oleg.nauman gmail.com) [rtw88]
Differential Revision: https://reviews.freebsd.org/D49734

show more ...

LinuxKPI: 802.11: improve key update locking to work around net80211

As indicated in 11db70b6057e there was another panic on key removal
which could no longer be reproduced. As originally assumed t

LinuxKPI: 802.11: improve key update locking to work around net80211

As indicated in 11db70b6057e there was another panic on key removal
which could no longer be reproduced. As originally assumed the
problem was "hidden" by commit 9763fec11b83 as mentioned in
11db70b6057e.
Said commit had logic inverted and 27bf5c405bf2 fixed that and with
that the possible panic came back.

The problem exists because some code paths out of net80211 are
locked while others are not. This opens a possible race in
net80211 which was tracked by extra logging in
(*iv_key_update_begin)() (log lines shortend):
key_update_begin: tid 100112 vap X nt Y unlocked
key_update_begin: tid 100133 vap X nt Y locked
One thread can be wpa_supplicant, the other is driven from the
driver net80211 taskq.
Further LinuxKPI needs to unlock (conditionally in case the lock
is held) as a downcall to the driver/FW may sleep. This opens up
possibilities for said race even further so that we observe it
more reliably.

This all leads to one thread calling down into the driver/firmware
(unlocked) while the other will get to the same place (after acquiring
the wiphy lock) before the nt re-lock happens and thus state checks
did not catch this either.

For LinuxKPI work around the problem utilizing
(*iv_key_update_begin/end)() and taking the wiphy_lock() there
holding it over the entire operation.
Given we still have to conditionally unlock we need to keep track
from _begin to _end on whether we have to re-lock. The checks for
this need to be done under the wiphy_lock().
While a bool would suffice we use a refcount to make any future
debugging easier.

This isn't the most elegant solution but having the wiphy lock
covering the full operation allows the 2nd thread to later run through
the same code path and find the key gone (which we already checked).
It remains questionable if (*iv_key_update_begin/end)() is the
correct solution (as there are futher callers covering which would
not need the unlock cycle) or if it should be done in the current
code. The former will allow us to cover a full key store which
we will need in case we will implement suspend/resume beyond what
is done in native drivers/net80211 currently, if we will factor
out the crypto locking for good, and fix the inconsistent locking
of the nt (NODE) lock in net80211.

Alternate solutions were discussed on freebsd-wireless today
(2025-03-06, in the thread "Re: HEADS UP! Do not update on main
currently (panic - on boot)").

Sponsored by: The FreeBSD Foundation
MFC after: 3 days
X-MFC with: 27bf5c405bf2
Differential Revision: https://reviews.freebsd.org/D49256

show more ...

LinuxKPI: 802.11: switch vif station list to a linux list

We ran into problems with locking the VIF for the lsta tailq on and
off. Switch from a native tailq to the LinuxKPI list.
This allows us to

LinuxKPI: 802.11: switch vif station list to a linux list

We ran into problems with locking the VIF for the lsta tailq on and
off. Switch from a native tailq to the LinuxKPI list.
This allows us to implement the "rcu" part in
linuxkpi_ieee80211_iterate_keys() which we could not before.
Further using either rcu or the wiphy lock we no longer run into
problems with the lock not being sleepable.
The last case was rtw89 debugfs which was doing a sleepable alloc
in the iterator callback of linuxkpi_ieee80211_iterate_stations_atomic().

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

show more ...

LinuxKPI: 802.11: hardware crypto offload improvements

Implement mac80211 functions ieee80211_iter_keys[_rcu](), and
ieee80211_get_key_rx_seq() (*).
Implement an internal function lkpi_sta_del_keys(

LinuxKPI: 802.11: hardware crypto offload improvements

Implement mac80211 functions ieee80211_iter_keys[_rcu](), and
ieee80211_get_key_rx_seq() (*).
Implement an internal function lkpi_sta_del_keys() to delete keys
when we are leaving RUN (AUTHORIZED) state.
Improve and make work (*) the net80211 vap function pointers
(*iv_key_set)(), (*iv_key_delete)() implementations.
Correct the logic in lkpi_80211_txq_tx_one() and factor most crypto
related bits out into lkpi_hw_crypto_prepare() (*).

(*) We are currently supporting CCMP only. I would hope we will
not have to do full WEP/TKIP support anymore given both are deprecated.

The entire logic remains behind the LKPI_80211_HW_CRYPTO pre-processor
condition and with this commit in addition behind a tunable.
The code is compiled in by default now but the tunable remains off until
wider testing has shown no problems.
I have seen one net80211 triggered panic on shutdown related to deleting
keys which I cannot reproduce anymore and could have been fixed by
9763fec11b83; otherwise we will have to investigate as it shows again.
The dedicated hw crypto tracing option can help in that case with debug
kernels.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Fixes: b35f6cd06612

show more ...

LinuxKPI: 802.11: dump station_info using (*sta_statistics)() as sysctl

Implement the mac80211 (*sta_statistics) to obtain station statistics.
Fix up struct station_info for that.
Add supporting fun

LinuxKPI: 802.11: dump station_info using (*sta_statistics)() as sysctl

Implement the mac80211 (*sta_statistics) to obtain station statistics.
Fix up struct station_info for that.
Add supporting funtions to decode station_info and rate_info_bw fields
to make the output more usable to human beings.

Add a per-VIF (VAP) sysctl to export that information. This is mostly
used for now to see what the driver/fw thinks about its TX rate.
We should later gather this information in different ways and pass it
to net80211 to export it to user space so we can finally have nice
station information (also for the non-AP side).

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

show more ...

LinuxKPI: 802.11: improve the IMPROVE_HT() macro

Let the macro take a format string and arguments and
add __func__, __LINE__ to the output.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

LinuxKPI: 802.11: adjustments for v6.11 iwlwifi, rtw88 and rtw89

Bring in the LinuxKPI 802.11 compat bits which are altering
the mac80211 KPI.

* In struct ieee80211_bss_conf chandef -> chanreq.
* V

LinuxKPI: 802.11: adjustments for v6.11 iwlwifi, rtw88 and rtw89

Bring in the LinuxKPI 802.11 compat bits which are altering
the mac80211 KPI.

* In struct ieee80211_bss_conf chandef -> chanreq.
* Various struct ieee80211_ops gained a link_id arguemnt,
stop gained a suspend flag.
* Various functions gained a link_id argument.
* ieee80211_tx_status() was renamed to ieee80211_tx_status_skb()

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

show more ...

LinuxKPI: 802.11: adjustments for v6.11 iwlwifi, rtw88 and rtw89

Bring ing the LinuxKPI 802.11 compat bits which are not altering
the mac80211 ops KPI.

* Add various functions for drvier updates.
*

LinuxKPI: 802.11: adjustments for v6.11 iwlwifi, rtw88 and rtw89

Bring ing the LinuxKPI 802.11 compat bits which are not altering
the mac80211 ops KPI.

* Add various functions for drvier updates.
* Add functions (some compat code to I assume cleanup some
mac80211 ops) emulating chanctx changes doing (*config) updates.
* Adjust structs and defines.
* Deal with an enum growing more than 32 bits in printf.
* Add a mtx to struct wiphy which is exposed to the drivers.
Handle initialization and destruction for now.
* Implementation of wiphy_work and wiphy_delayed_work.
* Set was_assoc for deassoc/deauth in prep_tx_info.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

show more ...

LinuxKPI: 802.11: support manual lladdr changes

Allow a user to change the "ether" address by ifconfig while a VAP is
not UP. Compared to net80211 (given we have no callback) we register
an eventha

LinuxKPI: 802.11: support manual lladdr changes

Allow a user to change the "ether" address by ifconfig while a VAP is
not UP. Compared to net80211 (given we have no callback) we register
an eventhandler per-vif (a global one would force us to use hacks to
derive if a vap is indeed also a lkpi_80211 vif).

Sponsored by: The FreeBSD Foundation
PR: 277356
Tested by: lwhsu
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D46121

show more ...

LinuxKPI: 802.11 compile in debugging based on IEEE80211 debugging

If IEEE80211 debugging is turned on in kernel configs also turn on
LinuxKPI 802.11 and SKB debugging (sysctls) to have them availab

LinuxKPI: 802.11 compile in debugging based on IEEE80211 debugging

If IEEE80211 debugging is turned on in kernel configs also turn on
LinuxKPI 802.11 and SKB debugging (sysctls) to have them available.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D45820

show more ...

LinuxKPI: 802.11: rename chanctx_conf for consistency

We used to call the struct ieee80211_chanctx_conf variable "conf"
in some places but that becomes confusing with bss_conf and other
"conf" bits.

LinuxKPI: 802.11: rename chanctx_conf for consistency

We used to call the struct ieee80211_chanctx_conf variable "conf"
in some places but that becomes confusing with bss_conf and other
"conf" bits. On the vif it is already called chanctx_conf thus also
rename it on the internal struct lkpi_chanctx and for our variables
in the implementation.

This should not have any external visibility.
No functional changes intended.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D45185

show more ...

LinuxKPI: 802.11: implement a deferred RX path

Some calls, e.g., action frames cause us to call through all the
way down to firmware from the RX path without any deferral in
net80211.

For LinuxKPI

LinuxKPI: 802.11: implement a deferred RX path

Some calls, e.g., action frames cause us to call through all the
way down to firmware from the RX path without any deferral in
net80211.

For LinuxKPI and iwlwifi this goes (with omissions) like this:
lkpi_napi_task -> linuxkpi_ieee80211_rx -> ieee80211_input_mimo ->
sta_input -> ht_recv_action_ba_addba_request ->
lkpi_ic_ampdu_rx_start -> iwl_mvm_mac_ampdu_action ->
iwl_trans_txq_send_hcmd. At that point we are waiting for an
interrupt from the firmware but given the lkpi_napi_task has not
finished (and may have more to dispatch based on budget and what
was received) we will not see the new interrupt/fw response.
With no answer from the firmware, the software timeout in the
driver kills the command and the firmware and issues a complete
restart.

Implement the deferred RX path in LinuxKPI for the moment.
At a later point we should carefully shift this into net80211.

This fixes the hangs for (*ic_ampdu_rx_start)() calls with iwlwifi.

MFC after: 3 days
PR: 276083
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43968

show more ...

LinuxKPI: 802.11: lsta txq locking cleanup

Rename the LSTA lock to LSTA_TXQ lock as that is really what it is and
put down the full set of macros. Replace the init and destroy with the
macro invoca

LinuxKPI: 802.11: lsta txq locking cleanup

Rename the LSTA lock to LSTA_TXQ lock as that is really what it is and
put down the full set of macros. Replace the init and destroy with the
macro invocation rather than direct code.

Put locking around the txq_ready unset and check. Move the taskq_enqueue
call under lock to be sure we do not call it anymore after txq_ready
got unset.

Leave a comment related to the node reference which is passed into the
TX path on the recvif mbuf pointer.

Fixes: 0936c648ad0ee
PR: 274382 (possibly)
MFC after: 1 day
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D43909

show more ...

LinuxKPI: 802.11: update the ni/lsta reference cycle

Update the ni/lsta reference cycle, add extra checks and assertions.
This is to accomodate problems we were seeing based on net80211
behaviour (j

LinuxKPI: 802.11: update the ni/lsta reference cycle

Update the ni/lsta reference cycle, add extra checks and assertions.
This is to accomodate problems we were seeing based on net80211
behaviour (join1() and (*iv_update_bss)() as well as state changes for
new iv_bss nodes during an active session).
This should hopefully help to stabilise behaviour until the underlying
problems gets properly addressed (for this and all other device drivers).

PR: 272607, 273985, 274003
MFC after: 3 days
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43753

show more ...

LinuxKPI: 802.11: band-aid for invalid state changes after (*iv_update_bss)

With firmware based solutions we cannot just jump from an active session
to a new iv_bss node without tearing down state f

LinuxKPI: 802.11: band-aid for invalid state changes after (*iv_update_bss)

With firmware based solutions we cannot just jump from an active session
to a new iv_bss node without tearing down state for the old and bringing
up the new node. This likely used to work on softmac based cards/drivers
where one could essentially set the state and fire at will.

We track (*iv_update_bss) calls from net80211 and set a local flag that
we are out of synch and do not allow any further operations up the state
machine until we hit INIT or SCAN. That means someone will take the state
down, clean up firmware state and then we can join again and build up
state.

Apparently this problem has been "known" for a while as native iwm(4) and
others have similar workarounds (though less strict) and can be equally
pestered into bad states. For LinuxKPI all the KASSERTs just massively
brought this problem out. The solution will be some rewrites in net80211.
Until then, try to keep us more stable at least and not die on second
join1() calls triggered by service netif start wlan0 and similar.

PR: 271979, 271988, 275255, 263613, 274003
Sponsored by: The FreeBSD Foundation (2023, partial)
MFC after: 3 days
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43725

show more ...

LinuxKPI: 802.11: more TXQ implementation and locking

Implement ieee80211_handle_wake_tx_queue() and ieee80211_tx_dequeue_ni()
while looking at the code. They are needed by various wireless drivers

LinuxKPI: 802.11: more TXQ implementation and locking

Implement ieee80211_handle_wake_tx_queue() and ieee80211_tx_dequeue_ni()
while looking at the code. They are needed by various wireless drivers.

Introduce an ltxq lock and protect the skbq by that.
This prevents panics due to a race between a driver upcall and
the net80211 tx downcall. While the former should be rcu protected we
cannot rely on that.
It remains questionable if we need to protect further fields there
(with a different lock?).

Also introduce a txq_mtx on the lhw which needs to be further deployed
but we need to come up with a good strategy to not end up with 7 different
locks.

Sponsored by: The FreeBSD Foundation
PR: 274178, 275710
Tested by: cc
MFC after: 3 days

show more ...

LinuxKPI: 802.11: bring in some HT code

Fix defines and structures to use proper types.

Bring in basic ni->sta synchronization, some channel width handling,
and overload the net80211 functions so t

LinuxKPI: 802.11: bring in some HT code

Fix defines and structures to use proper types.

Bring in basic ni->sta synchronization, some channel width handling,
and overload the net80211 functions so that we can talk to
driver/firmware to setup parameters. We will likely not need one
or two of those but it is good for tracing currently.

Cover HT and bits of VHT code in LinuxKPI behind apropriate #ifdef
which are currently not enabled (like LKPI_80211_HW_CRYPTO) until
confirmed to work.
Last, IEEE80211_AMPDU_RX_START made some firmware unhappy.

This will allow others to work on it and test as well.

Sponsored by: The FreeBSD Foundation
MFC after: 10 days

show more ...

LinuxKPI: 802.11: zero-pad debug flags

Write the debug flags as full 32bit hex numbers to have a better
view on them.

No functional changes.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

LinuxKPI: 802.11: zero-pad debug flags

Write the debug flags as full 32bit hex numbers to have a better
view on them.

No functional changes.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: cc, emaste
Differential Revision: https://reviews.freebsd.org/D42426

show more ...

LiunxKPI: 802.11: move ieee80211_chanctx_conf into lkpi private struct

Factor out ieee80211_chanctx_conf into struct lkpi_chanctx in order to
keep local state as well. In first instance that is add

LiunxKPI: 802.11: move ieee80211_chanctx_conf into lkpi private struct

Factor out ieee80211_chanctx_conf into struct lkpi_chanctx in order to
keep local state as well. In first instance that is added_to_drv
only. For now we stay single-chanctx only but this paves the path
to make it a list.
Use the new information to implement ieee80211_iter_chan_contexts_atomic().

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

show more ...