Re: mwifiex won't connect to WPA2 anymore

[Dan Williams]

On Thu, 2017-05-04 at 23:27 +0200, Julien Cubizolles wrote:
> Dan Williams  writes:
> 
> > On Wed, 2017-05-03 at 22:33 +0200, Julien Cubizolles wrote:
> > > It turns out that the problem lies with NetworkManager, I managed
> > > to
> > > get
> > > the wifi working with wpa_supplicant.
> > 
> > That's odd.  Any idea what that was?  MAC randomization?  
> 
> I don't know if MAC randomization is supposed to be happen but
> ifconfig
> always display the same MAC address for the wifi interface. Also the
> same wifi router allows connections without secrets with another
> ssid,
> and I have no problem connecting in this case.
> 
> > NM just uses the supplicant underneath, so there's no particular
> > reason NM wouldn't work but wpa_supplicant itself would.
> 
> I'm using the following /etc/wpa_supplicant.conf file:
> 
> --8<---cut here---start->8---
> ctrl_interface=/var/run/wpa_supplicant
> ap_scan=1
> network={
>   priority=2
> ssid="beguiled"
> psk="*"

Just to test, could you add:

auth_alg=OPEN
key_mgmt=WPA-PSK
scan_ssid=1

to the block and retry with the supplicant?  I don't know why those
would make a difference but they might.

The reason code that is returned for the disconnect is unfortunately
WLAN_REASON_PREV_AUTH_NOT_VALID which doesn't tell us much.

Dan

> }
> 
> --8<---cut here---end--->8---
> 
> For the same ssid: NetworkManager uses the following
> /etc/NetworkManager/system-connections/beguiled
> 
> --8<---cut here---start->8---
> [connection]
> id=beguiled
> uuid=4ecc0776-046d-4f05-a324-19f5a8fe6853
> type=wifi
> permissions=
> secondaries=
> 
> [wifi]
> ssid=beguiled
> 
> [wifi-security]
> psk=**
> 
> [ipv4]
> dns-search=
> method=auto
> 
> [ipv6]
> addr-gen-mode=stable-privacy
> dns-search=
> method=auto
> --8<---cut here---end--->8---
> 
> Here are the logs when NM fails:
> --8<---cut here---start->8---
> 
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8411]
> device (wlx6045bdf646b4): set-hw-addr: set MAC address to
> E2:D4:E4:49:77:59 (scanning)
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8433]
> manager: NetworkManager state is now DISCONNECTED
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8435]
> device (wlx6045bdf646b4): Activation: starting connection 'beguiled'
> (406e52d4-e98b-454b-8d32-ce69fee5e03f)
> May  4 23:06:25 touco kernel: [   58.255775] IPv6:
> ADDRCONF(NETDEV_UP): wlx6045bdf646b4: link is not ready
> May  4 23:06:25 touco whoopsie[818]: [23:06:25] Cannot reach: https:/
> /daisy.ubuntu.com
> May  4 23:06:25 touco nm-dispatcher: req:2 'down' [wlx6045bdf646b4]:
> new request (2 scripts)
> May  4 23:06:25 touco nm-dispatcher: req:2 'down' [wlx6045bdf646b4]:
> start running ordered scripts...
> May  4 23:06:25 touco whoopsie[818]: [23:06:25] Cannot reach: https:/
> /daisy.ubuntu.com
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8711]
> sup-iface[0x5634f93244e0,wlx6045bdf646b4]: connection disconnected
> (reason -3)
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8712]
> device (wlx6045bdf646b4): supplicant interface state: completed ->
> disconnected
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8745]
> device (wlx6045bdf646b4): state change: disconnected -> prepare
> (reason 'none') [30 40 0]
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8747]
> manager: NetworkManager state is now CONNECTING
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.9016]
> device (wlx6045bdf646b4): set-hw-addr: set-cloned MAC address to
> 60:45:BD:F6:46:B4 (permanent)
> May  4 23:06:25 touco kernel: [   58.316182] IPv6:
> ADDRCONF(NETDEV_UP): wlx6045bdf646b4: link is not ready
> May  4 23:06:25 touco gsd-sharing[2450]: Failed to StopUnit service:
> GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit rygel.service
> not loaded.
> May  4 23:06:25 touco gsd-sharing[2450]: Failed to StopUnit service:
> GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit vino-
> server.service not loaded.
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.9314]
> device (wlx6045bdf646b4): state change: prepare -> config (reason
> 'none') [40 50 0]
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.9322]
> device (wlx6045bdf646b4): Activation: (wifi) access point 'beguiled'
> has security, but secrets are required.
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.9323]
> device (wlx6045bdf646b4): state change: config -> need-auth (reason
> 'none') [50 60 0]
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.9394]
> device (wlx6045bdf646b4): state change: need-auth -> prepare (reason
> 'none') [60 40 0]
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.9403]
> device (wlx6045bdf646b4): state change: prepare -> config (reason
> 'none') [40 50 0]
> May  4 

Re: mwifiex won't connect to WPA2 anymore

[Julien Cubizolles]

Dan Williams  writes:

> On Wed, 2017-05-03 at 22:33 +0200, Julien Cubizolles wrote:

>> It turns out that the problem lies with NetworkManager, I managed to
>> get
>> the wifi working with wpa_supplicant.
>
> That's odd.  Any idea what that was?  MAC randomization?  

