Modify the prototype for change_beacon() in struct cfg80211_op to
accept cfg80211_ap_settings instead of cfg80211_beacon_data so that
it can process data in addition to beacons.
Modify the prototypes of ieee80211_change_beacon() and driver specific
functions accordingly.
Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://lore.kernel.org/r/20230727174100.11721-4-quic_alokad@quicinc.com
[while at it, remove pointless "if (info)" check in tracing that just
makes all the lines longer than they need be - it's never NULL]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
FILS discovery configuration gets updated only if the maximum interval
is set to a non-zero value, hence there is no way to reset this value
to 0 once set. Replace the check for interval with a new flag which is
set only if the configuration should be updated.
Add similar changes for the unsolicited broadcast probe response handling.
Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://lore.kernel.org/r/20230727174100.11721-3-quic_alokad@quicinc.com
[move NULL'ing to else branch to not have intermediate NULL visible]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add a new flag 'update' which is set to true during start_ap()
if (and only if) one of the following two conditions are met:
- Userspace passed an empty nested attribute which indicates that
the feature should be disabled and templates deleted.
- Userspace passed all the parameters for the nested attribute.
Existing configuration will not be changed while the flag
remains false.
Add similar changes for unsolicited broadcast probe response
transmission.
Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://lore.kernel.org/r/20230727174100.11721-2-quic_alokad@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
clang with W=1 reports
net/wireless/lib80211_crypt_tkip.c:667:7: error: variable 'iv32'
set but not used [-Werror,-Wunused-but-set-variable]
u32 iv32 = tkey->tx_iv32;
^
This variable not used so remove it.
Then remove a similar iv16 variable.
Change the comment because the unmodified value is returned.
Signed-off-by: Tom Rix <trix@redhat.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Link: https://lore.kernel.org/r/20230517123310.873023-1-trix@redhat.com
[change commit log wrt. 'length', add comment in the code]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We really cannot even get into this as we can't have
a BSS with a 5/10 MHz (scan) width, and therefore all
the code handling shifted rates cannot happen. Remove
it all, since it's broken anyway, at least with MLO.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There really isn't any support for scanning at different
channel widths than 20 MHz since there's no way to set it.
Remove this support for now, if somebody wants to maintain
this whole thing later we can revisit how it should work.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Clearly, there's no space in the function name, not sure how
that could've happened. Put the underscore that it should be.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Fixes: 56cfb8ce1f ("wifi: cfg80211: add flush functions for wiphy work")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The firmware was trying to report the B2 RU allocation in
the place previously used here as well, but there's a HW
block that clears the lower 8 bits in this metadata word
even in sniffer mode. Thus, firmware moved B2 to another
place, follow that.
There's no need to detect the version since moving it to
the other place if firmware didn't just means that we'll
continue to report the (erroneous) zero value, and it's
not really something we can detect from the firmware now.
While debugging this we realized that the comments about
placement in the metadata dwords are wrong, update them.
Reported-by: Youhan Kim <youhank@qti.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230830112059.dec7f1e07ff8.I623fee2d710cc7b6f392d65b708883ed58632b45@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The last member of the enum is meant to count the items,
but sparse cannot increment the previous member due to
its bitwise type. Declaring the last entry with a value
doesn't work either (cannot mix bitwise/non-bitwise) and
declaring it with a bitwise value doesn't work due to
the way it gets used. This led to the current construct.
However, that construct the kernel-doc script doesn't
understand this construct due to the use of #ifdef/#else.
Find another solution that makes both tools happy, we
do now do declare it as the bitwise value but then just
redefine it so that doesn't get used, all still under
__CHECKER__ conditional.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230830112059.44bdf6a5fa9e.I9f1ea129f89e53043d48676aed0a3b8f6c31ac08@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In the spec, CSA is defined roughly as follows:
- TBTT x: beacon with CSA, count=n (old channel)
- TBTT x+1: beacon with CSA, count=n-1 (old channel)
- TBTT x+n-1: beacon with CSA, count=1 (old channel)
"A Channel Switch Count field set to 1 indicates that the switch
occurs immediately before the next TBTT.
- TBTT x+n: beacon without CSA (new channel)
When we detect it, we currently schedule the CSA event to
be at 10 TUs before TBTT x+n-1, for a beacon interval, to
give us quiet time.
When this event *starts*, we currently notify mac80211
that the channel switch happened, which causes us to add
a session protection event to listen for the first beacon
(and enable TX etc. when that arrives).
We don't even ask for a notification when this event ends
so the code that handles that is effectively dead code.
The session protection duration is 3 beacon intervals,
scheduled at 10 TU before TBTT x+n-1. It will thus end
just before TBTT x+n+2.
Unfortunately, if the AP doesn't transmit or we miss just
the first two beacons on the new channel, then this will
cause us to disconnect. Or even just one, if the AP isn't
quite aligned with the TBTT after the switch.
However, listening to the _end_ of the time event isn't
what we want either, because we want all the new PHY and
other config that needs to come from mac80211 to start
early, so we have a head-start for the new channel, since
we're not going to use the old one anyway for this time.
So since we don't really have anything better to do at
this time, and this is relatively rare, just make the
session protection use 5x the beacon interval instead of
just 3x, so it's more likely we catch a beacon even if
the AP neglected to send it, or we just miss it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230830112059.a74176bac37c.I029a2ebcd1b5012327c728ffa1d33fac19cfdf4b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The code that sets up the assoc link will currently take the BSS
element data from the beacon only. This is correct for some of
the data, notably the timing and the "have_beacon", but all the
data about MBSSID and EHT really doesn't need to be taken from
there, and if the EHT puncturing is misconfigured on the AP but
we didn't receive a beacon yet, this causes us to connect but
immediately disconnect upon receiving the first beacon, rather
than connecting without EHT in the first place.
Change the code to take MBSSID and EHT data also from the probe
response, for a better picture of what the BSS capabilities are
and to avoid that EHT puncturing problem.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230827135854.3c7e52d49482.Iba6b672f6dc74b45bba26bc497e953e27da43ef9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In mesh_fast_tx_flush_addr() we already hold the lock, so
don't need additional hashtable RCU protection. Use the
rhashtable_lookup_fast() variant to avoid RCU protection
warnings.
Fixes: d5edb9ae8d ("wifi: mac80211: mesh fast xmit support")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There were are a number of cases in mac80211 and iwlwifi (at
least) that used the sband->iftype_data pointer directly,
instead of using the accessors to find the right array entry
to use.
Make sparse warn when such a thing is done.
To not have a lot of casts, add two helper functions/macros
- ieee80211_set_sband_iftype_data()
- for_each_sband_iftype_data()
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
As previously reported by Alexander, whose commit 69403bad97
("wifi: mac80211: sdata can be NULL during AMPDU start") I'm
reverting as part of this commit, there's a race between station
destruction and aggregation setup, where the aggregation setup
can happen while the station is being removed and queue the work
after ieee80211_sta_tear_down_BA_sessions() has already run in
__sta_info_destroy_part1(), and thus the worker will run with a
now freed station. In his case, this manifested in a NULL sdata
pointer, but really there's no guarantee whatsoever.
The real issue seems to be that it's possible at all to have a
situation where this occurs - we want to stop the BA sessions
when doing _part1, but we cannot be sure, and WLAN_STA_BLOCK_BA
isn't necessarily effective since we don't know that the setup
isn't concurrently running and already got past the check.
Simply call ieee80211_sta_tear_down_BA_sessions() again in the
second part of station destruction, since at that point really
nothing else can hold a reference to the station any more.
Also revert the sdata checks since those are just misleading at
this point.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When compiling with clang 16.0.6 and CONFIG_FORTIFY_SOURCE=y, I've
noticed the following (somewhat confusing due to absence of an actual
source code location):
In file included from drivers/net/wireless/virtual/mac80211_hwsim.c:18:
In file included from ./include/linux/slab.h:16:
In file included from ./include/linux/gfp.h:7:
In file included from ./include/linux/mmzone.h:8:
In file included from ./include/linux/spinlock.h:56:
In file included from ./include/linux/preempt.h:79:
In file included from ./arch/x86/include/asm/preempt.h:9:
In file included from ./include/linux/thread_info.h:60:
In file included from ./arch/x86/include/asm/thread_info.h:53:
In file included from ./arch/x86/include/asm/cpufeature.h:5:
In file included from ./arch/x86/include/asm/processor.h:23:
In file included from ./arch/x86/include/asm/msr.h:11:
In file included from ./arch/x86/include/asm/cpumask.h:5:
In file included from ./include/linux/cpumask.h:12:
In file included from ./include/linux/bitmap.h:11:
In file included from ./include/linux/string.h:254:
./include/linux/fortify-string.h:592:4: warning: call to '__read_overflow2_field'
declared with 'warning' attribute: detected read beyond size of field (2nd
parameter); maybe use struct_group()? [-Wattribute-warning]
__read_overflow2_field(q_size_field, size);
The compiler actually complains on 'mac80211_hwsim_get_et_strings()' where
fortification logic inteprets call to 'memcpy()' as an attempt to copy the
whole 'mac80211_hwsim_gstrings_stats' array from its first member and so
issues an overread warning. This warning may be silenced by passing
an address of the whole array and not the first member to 'memcpy()'.
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Link: https://lore.kernel.org/r/20230829094140.234636-1-dmantipov@yandex.ru
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We currently call ieee80211_txq_teardown_flows() as part
of ieee80211_remove_interfaces(), but that's not really
right in case of HW registration failures, specifically
rate control. Call it separately to fix that issue.
Reported-by: Zhengchao Shao <shaozhengchao@huawei.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since we're now protecting everything with the wiphy mutex
(and were really using it for almost everything before),
there's no longer any real reason to have a separate wdev
mutex. It may feel better, but really has no value.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We now hold the wiphy mutex everywhere that we use or
needed the iflist_mtx, so we don't need this mutex any
more in mac80211. However, drivers may also iterate,
and in some cases (e.g. mt76) do so from high-priority
contexts. Thus, keep the mutex around but remove its
usage in mac80211 apart from those driver-visible parts
that are still needed.
Most of this change was done automatically with spatch,
with the parts that are still needed as described above
reverted manually.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
