summaryrefslogtreecommitdiff
path: root/net/mac80211
AgeCommit message (Collapse)Author
2019-10-07mac80211: fix scan when operating on DFS channels in ETSI domainsAaron Komisar
In non-ETSI regulatory domains scan is blocked when operating channel is a DFS channel. For ETSI, however, once DFS channel is marked as available after the CAC, this channel will remain available (for some time) even after leaving this channel. Therefore a scan can be done without any impact on the availability of the DFS channel as no new CAC is required after the scan. Enable scan in mac80211 in these cases. Signed-off-by: Aaron Komisar <aaron.komisar@tandemg.com> Link: https://lore.kernel.org/r/1570024728-17284-1-git-send-email-aaron.komisar@tandemg.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-10-07mac80211: accept deauth frames in IBSS modeJohannes Berg
We can process deauth frames and all, but we drop them very early in the RX path today - this could never have worked. Fixes: 2cc59e784b54 ("mac80211: reply to AUTH with DEAUTH if sta allocation fails in IBSS") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20191004123706.15768-2-luca@coelho.fi Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-10-04mac80211: Reject malformed SSID elementsWill Deacon
Although this shouldn't occur in practice, it's a good idea to bounds check the length field of the SSID element prior to using it for things like allocations or memcpy operations. Cc: <stable@vger.kernel.org> Cc: Kees Cook <keescook@chromium.org> Reported-by: Nicolas Waisman <nico@semmle.com> Signed-off-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20191004095132.15777-1-will@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-10-01mac80211: keep BHs disabled while calling drv_tx_wake_queue()Johannes Berg
Drivers typically expect this, as it's the case for almost all cases where this is called (i.e. from the TX path). Also, the code in mac80211 itself (if the driver calls ieee80211_tx_dequeue()) expects this as it uses this_cpu_ptr() without additional protection. This should fix various reports of the problem: https://bugzilla.kernel.org/show_bug.cgi?id=204127 https://lore.kernel.org/linux-wireless/CAN5HydrWb3o_FE6A1XDnP1E+xS66d5kiEuhHfiGKkLNQokx13Q@mail.gmail.com/ https://lore.kernel.org/lkml/nycvar.YFH.7.76.1909111238470.473@cbobk.fhfr.pm/ Cc: stable@vger.kernel.org Reported-and-tested-by: Jiri Kosina <jkosina@suse.cz> Reported-by: Aaron Hill <aa1ronham@gmail.com> Reported-by: Lukas Redlinger <rel+kernel@agilox.net> Reported-by: Oleksii Shevchuk <alxchk@gmail.com> Fixes: 21a5d4c3a45c ("mac80211: add stop/start logic for software TXQs") Link: https://lore.kernel.org/r/1569928763-I3e8838c5ecad878e59d4a94eb069a90f6641461a@changeid Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-10-01mac80211: fix txq null pointer dereferenceMiaoqing Pan
If the interface type is P2P_DEVICE or NAN, read the file of '/sys/kernel/debug/ieee80211/phyx/netdev:wlanx/aqm' will get a NULL pointer dereference. As for those interface type, the pointer sdata->vif.txq is NULL. Unable to handle kernel NULL pointer dereference at virtual address 00000011 CPU: 1 PID: 30936 Comm: cat Not tainted 4.14.104 #1 task: ffffffc0337e4880 task.stack: ffffff800cd20000 PC is at ieee80211_if_fmt_aqm+0x34/0xa0 [mac80211] LR is at ieee80211_if_fmt_aqm+0x34/0xa0 [mac80211] [...] Process cat (pid: 30936, stack limit = 0xffffff800cd20000) [...] [<ffffff8000b7cd00>] ieee80211_if_fmt_aqm+0x34/0xa0 [mac80211] [<ffffff8000b7c414>] ieee80211_if_read+0x60/0xbc [mac80211] [<ffffff8000b7ccc4>] ieee80211_if_read_aqm+0x28/0x30 [mac80211] [<ffffff80082eff94>] full_proxy_read+0x2c/0x48 [<ffffff80081eef00>] __vfs_read+0x2c/0xd4 [<ffffff80081ef084>] vfs_read+0x8c/0x108 [<ffffff80081ef494>] SyS_read+0x40/0x7c Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org> Acked-by: Toke Høiland-Jørgensen <toke@redhat.com> Link: https://lore.kernel.org/r/1569549796-8223-1-git-send-email-miaoqing@codeaurora.org [trim useless data from commit message] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-09-15Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller
Minor overlapping changes in the btusb and ixgbe drivers. Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-11mac80211: Do not send Layer 2 Update frame before authorizationJouni Malinen
The Layer 2 Update frame is used to update bridges when a station roams to another AP even if that STA does not transmit any frames after the reassociation. This behavior was described in IEEE Std 802.11F-2003 as something that would happen based on MLME-ASSOCIATE.indication, i.e., before completing 4-way handshake. However, this IEEE trial-use recommended practice document was published before RSN (IEEE Std 802.11i-2004) and as such, did not consider RSN use cases. Furthermore, IEEE Std 802.11F-2003 was withdrawn in 2006 and as such, has not been maintained amd should not be used anymore. Sending out the Layer 2 Update frame immediately after association is fine for open networks (and also when using SAE, FT protocol, or FILS authentication when the station is actually authenticated by the time association completes). However, it is not appropriate for cases where RSN is used with PSK or EAP authentication since the station is actually fully authenticated only once the 4-way handshake completes after authentication and attackers might be able to use the unauthenticated triggering of Layer 2 Update frame transmission to disrupt bridge behavior. Fix this by postponing transmission of the Layer 2 Update frame from station entry addition to the point when the station entry is marked authorized. Similarly, send out the VLAN binding update only if the STA entry has already been authorized. Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-11Merge tag 'mac80211-next-for-davem-2019-09-11' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== We have a number of changes, but things are settling down: * a fix in the new 6 GHz channel support * a fix for recent minstrel (rate control) updates for an infinite loop * handle interface type changes better wrt. management frame registrations (for management frames sent to userspace) * add in-BSS RX time to survey information * handle HW rfkill properly if !CONFIG_RFKILL * send deauth on IBSS station expiry, to avoid state mismatches * handle deferred crypto tailroom updates in mac80211 better when device restart happens * fix a spectre-v1 - really a continuation of a previous patch * advertise NL80211_CMD_UPDATE_FT_IES as supported if so * add some missing parsing in VHT extended NSS support * support HE in mac80211_hwsim * let mac80211 drivers determine the max MTU themselves along with the usual cleanups etc. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-11mac80211: allow drivers to set max MTUWen Gong
Make it possibly for drivers to adjust the default max_mtu by storing it in the hardware struct and using that value for all interfaces. Signed-off-by: Wen Gong <wgong@codeaurora.org> Link: https://lore.kernel.org/r/1567738137-31748-1-git-send-email-wgong@codeaurora.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-09-11mac80211: IBSS: send deauth when expiring inactive STAsJohannes Berg
When we expire an inactive station, try to send it a deauth. This helps if it's actually still around, and just has issues with beacon distribution (or we do), and it will not also remove us. Then, if we have shared state, this may not be reset properly, causing problems; for example, we saw a case where aggregation sessions weren't removed properly (due to the TX start being offloaded to firmware and it relying on deauth for stop), causing a lot of traffic to get lost due to the SN reset after remove/add of the peer. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20190830112451.21655-9-luca@coelho.fi Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-09-11mac80211: don't check if key is NULL in ieee80211_key_link()Luca Coelho
We already assume that key is not NULL and dereference it in a few other places before we check whether it is NULL, so the check is unnecessary. Remove it. Fixes: 96fc6efb9ad9 ("mac80211: IEEE 802.11 Extended Key ID support") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20190830112451.21655-8-luca@coelho.fi Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-09-11mac80211: clear crypto tx tailroom counter upon keys enableLior Cohen
In case we got a fw restart while roaming from encrypted AP to non-encrypted one, we might end up with hitting a warning on the pending counter crypto_tx_tailroom_pending_dec having a non-zero value. The following comment taken from net/mac80211/key.c explains the rational for the delayed tailroom needed: /* * The reason for the delayed tailroom needed decrementing is to * make roaming faster: during roaming, all keys are first deleted * and then new keys are installed. The first new key causes the * crypto_tx_tailroom_needed_cnt to go from 0 to 1, which invokes * the cost of synchronize_net() (which can be slow). Avoid this * by deferring the crypto_tx_tailroom_needed_cnt decrementing on * key removal for a while, so if we roam the value is larger than * zero and no 0->1 transition happens. * * The cost is that if the AP switching was from an AP with keys * to one without, we still allocate tailroom while it would no * longer be needed. However, in the typical (fast) roaming case * within an ESS this usually won't happen. */ The next flow lead to the warning eventually reported as a bug: 1. Disconnect from encrypted AP 2. Set crypto_tx_tailroom_pending_dec = 1 for the key 3. Schedule work 4. Reconnect to non-encrypted AP 5. Add a new key, setting the tailroom counter = 1 6. Got FW restart while pending counter is set ---> hit the warning While on it, the ieee80211_reset_crypto_tx_tailroom() func was merged into its single caller ieee80211_reenable_keys (previously called ieee80211_enable_keys). Also, we reset the crypto_tx_tailroom_pending_dec and remove the counters warning as we just reset both. Signed-off-by: Lior Cohen <lior2.cohen@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20190830112451.21655-7-luca@coelho.fi Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-09-11mac80211: remove unnecessary key conditionJohannes Berg
When we reach this point, the key cannot be NULL. Remove the condition that suggests otherwise. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20190830112451.21655-6-luca@coelho.fi Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-09-11mac80211: list features in WEP/TKIP disable in better orderJohannes Berg
"HE/HT/VHT" is a bit confusing since really the order of development (and possible support) is different - change this to "HT/VHT/HE". Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20190830112451.21655-4-luca@coelho.fi Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-09-11mac80211: vht: add support VHT EXT NSS BW in parsing VHTMordechay Goodstein
This fixes was missed in parsing the vht capabilities max bw support. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Fixes: e80d642552a3 ("mac80211: copy VHT EXT NSS BW Support/Capable data to station") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20190830114057.22197-1-luca@coelho.fi Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-09-02Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller
r8152 conflicts are the NAPI fixes in 'net' overlapping with some tasklet stuff in net-next Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-29mac80211: Correctly set noencrypt for PAE framesDenis Kenzior
The noencrypt flag was intended to be set if the "frame was received unencrypted" according to include/uapi/linux/nl80211.h. However, the current behavior is opposite of this. Cc: stable@vger.kernel.org Fixes: 018f6fbf540d ("mac80211: Send control port frames over nl80211") Signed-off-by: Denis Kenzior <denkenz@gmail.com> Link: https://lore.kernel.org/r/20190827224120.14545-3-denkenz@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-08-29mac80211: Don't memset RXCB prior to PAE interceptDenis Kenzior
In ieee80211_deliver_skb_to_local_stack intercepts EAPoL frames if mac80211 is configured to do so and forwards the contents over nl80211. During this process some additional data is also forwarded, including whether the frame was received encrypted or not. Unfortunately just prior to the call to ieee80211_deliver_skb_to_local_stack, skb->cb is cleared, resulting in incorrect data being exposed over nl80211. Fixes: 018f6fbf540d ("mac80211: Send control port frames over nl80211") Cc: stable@vger.kernel.org Signed-off-by: Denis Kenzior <denkenz@gmail.com> Link: https://lore.kernel.org/r/20190827224120.14545-2-denkenz@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-08-27Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller
Minor conflict in r8169, bug fix had two versions in net and net-next, take the net-next hunks. Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-22mac80211: minstrel_ht: fix infinite loop because supported is not being shiftedColin Ian King
Currently the for-loop will spin forever if variable supported is non-zero because supported is never changed. Fix this by adding in the missing right shift of supported. Addresses-Coverity: ("Infinite loop") Fixes: 48cb39522a9d ("mac80211: minstrel_ht: improve rate probing for devices with static fallback") Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20190822122034.28664-1-colin.king@canonical.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-08-21mac80211: minstrel_ht: improve rate probing for devices with static fallbackFelix Fietkau
On some devices that only support static rate fallback tables sending rate control probing packets can be really expensive. Probing lower rates can already hurt throughput quite a bit. What hurts even more is the fact that on mt76x0/mt76x2, single probing packets can only be forced by directing packets at a different internal hardware queue, which causes some heavy reordering and extra latency. The reordering issue is mainly problematic while pushing lots of packets to a particular station. If there is little activity, the overhead of probing is neglegible. The static fallback behavior is designed to pretty much only handle rate control algorithms that use only a very limited set of rates on which the algorithm switches up/down based on packet error rate. In order to better support that kind of hardware, this patch implements a different approach to rate probing where it switches to a slightly higher rate, waits for tx status feedback, then updates the stats and switches back to the new max throughput rate. This only triggers above a packet rate of 100 per stats interval (~50ms). For that kind of probing, the code has to reduce the set of probing rates a lot more compared to single packet probing, so it uses only one packet per MCS group which is either slightly faster, or as close as possible to the max throughput rate. This allows switching between similar rates with different numbers of streams. The algorithm assumes that the hardware will work its way lower within an MCS group in case of retransmissions, so that lower rates don't have to be probed by the high packets per second rate probing code. To further reduce the search space, it also does not probe rates with lower channel bandwidth than the max throughput rate. At the moment, these changes will only affect mt76x0/mt76x2. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20190820095449.45255-4-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-08-21mac80211: minstrel_ht: fix default max throughput rate indexesFelix Fietkau
Use the first supported rate instead of 0 (which can be invalid) Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20190820095449.45255-3-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-08-21mac80211: minstrel_ht: reduce unnecessary rate probing attemptsFelix Fietkau
On hardware with static fallback tables (e.g. mt76x2), rate probing attempts can be very expensive. On such devices, avoid sampling rates slower than the per-group max throughput rate, based on the assumption that the fallback table will take care of probing lower rates within that group if the higher rates fail. To further reduce unnecessary probing attempts, skip duplicate attempts on rates slower than the max throughput rate. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20190820095449.45255-2-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-08-21mac80211: minstrel_ht: fix per-group max throughput rate initializationFelix Fietkau
The group number needs to be multiplied by the number of rates per group to get the full rate index Fixes: 5935839ad735 ("mac80211: improve minstrel_ht rate sorting by throughput & probability") Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20190820095449.45255-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-08-21nl80211: Add support for EDMG channelsAlexei Avshalom Lazar
802.11ay specification defines Enhanced Directional Multi-Gigabit (EDMG) STA and AP which allow channel bonding of 2 channels and more. Introduce new NL attributes that are needed for enabling and configuring EDMG support. Two new attributes are used by kernel to publish driver's EDMG capabilities to the userspace: NL80211_BAND_ATTR_EDMG_CHANNELS - bitmap field that indicates the 2.16 GHz channel(s) that are supported by the driver. When this attribute is not set it means driver does not support EDMG. NL80211_BAND_ATTR_EDMG_BW_CONFIG - represent the channel bandwidth configurations supported by the driver. Additional two new attributes are used by the userspace for connect command and for AP configuration: NL80211_ATTR_WIPHY_EDMG_CHANNELS NL80211_ATTR_WIPHY_EDMG_BW_CONFIG New rate info flag - RATE_INFO_FLAGS_EDMG, can be reported from driver and used for bitrate calculation that will take into account EDMG according to the 802.11ay specification. Signed-off-by: Alexei Avshalom Lazar <ailizaro@codeaurora.org> Link: https://lore.kernel.org/r/1566138918-3823-2-git-send-email-ailizaro@codeaurora.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-08-21mac80211: fix possible NULL pointerderef in obss pd codeJohn Crispin
he_spr_ie_elem is dereferenced before the NULL check. fix this by moving the assignment after the check. fixes commit 697f6c507c74 ("mac80211: propagate HE operation info into bss_conf") This was reported by the static code checker. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: John Crispin <john@phrozen.org> Link: https://lore.kernel.org/r/20190813070712.25509-1-john@phrozen.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-08-21mac80211: add assoc-at supportBen Greear
Report timestamp for when sta becomes associated. Signed-off-by: Ben Greear <greearb@candelatech.com> Link: https://lore.kernel.org/r/20190809180001.26393-2-greearb@candelatech.com [fix ktime_get_boot_ns() to ktime_get_boottime_ns(), assoc_at type to u64] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-08-21nl80211: add 6GHz band definition to enum nl80211_bandArend van Spriel
In the 802.11ax specification a new band is introduced, which is also proposed by FCC for unlicensed use. This band is referred to as 6GHz spanning frequency range from 5925 to 7125 MHz. Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by: Leon Zegers <leon.zegers@broadcom.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://lore.kernel.org/r/1564745465-21234-2-git-send-email-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-08-21mac80211: add missing length field increment when generating Radiotap headerJohn Crispin
The code generating the Tx Radiotap header when using tx_status_ext was missing a field increment after setting the VHT bandwidth. Fixes: 3d07ffcaf320 ("mac80211: add struct ieee80211_tx_status support to ieee80211_add_tx_radiotap_header") Signed-off-by: John Crispin <john@phrozen.org> Link: https://lore.kernel.org/r/20190807075949.32414-4-john@phrozen.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-08-21mac80211: 80Mhz was not reported properly when using tx_status_extJohn Crispin
When reporting 80MHz, we need to set 4 and not 2 inside the corresponding field inside the Tx Radiotap header. Fixes: 3d07ffcaf320 ("mac80211: add struct ieee80211_tx_status support to ieee80211_add_tx_radiotap_header") Signed-off-by: John Crispin <john@phrozen.org> Link: https://lore.kernel.org/r/20190807075949.32414-3-john@phrozen.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-08-21mac80211: fix bad guard when reporting legacy ratesJohn Crispin
When reporting legacy rates inside the TX Radiotap header we need to split the check between "uses tx_statua_ext" and "is legacy rate". Not doing so would make the code drop into the !tx_status_ext path. Fixes: 3d07ffcaf320 ("mac80211: add struct ieee80211_tx_status support to ieee80211_add_tx_radiotap_header") Signed-off-by: John Crispin <john@phrozen.org> Link: https://lore.kernel.org/r/20190807075949.32414-2-john@phrozen.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-08-21mac80211: fix TX legacy rate reporting when tx_status_ext is usedJohn Crispin
The RX Radiotap header length was not calculated properly when reporting legacy rates using tx_status_ext. Fixes: 3d07ffcaf320 ("mac80211: add struct ieee80211_tx_status support to ieee80211_add_tx_radiotap_header") Signed-off-by: John Crispin <john@phrozen.org> Link: https://lore.kernel.org/r/20190807075949.32414-1-john@phrozen.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-08-21mac80211: fix possible sta leakJohannes Berg
If TDLS station addition is rejected, the sta memory is leaked. Avoid this by moving the check before the allocation. Cc: stable@vger.kernel.org Fixes: 7ed5285396c2 ("mac80211: don't initiate TDLS connection if station is not associated to AP") Link: https://lore.kernel.org/r/20190801073033.7892-1-johannes@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-08-06Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller
Just minor overlapping changes in the conflicts here. Signed-off-by: David S. Miller <davem@davemloft.net>
2019-07-31mac80211: HE STA disassoc due to QOS NULL not sentShay Bar
In case of HE AP-STA link, ieee80211_send_nullfunc() will not send the QOS NULL packet to check if AP is still associated. In this case, probe_send_count will be non-zero and ieee80211_sta_work() will later disassociate the AP, even though no packet was ever sent. Fix this by decrementing probe_send_count and not calling ieee80211_send_nullfunc() in case of HE link, so that we still wait for some time for the AP beacon to reappear and don't disconnect right away. Signed-off-by: Shay Bar <shay.bar@celeno.com> Link: https://lore.kernel.org/r/20190703131848.22879-1-shay.bar@celeno.com [clarify commit message] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-07-31mac80211: allow setting spatial reuse parameters from bss_confJohn Crispin
Store the OBSS PD parameters inside bss_conf when bringing up an AP and/or when a station connects to an AP. This allows the driver to configure the HW accordingly. Signed-off-by: John Crispin <john@phrozen.org> Link: https://lore.kernel.org/r/20190730163701.18836-3-john@phrozen.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-07-31mac80211: reject zero MAC address in add stationKarthikeyan Periyasamy
This came up in fuzz testing, and really we don't consider all-zeroes to be a valid MAC address in most places, so also reject it here to avoid confusion later on. Signed-off-by: Karthikeyan Periyasamy <periyasa@codeaurora.org> Link: https://lore.kernel.org/r/1563959770-21570-1-git-send-email-periyasa@codeaurora.org [rewrite commit message] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-07-31mac80211: add missing null return check from call to ieee80211_get_sbandColin Ian King
The return from ieee80211_get_sband can potentially be a null pointer, so it seems prudent to add a null check to avoid a null pointer dereference on sband. Addresses-Coverity: ("Dereference null return") Fixes: 2ab45876756f ("mac80211: add support for the ADDBA extension element") Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20190730143205.14261-1-colin.king@canonical.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-07-30Revert "mac80211: set NETIF_F_LLTX when using intermediate tx queues"Johannes Berg
Revert this for now, it has been reported multiple times that it completely breaks connectivity on various devices. Cc: stable@vger.kernel.org Fixes: 8dbb000ee73b ("mac80211: set NETIF_F_LLTX when using intermediate tx queues") Reported-by: Jean Delvare <jdelvare@suse.de> Reported-by: Peter Lebbing <peter@digitalbrains.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-07-29mac80211: add support for the ADDBA extension elementJohn Crispin
HE allows peers to negotiate the aggregation fragmentation level to be used during transmission. The level can be 1-3. The Ext element is added behind the ADDBA request inside the action frame. The responder will then reply with the same level or a lower one if the requested one is not supported. This patch only handles the negotiation part as the ADDBA frames get passed to the ATH11k firmware, which does the rest of the magic for us aswell as generating the requests. Signed-off-by: Shashidhar Lakkavalli <slakkavalli@datto.com> Signed-off-by: John Crispin <john@phrozen.org> Link: https://lore.kernel.org/r/20190729104512.27615-1-john@phrozen.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-07-29mac80211: propagate HE operation info into bss_confJohn Crispin
Upon a successful assoc a station shall store the content of the HE operation element inside bss_conf so that the driver can setup the hardware accordingly. Signed-off-by: Shashidhar Lakkavalli <slakkavalli@datto.com> Signed-off-by: John Crispin <john@phrozen.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20190729102342.8659-2-john@phrozen.org [use struct copy] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-07-29mac80211: don't WARN on short WMM parameters from APBrian Norris
In a very similar spirit to commit c470bdc1aaf3 ("mac80211: don't WARN on bad WMM parameters from buggy APs"), an AP may not transmit a fully-formed WMM IE. For example, it may miss or repeat an Access Category. The above loop won't catch that and will instead leave one of the four ACs zeroed out. This triggers the following warning in drv_conf_tx() wlan0: invalid CW_min/CW_max: 0/0 and it may leave one of the hardware queues unconfigured. If we detect such a case, let's just print a warning and fall back to the defaults. Tested with a hacked version of hostapd, intentionally corrupting the IEs in hostapd_eid_wmm(). Cc: stable@vger.kernel.org Signed-off-by: Brian Norris <briannorris@chromium.org> Link: https://lore.kernel.org/r/20190726224758.210953-1-briannorris@chromium.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-07-26mac80211: implement HE support for meshSven Eckelmann
Implement the basics required for supporting high efficiency with mesh: include HE information elements in beacons, probe responses, and peering action frames, and check for compatible HE configurations when peering. Signed-off-by: Sven Eckelmann <seckelmann@datto.com> Forwarded: https://patchwork.kernel.org/patch/11029299/ Link: https://lore.kernel.org/r/20190724163359.3507-2-sven@narfation.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-07-26mac80211: add IEEE80211_KEY_FLAG_GENERATE_MMIE to ieee80211_key_flagsLorenzo Bianconi
Add IEEE80211_KEY_FLAG_GENERATE_MMIE flag to ieee80211_key_flags in order to allow the driver to notify mac80211 to generate MMIE and that it requires sequence number generation only. This is a preliminary patch to add BIP_CMAC_128 hw support to mt7615 driver Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/dfe275f9aa0f1cc6b33085f9efd5d8447f68ad13.1563228405.git.lorenzo@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-07-26mac80211: HE: add Spatial Reuse element parsing supportJohn Crispin
Add support to mac80211 for parsing SPR elements as per P802.11ax_D4.0 section 9.4.2.241. Signed-off-by: Shashidhar Lakkavalli <slakkavalli@datto.com> Signed-off-by: John Crispin <john@phrozen.org> Link: https://lore.kernel.org/r/20190618061915.7102-2-john@phrozen.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-07-26mac80211: add struct ieee80211_tx_status support to ↵John Crispin
ieee80211_add_tx_radiotap_header Add support to ieee80211_add_tx_radiotap_header() for handling rates reported via ieee80211_tx_status. This allows us to also report HE rates. Signed-off-by: John Crispin <john@phrozen.org> Link: https://lore.kernel.org/r/20190714154419.11854-4-john@phrozen.org [remove text about 60 GHz, mac80211 doesn't support it, fix endianness issue] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-07-26{nl,mac}80211: fix interface combinations on crypto controlled devicesManikanta Pubbisetty
Commit 33d915d9e8ce ("{nl,mac}80211: allow 4addr AP operation on crypto controlled devices") has introduced a change which allows 4addr operation on crypto controlled devices (ex: ath10k). This change has inadvertently impacted the interface combinations logic on such devices. General rule is that software interfaces like AP/VLAN should not be listed under supported interface combinations and should not be considered during validation of these combinations; because of the aforementioned change, AP/VLAN interfaces(if present) will be checked against interfaces supported by the device and blocks valid interface combinations. Consider a case where an AP and AP/VLAN are up and running; when a second AP device is brought up on the same physical device, this AP will be checked against the AP/VLAN interface (which will not be part of supported interface combinations of the device) and blocks second AP to come up. Add a new API cfg80211_iftype_allowed() to fix the problem, this API works for all devices with/without SW crypto control. Signed-off-by: Manikanta Pubbisetty <mpubbise@codeaurora.org> Fixes: 33d915d9e8ce ("{nl,mac}80211: allow 4addr AP operation on crypto controlled devices") Link: https://lore.kernel.org/r/1563779690-9716-1-git-send-email-mpubbise@codeaurora.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-07-26mac80211: propagate struct ieee80211_tx_status into ieee80211_tx_monitor()John Crispin
This will allow use to report HE rates on the radiotap interface. Signed-off-by: John Crispin <john@phrozen.org> Link: https://lore.kernel.org/r/20190714154419.11854-3-john@phrozen.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-07-26mac80211: add support for parsing ADDBA_EXT IEsJohn Crispin
ADDBA_EXT IEs can be used to negotiate the BA fragmentation level. Signed-off-by: John Crispin <john@phrozen.org> Link: https://lore.kernel.org/r/20190713163642.18491-2-john@phrozen.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-07-26mac80211: AMPDU handling for rekeys with Extended Key IDAlexander Wetzel
Extended Key ID allows A-MPDU sessions while rekeying as long as each A-MPDU aggregates only MPDUs with one keyid together. Drivers able to segregate MPDUs accordingly can tell mac80211 to not stop A-MPDU sessions when rekeying by setting the new flag IEEE80211_HW_AMPDU_KEYBORDER_SUPPORT. Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de> Link: https://lore.kernel.org/r/20190629195015.19680-3-alexander@wetzel-home.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>