For MLD stations, userspace may need to explicitly transmit a frame to
a specific link address. In that case, it needs to ensure that no
address translation happens.
In the reverse case of an RX, userspace may need to know the link
address for a frame. By passing the information whether a STA is known
for the frame, userspace knows whether link translation happened and
can do the reverse lookup when needed.
This is important for flows where a STA is still registered but the
connection has been lost and it is returning again.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://patch.msgid.link/20260915151925.f12af80b1972.I4cfd3db83ba3dc0267575f919ba613ea5d10abd5@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The code has grown over time and it was not correctly handling all
cases. Examples of issues are that for management frames we would match
the received address against the MLD address even though we should not
resolve the station in that case. Another issue was that for data frames
we would not correctly fall back to use link addresses when the driver
does not provide the pubsta already.
The new code still uses the same approach as before. For data frames,
assume that a valid station exists and interfaces do not need to be
iterated. On the other hand, for non-data frames (or if a data frame
without a station is received) all interfaces must be iterated.
Note that this rework makes mac80211 slightly more strict. For example,
previously mac80211 would have incorrectly accepted a data frame that
was transmitted on the wrong link.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://patch.msgid.link/20260915151925.de2fc9a47273.Ie12ec077142c6a7fdbb58cdfc5660497cc75150e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The link ID for one frequency may be different between VIFs. As such,
the sensible thing is to set the link ID later in the flow once the SKB
is duplicated for each VIF. As the link ID is not passed in from outside
mac80211 it is always valid and the corresponding bit can be dropped.
Also switch a few more places to pass the link STA as that is a natural
way to pass the link information around.
This fixes the per-link statistics when frames are reordered.
Note that this patch deliberately leaves some places unchanged and even
incorrect as this will be addressed by further refactorings.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://patch.msgid.link/20260915151925.467593bc1105.I8abe3601d0335dca22d48bcee864817cfccf0de0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If a station is passed then the link ID also needs to be known. As such,
it is a more natural API to simply pass the link station directly rather
than pushing the link information into the RX status.
Furthermore, having the link ID in the RX status is not actually correct
because the link IDs are VIF specific and there may be multiple VIFs. In
the case of a station this relationship is clear, but then one may as
well use the link station.
This patch only changes the API and emulates the old (incorrect)
behaviour for now. The mac80211 RX code will be updated in later
patches.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://patch.msgid.link/20260915151925.06f41565116a.I4a2d45609e94b52654b10ec572e59a45d09c41f4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Using the link_sta is a natural way to pass both the STA and the link ID
information at the same time. Use that internally to the driver in
preparation to mac80211 changing its API and adopting the same method.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://patch.msgid.link/20260915151925.0b1269375e9e.I41df561f8129fac1327a07729cf4734b8752bcd6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
wireless.wiki.kernel.org has not existed for a while. Update all links to
point to the current rendered pages at wireless.docs.kernel.org.
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Link: https://patch.msgid.link/20260915-wireless-wiki-v1-1-21dc76684b44@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
brcmf_bss_connect_done() receives the firmware event in @e but discards it
on the failure path. Every failed connect is reported to cfg80211 as
WLAN_STATUS_AUTH_TIMEOUT (16), whatever the firmware actually said, so
userspace only ever sees:
wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16
The all-zero BSSID comes from the same place: conn_params is memset to
zero and profile->bssid has not been filled in when the station never
associated.
status_code=16 therefore carries no information about the cause. It is not
an AP response and it does not mean "authentication timed out" - it is the
only failure value this driver can produce. This is a recurring source of
confusion: [1] has been open since 2023 with more than twenty follow-ups
and no explanation of the code, and covers BCM4345/6, BCM43430 and
CYW43455 across several kernel versions. It supersedes [2], filed against
the firmware repository a day earlier and closed in favour of it.
The firmware's own status (BRCMF_E_STATUS_*) is more specific - FAIL,
TIMEOUT, NO_NETWORKS, ABORT and so on - and it is already in hand. Log it
so the cause can be narrowed down without rebuilding the kernel.
bphy_err() is used rather than brcmf_dbg() or brcmf_info(): it is the form
the rest of this file uses, and of the three it is the only one that is
both visible in a distribution kernel and bounded. brcmf_dbg(CONN)
expands to no_printk() unless CONFIG_BRCMDBG is set, which is what makes
the reports in [1] and [2] impossible to act on - the people hitting this
run stock kernels. brcmf_info() expands to a plain pr_info() in a
non-debug build and is not rate limited, and wpa_supplicant retries the
association every few seconds, so it would flood the log. bphy_err() is
guarded by net_ratelimit() there, so a station retrying against an
unreachable AP prints at most a few lines per second.
All three fields are printed because only some of them are meaningful on
each path into the failure branch. brcmf_is_nonetwork() keys off @status,
so that is the useful field for a join that never associated - the case in
[1]. brcmf_is_linkdown() keys off @event_code and @flags and does not look
at @status at all, so @status can read 0 there; on those events it is
@reason which carries the 802.11 reason code, as the mapping in
brcmf_map_fw_linkdown_reason() shows. Printing the three together lets
the reader tell which path was taken instead of guessing from one number.
The status reported to cfg80211 is left alone; changing it would alter what
userspace sees.
[1] https://github.com/RPi-Distro/firmware-nonfree/issues/38
[2] https://github.com/raspberrypi/firmware/issues/1829
Assisted-by: Claude:claude-opus-5
Signed-off-by: Ryohei Hashimoto <laurel.medalist12@gmail.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260913165526.4426-1-laurel.medalist12@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Advertise NL80211_EXT_FEATURE_FAST_ROAM_OFFLOAD only when firmware
reports FBT or OKC support. That lets userspace provide PMK material for
firmware fast roaming without enabling the path on devices that cannot
complete the offloaded roam.
Assisted-by: GitHub-Copilot-CLI:gpt-5.5
Signed-off-by: Carella Chen <carella.chen@infineon.com>
Signed-off-by: Jason Huang <jason.huang2@infineon.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260911065656.1269623-6-Jason.Huang2@infineon.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Firmware can complete FT or OKC roaming before the driver reports the
connect or roam event to cfg80211. Detect those successful offloaded
cases when the profile uses firmware 1X or roaming offload and the
association request carries PMK cache state, FT is in use, or OKC is
enabled.
After reporting the connect or roam event, call cfg80211_port_authorized()
so nl80211 emits the dedicated NL80211_CMD_PORT_AUTHORIZED event instead
of reusing the reserved NL80211_ATTR_PORT_AUTHORIZED flag in CONNECT/ROAM
notifications.
Assisted-by: GitHub-Copilot-CLI:gpt-5.5
Signed-off-by: Darren Li <hsin-hung.li@cypress.com>
Signed-off-by: Chung-Hsien Hsu <Chung-Hsien.Hsu@infineon.com>
Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: Carella Chen <carella.chen@infineon.com>
Signed-off-by: Jason Huang <jason.huang2@infineon.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260911065656.1269623-5-Jason.Huang2@infineon.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
FT and OKC roaming offload need PMK material in firmware even when
the initial 802.1X exchange is handled by userspace. Add a roaming
firmware-supplicant profile state for those connections and allow PMK
configuration while firmware FT or OKC state is active.
Program the OKC PMK through the okc_info_pmk iovar before setting the
regular PMK when firmware reports OKC state. Only select the roaming
firmware-supplicant state when firmware advertises FBT or OKC support;
devices without those capabilities keep the profile in the userspace
supplicant state and do not issue roaming-offload specific iovars on
every connect.
For FT-PSK with firmware supplicant support, keep the profile in the
PSK firmware-supplicant state.
Assisted-by: GitHub-Copilot-CLI:gpt-5.5
Signed-off-by: Darren Li <hsin-hung.li@cypress.com>
Signed-off-by: Chung-Hsien Hsu <Chung-Hsien.Hsu@infineon.com>
Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com>
Co-developed-by: Carella Chen <carella.chen@infineon.com>
Signed-off-by: Carella Chen <carella.chen@infineon.com>
Co-developed-by: Shelley Yang <shelley.yang@infineon.com>
Signed-off-by: Shelley Yang <shelley.yang@infineon.com>
Signed-off-by: Jason Huang <jason.huang2@infineon.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260911065656.1269623-4-Jason.Huang2@infineon.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Some firmware advertises Fast BSS Transition and Opportunistic Key
Caching support through the firmware capability string. Track those
capabilities so later roaming offload handling can be enabled only
when firmware reports support.
Assisted-by: GitHub-Copilot-CLI:gpt-5.5
Signed-off-by: Carella Chen <carella.chen@infineon.com>
Signed-off-by: Jason Huang <jason.huang2@infineon.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260911065656.1269623-3-Jason.Huang2@infineon.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Drivers can offload FT or OKC roaming without necessarily advertising
full 802.1X 4-way handshake offload. Add an extended feature bit for
that capability and allow PMK configuration when it is present.
This gives userspace a way to provide PMK or PMK-R0 material needed by
fast roaming firmware implementations while keeping the existing 4-way
handshake offload capability unchanged.
Assisted-by: GitHub-Copilot-CLI:gpt-5.5
Signed-off-by: Carella Chen <carella.chen@infineon.com>
Signed-off-by: Jason Huang <jason.huang2@infineon.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260911065656.1269623-2-Jason.Huang2@infineon.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The rt2x00 PCI and USB probe paths allocate EEPROM and RF storage with
plain kzalloc() and then free it from bus-specific teardown helpers. The
USB path also manages the CSR cache the same way. These buffers are
tied to the device lifetime, so the explicit free paths add probe and
disconnect cleanup without providing separate ownership.
Allocate the buffers with devm_kzalloc() before the mac80211 hardware is
allocated, then attach the resulting storage to struct rt2x00_dev after
the driver-private state exists. This lets driver detach and probe
failure rely on device-managed cleanup and removes the duplicated
bus-specific buffer freeing.
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Link: https://patch.msgid.link/20260904211628.83180-1-rosenp@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The 'secure link' feature is not supported by upstream (the reference
code relies on mbedTLS to implement it, which is not an option for the
Linux kernel).
If the firmware enforce the 'secure link' feature, wfx_probe() exits
early. However, err still holds the value returned by the previous call
to wait_for_completion_timeout(), which is the number of jiffies left
before the timeout, hence strictly positive (the zero case is handled
just above).
wfx_probe() therefore returns a positive value. The bus probe functions
forward it as-is and the driver core negates it (see really_probe()).
The device does not get bound, which is the expected outcome, but the
reported error code is a meaningless negative jiffies count instead of
an errno.
Return -EOPNOTSUPP, as already done a few lines above when the firmware
API version is not supported.
Copilot reviewed the code and wrote some parts of the log.
Reported-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Closes: https://lore.kernel.org/all/cc4de4e40e3ca50e7288be2b9067802576567c25.camel@siemens.com/
Assisted-by: Copilot:claude-opus-5
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Link: https://patch.msgid.link/20260906204831.949692-3-jerome.pouiller@silabs.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When the device reports that it is too hot, wfx_suspend_hot_dev() blocks
the Tx queues and arms cooling_timeout_work with a 10s delay. If the
device recovers a normal temperature before the delay expires, the work
is canceled. Else, the work declares the chip frozen and unblocks the Tx
queues.
However, this work is never canceled when the device is removed.
cooling_timeout_work is queued on the system workqueue, while struct
wfx_dev is released by wfx_free_common() (through ieee80211_free_hw()).
So, if the device is unbound during this 10s window, the work fires
after struct wfx_dev has been freed and dereferences it.
Cancel the work during the teardown. It has to be done after
wfx_bh_unregister(): the "device too hot" indication is processed by the
bh, so canceling the work earlier would allow the bh to rearm it. On the
other hand, the work calls wfx_tx_unlock(), which may in turn call
wfx_bh_request_tx(). So it has to be canceled before bh_wq is destroyed.
Note that the Tx queues are intentionally left blocked: the device is
going away, so there is nothing to unblock.
The issue was reported by the Sashiko review bot and the fix has been
written by Copilot (including the commit log). The use-case is difficult
to reproduce, so this code has not been tested. However, I don't believe
this patch could cause any regression.
Fixes: 1d52d29983 ("staging: wfx: add support for 'device too hot' indication")
Assisted-by: Sashiko:gemini-3.1-pro-preview
Assisted-by: Copilot:claude-opus-5
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Link: https://patch.msgid.link/20260906204831.949692-2-jerome.pouiller@silabs.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In a new test framework for hwsim I'm working on,
tests can modify the frame as it passes through
the wmediumd APIs. If then the original frame is
reported on the monitor interface, things get a
bit confusing.
Overwrite the frame that will be reported to the
monitor with the frame reported for RX if both
transmitter and cookie attributes are present
(wmediumd doesn't set them).
Also add a HWSIM_ATTR_NO_MONITOR flag to allow a
frame to be dropped entirely from monitor report,
e.g. in case it was never delivered to any peer.
Link: https://patch.msgid.link/20260911154632.c06da6d18055.Iaba24acec4c5765fbad77376418b17d1b863791b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
A round is ended when ieee80211_next_txq() meets a txq whose remembered
round number is the current one, meaning it has gone full circle.
When the AC exceeds the airtime limit, ieee80211_txq_schedule_start()
sets the round number to 0 to close the round. The next open round is
1. A txq from an earlier round 1 still remembers the "1", so the next
round stops on it and serves nothing.
Fix: use a separate open/closed flag and let the round number keep
counting.
Testing: ~4200 skipped selections per 20s without the fix and 20
skipped selections per 20s with the fix on ath11k (with my AQL series
applied) at BE 500/1000.
Fixes: 8e4bac0671 ("wifi: mac80211: add a per-PHY AQL limit to improve fairness")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Reviewed-by: Toke Høiland-Jørgensen <toke@toke.dk>
Link: https://patch.msgid.link/20260908144155.756569-1-julius@bairaktaris.de
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mesh_path_add() has returned the new (or the already existing) struct
mesh_path, or an ERR_PTR(), since commit ae76eef027 ("mac80211: return
new mpath from mesh_path_add()"), but its kernel-doc still says
"Returns: 0 on success". Describe the pointer.
Fixes: ae76eef027 ("mac80211: return new mpath from mesh_path_add()")
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Link: https://patch.msgid.link/20260912072840.50710-1-kmehltretter@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ieee80211_tx_control_port() can be called from nl80211_tx_control_port()
in normal process context via netlink sendmsg(), where BH/preemption
is not disabled. dev_sw_netstats_tx_add() uses this_cpu_ptr() internally,
which requires preemption to be disabled, triggering a
"BUG: using smp_processor_id() in preemptible code" warning.
Fix this by moving the local_bh_disable()/local_bh_enable() section to
also cover dev_sw_netstats_tx_add() and ieee80211_tpt_led_trig_tx().
Fixes: d5a014204a ("wifi: mac80211: tx: simplify control port frame transmission")
Reported-by: syzbot+d979bd35c8a76fd1b6f5@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=d979bd35c8a76fd1b6f5
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
Link: https://patch.msgid.link/20260910041047.24437-1-kartikey406@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
hwsim_mcast_config_msg() falls back to genlmsg_multicast() when it has no
genl_info, and that only reaches init_net. A radio in another namespace
therefore has its DEL_RADIO announced in init_net, while its own namespace
hears nothing.
Multicast to wiphy_net() instead, the net that GET and DUMP already filter
on. Tested with a config-group listener in each namespace, on a base and a
patched kernel.
Assisted-by: Claude:claude-opus-5 codeql
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
Link: https://patch.msgid.link/20260904140300.3402053-1-maoyixie.tju@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When bringing a monitor interface up and down again, the
refcount is leaked for active monitor interfaces, so the
hardware filter is never reset.
Move the decrement out so it mirrors the increment.
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Link: https://patch.msgid.link/20260904202817.12564-1-lucid_duck@justthetip.ca
[rewrite commit message better]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Drivers without FAST_XMIT and hardware scan support currently drop TX
frames during software scanning while being off-channel. This happens
in ieee80211_tx_h_check_assoc() before frames reach internal TX queue.
Move the off-channel check to invoke_tx_handlers_late(), after
ieee80211_queue_skb(). Frames can then remain queued and be transmitted
when the interface returns on-channel. This how TX works currently when
code goes via ieee80211_xmit_fast() path.
Below is rt2x00 driver ping output example while scanning, before and
after the fix. After the fix, packets are no longer lost. Some have
increased latency, what is expected behavior.
BEFORE:
64 bytes from 192.168.0.1: icmp_seq=29 ttl=64 time=3.61 ms
64 bytes from 192.168.0.1: icmp_seq=31 ttl=64 time=3.33 ms # Missed 30
64 bytes from 192.168.0.1: icmp_seq=32 ttl=64 time=4.03 ms
64 bytes from 192.168.0.1: icmp_seq=34 ttl=64 time=3.10 ms # Missed 33
64 bytes from 192.168.0.1: icmp_seq=36 ttl=64 time=3.04 ms # Missed 35
64 bytes from 192.168.0.1: icmp_seq=38 ttl=64 time=3.05 ms # Missed 37
64 bytes from 192.168.0.1: icmp_seq=40 ttl=64 time=4.14 ms # Missed 39
64 bytes from 192.168.0.1: icmp_seq=41 ttl=64 time=4.50 ms
AFTER:
64 bytes from 192.168.0.1: icmp_seq=29 ttl=64 time=3.40 ms
64 bytes from 192.168.0.1: icmp_seq=30 ttl=64 time=6.10 ms
64 bytes from 192.168.0.1: icmp_seq=31 ttl=64 time=4.69 ms
64 bytes from 192.168.0.1: icmp_seq=32 ttl=64 time=4.49 ms
64 bytes from 192.168.0.1: icmp_seq=33 ttl=64 time=148 ms
64 bytes from 192.168.0.1: icmp_seq=34 ttl=64 time=6.83 ms
64 bytes from 192.168.0.1: icmp_seq=35 ttl=64 time=8.66 ms
64 bytes from 192.168.0.1: icmp_seq=36 ttl=64 time=13.0 ms
64 bytes from 192.168.0.1: icmp_seq=37 ttl=64 time=4.78 ms
64 bytes from 192.168.0.1: icmp_seq=38 ttl=64 time=3.85 ms
Cc: <stable@vger.kernel.org>
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Link: https://patch.msgid.link/20260908124651.2995-1-stf_xl@wp.pl
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Without this ieee80211_select_key_8023() is never called and wifi never
connects.
Fixes: 0e80db0866 ("wifi: mac80211: fix key selection for encap offload frames")
Signed-off-by: Bert Karwatzki <spasswolf@web.de>
Link: https://patch.msgid.link/20260908094341.12196-1-spasswolf@web.de
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ieee80211_debugfs_rename_netdev() renames sdata->vif.debugfs_dir
without sharing synchronization with ieee80211_debugfs_recreate_netdev().
When MLO link updates switch an interface to or from MLO, the recreate
path can remove and rebuild that dentry while a concurrent netdev rename
still uses the stale pointer.
Serialize the rename helper with the same wiphy mutex that protects the
recreate path so the dentry cannot be removed while debugfs_change_name()
is operating on it.
Reported-by: Vega <vega@nebusec.ai>
Signed-off-by: Zhiling Zou <zhilinz@nebusec.ai>
Link: https://patch.msgid.link/76eecaf74ca2d4e4aedf46c3ee7505917433468b.1785729184.git.zhilinz@nebusec.ai
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When packet sockets use PACKET_QDISC_BYPASS, mac80211 can parse the
radiotap header while selecting the queue and again before transmit.
If the header includes an FCS, both parses trim the skb. Validate the FCS
on both parses, but trim it only before transmit. This keeps queue
selection read-only and avoids trimming shared skb data twice.
Fixes: cb17ed29a7 ("mac80211: parse radiotap header when selecting Tx queue")
Signed-off-by: Mariano Baragiola <mbaragiola@linux.com>
Link: https://patch.msgid.link/20260817233521.2747027-1-mbaragiola@linux.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
As per IEEE Std 802.11-2024, subclause 26.17.2.2, a 6 GHz AP can transmit
a Beacon frame using a non-HT duplicate PPDU, so that stations scanning
only PSC channels can discover it. Currently, there is no mechanism
to request the driver to transmit non-HT duplicate Beacon frames.
In [1], changes were made to parse the Beacon from user-space to set
the non-HT duplicate flag in the kernel. However, it was suggested that
non-HT transmission be part of the Beacon TX rate settings. Hence, add
NL80211_TXRATE_6GHZ_NON_HT_DUP as a flag attribute under
NL80211_ATTR_TX_RATES to let user-space request the driver to transmit
non-HT duplicate Beacons.
Also add validation to reject the Beacon if non-HT duplicate Beacon
transmission is enabled when legacy rates are not configured.
[1] https://lore.kernel.org/all/1644914581-21682-1-git-send-email-quic_ramess@quicinc.com/
Signed-off-by: Manish Dharanenthiran <manish.dharanenthiran@oss.qualcomm.com>
Link: https://patch.msgid.link/20260805-dup-beacon-v1-1-68574869c896@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The two scnprintf arguments for fq_overlimit and fq_overmemory are in the
wrong order, which results in the aqm debugfs file showing the overmemory
count under the fq_overlimit label and vice versa.
Fixes: 2a4e675d88 ("mac80211: Export fq memory limit information in debugfs")
Reviewed-by: Toke Høiland-Jørgensen <toke@toke.dk>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://patch.msgid.link/20260904090626.92727-1-julius@bairaktaris.de
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
check_fwfile_format() reads each block header and trusts its data length
before proving that both fit in the firmware image. A truncated header or
oversized block can therefore pass malformed extents to the download path.
Require the remaining image to contain the complete header and payload
before accepting each block.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260830140420.26399-1-pengpeng@iscas.ac.cn
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
check_fwfile_format() reads each block header and trusts its data length
before proving that both fit in the firmware image. A truncated header or
oversized block can therefore pass malformed extents to the download path.
Require the remaining image to contain the complete header and payload
before accepting each block.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260830124810.97223-1-pengpeng@iscas.ac.cn
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
WRT3200ACM and WRT32x routers always report a fixed US regulatory domain
from the mwifiex ROM, which conflicts with the platform regulatory
configuration on units sold outside the US market. For example:
- phy0 mwlwifi 5 GHz, hard-coded region 98 EU mapped to FR
- phy1 mwlwifi 2.4 GHz, hard-coded region 98 EU mapped to FR
- phy2 mwifiex 2.4 and 5 GHz, hard-coded region US
When the system boots, it detects a conflict between the user selected
region and the radios, e.g. BG FR US, and applies extreme restrictions,
preventing phy0 from starting on any DFS channel. phy2 works.
Add a device-tree flag, which allows affected devices, where the radio
conflicts with the platform to ignore the incorrect regulatory hint in
the ROM of the radio, so the platform regulatory domain can be used.
This does not allow the user to change the regulatory configuration of
any radio. It only allows phy0 to start and operate according to its
certified configuration.
The change affects only platforms which explicitly define this flag, and
helps overcome the incorrect behaviour of proprietary radio firmware.
The change has been tested on OpenWrt and fixes the issue where
phy0 does not start on WRT3200ACM-EU when a DFS channel is used
[1] https://github.com/kaloz/mwlwifi/issues/173#issuecomment-307879699
[2] https://github.com/openwrt/openwrt/issues/9956
Signed-off-by: Georgi Valkov <gvalkov@gmail.com>
Link: https://patch.msgid.link/20260827175850.89395-2-gvalkov@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
WRT3200ACM and WRT32x routers always report a fixed US regulatory domain
from the mwifiex ROM, which conflicts with the platform regulatory
configuration on units sold outside the US market. For example:
- phy0 mwlwifi 5 GHz, hard-coded region 98 EU mapped to FR
- phy1 mwlwifi 2.4 GHz, hard-coded region 98 EU mapped to FR
- phy2 mwifiex 2.4 and 5 GHz, hard-coded region US
When the system boots, it detects a conflict between the user selected
region and the radios, e.g. BG FR US, and applies extreme restrictions,
preventing phy0 from starting on any DFS channel. phy2 works.
Add a device-tree flag, which allows affected devices, where the radio
conflicts with the platform to ignore the incorrect regulatory hint in
the ROM of the radio, so the platform regulatory domain can be used.
This does not allow the user to change the regulatory configuration of
any radio. It only allows phy0 to start and operate according to its
certified configuration.
[1] https://github.com/kaloz/mwlwifi/issues/173#issuecomment-307879699
[2] https://github.com/openwrt/openwrt/issues/9956
Signed-off-by: Georgi Valkov <gvalkov@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260827175850.89395-1-gvalkov@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The WFxxx device provides an SDIO interface. In addition to the usual
in-band SDIO IRQ, the device also supports an out-of-band IRQ line.
However, using the OOB IRQ with SDIO requires to poll the control
register during the device initialization. This polling is unreliable:
if an IRQ is raised while the host reads the control register, the
device is lost and only a reset allows to recover it.
There is no way to fix this in software. So, warn the user that this
setup should be reserved to debug.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260901083548.113131-3-jerome.pouiller@silabs.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The WFxxx device provides an SDIO interface. In addition to the usual
in-band SDIO IRQ, the device also supports out-of-band IRQ line. OOB IRQ
requires a specific initialization described in commit f00dc1d789
("staging: wfx: poll IRQ during init"):
When the chip starts in SDIO mode, the external IRQ (aka Out-Of-Band
IRQ) cannot be used before to configure it. Therefore, the first
exchanges with the chip have to be done without the OOB IRQ.
This patch allow to poll the data until the OOB IRQ is correctly
setup. In order to keep the code simpler, this patch also poll data
even if OOB IRQ is not used.
Commit 57aa557f11 ("staging: wfx: introduce a way to poll IRQ")
announce some limitation about the data polling mechanism:
This function [wfx_bh_poll_irq()] must used with care: if an IRQ
fires while the host reads control register, the IRQ can be lost.
However, with last analysis, it seems it does not only impact the IRQ.
When this condition happen the hardware is lost and won't reply the next
commands. The only way to recover the error is to pull the reset pin and
bind the device again.
Currently wfx_bh_poll_irq() is only used during the two first exchanges
with the hardware. Therefore, it has been reported to only happen after
a few hours of bind/rebind in a loop. This explain why it has not been
reported before.
Fortunately, wfx_bh_poll_irq() is only required for OOB IRQ, which is
probably very marginal. The In-Band IRQ case also uses this function,
but only to simplify the code.
This patch limits the use of wfx_bh_poll_irq() to the OOB IRQ. The bus
driver now tells wfx_probe() whether polling is necessary. When it is
not (in-band SDIO IRQ and SPI), the IRQ is subscribed before the first
exchange with the device and wfx_bh_poll_irq() is never called. When it
is (SDIO with OOB IRQ), the behavior is unchanged: the control register
is polled until the PDS file has configured the IRQ line.
To conclude, In-Band users are now safe. Users of OOB IRQ will be still
impacted by the bug, but there is nothing we can do (and nobody
complained during the last 6 years).
Fixes: f00dc1d789 ("staging: wfx: poll IRQ during init")
Reported-by: Gerard Salvatella <gerard.salvatella@siemens.com>
Reported-by: Lukas Stockmann <lukas.stockmann@siemens.com>
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Link: https://patch.msgid.link/20260901083548.113131-2-jerome.pouiller@silabs.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The ack skb has to be stored while the frame is still in 802.3
format, since that is what is reported back to userspace. It's
currently done in ieee80211_build_hdr(), but that complicates
it a bit.
Thanks the the previous ieee80211_lookup_ra_sta() change, it's
now known whether or not the frame will be group addressed on
the air, which is needed for this condition.
Also simplify callers of ieee80211_store_ack_skb() by filling
the TX info directly and fix the free in ieee80211_build_hdr()
to use ieee80211_free_txskb(), reporting the drop to userspace
rather than being quiet about it.
This also lets use validate the link ID for control port TX in
that code itself, rather than interleaving it into build_hdr().
Link: https://patch.msgid.link/20260803141309.292711-16-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ieee80211_build_hdr() takes the info and control flags to use as
arguments, but that leads to some messy code and missed cleanup.
Fill them in the SKB before calling ieee80211_build_hdr().
Link: https://patch.msgid.link/20260803141309.292711-15-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ieee80211_lookup_ra_sta() returns ERR_PTR(-ENOENT) both when the
802.11 frame will be is group addressed and when it's going to
an unknown station.
Keep reporting an ERR_PTR() for group addressed but set to NULL
for individually addressed frames so the callers can use it to
distinguish later. This is already explicitly the case for all
interface types except mesh, and callers already tolerate (but
don't distinguish) both cases.
Also change the ieee80211_lookup_ra_sta() to be static.
Link: https://patch.msgid.link/20260803141309.292711-14-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ieee80211_build_hdr() unshares the skb halfway through, after it
has already looked at it but before it writes anything. That's not
a problem, but complicates the callers and requires passing the
flags to the function, etc.
Move the unsharing to the only caller that matters, the new one
from the previous patch has a fresh SKB and doesn't need it and
the TDLS callers via ieee80211_tdls_build_mgmt_packet_data() are
also fresh SKBs.
Link: https://patch.msgid.link/20260803141309.292711-13-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ieee80211_tx_control_port() already does most of the necessary work,
much of which is repeated by __ieee80211_subif_start_xmit(). Most
work in the latter function is completely unnecessary since these
are special frames we built directly here (long enough, etc.)
Call ieee80211_build_hdr() and ieee80211_xmit() directly instead.
It also means some errors can now be reported to userspace rather
than frames silently getting dropped, but that's a good thing.
Link: https://patch.msgid.link/20260803141309.292711-11-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In ieee80211_build_hdr(), IEEE80211_TX_CTL_REQ_TX_STATUS is checked
in ctrl_flags, which is wrong - IEEE80211_TX_CTL_REQ_TX_STATUS is in
info->flags, so the check is for IEEE80211_TX_CTRL_PORT_CTRL_PROTO
instead. This works out OK because the only place setting _that_ at
a point before this gets called is in fact ieee80211_tx_control_port()
which was intended here. This is actually needed for correctness, if
jt were checking info->flags instead, TDLS would fill/leak the status
frames created here.
However, we can just fix it by using the cookie instead, that'll be
set for PREAUTH frames via ieee80211_tx_control_port() as well, and
no other frames.
Additionally, the code also erroneously set it, but that just caused
preauth frames to get it set, since storing the ACK SKB will also set
the correct flag. Drop this assignment entirely.
Fixes: a7528198ad ("mac80211: support control port TX status reporting")
Link: https://patch.msgid.link/20260803141309.292711-10-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This function isn't used by any driver, and we may want to
change it in the future. Don't expose it. Drivers may still
do the same determination based on the flags, but if we'd
ever change the encapsulation internally etc. (which I'm
considering) then the use in mac80211 may need to change,
or the function itself.
Link: https://patch.msgid.link/20260803135248.cd23ccac65d7.I1c238c6abe39f5a1ff1b11d8556599d01dd03ff0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
For 802.11 frames, ieee80211_tx_h_select_key() drops a data frame
that ended up without a key if the station requires encryption, so
that traffic can never leak out unprotected. Encapsulation offload
erroneously didn't get this code path. Fix that.
Fixes: 50ff477a86 ("mac80211: add 802.11 encapsulation offloading support")
Link: https://patch.msgid.link/20260802085818.1336616-7-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ieee80211_tx_h_select_key() assumes the frame is in 802.11 format
for picking the key, at least when there's no pairwise TK for the
STA to transmit with.
For unicast this is likely not relevant because if there's no
pairwise TK for the STA there's probably not going to be any other
key either. But multicast encapsulation offload frames have no
STA, so it looks at the ethernet header as if it was 802.11. This
may not matter very much since multicast encapsulation offload is
likely to ignore the key selection, but it's still wrong.
Create a separate selection function that doesn't (need to) look
at the frame header - it's data anyway, so either unicast to a
station (with sta pointer) or multicast. For MLO, the driver has
to duplicate the frame and select the key anyway, so just skip
it in that case entirely.
Fixes: 50ff477a86 ("mac80211: add 802.11 encapsulation offloading support")
Link: https://patch.msgid.link/20260802105818.0feb7ad61047.Ia506ca211176a3c466bc60e4cc3e506df34a4a67@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The check in ieee80211_tx_dequeue() reads frame_control, addr1 and
addr2 out of the skb, but for encapsulation offload that's just a
random part of the ethernet addresses, so dropping depends on bits
in the destination address. This is obviously wrong.
Refactor the check and short-circuit for ethernet format frames,
it only needs the port-control flag check since those are locally
generated and not forwarded frames.
Fixes: 50ff477a86 ("mac80211: add 802.11 encapsulation offloading support")
Link: https://patch.msgid.link/20260802105818.dd5da579813d.I51ed0121154bb652bebc97bb0597b1fae9ac978f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
