- 22 9月, 2015 1 次提交
-
-
由 Emmanuel Grumbach 提交于
Advertise the capability to send A-MSDU within A-MPDU in the AddBA request sent by mac80211. Let the driver know about the peer's capabilities. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 26 8月, 2015 1 次提交
-
-
由 Michal Kazior 提交于
Kernel would complain about leaving a held lock after going back to userspace and would subsequently deadlock. Fixes: e04cafbc ("ath10k: fix peer limit enforcement") Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 17 8月, 2015 3 次提交
-
-
由 Michal Kazior 提交于
Apparently it's not safe to install both pairwise and groupwise keys on AP vdevs as it can cause traffic to stop working in some multi-vif (WPA+WEP) cases. Fixes: ce90b271 ("ath10k: fix multiple key static wep with ibss") Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
Vif's vdev_id is used as queue number. However due to the tx pausing design in ath10k it was possible for a new interface to be created with its tx queue stopped (via ieee80211_stop_queues). This could in turn leave the interface inoperable until ath10k_mac_tx_unlock() was called. This problem only affected multi-vif scenarios when new interfaces were created some time later after other interfaces have been running for some time and had Tx queue full at some point prior. Possible manifestation of the bug was authentication timeout for a client vif. Fixes: 96d828d4 ("ath10k: rework tx queue locking") Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
Once HTT Tx queue got full offchannel queue was stopped and never woken up again. This broke, e.g. P2P. This could be reproduced after running a lot of traffic enough to saturate 100% of the driver Tx queue and then trying to send offchannel traffic. Fixes: 96d828d4 ("ath10k: rework tx queue locking") Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 13 8月, 2015 6 次提交
-
-
由 Michal Kazior 提交于
Firmware peer entries are involved in internal firmware vdev structures. This was not accounted for and could lead firmware to crash due to asking it to do more than it could. Fixes: 039a0051 ("ath10k: allocate fw resources for iface combinations") Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
If peer creation failed during offchannel Tx the driver attempted to delete the peer nonetheless. This caused the ar->num_peers counter to be incorrectly decremented. This subsequently could cause the counter to drop below 0 and also eventually lead to firmware crash because host would think there are less peer entries created in firmware then there really were. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Vivek Natarajan 提交于
This patch enables MU-MIMO transmit beamforming support for QCA99X0 chipsets. Signed-off-by: NVivek Natarajan <nataraja@qti.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Vivek Natarajan 提交于
qca61x4 uses the vdev param as a sole sufficient configuration for txbf while qca99x0 enables txbf during peer assoc by combining the vdev param value with peer assoc's vht capabilities This patch gets the appropriate txbf configuration scheme before passing the wmi command to enable the same in the firmware. Signed-off-by: NVivek Natarajan <nataraja@qti.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
Even though there's a WMI enum for fragmentation threshold no known firmware actually implements it. Moreover it is not possible to rely frame fragmentation to mac80211 because firmware clears the "more fragments" bit in frame control making it impossible for remote devices to reassemble frames. Hence implement a dummy callback just to say fragmentation isn't supported. This effectively prevents mac80211 from doing frame fragmentation in software. This fixes Tx becoming broken after setting fragmentation threshold. Fixes: 1010ba4c ("ath10k: unregister and remove frag_threshold callback") Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
Commit 1010ba4c ("ath10k: unregister and remove frag_threshold callback") didn't remove all instances of (futile) fragmentation threshold configuration. No known firmware supports the parameter so don't even bother setting it. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 29 7月, 2015 1 次提交
-
-
由 David Liu 提交于
This patch enables raw Rx/Tx encap mode to support software based crypto engine. This patch introduces a new module param 'cryptmode'. cryptmode: 0: Use hardware crypto engine globally with native Wi-Fi mode TX/RX encapsulation to the firmware. This is the default mode. 1: Use sofware crypto engine globally with raw mode TX/RX encapsulation to the firmware. Known limitation: A-MSDU must be disabled for RAW Tx encap mode to perform well when heavy traffic is applied. Testing: (by Michal Kazior <michal.kazior@tieto.com>) a) Performance Testing cryptmode=1 ap=qca988x sta=killer1525 killer1525 -> qca988x 194.496 mbps [tcp1 ip4] killer1525 -> qca988x 238.309 mbps [tcp5 ip4] killer1525 -> qca988x 266.958 mbps [udp1 ip4] killer1525 -> qca988x 477.468 mbps [udp5 ip4] qca988x -> killer1525 301.378 mbps [tcp1 ip4] qca988x -> killer1525 297.949 mbps [tcp5 ip4] qca988x -> killer1525 331.351 mbps [udp1 ip4] qca988x -> killer1525 371.528 mbps [udp5 ip4] ap=killer1525 sta=qca988x qca988x -> killer1525 331.447 mbps [tcp1 ip4] qca988x -> killer1525 328.783 mbps [tcp5 ip4] qca988x -> killer1525 375.309 mbps [udp1 ip4] qca988x -> killer1525 403.379 mbps [udp5 ip4] killer1525 -> qca988x 203.689 mbps [tcp1 ip4] killer1525 -> qca988x 222.339 mbps [tcp5 ip4] killer1525 -> qca988x 264.199 mbps [udp1 ip4] killer1525 -> qca988x 479.371 mbps [udp5 ip4] Note: - only open network tested for RAW vs nwifi performance comparison - killer1525 (qca6174 hw2.2) is 2x2 device (hence max 866mbps) - used iperf - OTA, devices a few cm apart from each other, no shielding - tcpX/udpX, X - means number of threads used Overview: - relative Tx performance drop is seen but is within reasonable and expected threshold (A-MSDU must be disabled with RAW Tx) b) Connectivity Testing cryptmode=1 ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta OK ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br OK ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br1vlan OK ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br1vlan OK ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br1vlan OK Note: - each test takes all possible endpoint pairs and pings - each pair-ping flushes arp table - ip6 is used c) Testbed Topology: 1ap1sta: [ap] ---- [sta] endpoints: ap, sta 1ap1sta2br: [veth0] [ap] ---- [sta] [veth2] | | | | [veth1] | \ [veth3] \ / \ / [br0] [br1] endpoints: veth0, veth2, br0, br1 note: STA works in 4addr mode, AP has wds_sta=1 1ap1sta2br1vlan: [veth0] [ap] ---- [sta] [veth2] | | | | [veth1] | \ [veth3] \ / \ / [br0] [br1] | | [vlan0_id2] [vlan1_id2] endpoints: vlan0_id2, vlan1_id2 note: STA works in 4addr mode, AP has wds_sta=1 Credits: Thanks to Michal Kazior <michal.kazior@tieto.com> who helped find the amsdu issue, contributed a workaround (already squashed into this patch), and contributed the throughput and connectivity tests results. Signed-off-by: NDavid Liu <cfliu.tw@gmail.com> Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Tested-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 24 7月, 2015 1 次提交
-
-
由 Maninder Singh 提交于
chandef is initialized with NULL and on the very next line, we are using it to get channel, which is not correct. Channel should be initialized after obtaining chandef. Found by cppcheck: ath/ath10k/mac.c:839]: (error) Possible null pointer dereference: chandef Signed-off-by: NManinder Singh <maninder1.s@samsung.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 12 7月, 2015 6 次提交
-
-
由 Michal Kazior 提交于
Concurrent AP/GO operation on different channels isn't really supported well by the firmware so it's better to remove it from being advertised. Also tune the way station and p2p client interface limits are expressed to allow station + 2x p2p client or station + p2p client + p2p go. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
Whenever any vdev was supposed to be paused all Tx queues were stopped (except offchannel) instead of only these associated with the given vdev. This caused subtle issues with multi-channel/multi-vif scenarios, e.g. authentication of station vif could sometimes fail depending on fw tx pause request timing. Fixes: b4aa539d ("ath10k: implement tx pause wmi event") Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
Psmode can be forcefully enabled when vdev isn't started. It isn't guaranteed that mac80211 will re-issue psmode setting after vdev is started unless actual bss_conf.ps value has changed. Even if this doesn't fix any problems now it may prevent future breakage. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
The expiration function must not be called when roc is explicitly cancelled by mac80211. However since fcf98446 ("ath10k: fix hw roc expiration") the notification was never sent when roc actually expired. This fixes some P2P connection setup issues. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
Further testing proved that multi-channel AP+STA on QCA6174 with RM.2.0-00088 should have powersave force-disabled to avoid beacon misses/skipping on either side which in turn could disrupt communication. Since AP never has arvif->ps don't even bother checking it. Other combinations may be broken as well so disallow powersave with multivif outright unless firmware advertises otherwise. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
mac80211 already does provide complete IEs for Probe Requests for hw scan and ath10k firmware was appending duplicate Supported Rates IEs unnecessarily. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 02 7月, 2015 1 次提交
-
-
由 Raja Mani 提交于
10.4 fw supports upto 16 interface in ap mode and 1 interface in station mode, overall total interfaces supported are 16 interfaces. Populate this limit in wiphy->iface_combinations. Signed-off-by: NRaja Mani <rmani@qti.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 30 6月, 2015 1 次提交
-
-
由 Raja Mani 提交于
qca99X0 chip uses firmware version 10.4. Define a new macro ATH10K_FW_WMI_OP_VERSION_10_4 for 10.4 firmware and include in switch cases where ATH10K_FW_WMI_OP_VERSION_* is used to avoid compilation error. Signed-off-by: NRaja Mani <rmani@qti.qualcomm.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 16 6月, 2015 2 次提交
-
-
由 Nicholas Mc Guire 提交于
wait_event_timeout(), introduced in 'commit 5e3dd157 ("ath10k: mac80211 driver for Qualcomm Atheros 802.11ac CQA98xx devices")' never returns < 0 so the only failure condition to be checked is ==0 (timeout). Further the return type is long not int - an appropriately named variable is added and the assignments fixed up. Signed-off-by: NNicholas Mc Guire <hofrat@osadl.org> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Janusz Dziedzic 提交于
Enable VHT support for IBSS, while mac80211/cfg80211 and wpa_supplicant already support this. In my test env, qca988x 2x2 I get: (udp) ath10k-1 >>>> ath10k-2 (server) - speed: 419 Mbits/sec (tcp) ath10k-1 >>>> ath10k-2 (server) - speed: 404 Mbits/sec During tests I used wpa_supplicant (latest git version), which already support IBSS VHT, and choose highest available BW. Also tested with qca6174. Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 10 6月, 2015 1 次提交
-
-
由 Johannes Berg 提交于
As we're running out of hardware capability flags pretty quickly, convert them to use the regular test_bit() style unsigned long bitmaps. This introduces a number of helper functions/macros to set and to test the bits, along with new debugfs code. The occurrences of an explicit __clear_bit() are intentional, the drivers were never supposed to change their supported bits on the fly. We should investigate changing this to be a per-frame flag. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 09 6月, 2015 3 次提交
-
-
由 Michal Kazior 提交于
In the midst of chanctx patch review channel switching became broken which I failed to notice until now. Function ath10k_mac_vif_chan() reports current chandef which isn't updated until after switch_vif_chanctx() is returned from. Consequently the driver just restarted operation on channels it was residing already instead of switching to the new ones. Fixes: 500ff9f9 ("ath10k: implement chanctx API") Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
In practice there's no point in having a copy of chanctx_conf. Most of the time the channel pointer (and band along with it) is accessed and this can't change after a chanctx is created because switching is done using explicit chanctx swapping via switch_vif_chanctx(). The only thing that can change within a chanctx_conf and is used by the driver is radar_enabled and channel width. These are however always accessed in adequate mac80211 callback context which guarantees safe access to the chanctx data. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
Channel contexts aren't iterable until after they've been added to the driver. The code assumed otherwise. This problem could result in: * rx_channel being NULL and forcing Rx path to go the slow way to get channel on QCA988X, * report incorrect channel when running multi-channel on QCA61X4 hw2.1, * report incorrect channel after AP channel switch. Fixes: 500ff9f9 ("ath10k: implement chanctx API") Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 22 5月, 2015 1 次提交
-
-
由 Janusz Dziedzic 提交于
mac80211 can update vif powersave state while disconnected. Firmware doesn't behave nicely and consumes more power than necessary if PS is disabled on a non-started vdev. Hence force-enable PS for non-running vdevs. This reduces power drain on QCA61X4 from 88mA to 36mA when interface is up and not associated. QCA988X wasn't measured. Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 27 4月, 2015 1 次提交
-
-
由 Michal Kazior 提交于
Until now only a single fixed tx rate or nss was allowed to be set. The patch attempts to improve this by allowing most bitrate masks. The limitation is VHT MCS rates cannot be expressed separately using existing firmware interfaces and only the following VHT MCS ranges are supported: none, 0-7, 0-8, and 0-9. This keeps the old behaviour when requesting single tx rate or single nss. The new bitrate mask logic is only applied to other cases that would return -EINVAL until now. Depending on firmware revisions some combinations may crash firmware so use with care, please. This depends on "ath10k: don't use reassoc flag". Without it key cache would effectively be invalidated upon bitrate change leading to communication being no longer possible. These work: iw wlan0 set bitrates legacy-5 6 12 ht-mcs-5 1 2 3 iw wlan0 set bitrates legacy-5 ht-mcs-5 7 8 9 iw wlan0 set bitrates legacy-5 24 ht-mcs-5 vht-mcs-5 1:0-9 These won't work: iw wlan0 set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:0-5 iw wlan0 set bitrates vht-mcs-5 2:7-9 (note the invalid VHT MCS ranges) Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 24 4月, 2015 1 次提交
-
-
由 Johannes Berg 提交于
This support is essentially useless as typically networks are encrypted, frames will be filtered by hardware, and rate scaling will be done with the intended recipient in mind. For real monitoring of the network, the monitor mode support should be used instead. Removing it removes a lot of corner cases. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 22 4月, 2015 1 次提交
-
-
由 Johannes Berg 提交于
The driver can clearly enable fast-xmit since it does rate control in the device and thus must do duration calculation there as well. Acked-by: NKalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 17 4月, 2015 5 次提交
-
-
由 Janusz Dziedzic 提交于
With latest additions to the driver it seems viable to enable support for IBSS-RSN. It seems to work on QCA988X and 999.999.0.636 but is a bit slow to exchange RSN keys for some reason. This may be a firmware quirk or ath10k is missing something. Nevertheless it makes sense to finally enable IBSS-RSN in ath10k even if somewhat handicapped. QCA6174 firmware doesn't seem to be able to Tx EAPOL frames at all now (they get stuck in hw queues for some reason) so it never gets to set the keys in driver. It's fairly safe to assume that once this is fixed IBSS-RSN will work with QCA6174 firmware without any additional changes. Hence no special handling for advertising IEEE80211_HW_SUPPORTS_PER_STA_GTK and WIPHY_FLAG_IBSS_RSN is done now. Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
Some time ago there was a weird issue with AP using wrong multicast keys and generating corrupted traffic on 10.1 firmware. Apparently a very similar problem applies for IBSS-RSN on 999.999.0.636. ath10k doesn't have IBSS-RSN enabled yet. This patch is a prerequisite to support it. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
Apparently firmware requires both pairwise and groupwise keys to be installed per-peer for static WEP in IBSS. This wasn't necessary for AP mode (and installing both doesn't seem to break AP mode thus there's no special handling). Also there seems to be some kind of issue with mapping tx/rx keys in firmware properly which resulted in wrong keys being used and broken communication between devices. It can be argued the vdev param part is more of a workaround than a real fix. However I couldn't figure out how to fix this differently. It works and isn't super ugly. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
Firmware actually re-creates peer entry when reassoc flag is set. This is undesired and could cause trouble with IBSS crypto-wise. This is also important for upcomming bitrate mask improvement. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
mac80211 sets static WEP keys as groupwise while firmware requires them to be installed twice as both pairwise and groupwise. Until now these keys were installed once as pairwise only and, due to that special handling, needed additional tricks to support 802.1x as well. Without this patch in some cases (when AP and ath10k client use different default tx keys) multicast communication was broken. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 15 4月, 2015 2 次提交
-
-
由 Michal Kazior 提交于
This improves chances of getting onto a foreign channel and thus makes P2P a bit more reliable. Without scan burst it was possible for firmware to not switch to foreign channel resulting in "failed to switch to channel for roc scan" warning. This would also effectively fail some offchan tx requests and lead to P2P find/connect taking longer. This could be observed when other vifs were running/busy, e.g. with P2P GO. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
It is not guaranteed firmware will switch to foreign channel immediately after starting scan sequence. To account for that don't use duration parameter for scan time. Instead request insanely long scan and use timeout worker to cancel it from driver. This should improve P2P reliability a bit. Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
- 09 4月, 2015 2 次提交
-
-
由 Michal Kazior 提交于
The default keyidx callback may be called after more than 1 key is installed. This led to only 1 WEP key being reinstalled only. This caused Rxed traffic encrypted with other WEP keys to be dropped in client mode. Tested-by: NBartosz Markowski <bartosz.markowski@tieto.com> Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-
由 Michal Kazior 提交于
The variable should be cleared regardless of whether there's a peer associated with the key or not. This fixes case when user first associates with 2 WEP keys and then disconnects and connects with 1 WEP key. This resulted in WEP key count being 2 in the driver leading to default keyidx fixup failure. Tested-by: NBartosz Markowski <bartosz.markowski@tieto.com> Signed-off-by: NMichal Kazior <michal.kazior@tieto.com> Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
-