Realtek RTL8191SU really slow with „N” mode enabled
Dear list members, I have a "0bda:8172 Realtek RTL8191SU 802.11n WLAN Adapter” working - previously with kernel v4.0 staging driver r8712u, - and now with wireless kernel v4.1 driver rtl8192su (from https://github.com/chunkeey/rtl8192su). My problem is when, by default, the 802.11n mode is enabled, the USB dongle's connection speed is only around 1 Mb/s (with both drivers). When I turn it off with "options rtl8192su ht_enable=0" in its config file, I get my full internet speed, about 30 Mb/s. I'm asking whether it's a problem in the firmware or somewhere in the driver code? If it's the latter case and you're interested in, I would like to help debugging the problem and help you to fix this issue. Thank you very much. All the best, Ákos -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] staging: wilc1000: Deletion of two unnecessary checks
From: Markus Elfring Further update suggestions were taken into account after a patch was applied from static source code analysis. Markus Elfring (2): Delete unnecessary checks before two function calls One function call less in mac_ioctl() after error detection drivers/staging/wilc1000/linux_wlan.c | 17 + 1 file changed, 5 insertions(+), 12 deletions(-) -- 2.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] staging: wilc1000: Delete unnecessary checks before two function calls
From: Markus Elfring
Date: Sat, 27 Jun 2015 15:56:57 +0200
The functions kfree() and release_firmware() test whether their argument
is NULL and then return immediately.
Thus the test around the calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/staging/wilc1000/linux_wlan.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/wilc1000/linux_wlan.c
b/drivers/staging/wilc1000/linux_wlan.c
index b352c50..2aa8d9b 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -2421,11 +2421,7 @@ int mac_ioctl(struct net_device *ndev, struct ifreq
*req, int cmd)
}
done:
-
- if (buff != NULL) {
- kfree(buff);
- }
-
+ kfree(buff);
return s32Error;
}
@@ -2707,8 +2703,7 @@ static void __exit exit_wilc_driver(void)
}
}
-
- if ((g_linux_wlan != NULL) && g_linux_wlan->wilc_firmware != NULL) {
+ if (g_linux_wlan) {
release_firmware(g_linux_wlan->wilc_firmware);
g_linux_wlan->wilc_firmware = NULL;
}
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] staging: wilc1000: One function call less in mac_ioctl() after error detection
From: Markus Elfring
Date: Sat, 27 Jun 2015 16:00:59 +0200
The kfree() function was called in two cases by the mac_ioctl() function
during error handling even if the passed variable did not contain a pointer
for a valid data item.
* This implementation detail could be improved by the introduction
of another jump label.
* Drop an unnecessary initialisation for the variable "buff" then.
Signed-off-by: Markus Elfring
---
drivers/staging/wilc1000/linux_wlan.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/wilc1000/linux_wlan.c
b/drivers/staging/wilc1000/linux_wlan.c
index 2aa8d9b..f492310 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -2351,16 +2351,13 @@ int mac_close(struct net_device *ndev)
int mac_ioctl(struct net_device *ndev, struct ifreq *req, int cmd)
{
-
- u8 *buff = NULL;
+ u8 *buff;
s8 rssi;
u32 size = 0, length = 0;
perInterface_wlan_t *nic;
struct WILC_WFI_priv *priv;
s32 s32Error = WILC_SUCCESS;
-
-
/* struct iwreq *wrq = (struct iwreq *) req;// tony moved to case
SIOCSIWPRIV */
#ifdef USE_WIRELESS
nic = netdev_priv(ndev);
@@ -2405,7 +2402,7 @@ int mac_ioctl(struct net_device *ndev, struct ifreq *req,
int cmd)
if (copy_to_user(wrq->u.data.pointer, buff,
size)) {
PRINT_ER("%s: failed to copy data to
user buffer\n", __func__);
s32Error = -EFAULT;
- goto done;
+ goto free_buffer;
}
}
}
@@ -2420,8 +2417,9 @@ int mac_ioctl(struct net_device *ndev, struct ifreq *req,
int cmd)
}
}
-done:
+free_buffer:
kfree(buff);
+done:
return s32Error;
}
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Null pointer dereference when station associates
I am encountering null pointer dereference when a station associates with my Fedora 22 box which is running as an access point. Wireless card is: 02:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network Adapter (PCI-Express) (rev 01) Subsystem: Qualcomm Atheros Device 3099 Kernel driver in use: ath9k Kernel modules: ath9k relevant software: hostapd-2.4-2.fc22.i686 kernel-PAE-core-4.0.4-301.fc22.i686 kernel-PAE-core-4.0.5-300.fc22.i686 The machine had been running under the 4.0.4 kernel for about a month until it hit this error yesterday. Rebooting it came up in 4.0.5 and each time it hit the error almost immediately. Going back to 4.0.4 it has been stable so far. The actual trace, from the 4.0.5 kernel is: Jun 26 14:51:00 gosford.compton.nu hostapd[820]: wlp2s0: STA cc:fa:00:aa:4e:59 IEEE 802.11: authentication OK (open system) Jun 26 14:51:00 gosford.compton.nu hostapd[820]: wlp2s0: STA cc:fa:00:aa:4e:59 MLME: MLME-AUTHENTICATE.indication(cc:fa:00:aa:4e:59, OPEN_SYSTEM) Jun 26 14:51:00 gosford.compton.nu hostapd[820]: wlp2s0: STA cc:fa:00:aa:4e:59 MLME: MLME-DELETEKEYS.request(cc:fa:00:aa:4e:59) Jun 26 14:51:00 gosford.compton.nu hostapd[820]: wlp2s0: STA cc:fa:00:aa:4e:59 IEEE 802.11: authenticated Jun 26 14:51:00 gosford.compton.nu hostapd[820]: wlp2s0: STA cc:fa:00:aa:4e:59 IEEE 802.11: association OK (aid 1) Jun 26 14:51:00 gosford.compton.nu hostapd[820]: wlp2s0: STA cc:fa:00:aa:4e:59 IEEE 802.11: associated (aid 1) Jun 26 14:51:00 gosford.compton.nu hostapd[820]: wlp2s0: STA cc:fa:00:aa:4e:59 MLME: MLME-ASSOCIATE.indication(cc:fa:00:aa:4e:59) Jun 26 14:51:00 gosford.compton.nu hostapd[820]: wlp2s0: STA cc:fa:00:aa:4e:59 MLME: MLME-DELETEKEYS.request(cc:fa:00:aa:4e:59) Jun 26 14:51:00 gosford.compton.nu kernel: BUG: unable to handle kernel NULL pointer dereference at 006c Jun 26 14:51:00 gosford.compton.nu kernel: IP: [] mutex_lock+0x12/0x30 Jun 26 14:51:00 gosford.compton.nu kernel: *pdpt = 34070001 *pde = Jun 26 14:51:00 gosford.compton.nu kernel: Oops: 0002 [#1] SMP Jun 26 14:51:00 gosford.compton.nu kernel: Modules linked in: 8021q garp mrp pppoe pppox ppp_generic slhc ip6t_REJECT nf_nat_ftp nf_reject_ipv6 nf_conntrack_ftp nf_log_ipv4 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_MASQUERADE nf_log_ipv6 nf Jun 26 14:51:00 gosford.compton.nu kernel: CPU: 1 PID: 820 Comm: hostapd Not tainted 4.0.5-300.fc22.i686+PAE #1 Jun 26 14:51:00 gosford.compton.nu kernel: Hardware name: /D945GSEJT , BIOS JT94510H.86A.0025.2009.0306.1639 03/06/2009 Jun 26 14:51:00 gosford.compton.nu kernel: task: f6a2c080 ti: f41c2000 task.ti: f41c2000 Jun 26 14:51:00 gosford.compton.nu kernel: EIP: 0060:[] EFLAGS: 00210286 CPU: 1 Jun 26 14:51:00 gosford.compton.nu kernel: EIP is at mutex_lock+0x12/0x30 Jun 26 14:51:00 gosford.compton.nu kernel: EAX: 006c EBX: 006c ECX: c0f66a68 EDX: 8000 Jun 26 14:51:00 gosford.compton.nu kernel: ESI: f41c3716 EDI: f3e843e0 EBP: f41c36b4 ESP: f41c36b0 Jun 26 14:51:00 gosford.compton.nu kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Jun 26 14:51:00 gosford.compton.nu kernel: CR0: 80050033 CR2: 006c CR3: 34102000 CR4: 07f0 Jun 26 14:51:00 gosford.compton.nu kernel: Stack: Jun 26 14:51:00 gosford.compton.nu kernel: f47e1000 f41c36d0 c0678ab4 0012 f41c3728 0002 f3aa5000 f73a2540 Jun 26 14:51:00 gosford.compton.nu kernel: f41c36f0 c0679203 f3aa5000 f73a2540 f3e843e0 f3aa5000 f73a2540 f3e843e0 Jun 26 14:51:00 gosford.compton.nu kernel: f41c3738 f8a938ae f41c3716 0012 f8ab0237 f3aa5620 0001 f41c3716 Jun 26 14:51:00 gosford.compton.nu kernel: Call Trace: Jun 26 14:51:01 gosford.compton.nu kernel: [] start_creating+0x44/0xc0 Jun 26 14:51:01 gosford.compton.nu kernel: [] debugfs_create_dir+0x13/0xf0 Jun 26 14:51:01 gosford.compton.nu kernel: [] ieee80211_sta_debugfs_add+0x6e/0x490 [mac80211] Jun 26 14:51:01 gosford.compton.nu kernel: [] ? ath9k_del_ps_key.isra.18+0x70/0x70 [ath9k] Jun 26 14:51:01 gosford.compton.nu kernel: [] sta_info_insert_finish+0x514/0x830 [mac80211] Jun 26 14:51:01 gosford.compton.nu kernel: [] ? __enqueue_entity+0x6d/0x80 Jun 26 14:51:01 gosford.compton.nu kernel: [] ? native_smp_send_reschedule+0x3f/0x60 Jun 26 14:51:01 gosford.compton.nu kernel: [] ? resched_curr+0x68/0xb0 Jun 26 14:51:01 gosford.compton.nu kernel: [] ? ath_buf_set_rate+0x362/0x410 [ath9k] Jun 26 14:51:01 gosford.compton.nu kernel: [] ? update_curr+0x5e/0x190 Jun 26 14:51:01 gosford.compton.nu kernel: [] ? sched_slice.isra.50+0x4a/0xb0 Jun 26 14:51:01 gosford.compton.nu kernel: [] ? __update_cpu_load+0xc7/0x100 Jun 26 14:51:01 gosford.compton.nu kernel: [] ? scheduler_tick+0x86/0xc0 Jun 26 14:51:01 gosford.compton.nu kernel: [] ? ktime_get+0x4a/0x120 Jun 26 14:51:01 gosford.compton.nu kernel: [] ? lapic_next_event+0x1b/0x20 Jun 26 14:51:01 gosford.compton.nu kernel: [] ? clockevents_program_event+0x8d/0x140 Jun 26 14:51:
buongiorno
Salve
moto, mac Laptop, Kamera, Telefon
samsung 6, € 320
w eb: isgayre. com
N�r��yb�X��ǧv�^�){.n�+{��*ޕ�,�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
Re: [PATCH 2/2] staging: wilc1000: One function call less in mac_ioctl() after error detection
On Sat, 27 Jun 2015, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sat, 27 Jun 2015 16:00:59 +0200
>
> The kfree() function was called in two cases by the mac_ioctl() function
> during error handling even if the passed variable did not contain a pointer
> for a valid data item.
>
> * This implementation detail could be improved by the introduction
> of another jump label.
>
> * Drop an unnecessary initialisation for the variable "buff" then.
>
> Signed-off-by: Markus Elfring
> ---
> drivers/staging/wilc1000/linux_wlan.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/linux_wlan.c
> b/drivers/staging/wilc1000/linux_wlan.c
> index 2aa8d9b..f492310 100644
> --- a/drivers/staging/wilc1000/linux_wlan.c
> +++ b/drivers/staging/wilc1000/linux_wlan.c
> @@ -2351,16 +2351,13 @@ int mac_close(struct net_device *ndev)
>
> int mac_ioctl(struct net_device *ndev, struct ifreq *req, int cmd)
> {
> -
> - u8 *buff = NULL;
> + u8 *buff;
> s8 rssi;
> u32 size = 0, length = 0;
> perInterface_wlan_t *nic;
> struct WILC_WFI_priv *priv;
> s32 s32Error = WILC_SUCCESS;
>
> -
> -
Removing these blank lines seems to have nothing to do with the topic of
the patch.
julia
> /* struct iwreq *wrq = (struct iwreq *) req;// tony moved to case
> SIOCSIWPRIV */
> #ifdef USE_WIRELESS
> nic = netdev_priv(ndev);
> @@ -2405,7 +2402,7 @@ int mac_ioctl(struct net_device *ndev, struct ifreq
> *req, int cmd)
> if (copy_to_user(wrq->u.data.pointer, buff,
> size)) {
> PRINT_ER("%s: failed to copy data to
> user buffer\n", __func__);
> s32Error = -EFAULT;
> - goto done;
> + goto free_buffer;
> }
> }
> }
> @@ -2420,8 +2417,9 @@ int mac_ioctl(struct net_device *ndev, struct ifreq
> *req, int cmd)
> }
> }
>
> -done:
> +free_buffer:
> kfree(buff);
> +done:
> return s32Error;
> }
>
> --
> 2.4.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Realtek RTL8191SU really slow with „N” mode enabled
Hello, On Saturday, June 27, 2015 11:16:21 AM Szőts Ákos wrote: > I have a "0bda:8172 Realtek RTL8191SU 802.11n WLAN Adapter” working > - previously with kernel v4.0 staging driver r8712u, > - and now with wireless kernel v4.1 driver rtl8192su (from > https://github.com/chunkeey/rtl8192su). > > My problem is when, by default, the 802.11n mode is enabled, the USB dongle's > connection speed is only around 1 Mb/s (with both drivers). When I turn it > off > with "options rtl8192su ht_enable=0" in its config file, I get my full > internet > speed, about 30 Mb/s. Wait! There isn't any ht_enable option for the rtl8192su(.ko) driver...?! > I'm asking whether it's a problem in the firmware or somewhere in the driver > code? If it's the latter case and you're interested in, I would like to help > debugging the problem and help you to fix this issue. Can't help you with debugging the problem as long as I can't reproduce the issue. No idea if this is a hardware, firmware, driver, setup or some kind of interaction issue. In my opinion: you simply disable HT, then you just did take a feature away rather than dealing with anything. But, if that's what you want: fine. Note: I think the simplest solution would be to have a working reference. If you are looking for a wifi usb-stick, ath9k_htc solutions are usually the way to go. Regards, Christian -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MediaTek WiFi hardware support in upstream kernel
mt7601u landed in 'linux-next' https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/drivers/net/wireless/mediatek/mt7601u the v4.2 kernel is predicted for Sunday, 2015-08-23 http://phb-crystal-ball.org For the firmware(mt7601u.bin) as part of the essential functionality of the device it would be good to land in 'linux-firmware' *even* before the actual kernel release v4.2 http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree tempus fugit -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AP + P2P_GO multichan tests with intel7260 as a P2P_CLIENT - direct probe issue
On 24 June 2015 at 14:20, Peer, Ilan wrote:
> Hi Janusz,
>
> Any chance you can check if the attached patch fixes the issue you reported?
>
> Thanks in advance,
>
I just check the mac80211/cfg80211 code, and I am not sure this direct
probe could work correctly.
Function ieee80211_rx_mgmt_probe_resp() is interesting.
Seems we call
ieee80211_rx_bss_info() -> ieee80211_bss_info_update ->
cfg80211_inform_bss_width_frame() -> cfg80211_bss_update() -> this
could set bss->proberesp_ies
and after that check:
if (ifmgd->auth_data && !ifmgd->auth_data->bss->proberesp_ies &&
ether_addr_equal(mgmt->bssid, ifmgd->auth_data->bss->bssid)) {
/* got probe response, continue with auth */
sdata_info(sdata, "direct probe responded\n");
So, ifmgd->auth_data->bss->proberesp_ies could be set before check?
BTW, During my tests (no matter which card used) I never saw this msg:
sdata_info(sdata, "direct probe responded\n");
And always saw 3 failed direct probes.
@Johannes: Is that possible or I miss something.
BR
Janusz
> Ilan.
>
>> -Original Message-
>> From: linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless-
>> ow...@vger.kernel.org] On Behalf Of Peer, Ilan
>> Sent: Tuesday, June 23, 2015 21:00
>> To: chaitanya.m...@gmail.com
>> Cc: linux-wireless@vger.kernel.org; janusz.dzied...@tieto.com
>> Subject: Re: AP + P2P_GO multichan tests with intel7260 as a P2P_CLIENT -
>> direct probe issue
>>
>> -Original Message-
>> From: Krishna Chaitanya
>> mailto:Krishna%20Chaitanya%20%3cchaitanya.m
>> g...@gmail.com%3e>>
>> To: "Peer, Ilan"
>> mailto:%22Peer,%20Ilan%22%20%3cilan.peer@intel.c
>> om%3e>>
>> Cc: Janusz Dziedzic
>> mailto:Janusz%20Dziedzic%20%3cjanusz.dziedzic
>> @tieto.com%3e>>, linux-wireless@vger.kernel.org > wirel...@vger.kernel.org> wirel...@vger.kernel.org%22%20%3clinux-wirel...@vger.kernel.org%3e>>
>> Subject: Re: AP + P2P_GO multichan tests with intel7260 as a P2P_CLIENT -
>> direct probe issue
>> Date: Tue, 23 Jun 2015 17:34:59 +0530
>>
>>
>>
>> On Tue, Jun 23, 2015 at 5:25 PM, Peer, Ilan
>> mailto:ilan.p...@intel.com>> wrote:
>> >> >>
>> >> >> I suspect this is because of P2P_GO NoA?
>> >> >> Who should care about this direct probes tx when GO is not present?
>> >> >>
>> >> >> In case we didn't send direct probes - there is no problem and TC
>> >> >> works correctly
>> >> >>
>> >> >
>> >> > Interesting :)
>> >> >
>> >> > Any chance you can provide trace-cmd and sniffer capture?
>> >> >
>> >> > Normally, if we provided the FW with the BSSID information and TSF
>> >> > information for syncing, once the FW hears the 1st beacon with the
>> >> > NoA it should sync on it and not try to attempt to transmit any
>> >> > frames as long as the AP is absent. It might also be related to the
>> >> > fact that the probe requests are sent to broadcast address, but I
>> >> > need to further checks this. Anyway, having some data would help ;)
>> >> >
>> >> Thats exactly the point, if GO is in NoA FW will not transmit but
>> >> mac80211 timed-out for direct probe.
>> >>
>> >> So the question is should mac80211 even send the direct probe in this
>> >> case when GO is in NoA?
>> >
>> > I think that this should be the driver's/FW responsibility, as at this
>> > stage
>> mac80211 already configured all the information needed for the driver to
>> sync (assuming it heard a beacon/probe) and in addition mgd_prepare_tx() is
>> called to have the driver/FW prepare for a transmission of the mgmt. frame,
>> including synchronization with the P2P GO power state.
>> Agree, the actual transmission should definitely be in driver/FW but the
>> timeout for such frames are still at mac80211, so unless su it synchronizes
>> the
>> timeouts to GO NoA period this "can" fail depending on the absence period of
>> GO. Default auth_timeout is 200ms.
>>
>>
>> I do not think that mac80211 should handle the synchronization, mostly since
>> it does not get the beacons from the AP we are associated with. As I
>> explained above, this should be the drivers/FW responsibility once they have
>> all the information they require. As such, I think that is expected from the
>> driver/FW to only send the frames when the P2P GO/AP is on the channel.
>>
>> Regards,
>>
>> Ilan.
>>
>>
>>
>> N r y b X ǧv ^ ){.n +{ *ޕ , {ay ʇڙ ,j f h z w
>> j:+v w j m zZ+
>> ݢj" ! i
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AP + P2P_GO multichan tests with intel7260 as a P2P_CLIENT - direct probe issue
On 27 June 2015 at 23:49, Janusz Dziedzic wrote:
> On 24 June 2015 at 14:20, Peer, Ilan wrote:
>> Hi Janusz,
>>
>> Any chance you can check if the attached patch fixes the issue you reported?
>>
>> Thanks in advance,
>>
> I just check the mac80211/cfg80211 code, and I am not sure this direct
> probe could work correctly.
>
> Function ieee80211_rx_mgmt_probe_resp() is interesting.
> Seems we call
> ieee80211_rx_bss_info() -> ieee80211_bss_info_update ->
> cfg80211_inform_bss_width_frame() -> cfg80211_bss_update() -> this
> could set bss->proberesp_ies
> and after that check:
>
> if (ifmgd->auth_data && !ifmgd->auth_data->bss->proberesp_ies &&
> ether_addr_equal(mgmt->bssid, ifmgd->auth_data->bss->bssid)) {
> /* got probe response, continue with auth */
> sdata_info(sdata, "direct probe responded\n");
>
> So, ifmgd->auth_data->bss->proberesp_ies could be set before check?
>
> BTW, During my tests (no matter which card used) I never saw this msg:
> sdata_info(sdata, "direct probe responded\n");
> And always saw 3 failed direct probes.
>
> @Johannes: Is that possible or I miss something.
>
Simplest patch I made:
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index e9f36f7..8ceae3d 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -371,6 +371,7 @@ struct ieee80211_mgd_auth_data {
struct cfg80211_bss *bss;
unsigned long timeout;
int tries;
+ bool waiting_probe_resp;
u16 algorithm, expected_transaction;
u8 key[WLAN_KEY_LEN_WEP104];
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 3294666..6f4027e 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -3212,13 +3212,14 @@ static void
ieee80211_rx_mgmt_probe_resp(struct ieee80211_sub_if_data *sdata,
ether_addr_equal(mgmt->bssid, ifmgd->associated->bssid))
ieee80211_reset_ap_probe(sdata);
- if (ifmgd->auth_data && !ifmgd->auth_data->bss->proberesp_ies &&
+ if (ifmgd->auth_data && ifmgd->auth_data->waiting_probe_resp &&
ether_addr_equal(mgmt->bssid, ifmgd->auth_data->bss->bssid)) {
/* got probe response, continue with auth */
sdata_info(sdata, "direct probe responded\n");
ifmgd->auth_data->tries = 0;
ifmgd->auth_data->timeout = jiffies;
ifmgd->auth_data->timeout_started = true;
+ ifmgd->auth_data->waiting_probe_resp = false;
run_again(sdata, ifmgd->auth_data->timeout);
}
}
@@ -3727,6 +3728,8 @@ static int ieee80211_probe_auth(struct
ieee80211_sub_if_data *sdata)
auth_data->bss->bssid, auth_data->tries,
IEEE80211_AUTH_MAX_TRIES);
+ auth_data->waiting_probe_resp = true;
+
rcu_read_lock();
ssidie = ieee80211_bss_get_ie(auth_data->bss, WLAN_EID_SSID);
if (!ssidie) {
BR
Janusz
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
