- 31 Jul, 2019 7 commits
-
-
John Crispin authored
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.orgSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Add a strict start type so all new attributes starting from NL80211_ATTR_HE_OBSS_PD are validated strictly. Signed-off-by: -
John Crispin authored
Add the data structure, policy and parsing code allowing userland to send the OBSS PD information into the kernel. Signed-off-by:
-
Karthikeyan Periyasamy authored
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 authored
Over time, we really need to get rid of all of our global locking. One of the things needed is to use parallel_ops. This isn't really the most important (RTNL is much more important) but OTOH we just keep adding uses of genl_family_attrbuf() now. Use .parallel_ops to disallow this. Reviewed-By:
Denis Kenzior <denkenz@gmail.com> Link: https://lore.kernel.org/r/20190729143109.18683-1-johannes@sipsolutions.netSigned-off-by:
-
Johannes Berg authored
Give a proper boottime_ns value for netlink RX to avoid scan issues here. Signed-off-by:
-
Colin Ian King authored
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: 2ab45876 ("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.comSigned-off-by:
-
- 29 Jul, 2019 6 commits
-
-
John Crispin authored
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 authored
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:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20190729102342.8659-2-john@phrozen.org [use struct copy] Signed-off-by:
-
John Crispin authored
Johannes mentioned that the comment should not reference mac80211 as other subsystems might call the helper. Signed-off-by:
-
Michael Vassernis authored
Depending on the regulatory domain, leaving a DFS channel requires a new CAC to be performed when returning back to that channel. If needed, update dfs states after a driver channel switch. Signed-off-by:
Michael Vassernis <michael.vassernis@tandemg.com> Link: https://lore.kernel.org/r/20190729060024.5660-1-michael.vassernis@tandemg.comSigned-off-by:
-
Sergey Matyukevich authored
When associated BSS completes channel switch procedure, its channel record needs to be updated. The existing mac80211 solution was extended to cfg80211 in commit 5dc8cdce ("mac80211/cfg80211: update bss channel on channel switch"). However that solution still appears to be incomplete as it may lead to duplicated scan entries for associated BSS after channel switch. The root cause of the problem is as follows. Each BSS entry is included into the following data structures: - bss list rdev->bss_list - bss search tree rdev->bss_tree Updating BSS channel record without rebuilding bss_tree may break tree search since cmp_bss considers all of the following: channel, bssid, ssid. When BSS channel is updated, but its location in bss_tree is not updated, then subsequent search operations may fail to locate this BSS since they will be traversing bss_tree in wrong direction. As a result, for scan performed after associated BSS channel switch, cfg80211_bss_update may add the second entry for the same BSS to both bss_list and bss_tree, rather then update the existing one. To summarize, if BSS channel needs to be updated, then bss_tree should be rebuilt in order to put updated BSS entry into a proper location. This commit suggests the following straightforward solution: - if new entry has been already created for BSS after channel switch, then use its IEs to update known BSS entry and then remove new entry completely - use rb_erase/rb_insert_bss reinstall updated BSS in bss_tree - for nontransmit BSS entry, the whole transmit BSS hierarchy is updated Signed-off-by:
Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> Link: https://lore.kernel.org/r/20190726163922.27509-3-sergey.matyukevich.os@quantenna.comSigned-off-by:
-
Sergey Matyukevich authored
This patch implements minor refactoring for cfg80211_bss_update function. Code path for updating known BSS is extracted into dedicated cfg80211_update_known_bss function. Signed-off-by:
-
- 26 Jul, 2019 24 commits
-
-
Denis Kenzior authored
Include wiphy address setup in wiphy dumps and new wiphy events. The wiphy permanent address is exposed as ATTR_MAC. If addr_mask is setup, then it is included as ATTR_MAC_MASK attribute. If multiple addresses are available, then their are exposed in a nested ATTR_MAC_ADDRS array. This information is already exposed via sysfs, but it makes sense to include it in the wiphy dump as well. Signed-off-by:
-
Denis Kenzior authored
Commit 1c38c7f2 ("nl80211: send event when CMD_FRAME duration expires") added the possibility of NL80211_CMD_FRAME_WAIT_CANCEL being sent whenever the off-channel wait time associated with a CMD_FRAME completes. Document this in the uapi/linux/nl80211.h file. Signed-off-by:
-
Sven Eckelmann authored
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.orgSigned-off-by:
-
Lorenzo Bianconi authored
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.orgSigned-off-by:
-
John Crispin authored
Add support to mac80211 for parsing SPR elements as per P802.11ax_D4.0 section 9.4.2.241. Signed-off-by:
-
John Crispin authored
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 authored
This will allow use to report HE rates on the radiotap interface. Signed-off-by:
-
John Crispin authored
Right now struct ieee80211_tx_rate cannot hold HE rates. Lets use struct ieee80211_tx_status instead. This will also make the code future-proof for when we have EHT. Signed-off-by:
-
John Crispin authored
ADDBA_EXT IEs can be used to negotiate the BA fragmentation level. Signed-off-by:
-
Johannes Berg authored
If we just read jiffies over and over again, a non-transmitting entry may have a newer timestamp than the transmitting one, leading to possible confusion on expiry. Give them all the same timestamp when creating them. Signed-off-by:
-
Johannes Berg authored
Don't parse the multi-BSSID structures if we couldn't even create their transmitting BSS, this would confuse all of our tracking. This also means that non_tx_data->tx_bss will never be NULL, so we can clean up a little bit. Signed-off-by:
-
Johannes Berg authored
cfg80211_inform_single_bss_frame_data() doesn't need the non_tx_data data argument since it's always NULL. Signed-off-by:
-
Greg Kroah-Hartman authored
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20190703070142.GA29993@kroah.comSigned-off-by:
-
Alexander Wetzel authored
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.deSigned-off-by:
-
Alexander Wetzel authored
1) Drop IEEE80211_HW_EXT_KEY_ID_NATIVE and let drivers directly set the NL80211_EXT_FEATURE_EXT_KEY_ID flag. 2) Drop IEEE80211_HW_NO_AMPDU_KEYBORDER_SUPPORT and simply assume all drivers are unable to handle A-MPDU key borders. The new Extended Key ID API now requires all mac80211 drivers to set NL80211_EXT_FEATURE_EXT_KEY_ID when they implement set_key() and can handle Extended Key ID. For drivers not providing set_key() mac80211 itself enables Extended Key ID support, using the internal SW crypto services. Signed-off-by:
-
Alexander Wetzel authored
Prepare hwsim Extended Key ID support for a mac80211 API change. The mac80211 flag IEEE80211_HW_EXT_KEY_ID_NATIVE is being replaced by NL80211_EXT_FEATURE_EXT_KEY_ID which only must be set by drivers when they support HW crypto. This reverts commit cfe7007a ("mac80211_hwsim: Extended Key ID support"). Signed-off-by:
-
Erik Stromdahl authored
Since ieee80211_tx_dequeue() must not be called with softirqs enabled (i.e. from process context without proper disable of bottom halves), we add a wrapper that disables bottom halves before calling ieee80211_tx_dequeue() The new function is named ieee80211_tx_dequeue_ni() just as all other from-process-context versions found in mac80211. The documentation of ieee80211_tx_dequeue() is also updated so it mentions that the function should not be called from process context. Signed-off-by:
Erik Stromdahl <erik.stromdahl@gmail.com> Link: https://lore.kernel.org/r/20190617200140.6189-1-erik.stromdahl@gmail.comSigned-off-by:
-
Ard Biesheuvel authored
Instead of open coding the CCM aead mode in the driver, and invoking the AES block cipher block by block, use a ccm(aes) aead transform which already encapsulates this functionality. This is a cleaner use of the crypto API, and permits optimized implementations to be used, which are typically much faster and deal more efficiently with the SIMD register file, which usually needs to be preserved/restored in order to use special AES instructions. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Link: https://lore.kernel.org/r/20190617091901.7063-1-ard.biesheuvel@linaro.orgSigned-off-by:
-
Greg Kroah-Hartman authored
The remove_sta_debugfs callback in struct rate_control_ops is no longer used by any driver, as there is no need for it (the debugfs directory is already removed recursivly by the mac80211 core.) Because no one needs it, just remove it to keep anyone else from accidentally using it in the future. Cc: Johannes Berg <johannes@sipsolutions.net> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by:
-
Greg Kroah-Hartman authored
The .remove_sta_debugfs callback was not doing anything in this driver, so remove it as it is not needed. Signed-off-by:
-
Greg Kroah-Hartman authored
When calling debugfs functions, there is no need to ever check the return value. This driver was saving the debugfs file away to be removed at a later time. However, the 80211 core would delete the whole directory that the debugfs files are created in, after it asks the driver to do the deletion, so just rely on the 80211 core to do all of the cleanup for us, making us not need to keep a pointer to the dentries around at all. This cleans up the structure of the driver data a bit and makes the code a tiny bit smaller. Signed-off-by:
-
Emmanuel Grumbach authored
This low level driver can find it useful to get the vif when a remain on channel session is cancelled. iwlwifi will need this soon. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://lore.kernel.org/r/20190723180001.5828-1-emmanuel.grumbach@intel.comSigned-off-by:
-
Christophe JAILLET authored
This function name should be 'mac80211_hwsim_he_capab()' (s wand w switched) to be consistent with the rest of the file. Fix and use it. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/20190725191328.18010-1-christophe.jaillet@wanadoo.frSigned-off-by:
-
Jisheng Zhang authored
devm_platform_ioremap_resource() wraps platform_get_resource() and devm_ioremap_resource() in a single helper, let's use that helper to simplify the code. Signed-off-by:
Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 25 Jul, 2019 3 commits
-
-
David S. Miller authored
Tuong Lien says: ==================== tipc: link changeover issues This patch series is to resolve some issues found with the current link changeover mechanism, it also includes an optimization for the link synching. ==================== Signed-off-by: -
Tuong Lien authored
In conjunction with changing the interfaces' MTU (e.g. especially in the case of a bonding) where the TIPC links are brought up and down in a short time, a couple of issues were detected with the current link changeover mechanism: 1) When one link is up but immediately forced down again, the failover procedure will be carried out in order to failover all the messages in the link's transmq queue onto the other working link. The link and node state is also set to FAILINGOVER as part of the process. The message will be transmited in form of a FAILOVER_MSG, so its size is plus of 40 bytes (= the message header size). There is no problem if the original message size is not larger than the link's MTU - 40, and indeed this is the max size of a normal payload messages. However, in the situation above, because the link has just been up, the messages in the link's transmq are almost SYNCH_MSGs which had been generated by the link synching procedure, then their size might reach the max value already! When the FAILOVER_MSG is built on the top of such a SYNCH_MSG, its size will exceed the link's MTU. As a result, the messages are dropped silently and the failover procedure will never end up, the link will not be able to exit the FAILINGOVER state, so cannot be re-established. 2) The same scenario above can happen more easily in case the MTU of the links is set differently or when changing. In that case, as long as a large message in the failure link's transmq queue was built and fragmented with its link's MTU > the other link's one, the issue will happen (there is no need of a link synching in advance). 3) The link synching procedure also faces with the same issue but since the link synching is only started upon receipt of a SYNCH_MSG, dropping the message will not result in a state deadlock, but it is not expected as design. The 1) & 3) issues are resolved by the last commit that only a dummy SYNCH_MSG (i.e. without data) is generated at the link synching, so the size of a FAILOVER_MSG if any then will never exceed the link's MTU. For the 2) issue, the only solution is trying to fragment the messages in the failure link's transmq queue according to the working link's MTU so they can be failovered then. A new function is made to accomplish this, it will still be a TUNNEL PROTOCOL/FAILOVER MSG but if the original message size is too large, it will be fragmented & reassembled at the receiving side. Acked-by:
Ying Xue <ying.xue@windriver.com> Acked-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
Tuong Lien <tuong.t.lien@dektech.com.au> Signed-off-by:
-
Tuong Lien authored
This commit along with the next one are to resolve the issues with the link changeover mechanism. See that commit for details. Basically, for the link synching, from now on, we will send only one single ("dummy") SYNCH message to peer. The SYNCH message does not contain any data, just a header conveying the synch point to the peer. A new node capability flag ("TIPC_TUNNEL_ENHANCED") is introduced for backward compatible! Acked-by:
-