I don't know if MAC randomization is supposed to be happen but ifconfig
always display the same MAC address for the wifi interface. Also the
same wifi router allows connections without secrets with another ssid,
and I have no problem connecting in this case.

> NM just uses the supplicant underneath, so there's no particular
> reason NM wouldn't work but wpa_supplicant itself would.

I'm using the following /etc/wpa_supplicant.conf file:

--8<---cut here---start->8---
ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
network={
priority=2
ssid="beguiled"
psk="*"
}

--8<---cut here---end--->8---

For the same ssid: NetworkManager uses the following
/etc/NetworkManager/system-connections/beguiled

--8<---cut here---start->8---
[connection]
id=beguiled
uuid=4ecc0776-046d-4f05-a324-19f5a8fe6853
type=wifi
permissions=
secondaries=

[wifi]
ssid=beguiled

[wifi-security]
psk=**

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto
--8<---cut here---end--->8---

Here are the logs when NM fails:
--8<---cut here---start->8---

May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8411] device 
(wlx6045bdf646b4): set-hw-addr: set MAC address to E2:D4:E4:49:77:59 (scanning)
May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8433] manager: 
NetworkManager state is now DISCONNECTED
May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8435] device 
(wlx6045bdf646b4): Activation: starting connection 'beguiled' 
(406e52d4-e98b-454b-8d32-ce69fee5e03f)
May  4 23:06:25 touco kernel: [   58.255775] IPv6: ADDRCONF(NETDEV_UP): 
wlx6045bdf646b4: link is not ready
May  4 23:06:25 touco whoopsie[818]: [23:06:25] Cannot reach: 
https://daisy.ubuntu.com
May  4 23:06:25 touco nm-dispatcher: req:2 'down' [wlx6045bdf646b4]: new 
request (2 scripts)
May  4 23:06:25 touco nm-dispatcher: req:2 'down' [wlx6045bdf646b4]: start 
running ordered scripts...
May  4 23:06:25 touco whoopsie[818]: [23:06:25] Cannot reach: 
https://daisy.ubuntu.com
May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8711] 
sup-iface[0x5634f93244e0,wlx6045bdf646b4]: connection disconnected (reason -3)
May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8712] device 
(wlx6045bdf646b4): supplicant interface state: completed -> disconnected
May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8745] device 
(wlx6045bdf646b4): state change: disconnected -> prepare (reason 'none') [30 40 
0]
May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8747] manager: 
NetworkManager state is now CONNECTING
May  4 23:06:25 touco NetworkManager[833]:   [1493931985.9016] device 
(wlx6045bdf646b4): set-hw-addr: set-cloned MAC address to 60:45:BD:F6:46:B4 
(permanent)
May  4 23:06:25 touco kernel: [   58.316182] IPv6: ADDRCONF(NETDEV_UP): 
wlx6045bdf646b4: link is not ready
May  4 23:06:25 touco gsd-sharing[2450]: Failed to StopUnit service: 
GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit rygel.service not loaded.
May  4 23:06:25 touco gsd-sharing[2450]: Failed to StopUnit service: 
GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit vino-server.service not 
loaded.
May  4 23:06:25 touco NetworkManager[833]:   [1493931985.9314] device 
(wlx6045bdf646b4): state change: prepare -> config (reason 'none') [40 50 0]
May  4 23:06:25 touco NetworkManager[833]:   [1493931985.9322] device 
(wlx6045bdf646b4): Activation: (wifi) access point 'beguiled' has security, but 
secrets are required.
May  4 23:06:25 touco NetworkManager[833]:   [1493931985.9323] device 
(wlx6045bdf646b4): state change: config -> need-auth (reason 'none') [50 60 0]
May  4 23:06:25 touco NetworkManager[833]:   [1493931985.9394] device 
(wlx6045bdf646b4): state change: need-auth -> prepare (reason 'none') [60 40 0]
May  4 23:06:25 touco NetworkManager[833]:   [1493931985.9403] device 
(wlx6045bdf646b4): state change: prepare -> config (reason 'none') [40 50 0]
May  4 23:06:25 touco NetworkManager[833]:   [1493931985.9406] device 
(wlx6045bdf646b4): Activation: (wifi) connection 'beguiled' has security, and 
secrets exist.  No new secrets needed.
May  4 23:06:25 touco NetworkManager[833]:   [1493931985.9406] Config: 
added 'ssid' value 'beguiled'
May  4 23:06:25 touco NetworkManager[833]:   [1493931985.9407] Config: 
added 'scan_ssid' value '1'
May  4 23:06:25 touco NetworkManager[833]:   [1493931985.9407] Config: 
added 'key_mgmt' value 'WPA-PSK'
May  4 23:06:25 touco NetworkManager[833]:   [1493931985.9407] Config: 
added 'auth_alg' value 'OPEN'
May  4 

[PATCH v2 3/4] rtlwifi: btcoex: Remove 23b 2ant configuration parameter

[Larry Finger]

In file halbtc8723b2ant.c, there are directives that depend on an
undocumented configuration parameter BT_AUTO_REPORT_ONLY_8723B_2ANT
that cannot be set from Kconfig. This parameter is replaced by a
boolean in the main structure used by all routines. It still cannot
be changed dynamically, but it is easier to document.

Routines halbtc8723b2ant_set_bt_auto_report(), and
btc8723b2ant_bt_auto_report() are restored.

Signed-off-by: Larry Finger 
Cc: Yan-Hsuan Chuang 
Cc: Pkshih 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
---
v2 - Some earlier patches were missed in v1.
---
 .../realtek/rtlwifi/btcoexist/halbtc8723b2ant.c| 79 +++---
 .../realtek/rtlwifi/btcoexist/halbtc8723b2ant.h|  2 -
 2 files changed, 53 insertions(+), 28 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
index 2f3946be4ce2..b071ea2728fc 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
@@ -707,6 +707,36 @@ static void btc8723b2ant_dec_bt_pwr(struct btc_coexist 
*btcoexist,
coex_dm->pre_dec_bt_pwr_lvl = coex_dm->cur_dec_bt_pwr_lvl;
 }
 
+static
+void halbtc8723b2ant_set_bt_auto_report(struct btc_coexist *btcoexist,
+   bool enable_auto_report)
+{
+   u8 h2c_parameter[1] = {0};
+
+   h2c_parameter[0] = 0;
+
+   if (enable_auto_report)
+   h2c_parameter[0] |= BIT(0);
+
+   btcoexist->btc_fill_h2c(btcoexist, 0x68, 1, h2c_parameter);
+}
+
+static
+void btc8723b2ant_bt_auto_report(struct btc_coexist *btcoexist,
+bool force_exec, bool enable_auto_report)
+{
+   coex_dm->cur_bt_auto_report = enable_auto_report;
+
+   if (!force_exec) {
+   if (coex_dm->pre_bt_auto_report == coex_dm->cur_bt_auto_report)
+   return;
+   }
+   halbtc8723b2ant_set_bt_auto_report(btcoexist,
+  coex_dm->cur_bt_auto_report);
+
+   coex_dm->pre_bt_auto_report = coex_dm->cur_bt_auto_report;
+}
+
 static void btc8723b2ant_fw_dac_swing_lvl(struct btc_coexist *btcoexist,
  bool force_exec, u8 fw_dac_swing_lvl)
 {
@@ -3666,6 +3696,7 @@ void ex_btc8723b2ant_init_hwconfig(struct btc_coexist 
*btcoexist)
btcoexist->btc_write_1byte(btcoexist, 0x76e, 0x4);
btcoexist->btc_write_1byte(btcoexist, 0x778, 0x3);
btcoexist->btc_write_1byte_bitmask(btcoexist, 0x40, 0x20, 0x1);
+   btcoexist->auto_report_2ant = true;
 }
 
 void ex_btc8723b2ant_power_on_setting(struct btc_coexist *btcoexist)
@@ -3966,9 +3997,8 @@ void ex_btc8723b2ant_display_coex_info(struct btc_coexist 
*btcoexist)
RT_TRACE(rtlpriv, COMP_INIT, DBG_DMESG, "\r\n %-35s = %d/ %d",
 "0x774(low-pri rx/tx)", coex_sta->low_priority_rx,
 coex_sta->low_priority_tx);
-#if (BT_AUTO_REPORT_ONLY_8723B_2ANT == 1)
-   btc8723b2ant_monitor_bt_ctr(btcoexist);
-#endif
+   if (btcoexist->auto_report_2ant)
+   btc8723b2ant_monitor_bt_ctr(btcoexist);
btcoexist->btc_disp_dbg_msg(btcoexist,
BTC_DBG_DISP_COEX_STATISTICS);
 }
@@ -4190,14 +4220,11 @@ void ex_btc8723b2ant_bt_info_notify(struct btc_coexist 
*btcoexist,
} else {
/* BT already NOT ignore Wlan active, do nothing here.*/
}
-#if (BT_AUTO_REPORT_ONLY_8723B_2ANT == 0)
-   if ((coex_sta->bt_info_ext & BIT4)) {
-   /* BT auto report already enabled, do nothing*/
-   } else {
-   btc8723b2ant_bt_auto_report(btcoexist, FORCE_EXEC,
-   true);
+   if (!btcoexist->auto_report_2ant) {
+   if (!(coex_sta->bt_info_ext & BIT4))
+   btc8723b2ant_bt_auto_report(btcoexist,
+   FORCE_EXEC, true);
}
-#endif
}
 
/* check BIT2 first ==> check if bt is under inquiry or page scan */
@@ -4347,21 +4374,22 @@ void ex_btc8723b2ant_periodical(struct btc_coexist 
*btcoexist)
}
}
 
-#if (BT_AUTO_REPORT_ONLY_8723B_2ANT == 0)
-   btc8723b2ant_query_bt_info(btcoexist);
-#else
-   btc8723b2ant_monitor_bt_ctr(btcoexist);
-   btc8723b2ant_monitor_wifi_ctr(btcoexist);
+   if (!btcoexist->auto_report_2ant) {
+   btc8723b2ant_query_bt_info(btcoexist);
+   } else {
+   btc8723b2ant_monitor_bt_ctr(btcoexist);
+   btc8723b2ant_monitor_wifi_ctr(btcoexist);
 
-   /* for some BT speakers that High-Priority pkts appear before
-* playing, 

Re: [PATCH] cfg80211: make RATE_INFO_BW_20 the default

[Linus Torvalds]

On Thu, May 4, 2017 at 8:22 AM, David Miller  wrote:
> From: Johannes Berg 
>>
>> I figured I'd give Linus to a chance to try or even apply it, but I
>> have no objection to you applying it either. I don't have anything else
>>   yet right now, and sending a pull request for just a single patch
>> would be quite pointless.
>
> Ok, let's give Linus a chance to test the patch.

I'm having trouble recreating the warning. I have no idea why. It only
happened during ten minutes yesterday, and nothing in my wireless
setup has changed.

I wonder if *normally* my setup ends up connecting with a 40MHz band
or something, and I just happened to see the default uninitialized
case once.

I see that Jens reported that the patch works, although I'm wondering
how repeatable it was for him.  The patch obviously looks simple and
seems like an obviously GoodThing(tm) regardless.

   Linus

Re: WARNING: CPU: 2 PID: 682 at net/wireless/util.c:1236

[David Miller]

From: Jens Axboe 
Date: Thu, 4 May 2017 09:40:08 -0600

> On 05/04/2017 09:27 AM, Jens Axboe wrote:
>> On 05/04/2017 09:25 AM, David Miller wrote:
>>> From: Jens Axboe 
>>> Date: Thu, 4 May 2017 09:23:36 -0600
>>>
 Running current -git on my laptop, and I see this spew every once
 in a while. This is new, haven't seen it in 4.11 or previously. Driver
 is iwlwifi:
>>>
>>> Please try:
>>>
>>> http://patchwork.ozlabs.org/patch/758364/
>> 
>> Will do, compiling...
> 
> Yep works, thanks.

Thanks for testing.

Re: WARNING: CPU: 2 PID: 682 at net/wireless/util.c:1236

[Jens Axboe]

On 05/04/2017 09:27 AM, Jens Axboe wrote:
> On 05/04/2017 09:25 AM, David Miller wrote:
>> From: Jens Axboe 
>> Date: Thu, 4 May 2017 09:23:36 -0600
>>
>>> Running current -git on my laptop, and I see this spew every once
>>> in a while. This is new, haven't seen it in 4.11 or previously. Driver
>>> is iwlwifi:
>>
>> Please try:
>>
>> http://patchwork.ozlabs.org/patch/758364/
> 
> Will do, compiling...

Yep works, thanks.

-- 
Jens Axboe

Re: WARNING: CPU: 2 PID: 682 at net/wireless/util.c:1236

[Jens Axboe]

On 05/04/2017 09:25 AM, David Miller wrote:
> From: Jens Axboe 
> Date: Thu, 4 May 2017 09:23:36 -0600
> 
>> Running current -git on my laptop, and I see this spew every once
>> in a while. This is new, haven't seen it in 4.11 or previously. Driver
>> is iwlwifi:
> 
> Please try:
> 
> http://patchwork.ozlabs.org/patch/758364/

Will do, compiling...

-- 
Jens Axboe

Re: WARNING: CPU: 2 PID: 682 at net/wireless/util.c:1236

[David Miller]

From: Jens Axboe 
Date: Thu, 4 May 2017 09:23:36 -0600

> Running current -git on my laptop, and I see this spew every once
> in a while. This is new, haven't seen it in 4.11 or previously. Driver
> is iwlwifi:

Please try:

http://patchwork.ozlabs.org/patch/758364/

Re: [PATCH] cfg80211: make RATE_INFO_BW_20 the default

[David Miller]

From: Johannes Berg 
Date: Thu, 04 May 2017 17:16:42 +0200

> On Thu, 2017-05-04 at 11:13 -0400, David Miller wrote:
>> 
>> Johannes, would you like me to merge this in via my tree directly?
> 
> I figured I'd give Linus to a chance to try or even apply it, but I
> have no objection to you applying it either. I don't have anything else
>   yet right now, and sending a pull request for just a single patch
> would be quite pointless.

Ok, let's give Linus a chance to test the patch.

WARNING: CPU: 2 PID: 682 at net/wireless/util.c:1236

[Jens Axboe]

Hi,

Running current -git on my laptop, and I see this spew every once
in a while. This is new, haven't seen it in 4.11 or previously. Driver
is iwlwifi:

04:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)


[ 3285.862640] IPv6: ADDRCONF(NETDEV_CHANGE): wlp4s0: link becomes ready
[ 3285.978482] [ cut here ]
[ 3285.978501] WARNING: CPU: 2 PID: 682 at net/wireless/util.c:1236 
cfg80211_calculate_bitrate+0x130/0x160 [cfg80211]
[ 3285.978502] Modules linked in: ctr ccm rfcomm fuse bnep arc4 
snd_hda_codec_hdmi iwlmvm snd_hda_codec_conexant snd_hda_codec_generic mac80211 
snd_hda_intel snd_hda_codec binfmt_misc snd_hwdep snd_hda_core snd_pcm 
x86_pkg_temp_thermal nls_iso8859_1 intel_powerclamp nls_cp437 kvm_intel vfat 
snd_seq_midi fat kvm iwlwifi snd_seq_midi_event btusb snd_rawmidi btintel 
bluetooth snd_seq uvcvideo irqbypass aesni_intel videobuf2_vmalloc 
videobuf2_memops snd_seq_device aes_x86_64 videobuf2_v4l2 crypto_simd snd_timer 
videobuf2_core cryptd glue_helper videodev cfg80211 ecdh_generic snd soundcore 
hid_generic usbhid hid i915 psmouse e1000e ptp pps_core xhci_pci xhci_hcd 
intel_gtt
[ 3285.978536] CPU: 2 PID: 682 Comm: NetworkManager Tainted: G U  
4.11.0+ #59
[ 3285.978537] Hardware name: LENOVO 20FBCTO1WW/20FBCTO1WW, BIOS N1FET50W (1.24 
) 03/08/2017
[ 3285.978538] task: 880421de2880 task.stack: 8804234a8000
[ 3285.978551] RIP: 0010:cfg80211_calculate_bitrate+0x130/0x160 [cfg80211]
[ 3285.978552] RSP: 0018:8804234ab638 EFLAGS: 00010293
[ 3285.978553] RAX:  RBX: 88042df2cf00 RCX: 0002
[ 3285.978554] RDX:  RSI:  RDI: 8804234ab7d6
[ 3285.978555] RBP: 8804234ab638 R08: 0004 R09: 8804252c20d4
[ 3285.978556] R10: 088002aa R11: a02a6000 R12: 8804234ab7d6
[ 3285.978557] R13: 8804252c20d0 R14: 8804252c2030 R15: 880424bf
[ 3285.978559] FS:  7f4e016a8940() GS:88044150() 
knlGS:
[ 3285.978560] CS:  0010 DS:  ES:  CR0: 80050033
[ 3285.978561] CR2: 0c5e5d540010 CR3: 00042b626000 CR4: 001406e0
[ 3285.978561] DR0:  DR1:  DR2: 
[ 3285.978562] DR3:  DR6: fffe0ff0 DR7: 0400
[ 3285.978563] Call Trace:
[ 3285.978577]  nl80211_put_sta_rate+0x4e/0x1f0 [cfg80211]
[ 3285.978591]  nl80211_send_station.isra.66+0x344/0xcc0 [cfg80211]
[ 3285.978595]  ? __kmalloc_track_caller+0x31/0x1a0
[ 3285.978608]  nl80211_get_station+0x1d9/0x250 [cfg80211]
[ 3285.978620]  genl_family_rcv_msg+0x1bf/0x380
[ 3285.978622]  genl_rcv_msg+0x4c/0x90
[ 3285.978623]  ? genl_family_rcv_msg+0x380/0x380
[ 3285.978629]  netlink_rcv_skb+0x7f/0x110
[ 3285.978630]  genl_rcv+0x28/0x40
[ 3285.978633]  netlink_unicast+0x183/0x220
[ 3285.978635]  netlink_sendmsg+0x293/0x390
[ 3285.978637]  sock_sendmsg+0x38/0x50
[ 3285.978638]  ___sys_sendmsg+0x256/0x2b0
[ 3285.978641]  ? __slab_free+0x1d1/0x2c0
[ 3285.978643]  ? destroy_inode+0x3b/0x60
[ 3285.978645]  ? do_wp_page+0x103/0x440
[ 3285.978646]  ? __handle_mm_fault+0x34e/0xa10
[ 3285.978648]  ? __fget+0x6e/0x90
[ 3285.978650]  __sys_sendmsg+0x45/0x80
[ 3285.978652]  ? __sys_sendmsg+0x45/0x80
[ 3285.978654]  SyS_sendmsg+0x12/0x20
[ 3285.978656]  entry_SYSCALL_64_fastpath+0x13/0x94
[ 3285.978657] RIP: 0033:0x7f4dff521a6d
[ 3285.978658] RSP: 002b:7ffc7507aec0 EFLAGS: 0293 ORIG_RAX: 
002e
[ 3285.978660] RAX: ffda RBX: 02044b60 RCX: 7f4dff521a6d
[ 3285.978661] RDX:  RSI: 7ffc7507af50 RDI: 0010
[ 3285.978661] RBP: 7f4dff50bb20 R08:  R09: 
[ 3285.978662] R10: 01fd8df0 R11: 0293 R12: 1010
[ 3285.978663] R13: 7f4dff50bb78 R14: 26fc R15: 01ffc570
[ 3285.978664] Code: d0 f7 e1 d1 ea 8d 14 92 01 d2 81 c2 50 c3 00 00 b9 c5 5a 
7c 0a 5d c1 ea 05 89 d0 f7 e1 89 d0 c1 e8 07 c3 31 c0 40 80 fe 02 74 b6 <0f> ff 
31 c0 eb b0 8d 14 52 01 d2 e9 41 ff ff ff 0f ff 31 c0 5d 
[ 3285.978693] ---[ end trace ae08dfa326cc120a ]---

-- 
Jens Axboe

Re: [PATCH] cfg80211: make RATE_INFO_BW_20 the default

[Johannes Berg]

On Thu, 2017-05-04 at 11:13 -0400, David Miller wrote:
> 
> Johannes, would you like me to merge this in via my tree directly?

I figured I'd give Linus to a chance to try or even apply it, but I
have no objection to you applying it either. I don't have anything else
  yet right now, and sending a pull request for just a single patch
would be quite pointless.

johannes

Re: [PATCH] cfg80211: make RATE_INFO_BW_20 the default

[David Miller]

From: Johannes Berg 
Date: Thu,  4 May 2017 08:42:30 +0200

> From: Johannes Berg 
> 
> Due to the way I did the RX bitrate conversions in mac80211 with
> spatch, going setting flags to setting the value, many drivers now
> don't set the bandwidth value for 20 MHz, since with the flags it
> wasn't necessary to (there was no 20 MHz flag, only the others.)
> 
> Rather than go through and try to fix up all the drivers, instead
> renumber the enum so that 20 MHz, which is the typical bandwidth,
> actually has the value 0, making those drivers all work again.
> 
> If VHT was hit used with a driver not reporting it, e.g. iwlmvm,
> this manifested in hitting the bandwidth warning in
> cfg80211_calculate_bitrate_vht().
> 
> Reported-by: Linus Torvalds 
> Signed-off-by: Johannes Berg 

Johannes, would you like me to merge this in via my tree directly?

Thanks.

Re: [PATCH 1/2] wcn36xx: Pass used skb to ieee80211_tx_status()

[Kalle Valo]

Bjorn Andersson  writes:

> On Thu 27 Apr 01:22 PDT 2017, Johannes Berg wrote:
>
>> 
>> > @@ -371,7 +371,7 @@ static void reap_tx_dxes(struct wcn36xx *wcn,
>> > struct wcn36xx_dxe_ch *ch)
>> >    info = IEEE80211_SKB_CB(ctl->skb);
>> >    if (!(info->flags &
>> > IEEE80211_TX_CTL_REQ_TX_STATUS)) {
>> >    /* Keep frame until TX status comes
>> > */
>> > -  ieee80211_free_txskb(wcn->hw, ctl-
>> > >skb);
>> > +  ieee80211_tx_status(wcn->hw, ctl-
>> > >skb);
>> > 
>> 
>> I don't think this is a good idea.
>
> Thanks for letting me know :)
>
>> This code intentionally checked if TX status was requested, and if not
>> then it doesn't go to the effort of building it.
>> 
>
> What I'm finding puzzling is the fact that the only caller of
> ieee80211_led_tx() is ieee80211_tx_status() and it seems like drivers,
> such as ath10k, call this for each packet handled - but I'm likely
> missing something.
>
>> As it is with your patch, it'll go and report the TX status without any
>> TX status information - which is handled in wcn36xx_dxe_tx_ack_ind()
>> for those frames needing it.
>> 
>
> Right, it doesn't sound desired. However, during normal operation I'm
> not seeing IEEE80211_TX_CTL_REQ_TX_STATUS being set and as such
> ieee80211_led_tx() is never called.

So what's the conclusion? How do we get leds working?

-- 
Kalle Valo

Re: [4/4] mwifiex: pcie: de-duplicate buffer allocation code

[Kalle Valo]

Brian Norris  writes:

> On Tue, Mar 21, 2017 at 02:14:05PM +0200, Kalle Valo wrote:
>> What I could do is to wait for the patches 1-3 trickle down to w-d-next
>> and then apply this patch. It usually takes few weeks, but with bad luck
>> it might happen only after the merge window. Would that work?
>
> Is this going to get picked up?

Oh man, I thought I had changed the state of this patch from Changes
Requested to Awaiting Upstream but apparently I didn't do that and hence
missed the patch. It's now back in active my queue in Under Review
state:

https://patchwork.kernel.org/patch/9618309/

Thanks for reminding me and sorry for the screwup.

-- 
Kalle Valo

Re: ath6kl: assure headroom of skbuff is writable in .start_xmit()

[Kalle Valo]

Steve deRosier  writes:

> On Wed, Apr 26, 2017 at 12:54 PM, James Hughes
>  wrote:
>> On 26 April 2017 at 19:03, Arend Van Spriel
>>  wrote:
>>>
>>>
>>> On 26-4-2017 17:44, Steve deRosier wrote:
 On Wed, Apr 26, 2017 at 1:53 AM, Kalle Valo  wrote:
> Arend Van Spriel  wrote:
>> An issue was found brcmfmac driver in which a skbuff in .start_xmit()
>> callback was actually cloned. So instead of checking for sufficient
>> headroom it should also be writable. Hence use skb_cow_head() to
>> check and expand the headroom appropriately.
>>
>> Signed-off-by: Arend van Spriel 
>
> Steve, would you have time to run a quick test with this?
>
> Patch set to Deferred.
>

 Happy to give it a quick spin on both of my platforms.

>
> @ Arend and James, thanks for the info. I understand it, but
> unfortunately I can't seem to replicate the problems on my platforms
> with the limited time I have available to test it. It also may have to
> do with my platforms having special custom bridging related code, or
> just me having setup too simple of a test.
>
> That said...
>
> @Kalle: I have tested on both my 6004 and 6003 platforms. I didn't
> notice any incorrect behavior in my testing. But I don't have a test
> setup that would have shown the original problem as reported on the
> brcm driver so I can't say that the change actually _fixes_ anything.
> Only that in my testing it doesn't seem to break anything.
>
> Tested-by: Steve deRosier 

Yeah, I was mostly worried about regression. I didn't expect you to
replicate the bug. Thanks for testing, I'll add this patch to my queue.

-- 
Kalle Valo

Re: ath10k: append the wmi_op_version to testmode get_version cmd

[Kalle Valo]

ryan...@qti.qualcomm.com wrote:
> From: Ryan Hsu 
> 
> QCA9xxx and QCA61x4/QCA93xx are using different wmi operation, in order
> for userspace to differentiate it, appends the wmi_op_version information
> alone with the get_version command.
> 
> Signed-off-by: Ryan Hsu 

Patch applied to ath-next branch of ath.git, thanks.

4dcb78085d56 ath10k: append the wmi_op_version to testmode get_version cmd

-- 
https://patchwork.kernel.org/patch/9699775/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [RESEND] ath10k: fix out of bounds access to local buffer

[Kalle Valo]

Michael Mera  wrote:
> During write to debugfs file simulate_fw_crash, fixed-size local buffer
> 'buf' is accessed and modified at index 'count-1', where 'count' is the
> size of the write (so potentially out of bounds).
> This patch fixes this problem.
> 
> Signed-off-by: Michael Mera 

Patch applied to ath-next branch of ath.git, thanks.

a16703aaeaed ath10k: fix out of bounds access to local buffer

-- 
https://patchwork.kernel.org/patch/9695703/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [v7,01/10] ath10k: htc: made static function public

[Kalle Valo]

Kalle Valo  wrote:
> From: Erik Stromdahl 
> 
> Changed ath10k_htc_notify_tx_completion and
> ath10k_htc_process_trailer from static to non static.
> 
> These functions are needed by SDIO/mbox.
> 
> Signed-off-by: Erik Stromdahl 
> Signed-off-by: Kalle Valo 

10 patches applied to ath-next branch of ath.git, thanks.

3e0dd820f07f ath10k: htc: made static function public
680ebb4e7977 ath10k: htc: rx trailer lookahead support
ea1a3ddf6273 ath10k: htc: move htc ctrl ep connect to htc_init
fcd2113363dd ath10k: htc: refactorization
01d6fd6965ea ath10k: various sdio related definitions
60bdfffa1254 ath10k: add sdio extra initializations
34dd398a55ff ath10k: sdio get target info
04ff79467ec2 ath10k: htc: ready_ext msg support
f008d1537bf8 ath10k: different fw file name for sdio
d96db25d2025 ath10k: add initial SDIO support

-- 
https://patchwork.kernel.org/patch/9678959/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH] b43: Add missing MODULE_FIRMWARE()

[Takashi Iwai]

On Thu, 04 May 2017 11:43:14 +0200,
Kalle Valo wrote:
> 
> Takashi Iwai  writes:
> 
> > Some recent firmware entries were forgotten to be added via
> > MODULE_FIRMWARE(), which may result in the non-functional state when
> > the driver is loaded in initrd.
> >
> > Link: http://bugzilla.opensuse.org/show_bug.cgi?id=1037344
> > Signed-off-by: Takashi Iwai 
> 
> With recent you mean three years ago? ;)

Heh, time flies :)

> Some of these were added by
> Rafal (CCed) in commit 15be8e89cdd99 and some in a60f99f75dd35.
> 
> I'll replace the word recent and add:
> 
> Fixes: 15be8e89cdd9 ("b43: add more bcma cores")
> 
> But as this is so old bug I'll queue this to 4.13.

Thanks, it's no urgent fix, obviously.  We just stumbled on this
casually.


Takashi

Re: [PATCH] b43: Add missing MODULE_FIRMWARE()

[Kalle Valo]

Takashi Iwai  writes:

> Some recent firmware entries were forgotten to be added via
> MODULE_FIRMWARE(), which may result in the non-functional state when
> the driver is loaded in initrd.
>
> Link: http://bugzilla.opensuse.org/show_bug.cgi?id=1037344
> Signed-off-by: Takashi Iwai 

With recent you mean three years ago? ;) Some of these were added by
Rafal (CCed) in commit 15be8e89cdd99 and some in a60f99f75dd35.

I'll replace the word recent and add:

Fixes: 15be8e89cdd9 ("b43: add more bcma cores")

But as this is so old bug I'll queue this to 4.13.

-- 
Kalle Valo

Fwd: mwl8k driver issue: frequent disconnect with Android phone

[Menion]

Hello
Actually I was trying to workaround the below problem using WPA2-EAP.
But the PEAP-mschapv2 doesn't work with mwl8k driver on 5Ghz radio
My setup include two different Cisco/Linksys EA4500 running LEDE
17.01.1 and one TPLink WDR3600 with ath9x radios
The EA4500 chipset is Marvell 88W8366 v48.
Well with both 5Ghz radio of my two EA4500 the PEAP MSCHAPV2
authentication fails at the certificates exchange
This is the log I see in freeradius 2

Wed May 3 21:17:26 2017 : Debug: Going to the next request
Wed May 3 21:17:26 2017 : Debug: Waking up in 4.9 seconds.
Wed May 3 21:17:31 2017 : Info: Cleaning up request 34 ID 41 with timestamp +574
Wed May 3 21:17:31 2017 : Info: Cleaning up request 35 ID 42 with timestamp +574
Wed May 3 21:17:31 2017 : Info: Cleaning up request 36 ID 43 with timestamp +574
Wed May 3 21:17:31 2017 : Debug: WARNING:
!!
Wed May 3 21:17:31 2017 : Debug: WARNING: !! EAP session for state
0xd1f19d03d34c849e did not finish!
Wed May 3 21:17:31 2017 : Debug: WARNING: !! Please read
http://wiki.freeradius.org/guide/Certificate_Compatibility
Wed May 3 21:17:31 2017 : Debug: WARNING:
!!
Wed May 3 21:17:31 2017 : Info: Ready to process requests.

On hostapd size the logs say that the radius response is received but
the next stage never arrives.
Using the same freeradius 2 I can get PEAP working with the 2.4Ghz
radio with no issue and most important with both 2.4Ghz and 5Ghz radio
on wdr3600, that run the same LEDE release (same kernel) and the same
userland app, so it seems that the problem is really in the
interaction between the mwl8k driver, 5Ghz radio and hostapd and
freeradius.
The problem is shared by two android device (one 7.0.1 and one 6.1)
and and iPhone 7.
Can anyone follow me on the troubleshooting?
Bye

-- Forwarded message --
From: Menion 
Date: 2017-04-30 9:51 GMT+02:00
Subject: mwl8k driver issue: frequent disconnect with Android phone
To: linux-wireless@vger.kernel.org


Hi all
I would like to recall to attention an issue that various user are
observing running mwl8k driver together with android clients
Relevant information can be found here:

https://dev.openwrt.org/ticket/21284
http://www.spinics.net/lists/linux-wireless/msg151171.html

Unfortunately I don't have other information to add, logs on my sistem
which is a kirkwood router running kernel 4.4.x with Lede are
identical to the ones already provided.
I can add that the problem seems to get worst depending on the
bandwidth usage (higher is worst).
And I can confirm that apparently only android clients are affected,
in the sense that here I have also iPhones and some IP WebCam that
work rock stable with the same router.
Also both 5Ghz and 2.5Ghz radio are affected
Userland seems to have no influence, I have tried wpad and hostapd,
both show the problem
Let me know how can I help
Bye

Re: new warning at net/wireless/util.c:1236

[Johannes Berg]

Hi,

> Things still work, but when it starts warning, it generates a *lot*
> of noise (I got 36 of these within about ten minutes).

Yeah, that's kinda dumb - I just sent a patch to make that just warn
once and actually report the configuration.

> I have no idea what triggered it, because when I rebooted (not
> because of this issue, but just to reboot into a newer kernel) I
> don't see it again.

That's odd. Perhaps you connected to a different wireless network on
the next boot? I'm pretty sure I found the cause for this, and will
send out a patch in a minute, but that wouldn't go away with a
different kernel.

johannes

[PATCH] cfg80211: make RATE_INFO_BW_20 the default

[Johannes Berg]

From: Johannes Berg 

Due to the way I did the RX bitrate conversions in mac80211 with
spatch, going setting flags to setting the value, many drivers now
don't set the bandwidth value for 20 MHz, since with the flags it
wasn't necessary to (there was no 20 MHz flag, only the others.)

Rather than go through and try to fix up all the drivers, instead
renumber the enum so that 20 MHz, which is the typical bandwidth,
actually has the value 0, making those drivers all work again.

If VHT was hit used with a driver not reporting it, e.g. iwlmvm,
this manifested in hitting the bandwidth warning in
cfg80211_calculate_bitrate_vht().

Reported-by: Linus Torvalds 
Signed-off-by: Johannes Berg 
---
 include/net/cfg80211.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 6e90f1a4950f..15d6599b8bc6 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1013,9 +1013,9 @@ enum rate_info_flags {
  * @RATE_INFO_BW_160: 160 MHz bandwidth
  */
 enum rate_info_bw {
+   RATE_INFO_BW_20 = 0,
RATE_INFO_BW_5,
RATE_INFO_BW_10,
-   RATE_INFO_BW_20,
RATE_INFO_BW_40,
RATE_INFO_BW_80,
RATE_INFO_BW_160,
-- 
2.11.0

Re: new warning at net/wireless/util.c:1236

[Coelho, Luciano]

On Thu, 2017-05-04 at 07:35 +0300, Kalle Valo wrote:
> Linus Torvalds  writes:
> 
> > So my Dell XPS 13 seems to have grown a new warning as of the
> > networking merge yesterday.
> > 
> > Things still work, but when it starts warning, it generates a *lot* of
> > noise (I got 36 of these within about ten minutes).
> > 
> > I have no idea what triggered it, because when I rebooted (not because
> > of this issue, but just to reboot into a newer kernel) I don't see it
> > again.
> > 
> > This is all pretty regular wireless - it's intel 8260 wireless in a
> > fairly normal laptop.
> > 
> > Things still seem to *work* ok, so the only problem here is the overly
> > verbose and useless WARN_ON. It doesn't even print out *which* rate it
> > is warning about, it just does that stupid unconditional WARN_ON()
> > without ever shutting up about it..
> > 
> > The WARN_ON() seems to be old, but my logs don't seem to have any
> > mention of this until today, so there's something that has changed
> > that now triggers it.
> > 
> > Ideas?
> > 
> >   Linus
> > 
> > ---
> > 
> > WARNING: CPU: 3 PID: 1138 at net/wireless/util.c:1236
> > cfg80211_calculate_bitrate+0x139/0x170 [cfg80211]
> 
> As this is with iwlwifi adding also Luca. There were some rate handling
> changes in iwlwifi, like commit 77e409455f41, but don't know if that
> could cause this.

Thanks Kalle.  I don't see anything in the iwlwifi driver that could be
causing this.  Johannes suspects some RX rate changes he made in
mac80211...

--
Luca.