Re: [RESEND] ath9k failure to authenticate WPA2 client mode

[Janusz Dziedzic]

On 29 March 2017 at 19:03, Tim Harvey  wrote:
> Greetings,
>
> (resending plaintext - oops)
>
> I'm seeing failures to authenticate with a WPA2 secured AP using ath9k
> based cards on wireless-next:
>
> root@xenial-armhf:~# wpa_passphrase testssid testpass >
> /etc/wpa_supplicant/wpa_supplicant.conf
>
> root@xenial-armhf:~# iw reg get
> country US: DFS-FCC
> (2402 - 2472 @ 40), (N/A, 30), (N/A)
> (5170 - 5250 @ 80), (N/A, 17), (N/A)
> (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS
> (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
> (5735 - 5835 @ 80), (N/A, 30), (N/A)
> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>
> root@xenial-armhf:~# wpa_supplicant -i wlan0 -c
> /etc/wpa_supplicant/wpa_supplicant.conf
> Successfully initialized wpa_supplicant
> [ 1882.699010] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> nl80211: send_and_recv->nl_recvms[ 1886.262884] wlan0: authenticate
> with 02:1a:11:f2:35:9c
> gs failed: -33
> wlan0: SME: Trying to authenticate with 02:1a:11:f2:35:9c
> (SSID='testssid' freq=2437 MHz)
> [ 1886.280755] wlan0: send auth to 02:1a:11:f2:35:9c (try 1/3)
> [ 1887.033449] wlan0: send auth to 02:1a:11:f2:35:9c (try 2/3)
> [ 1887.993413] wlan0: send auth to 02:1a:11:f2:35:9c (try 3/3)
> [ 1888.953390] wlan0: authentication with 02:1a:11:f2:35:9c timed out
> wlan0: SME: Trying to authenticat[ 1892.507484] wlan0: authenticate
> with 02:1a:11:f2:35:9c
> e with 02:1a:11:f2:35:9c (SSID='testssid' freq=2437 MHz)
> [ 1892.527460] wlan0: send auth to 02:1a:11:f2:35:9c (try 1/3)
> [ 1893.993401] wlan0: send auth to 02:1a:11:f2:35:9c (try 2/3)
> [ 1894.953419] wlan0: send auth to 02:1a:11:f2:35:9c (try 3/3)
> [ 1895.993387] wlan0: authentication with 02:1a:11:f2:35:9c timed out
> wlan0: SME: Trying to authenticat[ 1899.997262] wlan0: authenticate
> with 02:1a:11:f2:35:9c
> e with 02:1a:11:f2:35:9c (SSID='testssid' freq=2437 MHz)
> [ 1900.017252] wlan0: send auth to 02:1a:11:f2:35:9c (try 1/3)
> [ 1901.033259] wlan0: send auth to 02:1a:11:f2:35:9c (try 2/3)
> [ 1901.993345] wlan0: send auth to 02:1a:11:f2:35:9c (try 3/3)
> [ 1902.953270] wlan0: authentication with 02:1a:11:f2:35:9c timed out
> wlan0: SME: Trying to authenticat[ 1907.407446] wlan0: authenticate
> with 02:1a:11:f2:35:9c
> e with 02:1a:11:f2:35:9c (SSID='testssid' freq=2437 MHz)
> [ 1907.427370] wlan0: send auth to 02:1a:11:f2:35:9c (try 1/3)
> [ 1908.003204] wlan0: send auth to 02:1a:11:f2:35:9c (try 2/3)
> [ 1908.953275] wlan0: send auth to 02:1a:11:f2:35:9c (try 3/3)
> [ 1909.993254] wlan0: authentication with 02:1a:11:f2:35:9c timed out
> wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="testssid"
> auth_failures=1 duration=10 reason=CONN_FAILED
> ^Cnl80211: deinit ifname=wlan0 disabled_11b_rates=0
> wlan0: CTRL-EVENT-TERMINATING
>
> I've tried loading ath9k with nohwcrypt=1 and see the same.
>
> I do not have any trouble with an ath10k card in the same system:
>
> root@xenial-armhf:~# wpa_supplicant -i wlan1 -c
> /etc/wpa_supplicant/wpa_supplicant.conf
> Successfully initialized wpa_supplicant
> [  593.401846] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
> wlan1: SME: Trying to authenticat[  596.857230] wlan1: authenticate
> with 02:1a:11:f1:b9:02
> e with 02:1a:11:f1:b9:02 (SSID='testssid' freq=2437 MHz)
> [  596.876749] wlan1: send auth to 02:1a:11:f1:b9:02 (try 1/3)
> [  596.886290] wlan1: authenticated
> wlan1: Trying to associate with 02:1a:11:f1:b9:02 (SSID='testssid'
> freq=2437 MHz)
> [  596.909012] wlan1: associate with 02:1a:11:f1:b9:02 (try 1/3)
> [  596.922374] wlan1: RX AssocResp from 02:1a:11:f1:b9:02 (capab=0x411
> status=0 aid=1)
> [  596.940754] wlan1: associated
> [  596.943954] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
> wlan1: Associated with 02:1a:11:f1:b9:02
> wlan1: WPA: Key negotiation completed with 02:1a:11:f1:b9:02 [PTK=CCMP 
> GTK=CCMP]
> wlan1: CTRL-EVENT-CONNECTED - Connection to 02:1a:11:f1:b9:02
> completed [id=0 id_str=]
> wlan1: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=US
>  at this point I can dhcp IP config and all is good
>
> Here's the PCI info for the two cards:
>
> 08:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd.
> 88E8057 PCI-E Gigabit Ethernet Controller [11ab:4380]
> 09:00.0 Network controller [0280]: Qualcomm Atheros AR9580 Wireless
> Network Adapter [168c:0033] (rev 01)
>
> I don't know when ath9k last worked honestly. I usually use them under
> OpenWrt which has its own patches against periodic updates of linux
> backports. I noticed this first with Ubuntu 16.04 with the Ubuntu 4.4
> kernel, saw it still with the Ubuntu 4.8 kernel, then repeated the
> issue in wireless-next.
>
> Any ideas?
>
Interesting. Are you sure wlan0 is ath9k and wlan1 is ath10k?
ath9k is quite stable - I have AR9462 and works fine with 4.4 and current.
So, I would suspect some issues with ath10k :)

What if you will modprobe -r ath10k_pci and next run the test?

BR
Janusz

> Regards,
>
> 

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

[Larry Finger]

On 03/29/2017 12:47 PM, Hans de Goede wrote:

The rtl8723bs is found on quite a few systems used by Linux users,
such as on Atom systems (Intel Computestick and various other
Atom based devices) and on many (budget) ARM boards such as
the CHIP.

The plan moving forward with this is for the new clean,
written from scratch, rtl8xxxu driver to eventually gain
support for sdio devices. But there is no clear timeline
for that, so lets add this driver included in staging for now.

Cc: Bastien Nocera 
Cc: Larry Finger 
Cc: Jes Sorensen 
Signed-off-by: Hans de Goede 


Hans,

I am still building the driver on my CherryTrail tablet, but I did see some 
warnings and errors listed by Smatch as follows:


finger@linux-4v1g:~/wireless-drivers-next> make CHECK=~/smatch/smatch C=2 
drivers/staging/rtl8723bs/

  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHECK   arch/x86/purgatory/purgatory.c
  CHECK   arch/x86/purgatory/sha256.c
  CHECK   arch/x86/purgatory/string.c
  CHK include/generated/bounds.h
  CHK include/generated/timeconst.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  CHECK   scripts/mod/empty.c
  CHECK   drivers/staging/rtl8723bs/core/rtw_ap.c
drivers/staging/rtl8723bs/core/rtw_ap.c:382 expire_timeout_chk() warn: 
inconsistent indenting

  CHECK   drivers/staging/rtl8723bs/core/rtw_btcoex.c
  CHECK   drivers/staging/rtl8723bs/core/rtw_cmd.c
  CHECK   drivers/staging/rtl8723bs/core/rtw_debug.c
drivers/staging/rtl8723bs/core/rtw_debug.c:454 proc_get_survey_info() error: we 
previously assumed 'phead' could be null (see line 453)
drivers/staging/rtl8723bs/core/rtw_debug.c:455 proc_get_survey_info() warn: 
variable dereferenced before check 'phead' (see line 454)

  CHECK   drivers/staging/rtl8723bs/core/rtw_efuse.c
  CHECK   drivers/staging/rtl8723bs/core/rtw_io.c
  CHECK   drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
  CHECK   drivers/staging/rtl8723bs/core/rtw_ieee80211.c
drivers/staging/rtl8723bs/core/rtw_ieee80211.c:83 rtw_is_cckrates_included() 
warn: if statement not indented
drivers/staging/rtl8723bs/core/rtw_ieee80211.c:98 rtw_is_cckratesonly_included() 
warn: if statement not indented

  CHECK   drivers/staging/rtl8723bs/core/rtw_mlme.c
drivers/staging/rtl8723bs/core/rtw_mlme.c:862 rtw_survey_event_callback() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_mlme.c:1102 rtw_free_assoc_resources() warn: 
if statement not indented
drivers/staging/rtl8723bs/core/rtw_mlme.c:1165 rtw_indicate_disconnect() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_mlme.c:2830 rtw_restructure_ht_ie() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_mlme.c:2991 rtw_update_ht_cap() warn: 
inconsistent indenting

  CHECK   drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:525 _mgt_dispatcher() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:1595 OnAssocReq() error: buffer 
overflow 'pstapriv->sta_aid' 32 <= 32
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:2391 dump_mgntframe_and_wait() 
warn: inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:2420 dump_mgntframe_and_wait_ack() 
warn: inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:4969 process_80211d() error: 
testing array offset 'i' after use.
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:5738 linked_status_chk() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:6459 sitesurvey_cmd_hdl() warn: 
inconsistent indenting

  CHECK   drivers/staging/rtl8723bs/core/rtw_odm.c
drivers/staging/rtl8723bs/core/rtw_odm.c:109 rtw_odm_dbg_comp_msg() warn: if 
statement not indented
drivers/staging/rtl8723bs/core/rtw_odm.c:146 rtw_odm_ability_msg() warn: if 
statement not indented

  CHECK   drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
drivers/staging/rtl8723bs/core/rtw_pwrctrl.c:641 LeaveAllPowerSaveModeDirect() 
warn: inconsistent indenting

  CHECK   drivers/staging/rtl8723bs/core/rtw_recv.c
drivers/staging/rtl8723bs/core/rtw_recv.c:598 portctrl() warn: inconsistent 
indenting
drivers/staging/rtl8723bs/core/rtw_recv.c:838 sta2sta_data_frame() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_recv.c:1547 validate_recv_frame() warn: 
inconsistent indenting

  CHECK   drivers/staging/rtl8723bs/core/rtw_rf.c
  CHECK   drivers/staging/rtl8723bs/core/rtw_security.c
drivers/staging/rtl8723bs/core/rtw_security.c:266 rtw_wep_encrypt() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_security.c:433 rtw_seccalctkipmic() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_security.c:749 rtw_tkip_encrypt() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_security.c:865 rtw_tkip_decrypt() warn: 
inconsistent indenting

Re: [PATCH 3/7] NFC: nfcmrvl: do not use device-managed resources

[Johan Hovold]

On Wed, Mar 29, 2017 at 06:21:08PM +0200, Johan Hovold wrote:
> This specifically fixes a NULL-pointer dereference when using the n_nci
> line discipline on one end of a Unix98 pty as well as resource leaks in
> the registration error paths.

I noticed I forgot to actually fix up the error paths, so will send a v2
tomorrow.

Johan

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Arend Van Spriel]

On 29-3-2017 22:15, Larry Finger wrote:
> On 03/29/2017 02:36 PM, Dennis New wrote:
>> global
>> country 00: DFS-UNSET
>> (2402 - 2472 @ 92), (N/A, 20), (N/A)
>> (2457 - 2482 @ 92), (N/A, 20), (N/A), PASSIVE-SCAN
>> (2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, PASSIVE-SCAN
>> (5170 - 5250 @ 160), (N/A, 20), (N/A), PASSIVE-SCAN
>> (5250 - 5330 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN
>> (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN
>> (5735 - 5835 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
>> (57240 - 63720 @ 2160), (N/A, 0), (N/A)
> 
> That "country 00" looks like commit
> 1d2a6a5e4bf2921531071fcff8538623dce74efa
> Author: Stanislaw Gruszka 
> Date:   Wed Mar 22 16:08:33 2017 +0100
> 
> genetlink: fix counting regression on ctrl_dumpfamily()

I am more confused about "(2402 - 2472 @ 92)". That is some seriously
strange bandwidth :-p

Regards,
Arend

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Larry Finger]

On 03/29/2017 02:36 PM, Dennis New wrote:

global
country 00: DFS-UNSET
(2402 - 2472 @ 92), (N/A, 20), (N/A)
(2457 - 2482 @ 92), (N/A, 20), (N/A), PASSIVE-SCAN
(2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, PASSIVE-SCAN
(5170 - 5250 @ 160), (N/A, 20), (N/A), PASSIVE-SCAN
(5250 - 5330 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN
(5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN
(5735 - 5835 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
(57240 - 63720 @ 2160), (N/A, 0), (N/A)


That "country 00" looks like commit 1d2a6a5e4bf2921531071fcff8538623dce74efa
Author: Stanislaw Gruszka 
Date:   Wed Mar 22 16:08:33 2017 +0100

genetlink: fix counting regression on ctrl_dumpfamily()

Larry

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Dennis New]

On Wed, 29 Mar 2017 13:49:06 +0200, Johannes Berg wrote:
> On Wed, 2017-03-29 at 06:28 -0400, Dennis New wrote:
> > On Wed, 29 Mar 2017 09:34:50 +0200, Johannes Berg wrote:
> > > On Fri, 2017-03-24 at 21:32 -0400, Dennis New wrote:
> > > > Ever since I upgraded to the 4.10 kernels (I don't think this
> > > > behavior existed in the 4.8 series), after I startup my laptop
> > > > (either from cold boot, or from standby), my wlan0 interface
> > > > keeps
> > > > deauthenticating
> > > > ...
> > > > 19:23:29 kernel: wlan0: authenticate with 00:11:22:33:44:55
> > > > 19:23:29 kernel: [ cut here ]
> > > > 19:23:29 kernel: WARNING: CPU: 0 PID: 18925 at
> > > > net/mac80211/mlme.c:287 ieee80211_determine_chantype+0x12e/0x380
> > > 
> > > This is already indicating a severe problem. I don't know how you
> > > end
> > > up in this situation with b43, since that doesn't have any
> > > regulatory
> > > magic afaict.
> > > 
> > > > 19:23:29 kernel: wlan0: associated
> > > > 
> > > > 19:24:29 kernel: wlan0: deauthenticating from 00:11:22:33:44:55
> > > > by
> > > > local choice (Reason: 3=DEAUTH_LEAVING)
> > > 
> > > I'm convinced that this comes from reg_check_channels().
> > > 
> > > The above WARN_ON() already told you that the channel was
> > > considered
> > > invalid.
> > > 
> > > Do you know what channel your AP is on?
> > 
> > 6
> > 
> > > Perhaps show the output of "iw wlan0 scan dump" while it's
> > 
> > connected (you have 60 seconds :P)
> > 
> > I have been having stable connections for the past few days,
> > simply by putting a 60 second sleep before starting my wlan0.
> > Although
> > if I /etc/init.d/net.wlan0 restart it (without the delay), it will
> > still do this deauth'ing.
> 
> Very strange.
> 
> > * 2437 MHz [6] 
> >   Maximum TX power: 20.0 dBm
> >   Channel widths:
> 
> That's quite odd, why isn't it listing any possible channel widths?!
> 
> I get:
>   * 2437 MHz [6] 
>     Maximum TX power: 15.0 dBm
>     Channel widths: 20MHz HT40- HT40+
> 
> What's "iw reg get"?

global
country 00: DFS-UNSET
(2402 - 2472 @ 92), (N/A, 20), (N/A)
(2457 - 2482 @ 92), (N/A, 20), (N/A), PASSIVE-SCAN
(2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, PASSIVE-SCAN
(5170 - 5250 @ 160), (N/A, 20), (N/A), PASSIVE-SCAN
(5250 - 5330 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN
(5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN
(5735 - 5835 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
(57240 - 63720 @ 2160), (N/A, 0), (N/A)

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Arend Van Spriel]

Op 29 mrt. 2017 13:51 schreef "Johannes Berg" >:
>
> On Wed, 2017-03-29 at 06:28 -0400, Dennis New wrote:
> > On Wed, 29 Mar 2017 09:34:50 +0200, Johannes Berg wrote:
> > > On Fri, 2017-03-24 at 21:32 -0400, Dennis New wrote:
> > > > Ever since I upgraded to the 4.10 kernels (I don't think this
> > > > behavior existed in the 4.8 series), after I startup my laptop
> > > > (either from cold boot, or from standby), my wlan0 interface
> > > > keeps
> > > > deauthenticating
> > > > ...
> > > > 19:23:29 kernel: wlan0: authenticate with 00:11:22:33:44:55
> > > > 19:23:29 kernel: [ cut here ]
> > > > 19:23:29 kernel: WARNING: CPU: 0 PID: 18925 at
> > > > net/mac80211/mlme.c:287 ieee80211_determine_chantype+0x12e/0x380
> > >
> > > This is already indicating a severe problem. I don't know how you
> > > end
> > > up in this situation with b43, since that doesn't have any
> > > regulatory
> > > magic afaict.
> > >
> > > > 19:23:29 kernel: wlan0: associated
> > > >
> > > > 19:24:29 kernel: wlan0: deauthenticating from 00:11:22:33:44:55
> > > > by
> > > > local choice (Reason: 3=DEAUTH_LEAVING)
> > >
> > > I'm convinced that this comes from reg_check_channels().
> > >
> > > The above WARN_ON() already told you that the channel was
> > > considered
> > > invalid.
> > >
> > > Do you know what channel your AP is on?
> >
> > 6
> >
> > > Perhaps show the output of "iw wlan0 scan dump" while it's
> >
> > connected (you have 60 seconds :P)
> >
> > I have been having stable connections for the past few days,
> > simply by putting a 60 second sleep before starting my wlan0.
> > Although
> > if I /etc/init.d/net.wlan0 restart it (without the delay), it will
> > still do this deauth'ing.
>
> Very strange.
>
> >   * 2437 MHz [6] 
> > Maximum TX power: 20.0 dBm
> > Channel widths:
>
> That's quite odd, why isn't it listing any possible channel widths?!

Is iw not handling 20MHZ_NOHT definition?

Regards,

Arend

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

[Hans de Goede]

Hi All,

I forgot to add --compose so I could add the cover letter I had
already written, so here it goes:

Hi Greg, all,

I'm hereby submitting the rtl8723bs driver which
Bastien Nocera and Larry Finger have been maintaining at:

https://github.com/hadess/rtl8723bs

For inclusion into staging, like most of the other rtl*
drivers in staging this is a cleaned up version of Realtek's
own driver code for Linux.

I would like to see this added to staging because the
rtl8723bs is found on quite a few systems used by Linux users,
such as on Atom systems (Intel Computestick and various other
Atom based devices) and on many (budget) ARM boards such as
the CHIP.

The plan moving forward with this is for the new clean,
written from scratch, rtl8xxxu driver to eventually gain
support for sdio devices. But there is no clear timeline
for that as Jes is doing that in his spare time, so
I would like to see this driver included in staging for now.

Regards,

Hans

Re: [PATCH v3 1/4] mac80211-hwsim: notify user-space about channel change.

[Ben Greear]

On 03/29/2017 09:51 AM, Johannes Berg wrote:



The patch appeared to solve my problem, and it seems an improvement
over what is there currently.  Whoever wants it to support even more
things can add that in the future?


Yes, that's kinda true. However, it also means that wmediumd (or
similar) would have to support the two APIs. It'd be simpler for them
to just have to support a single one, no?


I really don't understand what change you are suggesting.  Anything that
uses a new API needs to change, and as API is further improved, then the
app will need to change again.  Netlink's saving grace is that it is easy to
add new data members and so support new API in a forward/backward compatible 
manner.

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

[RESEND] ath9k failure to authenticate WPA2 client mode

[Tim Harvey]

Greetings,

(resending plaintext - oops)

I'm seeing failures to authenticate with a WPA2 secured AP using ath9k
based cards on wireless-next:

root@xenial-armhf:~# wpa_passphrase testssid testpass >
/etc/wpa_supplicant/wpa_supplicant.conf

root@xenial-armhf:~# iw reg get
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 17), (N/A)
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)

root@xenial-armhf:~# wpa_supplicant -i wlan0 -c
/etc/wpa_supplicant/wpa_supplicant.conf
Successfully initialized wpa_supplicant
[ 1882.699010] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
nl80211: send_and_recv->nl_recvms[ 1886.262884] wlan0: authenticate
with 02:1a:11:f2:35:9c
gs failed: -33
wlan0: SME: Trying to authenticate with 02:1a:11:f2:35:9c
(SSID='testssid' freq=2437 MHz)
[ 1886.280755] wlan0: send auth to 02:1a:11:f2:35:9c (try 1/3)
[ 1887.033449] wlan0: send auth to 02:1a:11:f2:35:9c (try 2/3)
[ 1887.993413] wlan0: send auth to 02:1a:11:f2:35:9c (try 3/3)
[ 1888.953390] wlan0: authentication with 02:1a:11:f2:35:9c timed out
wlan0: SME: Trying to authenticat[ 1892.507484] wlan0: authenticate
with 02:1a:11:f2:35:9c
e with 02:1a:11:f2:35:9c (SSID='testssid' freq=2437 MHz)
[ 1892.527460] wlan0: send auth to 02:1a:11:f2:35:9c (try 1/3)
[ 1893.993401] wlan0: send auth to 02:1a:11:f2:35:9c (try 2/3)
[ 1894.953419] wlan0: send auth to 02:1a:11:f2:35:9c (try 3/3)
[ 1895.993387] wlan0: authentication with 02:1a:11:f2:35:9c timed out
wlan0: SME: Trying to authenticat[ 1899.997262] wlan0: authenticate
with 02:1a:11:f2:35:9c
e with 02:1a:11:f2:35:9c (SSID='testssid' freq=2437 MHz)
[ 1900.017252] wlan0: send auth to 02:1a:11:f2:35:9c (try 1/3)
[ 1901.033259] wlan0: send auth to 02:1a:11:f2:35:9c (try 2/3)
[ 1901.993345] wlan0: send auth to 02:1a:11:f2:35:9c (try 3/3)
[ 1902.953270] wlan0: authentication with 02:1a:11:f2:35:9c timed out
wlan0: SME: Trying to authenticat[ 1907.407446] wlan0: authenticate
with 02:1a:11:f2:35:9c
e with 02:1a:11:f2:35:9c (SSID='testssid' freq=2437 MHz)
[ 1907.427370] wlan0: send auth to 02:1a:11:f2:35:9c (try 1/3)
[ 1908.003204] wlan0: send auth to 02:1a:11:f2:35:9c (try 2/3)
[ 1908.953275] wlan0: send auth to 02:1a:11:f2:35:9c (try 3/3)
[ 1909.993254] wlan0: authentication with 02:1a:11:f2:35:9c timed out
wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="testssid"
auth_failures=1 duration=10 reason=CONN_FAILED
^Cnl80211: deinit ifname=wlan0 disabled_11b_rates=0
wlan0: CTRL-EVENT-TERMINATING

I've tried loading ath9k with nohwcrypt=1 and see the same.

I do not have any trouble with an ath10k card in the same system:

root@xenial-armhf:~# wpa_supplicant -i wlan1 -c
/etc/wpa_supplicant/wpa_supplicant.conf
Successfully initialized wpa_supplicant
[  593.401846] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
wlan1: SME: Trying to authenticat[  596.857230] wlan1: authenticate
with 02:1a:11:f1:b9:02
e with 02:1a:11:f1:b9:02 (SSID='testssid' freq=2437 MHz)
[  596.876749] wlan1: send auth to 02:1a:11:f1:b9:02 (try 1/3)
[  596.886290] wlan1: authenticated
wlan1: Trying to associate with 02:1a:11:f1:b9:02 (SSID='testssid'
freq=2437 MHz)
[  596.909012] wlan1: associate with 02:1a:11:f1:b9:02 (try 1/3)
[  596.922374] wlan1: RX AssocResp from 02:1a:11:f1:b9:02 (capab=0x411
status=0 aid=1)
[  596.940754] wlan1: associated
[  596.943954] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
wlan1: Associated with 02:1a:11:f1:b9:02
wlan1: WPA: Key negotiation completed with 02:1a:11:f1:b9:02 [PTK=CCMP GTK=CCMP]
wlan1: CTRL-EVENT-CONNECTED - Connection to 02:1a:11:f1:b9:02
completed [id=0 id_str=]
wlan1: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=US
 at this point I can dhcp IP config and all is good

Here's the PCI info for the two cards:

08:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd.
88E8057 PCI-E Gigabit Ethernet Controller [11ab:4380]
09:00.0 Network controller [0280]: Qualcomm Atheros AR9580 Wireless
Network Adapter [168c:0033] (rev 01)

I don't know when ath9k last worked honestly. I usually use them under
OpenWrt which has its own patches against periodic updates of linux
backports. I noticed this first with Ubuntu 16.04 with the Ubuntu 4.4
kernel, saw it still with the Ubuntu 4.8 kernel, then repeated the
issue in wireless-next.

Any ideas?

Regards,

Tim

Re: [PATCH v3 3/4] mac80211-hwsim: add rate-limited debugging for rx-netlink

[Johannes Berg]

> > >   wiphy_debug(hw->wiphy,
> > > - "%s (freq=0 idle=%d ps=%d
> > > smps=%s)\n",
> > > + "%s (no-chandef-chan freq=0 idle=%d
> > > ps=%d smps=%s)\n",
> > 
> > This seems unrelated?
> 
> It can be cut out of the patch.  Want me to re-send?

No objection about that change itself, but I don't think it belongs
into the same patch, so yes, please do.

johannes

Re: [PATCH v3 1/4] mac80211-hwsim: notify user-space about channel change.

[Johannes Berg]

> The patch appeared to solve my problem, and it seems an improvement
> over what is there currently.  Whoever wants it to support even more
> things can add that in the future?

Yes, that's kinda true. However, it also means that wmediumd (or
similar) would have to support the two APIs. It'd be simpler for them
to just have to support a single one, no?

johannes

Re: compile driver for rtl8192su

[poma]

On 29.03.2017 14:51, walter strametz wrote:
> Hi - I try to get my D-Link N300 running and compiled the sources on
> github (chunkeey - rtl8192su).  Other trials also failed, because the
> driver-source is not compatible with the (newer) kernel.
> 
> See more information in the enclosed textfile .
> 
> Can you help me?
> 
> Thx, Walter
> 

>From the aforementioned attachment - compileerror.txt
[...]
walter@thinkpad ~/rtl8192su $ lsusb
Bus 002 Device 004: ID 2001:3319 D-Link Corp. 
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0a5c:217f Broadcom Corp. BCM2045B (BDC-2.1)
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[...]

= Bus 002 Device 004: ID 2001:3319 D-Link Corp. =


Support - DWA-131 - Revision E
http://www.dlink.com/uk/en/support/product/dwa-131-wireless-n-nano-usb-adapter?revision=deu_reve#downloads
Drivers
ftp://ftp.dlink.eu/Products/dwa/dwa-131/driver_software/DWA-131_drv_revE_5-03_eu_multi_20161215.zip

$ unzip DWA-131_drv_revE_5-03_eu_multi_20161215.zip
$ unzip 20161124_DWA-131E_V5.04b03.zip

$ dos2unix < 
20161124_DWA-131E_V5.04b03/Drivers/WinXPx86_Win2K/Dnetrtwlanu_XP.inf | grep 
2001.*3319
%DLink_131E.DeviceDesc% = RTL8192eu.ndi,
USB\VID_2001_3319



D-Link DWA-131 (N300, USB, WiFi Adapter)
http://www.linux-hardware-guide.com/2013-11-16-d-link-dwa-131-n300-usb-wifi-adapter
...
Version E1: 2001:3319
A new version of the DWA-131 was identified with USB ID 2001:3319
Bus 001 Device 003: ID 2001:3319 D-Link Corp
and seems to be based on the Realtek RTL8192eu chipset.
...

http://support.dlink.com.au/download/download.aspx?product=DWA-131
Drivers
ftp://files.dlink.com.au/products/DWA-131/REV_E/Drivers/DWA-131_Linux_driver_v4.3.1.1.zip

$ unzip DWA-131_Linux_driver_v4.3.1.1.zip
$ tar xf 20140812_rtl8192EU_linux_v4.3.1.1_11320.tar.gz

$ grep 2001.*3319 
20140812_rtl8192EU_linux_v4.3.1.1_11320/os_dep/linux/usb_intf.c
{USB_DEVICE(0x2001, 0x3319),.driver_info = RTL8192E}, /* D-Link - 
DWA-131 */

...

Drivers for the rtl8192eu chipset for wireless adapters (D-Link DWA-131 rev E1 
included!)
https://github.com/Mange/rtl8192eu-linux-driver

$ git clone https://github.com/Mange/rtl8192eu-linux-driver.git
$ cd rtl8192eu-linux-driver/
$ make
$ modinfo 8192eu.ko | grep 2001.3319
alias:  usb:v2001p3319d*dc*dsc*dp*ic*isc*ip*in*

Re: compile driver for rtl8192su

[Christian Lamparter]

Hello,

On Wednesday, March 29, 2017 2:51:13 PM CEST walter strametz wrote:
> I try to get my D-Link N300 running and compiled the sources on
> github (chunkeey - rtl8192su).  Other trials also failed, because the
> driver-source is not compatible with the (newer) kernel.
the 4.4.y kernel is too old.

Only kernels built from the latest wireless-testing.git are compatible.
If you want to know more about wireless-testing.git then visit the
wireless wiki's Git-Guide:


Regards,
Christian

[PATCH 3/7] NFC: nfcmrvl: do not use device-managed resources

[Johan Hovold]

This specifically fixes a NULL-pointer dereference when using the n_nci
line discipline on one end of a Unix98 pty as well as resource leaks in
the registration error paths.

Device-managed resources is a bad fit for this driver as devices can be
registered from the n_nci line discipline. Firstly, a tty may not even
have a corresponding device (should it be part of a Unix98 pty)
something which would lead to a NULL-pointer dereference when
registering resources.

Secondly, if the tty has a class device, its lifetime exceeds that of
the line discipline, which means that resources would leak every time
the line discipline is closed (or if registration fails).

Currently, the devres interface was only being used to request a reset
gpio despite the fact that it was already explicitly freed in
nfcmrvl_nci_unregister_dev() (along with the private data), something
which also prevented the resource leak at close.

Fixes: b2fe288eac72 ("NFC: nfcmrvl: free reset gpio")
Fixes: 4a2b947f56b3 ("NFC: nfcmrvl: add chip reset management")
Cc: stable  # 4.2: b2fe288eac72
Cc: Vincent Cuissard 
Signed-off-by: Johan Hovold 
---
 drivers/nfc/nfcmrvl/main.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/nfc/nfcmrvl/main.c b/drivers/nfc/nfcmrvl/main.c
index 51c8240a1672..8d4294fc3005 100644
--- a/drivers/nfc/nfcmrvl/main.c
+++ b/drivers/nfc/nfcmrvl/main.c
@@ -124,10 +124,9 @@ struct nfcmrvl_private *nfcmrvl_nci_register_dev(enum 
nfcmrvl_phy phy,
memcpy(>config, pdata, sizeof(*pdata));
 
if (priv->config.reset_n_io) {
-   rc = devm_gpio_request_one(dev,
-  priv->config.reset_n_io,
-  GPIOF_OUT_INIT_LOW,
-  "nfcmrvl_reset_n");
+   rc = gpio_request_one(priv->config.reset_n_io,
+ GPIOF_OUT_INIT_LOW,
+ "nfcmrvl_reset_n");
if (rc < 0)
nfc_err(dev, "failed to request reset_n io\n");
}
@@ -195,7 +194,7 @@ void nfcmrvl_nci_unregister_dev(struct nfcmrvl_private 
*priv)
nfcmrvl_fw_dnld_deinit(priv);
 
if (priv->config.reset_n_io)
-   devm_gpio_free(priv->dev, priv->config.reset_n_io);
+   gpio_free(priv->config.reset_n_io);
 
nci_unregister_device(ndev);
nci_free_device(ndev);
-- 
2.12.2

[PATCH 2/7] NFC: nfcmrvl_uart: add missing tty-device sanity check

[Johan Hovold]

Make sure to check the tty-device pointer before trying to access the
parent device to avoid dereferencing a NULL-pointer when the tty is one
end of a Unix98 pty.

Fixes: e097dc624f78 ("NFC: nfcmrvl: add UART driver")
Cc: stable  # 4.2
Cc: Vincent Cuissard 
Signed-off-by: Johan Hovold 
---
 drivers/nfc/nfcmrvl/uart.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/nfc/nfcmrvl/uart.c b/drivers/nfc/nfcmrvl/uart.c
index 83a99e38e7bd..6c0c301611c4 100644
--- a/drivers/nfc/nfcmrvl/uart.c
+++ b/drivers/nfc/nfcmrvl/uart.c
@@ -109,6 +109,7 @@ static int nfcmrvl_nci_uart_open(struct nci_uart *nu)
struct nfcmrvl_private *priv;
struct nfcmrvl_platform_data *pdata = NULL;
struct nfcmrvl_platform_data config;
+   struct device *dev = nu->tty->dev;
 
/*
 * Platform data cannot be used here since usually it is already used
@@ -116,9 +117,8 @@ static int nfcmrvl_nci_uart_open(struct nci_uart *nu)
 * and check if DT entries were added.
 */
 
-   if (nu->tty->dev->parent && nu->tty->dev->parent->of_node)
-   if (nfcmrvl_uart_parse_dt(nu->tty->dev->parent->of_node,
- ) == 0)
+   if (dev && dev->parent && dev->parent->of_node)
+   if (nfcmrvl_uart_parse_dt(dev->parent->of_node, ) == 0)
pdata = 
 
if (!pdata) {
@@ -131,7 +131,7 @@ static int nfcmrvl_nci_uart_open(struct nci_uart *nu)
}
 
priv = nfcmrvl_nci_register_dev(NFCMRVL_PHY_UART, nu, _ops,
-   nu->tty->dev, pdata);
+   dev, pdata);
if (IS_ERR(priv))
return PTR_ERR(priv);
 
-- 
2.12.2

[PATCH 1/7] NFC: fix broken device allocation

[Johan Hovold]

Commit 7eda8b8e9677 ("NFC: Use IDR library to assing NFC devices IDs")
moved device-id allocation and struct-device initialisation from
nfc_allocate_device() to nfc_register_device().

This broke just about every nfc-device-registration error path, which
continue to call nfc_free_device() that tries to put the device
reference of the now uninitialised (but zeroed) struct device:

kobject: '(null)' (ce316420): is not initialized, yet kobject_put() is being 
called.

The late struct-device initialisation also meant that various work
queues whose names are derived from the nfc device name were also
misnamed:

  421 root 0 SW<  [(null)_nci_cmd_]
  422 root 0 SW<  [(null)_nci_rx_w]
  423 root 0 SW<  [(null)_nci_tx_w]

Move the id-allocation and struct-device initialisation back to
nfc_allocate_device() and fix up the single call site which did not use
nfc_free_device() in its registration error path.

Fixes: 7eda8b8e9677 ("NFC: Use IDR library to assing NFC devices IDs")
Cc: stable  # 3.8
Cc: Samuel Ortiz 
Signed-off-by: Johan Hovold 
---
 net/nfc/core.c | 31 ++-
 net/nfc/nci/core.c |  3 +--
 2 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/net/nfc/core.c b/net/nfc/core.c
index 122bb81da918..5cf33df888c3 100644
--- a/net/nfc/core.c
+++ b/net/nfc/core.c
@@ -982,6 +982,8 @@ static void nfc_release(struct device *d)
kfree(se);
}
 
+   ida_simple_remove(_index_ida, dev->idx);
+
kfree(dev);
 }
 
@@ -1056,6 +1058,7 @@ struct nfc_dev *nfc_allocate_device(struct nfc_ops *ops,
int tx_headroom, int tx_tailroom)
 {
struct nfc_dev *dev;
+   int rc;
 
if (!ops->start_poll || !ops->stop_poll || !ops->activate_target ||
!ops->deactivate_target || !ops->im_transceive)
@@ -1068,6 +1071,15 @@ struct nfc_dev *nfc_allocate_device(struct nfc_ops *ops,
if (!dev)
return NULL;
 
+   rc = ida_simple_get(_index_ida, 0, 0, GFP_KERNEL);
+   if (rc < 0)
+   goto err_free_dev;
+   dev->idx = rc;
+
+   dev->dev.class = _class;
+   dev_set_name(>dev, "nfc%d", dev->idx);
+   device_initialize(>dev);
+
dev->ops = ops;
dev->supported_protocols = supported_protocols;
dev->tx_headroom = tx_headroom;
@@ -1090,6 +1102,11 @@ struct nfc_dev *nfc_allocate_device(struct nfc_ops *ops,
}
 
return dev;
+
+err_free_dev:
+   kfree(dev);
+
+   return ERR_PTR(rc);
 }
 EXPORT_SYMBOL(nfc_allocate_device);
 
@@ -1104,14 +1121,6 @@ int nfc_register_device(struct nfc_dev *dev)
 
pr_debug("dev_name=%s\n", dev_name(>dev));
 
-   dev->idx = ida_simple_get(_index_ida, 0, 0, GFP_KERNEL);
-   if (dev->idx < 0)
-   return dev->idx;
-
-   dev->dev.class = _class;
-   dev_set_name(>dev, "nfc%d", dev->idx);
-   device_initialize(>dev);
-
mutex_lock(_devlist_mutex);
nfc_devlist_generation++;
rc = device_add(>dev);
@@ -1149,12 +1158,10 @@ EXPORT_SYMBOL(nfc_register_device);
  */
 void nfc_unregister_device(struct nfc_dev *dev)
 {
-   int rc, id;
+   int rc;
 
pr_debug("dev_name=%s\n", dev_name(>dev));
 
-   id = dev->idx;
-
if (dev->rfkill) {
rfkill_unregister(dev->rfkill);
rfkill_destroy(dev->rfkill);
@@ -1179,8 +1186,6 @@ void nfc_unregister_device(struct nfc_dev *dev)
nfc_devlist_generation++;
device_del(>dev);
mutex_unlock(_devlist_mutex);
-
-   ida_simple_remove(_index_ida, id);
 }
 EXPORT_SYMBOL(nfc_unregister_device);
 
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index 61fff422424f..85a3d9ed4c29 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -1173,8 +1173,7 @@ struct nci_dev *nci_allocate_device(struct nci_ops *ops,
return ndev;
 
 free_nfc:
-   kfree(ndev->nfc_dev);
-
+   nfc_free_device(ndev->nfc_dev);
 free_nci:
kfree(ndev);
return NULL;
-- 
2.12.2

[PATCH 0/7] NFC: fix device allocation and nfcmrvl crashes

[Johan Hovold]

This started out with the observation that the nfcmrvl_uart driver
unconditionally dereferenced the tty class device despite the fact that
not every tty has an associated struct device (Unix98 ptys). Some
further changes were needed in the common nfcmrvl code to fully address
this, some of which also incidentally fixed a few related bugs (e.g.
resource leaks in error paths).

While fixing this I stumbled over a regression in NFC core that lead to
broken registration error paths and misnamed workqueues.

Note that this has only been tested by configuring the n_hci line
discipline for different ttys without any actual NFC hardware connected.

Johan


Johan Hovold (7):
  NFC: fix broken device allocation
  NFC: nfcmrvl_uart: add missing tty-device sanity check
  NFC: nfcmrvl: do not use device-managed resources
  NFC: nfcmrvl: use nfc-device for firmware download
  NFC: nfcmrvl: fix firmware-management initialisation
  NFC: nfcmrvl_uart: fix device-node leak during probe
  NFC: nfcmrvl_usb: use interface as phy device

 drivers/nfc/nfcmrvl/fw_dnld.c |  7 +--
 drivers/nfc/nfcmrvl/main.c| 25 +
 drivers/nfc/nfcmrvl/uart.c| 11 +++
 drivers/nfc/nfcmrvl/usb.c |  4 +---
 net/nfc/core.c| 31 ++-
 net/nfc/nci/core.c|  3 +--
 6 files changed, 45 insertions(+), 36 deletions(-)

-- 
2.12.2

[PATCH 7/7] NFC: nfcmrvl_usb: use interface as phy device

[Johan Hovold]

Use the USB-interface rather than parent USB-device device, which is
what this driver binds to, when registering the nci device.

Note that using the right device is important when dealing with device-
managed resources as the interface can be unbound independently of the
parent device.

Also note that private device pointer had already been set by
nfcmrvl_nci_register_dev() so the redundant assignment can therefore be
removed.

Signed-off-by: Johan Hovold 
---
 drivers/nfc/nfcmrvl/usb.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/nfc/nfcmrvl/usb.c b/drivers/nfc/nfcmrvl/usb.c
index 585a0f20835b..728b3321842d 100644
--- a/drivers/nfc/nfcmrvl/usb.c
+++ b/drivers/nfc/nfcmrvl/usb.c
@@ -341,15 +341,13 @@ static int nfcmrvl_probe(struct usb_interface *intf,
init_usb_anchor(_data->deferred);
 
priv = nfcmrvl_nci_register_dev(NFCMRVL_PHY_USB, drv_data, _ops,
-   _data->udev->dev, );
+   >dev, );
if (IS_ERR(priv))
return PTR_ERR(priv);
 
drv_data->priv = priv;
drv_data->priv->support_fw_dnld = false;
 
-   priv->dev = _data->udev->dev;
-
usb_set_intfdata(intf, drv_data);
 
return 0;
-- 
2.12.2

[PATCH 4/7] NFC: nfcmrvl: use nfc-device for firmware download

[Johan Hovold]

Use the nfc- rather than phy-device in firmware-management code that
needs a valid struct device.

This specifically fixes a NULL-pointer dereference in
nfcmrvl_fw_dnld_init() during registration when the underlying tty is
one end of a Unix98 pty.

Note that the driver still uses the phy device for any debugging, which
is fine for now.

Fixes: 3194c6870158 ("NFC: nfcmrvl: add firmware download support")
Cc: stable  # 4.4
Cc: Vincent Cuissard 
Signed-off-by: Johan Hovold 
---
 drivers/nfc/nfcmrvl/fw_dnld.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/nfc/nfcmrvl/fw_dnld.c b/drivers/nfc/nfcmrvl/fw_dnld.c
index f8dcdf4b24f6..af62c4c854f3 100644
--- a/drivers/nfc/nfcmrvl/fw_dnld.c
+++ b/drivers/nfc/nfcmrvl/fw_dnld.c
@@ -459,7 +459,7 @@ int nfcmrvl_fw_dnld_init(struct nfcmrvl_private *priv)
 
INIT_WORK(>fw_dnld.rx_work, fw_dnld_rx_work);
snprintf(name, sizeof(name), "%s_nfcmrvl_fw_dnld_rx_wq",
-dev_name(priv->dev));
+dev_name(>ndev->nfc_dev->dev));
priv->fw_dnld.rx_wq = create_singlethread_workqueue(name);
if (!priv->fw_dnld.rx_wq)
return -ENOMEM;
@@ -496,6 +496,7 @@ int nfcmrvl_fw_dnld_start(struct nci_dev *ndev, const char 
*firmware_name)
 {
struct nfcmrvl_private *priv = nci_get_drvdata(ndev);
struct nfcmrvl_fw_dnld *fw_dnld = >fw_dnld;
+   int res;
 
if (!priv->support_fw_dnld)
return -ENOTSUPP;
@@ -511,7 +512,9 @@ int nfcmrvl_fw_dnld_start(struct nci_dev *ndev, const char 
*firmware_name)
 */
 
/* Retrieve FW binary */
-   if (request_firmware(_dnld->fw, firmware_name, priv->dev) < 0) {
+   res = request_firmware(_dnld->fw, firmware_name,
+  >nfc_dev->dev);
+   if (res < 0) {
nfc_err(priv->dev, "failed to retrieve FW %s", firmware_name);
return -ENOENT;
}
-- 
2.12.2

[PATCH 6/7] NFC: nfcmrvl_uart: fix device-node leak during probe

[Johan Hovold]

Make sure to release the device-node reference when done parsing the
node.

Fixes: e097dc624f78 ("NFC: nfcmrvl: add UART driver")
Cc: Vincent Cuissard 
Signed-off-by: Johan Hovold 
---
 drivers/nfc/nfcmrvl/uart.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/nfc/nfcmrvl/uart.c b/drivers/nfc/nfcmrvl/uart.c
index 6c0c301611c4..91162f8e0366 100644
--- a/drivers/nfc/nfcmrvl/uart.c
+++ b/drivers/nfc/nfcmrvl/uart.c
@@ -84,6 +84,7 @@ static int nfcmrvl_uart_parse_dt(struct device_node *node,
ret = nfcmrvl_parse_dt(matched_node, pdata);
if (ret < 0) {
pr_err("Failed to get generic entries\n");
+   of_node_put(matched_node);
return ret;
}
 
@@ -97,6 +98,8 @@ static int nfcmrvl_uart_parse_dt(struct device_node *node,
else
pdata->break_control = 0;
 
+   of_node_put(matched_node);
+
return 0;
 }
 
-- 
2.12.2

[PATCH 5/7] NFC: nfcmrvl: fix firmware-management initialisation

[Johan Hovold]

The nci-device was never deregistered in the event that
fw-initialisation failed.

Fix this by moving the firmware initialisation before device
registration since the firmware work queue should be available before
registering.

Note that this depends on a recent fix that moved device-name
initialisation back to to nci_allocate_device() as the
firmware-workqueue name is now derived from the nfc-device name.

Fixes: 3194c6870158 ("NFC: nfcmrvl: add firmware download support")
Cc: stable  # 4.4
Cc: Vincent Cuissard 
Signed-off-by: Johan Hovold 
---
 drivers/nfc/nfcmrvl/main.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/nfc/nfcmrvl/main.c b/drivers/nfc/nfcmrvl/main.c
index 8d4294fc3005..f20220bab6b6 100644
--- a/drivers/nfc/nfcmrvl/main.c
+++ b/drivers/nfc/nfcmrvl/main.c
@@ -156,26 +156,28 @@ struct nfcmrvl_private *nfcmrvl_nci_register_dev(enum 
nfcmrvl_phy phy,
goto error;
}
 
+   rc = nfcmrvl_fw_dnld_init(priv);
+   if (rc) {
+   nfc_err(dev, "failed to initialize FW download %d\n", rc);
+   goto error_free_dev;
+   }
+
nci_set_drvdata(priv->ndev, priv);
 
rc = nci_register_device(priv->ndev);
if (rc) {
nfc_err(dev, "nci_register_device failed %d\n", rc);
-   goto error_free_dev;
+   goto error_fw_dnld_deinit;
}
 
/* Ensure that controller is powered off */
nfcmrvl_chip_halt(priv);
 
-   rc = nfcmrvl_fw_dnld_init(priv);
-   if (rc) {
-   nfc_err(dev, "failed to initialize FW download %d\n", rc);
-   goto error_free_dev;
-   }
-
nfc_info(dev, "registered with nci successfully\n");
return priv;
 
+error_fw_dnld_deinit:
+   nfcmrvl_fw_dnld_deinit(priv);
 error_free_dev:
nci_free_device(priv->ndev);
 error:
-- 
2.12.2

Re: [PATCH v3 3/4] mac80211-hwsim: add rate-limited debugging for rx-netlink

[Ben Greear]

On 03/29/2017 01:46 AM, Johannes Berg wrote:

On Thu, 2017-03-23 at 16:26 -0700, gree...@candelatech.com wrote:

From: Ben Greear 

This makes it easier to understand why wmediumd (or similar)
is getting errors when sending frames to the kernel.

Signed-off-by: Ben Greear 
---
 drivers/net/wireless/mac80211_hwsim.c | 55
+++
 1 file changed, 43 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index 234df8c..84dcddf 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -137,6 +137,12 @@ static int regtest = HWSIM_REGTEST_DISABLED;
 module_param(regtest, int, 0444);
 MODULE_PARM_DESC(regtest, "The type of regulatory test we want to
run");

+DEFINE_RATELIMIT_STATE(hwsim_ratelimit_state, 5 * HZ, 10);
+int hwsim_ratelimit(void)
+{
+   return __ratelimit(_ratelimit_state);
+}
+
 static const char *hwsim_alpha2s[] = {
"FI",
"AL",
@@ -1649,7 +1655,7 @@ static int mac80211_hwsim_config(struct
ieee80211_hw *hw, u32 changed)

if (conf->chandef.chan)
wiphy_debug(hw->wiphy,
-   "%s (freq=%d(%d - %d)/%s idle=%d ps=%d
smps=%s)\n",
+   "%s (chandef-chan freq=%d(%d - %d)/%s
idle=%d ps=%d smps=%s)\n",
__func__,
conf->chandef.chan->center_freq,
conf->chandef.center_freq1,
@@ -1660,7 +1666,7 @@ static int mac80211_hwsim_config(struct
ieee80211_hw *hw, u32 changed)
smps_modes[conf->smps_mode]);
else
wiphy_debug(hw->wiphy,
-   "%s (freq=0 idle=%d ps=%d smps=%s)\n",
+   "%s (no-chandef-chan freq=0 idle=%d
ps=%d smps=%s)\n",


This seems unrelated?


It can be cut out of the patch.  Want me to re-send?

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH v3 1/4] mac80211-hwsim: notify user-space about channel change.

[Ben Greear]

On 03/29/2017 01:42 AM, Johannes Berg wrote:



+   if (data->center_freq2)
+   if (nla_put_u32(skb, HWSIM_ATTR_CENTER_FREQ2, data-

center_freq2))

+   goto nla_put_failure;



That could be simplified (but isn't really interesting)


+ * @HWSIM_ATTR_CENTER_FREQ2: Configured center-freq-2.  Not reported
if value is zero.


The value 0 really just means "unused" - so this should say "if used"
or so.


+ * @HWSIM_ATTR_CH_WIDTH: Configured channel width.


That should point to  nl80211_chan_width I guess.

Anyway, all of that is minor. The biggest problem I have with this
patch upon close review is that it only handles one case, and actually
ties that case to the nl80211 API.

hwsim also can deal with channel contexts already, is there much point
in making the userspace API ignorant of that?


The patch appeared to solve my problem, and it seems an improvement
over what is there currently.  Whoever wants it to support even more things
can add that in the future?

If you remember, the first iteration of my patch had the NL API defines
more general, so that someone could just add more data members
as the needs grew.  It can still grow, however.

Thanks,
Ben


--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: Support of rtl8723bs

[Larry Finger]

On 03/29/2017 05:20 AM, Hanno Zulla wrote:

Hi,

it was exciting to see

https://marc.info/?l=linux-wireless=148735587909056=2

So please forgive me for asking about the current state of things.


I cannot divulge any details at present, but there are plans to submit a staging 
driver for the RTL8723BS card.


Larry

compile driver for rtl8192su

[walter strametz]

Hi - I try to get my D-Link N300 running and compiled the sources on
github (chunkeey - rtl8192su).  Other trials also failed, because the
driver-source is not compatible with the (newer) kernel.

See more information in the enclosed textfile .

Can you help me?

Thx, Walter
Hi - I try to get my D-Link N300 running and compiled: 

gthub.com/chunkeey/rtl8192su

walter@thinkpad ~/rtl8192su $ make
make -C /lib/modules/4.4.0-70-generic/build M=/home/walter/rtl8192su/rtlwifi 
CONFIG_RTL_CARDS=y CONFIG_RTLWIFI=m CONFIG_RTLWIFI_DEBUG=y 
CONFIG_RTLWIFI_DEBUGFS=y CONFIG_RTLWIFI_USB=m CONFIG_RTLWIFI_PCI=m 
CONFIG_RTL8192SU=m CONFIG_RTL8192SE=m CONFIG_RTL8192S_COMMON=m 
CONFIG_RTL8192CU=n CONFIG_RTL8192DE=n CONFIG_RTL8192CE=n 
CONFIG_RTL8192C_COMMON=n CONFIG_RTL8723AE=n CONFIG_RTL8188EE=n  
EXTRA_CFLAGS="-DDEBUG -DCONFIG_RTLWIFI_DEBUGFS=m"
make[1]: Entering directory '/usr/src/linux-headers-4.4.0-70-generic'
  CC [M]  /home/walter/rtl8192su/rtlwifi/base.o
In file included from /home/walter/rtl8192su/rtlwifi/base.c:26:0:
/home/walter/rtl8192su/rtlwifi/wifi.h:1363:40: error: ‘NUM_NL80211_BANDS’ 
undeclared here (not in a function)
  struct ieee80211_supported_band bands[NUM_NL80211_BANDS];
^
/home/walter/rtl8192su/rtlwifi/base.c: In function ‘rtlwifi_rate_mapping’:
/home/walter/rtl8192su/rtlwifi/base.c:961:25: warning: comparison between ‘enum 
nl80211_band’ and ‘enum ieee80211_band’ [-Wenum-compare]
   if (NL80211_BAND_2GHZ == hw->conf.chandef.chan->band) {
 ^
scripts/Makefile.build:258: recipe for target 
'/home/walter/rtl8192su/rtlwifi/base.o' failed
make[2]: *** [/home/walter/rtl8192su/rtlwifi/base.o] Error 1
Makefile:1420: recipe for target '_module_/home/walter/rtl8192su/rtlwifi' failed
make[1]: *** [_module_/home/walter/rtl8192su/rtlwifi] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.4.0-70-generic'
Makefile:22: recipe for target 'all' failed
make: *** [all] Error 2
walter@thinkpad ~/rtl8192su $ 

Here is some info about my environment: 

walter@thinkpad ~/rtl8192su $ lsusb
Bus 002 Device 004: ID 2001:3319 D-Link Corp. 
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0a5c:217f Broadcom Corp. BCM2045B (BDC-2.1)
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


walter@thinkpad ~/rtl8192su $ inxi  -Fx
System:Host: thinkpad Kernel: 4.4.0-70-generic x86_64 (64 bit gcc: 5.4.0)
   Desktop: Cinnamon 3.0.7 (Gtk 3.18.9-1ubuntu3.2)
   Distro: Linux Mint 18 Sarah
Machine:   System: LENOVO (portable) product: 3249CTO v: ThinkPad X201
   Mobo: LENOVO model: 3249CTO
   Bios: LENOVO v: 6QET61WW (1.31 ) date: 10/26/2010
CPU:   Dual core Intel Core i7 M 620 (-HT-MCP-) cache: 4096 KB
   flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 10639
   clock speeds: max: 2667 MHz 1: 1199 MHz 2: 1199 MHz 3: 2133 MHz
   4: 1333 MHz
Graphics:  Card: Intel Core Processor Integrated Graphics Controller
   bus-ID: 00:02.0
   Display Server: X.Org 1.18.4 drivers: intel (unloaded: fbdev,vesa)
   Resolution: 1280x800@60.00hz
   GLX Renderer: Mesa DRI Intel Ironlake Mobile
   GLX Version: 2.1 Mesa 12.0.6 Direct Rendering: Yes
Audio: Card Intel 5 Series/3400 Series High Definition Audio
   driver: snd_hda_intel bus-ID: 00:1b.0
   Sound: Advanced Linux Sound Architecture v: k4.4.0-70-generic
Network:   Card-1: Intel 82577LM Gigabit Network Connection
   driver: e1000e v: 3.2.6-k port: 1820 bus-ID: 00:19.0
   IF: enp0s25 state: up speed: 1000 Mbps duplex: full
   mac: f0:de:f1:3a:5e:7d
   Card-2: Intel Centrino Wireless-N 1000 [Condor Peak]
   driver: iwlwifi bus-ID: 02:00.0
   IF: wlp2s0 state: up mac: 8c:a9:82:10:b2:2c
Drives:HDD Total Size: 250.1GB (81.6% used)
   ID-1: /dev/sda model: Samsung_SSD_850 size: 250.1GB temp: 0C
Partition: ID-1: / size: 222G used: 183G (87%) fs: ext4 dev: /dev/sda1
   ID-2: swap-1 size: 8.37GB used: 0.00GB (0%) fs: swap dev: /dev/sda5
RAID:  No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   System Temperatures: cpu: 52.0C mobo: 0.0C
   Fan Speeds (in rpm): cpu: 3276
Info:  Processes: 200 Uptime: 9 min Memory: 1777.9/7779.5MB
   Init: systemd runlevel: 5 Gcc sys: 5.4.0
   Client: Shell (bash 4.3.421) inxi: 2.2.35 



can you help me? 

Thx, Walter

[PATCH] mac80211: unconditionally start new netdev queues with iTXQ support

[Johannes Berg]

From: Johannes Berg 

When internal mac80211 TXQs aren't supported, netdev queues must
always started out started even when driver queues are stopped
while the interface is added. This is necessary because with the
internal TXQ support netdev queues are never stopped and packet
scheduling/dropping is done in mac80211.

Cc: sta...@vger.kernel.org # 4.9+
Fixes: 80a83cfc434b1 ("mac80211: skip netdev queue control with software 
queuing")
Reported-and-tested-by: Sven Eckelmann 
Signed-off-by: Johannes Berg 
---
 net/mac80211/iface.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 40813dd3301c..5bb0c5012819 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -718,7 +718,8 @@ int ieee80211_do_open(struct wireless_dev *wdev, bool 
coming_up)
ieee80211_recalc_ps(local);
 
if (sdata->vif.type == NL80211_IFTYPE_MONITOR ||
-   sdata->vif.type == NL80211_IFTYPE_AP_VLAN) {
+   sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
+   local->ops->wake_tx_queue) {
/* XXX: for AP_VLAN, actually track AP queues */
netif_tx_start_all_queues(dev);
} else if (dev) {
-- 
2.11.0

Re: [REGRESSION] mac80211: IBSS vif queue stopped when started after 11s vif

[Sven Eckelmann]

On Mittwoch, 29. März 2017 13:53:06 CEST Johannes Berg wrote:
[...]
> > Not sure whether removing it in ieee80211_propagate_queue_wake will
> > have other odd side effects with software queuing. Maybe Michal
> > Kazior can tell us if it is safe to remove it.
> 
> No, it's the other way around.
> 
> Michal's patches correctly added a test for this to
> __ieee80211_stop_queue(), the only missing thing is that this test
> should also be in ieee80211_do_open() like this:
> 
> diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
> index 40813dd3301c..5bb0c5012819 100644
> --- a/net/mac80211/iface.c
> +++ b/net/mac80211/iface.c
> @@ -718,7 +718,8 @@ int ieee80211_do_open(struct wireless_dev *wdev, bool 
> coming_up)
>   ieee80211_recalc_ps(local);
>  
>   if (sdata->vif.type == NL80211_IFTYPE_MONITOR ||
> - sdata->vif.type == NL80211_IFTYPE_AP_VLAN) {
> + sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
> + local->ops->wake_tx_queue) {
>   /* XXX: for AP_VLAN, actually track AP queues */
>   netif_tx_start_all_queues(dev);
>   } else if (dev) {

Yes, this also works.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Get Number of Pending Wifi Frames in Mesh ALM calc

[Benjamin Beichler]

Hi,

we investigate a possibility to enrich the ALM with information about a
possible delay caused by buffering in all nodes along a mesh path. This
could better reflect the idea of an real "airtime" of a new send frame.
Therefore I'm searching for a general way to get the number of
outstanding frames of an mac80211 based wifi-driver.

I think it could be possible to count the number of one of the
skb_queues in struct ieee80211_local. Maybe there is also a possibility
to use the new codel infrastructure in mac80211 to get a impression
about buffered frames of a wiphy, but I think this would only work on
flow end-points, but we need a metric estimation on every node. Do
anybody know whether I'm right at this point ?

We will test our implementation on ath9k cards as well as on
mac80211_hwsim simulation, therefore it should work at least on this
both :-)

The nice thing could be, to combine end point regulation methods with
regulating parameters on nodes on the forwarding path to get better
throughput in mesh networks.


kind regards

-- 
M.Sc. Benjamin Beichler

Universität Rostock, Fakultät für Informatik und Elektrotechnik
Institut für Angewandte Mikroelektronik und Datentechnik

University of Rostock, Department of CS and EE
Institute of Applied Microelectronics and CE

Richard-Wagner-Straße 31
18119 Rostock
Deutschland/Germany

phone: +49 (0) 381 498 - 7278
email: benjamin.beich...@uni-rostock.de
www: http://www.imd.uni-rostock.de/

Re: [REGRESSION] mac80211: IBSS vif queue stopped when started after 11s vif

[Johannes Berg]

> if (local->ops->wake_tx_queue)
>   return;
> 
> evaluates to true. The rest rest of the function is therefore always
> skipped for ath9k.

Ahh, yes, ok.

> Removing this is enough to fix the problem. And now you will propably
> say "hey, this is not my code". And this is the reason why I have now
> CC'ed the author of 80a83cfc434b ("mac80211: skip netdev queue
> control with software queuing"). This change in
> ieee80211_propagate_queue_wake is basically breaking 
> the (delayed) startup of the ibss netdev queue [1] when the device
> was offchan during the ieee80211_do_open of the ibss interface.
> 
> Not sure whether removing it in ieee80211_propagate_queue_wake will
> have other odd side effects with software queuing. Maybe Michal
> Kazior can tell us if it is safe to remove it.

No, it's the other way around.

Michal's patches correctly added a test for this to
__ieee80211_stop_queue(), the only missing thing is that this test
should also be in ieee80211_do_open() like this:

diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 40813dd3301c..5bb0c5012819 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -718,7 +718,8 @@ int ieee80211_do_open(struct wireless_dev *wdev, bool 
coming_up)
ieee80211_recalc_ps(local);
 
if (sdata->vif.type == NL80211_IFTYPE_MONITOR ||
-   sdata->vif.type == NL80211_IFTYPE_AP_VLAN) {
+   sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
+   local->ops->wake_tx_queue) {
/* XXX: for AP_VLAN, actually track AP queues */
netif_tx_start_all_queues(dev);
} else if (dev) {

johannes

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Johannes Berg]

On Wed, 2017-03-29 at 06:28 -0400, Dennis New wrote:
> On Wed, 29 Mar 2017 09:34:50 +0200, Johannes Berg wrote:
> > On Fri, 2017-03-24 at 21:32 -0400, Dennis New wrote:
> > > Ever since I upgraded to the 4.10 kernels (I don't think this
> > > behavior existed in the 4.8 series), after I startup my laptop
> > > (either from cold boot, or from standby), my wlan0 interface
> > > keeps
> > > deauthenticating
> > > ...
> > > 19:23:29 kernel: wlan0: authenticate with 00:11:22:33:44:55
> > > 19:23:29 kernel: [ cut here ]
> > > 19:23:29 kernel: WARNING: CPU: 0 PID: 18925 at
> > > net/mac80211/mlme.c:287 ieee80211_determine_chantype+0x12e/0x380
> > 
> > This is already indicating a severe problem. I don't know how you
> > end
> > up in this situation with b43, since that doesn't have any
> > regulatory
> > magic afaict.
> > 
> > > 19:23:29 kernel: wlan0: associated
> > > 
> > > 19:24:29 kernel: wlan0: deauthenticating from 00:11:22:33:44:55
> > > by
> > > local choice (Reason: 3=DEAUTH_LEAVING)
> > 
> > I'm convinced that this comes from reg_check_channels().
> > 
> > The above WARN_ON() already told you that the channel was
> > considered
> > invalid.
> > 
> > Do you know what channel your AP is on?
> 
> 6
> 
> > Perhaps show the output of "iw wlan0 scan dump" while it's
> 
> connected (you have 60 seconds :P)
> 
> I have been having stable connections for the past few days,
> simply by putting a 60 second sleep before starting my wlan0.
> Although
> if I /etc/init.d/net.wlan0 restart it (without the delay), it will
> still do this deauth'ing.

Very strange.

>   * 2437 MHz [6] 
>     Maximum TX power: 20.0 dBm
>     Channel widths:

That's quite odd, why isn't it listing any possible channel widths?!

I get:
* 2437 MHz [6] 
  Maximum TX power: 15.0 dBm
  Channel widths: 20MHz HT40- HT40+

What's "iw reg get"?

johannes

Re: [PATCH] brcmfmac: wrap brcmf_fws_(de)init into bcdc layer

[Rafał Miłecki]

On 03/22/2017 08:43 PM, Arend Van Spriel wrote:

On 21-3-2017 14:44, Rafał Miłecki wrote:

From: Rafał Miłecki 

fwsignal is only used by bcdc. Create new protocol interface functions
for core code to perform proto specific (de)initialization. This makes
core agnostic to the protocol which will allow further optimizations.
We will be able to avoid compiling unused protocols or modularize them.


Thanks, Rafał

Franky had tackled this with two patches, which are queued to be submitted.


Given that your implementation (you now published) doesn't do any magic, is
there any real problem with my patch except of /not invented here/?

[0] https://en.wikipedia.org/wiki/Not_invented_here

Re: [PATCH 2/5] brcmfmac: move brcmf_fws_deinit to bcdc layer

[Rafał Miłecki]

On 03/28/2017 12:43 PM, Arend van Spriel wrote:

From: Franky Lin 

Move brcmf_fws_deinit into brcmf_proto_bcdc_detach since it is a bcdc
exclusive feature.

Signed-off-by: Franky Lin 
Change-Id: Iefa5db632b92185a49d538b1cd25b7d8be618ce0
Reviewed-on: http://hnd-swgit.sj.broadcom.com:8080/8157
Reviewed-by: brcm80211 ci 
Reviewed-by: Arend Van Spriel 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 1 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 7 ---
 2 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
index bc24b00..67a132c1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
@@ -464,6 +464,7 @@ int brcmf_proto_bcdc_attach(struct brcmf_pub *drvr)

 void brcmf_proto_bcdc_detach(struct brcmf_pub *drvr)
 {
+   brcmf_fws_deinit(drvr);
kfree(drvr->proto->pd);
drvr->proto->pd = NULL;
 }


I'd appreciate you commenting on someones work. I wouldn't mind "Move deinit to
brcmf_proto_bcdc_detach" comment so I could update my
[PATCH] brcmfmac: wrap brcmf_fws_(de)init into bcdc layer
if that is so important.



diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 9886280..ba4da48 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -32,7 +32,6 @@
 #include "p2p.h"
 #include "cfg80211.h"
 #include "fwil.h"
-#include "fwsignal.h"
 #include "feature.h"
 #include "proto.h"
 #include "pcie.h"
@@ -1034,10 +1033,6 @@ int brcmf_bus_started(struct device *dev)
brcmf_cfg80211_detach(drvr->config);
drvr->config = NULL;
}
-   if (drvr->fws) {
-   brcmf_proto_del_if(ifp->drvr, ifp);
-   brcmf_fws_deinit(drvr);
-   }
brcmf_net_detach(ifp->ndev, false);
if (p2p_ifp)
brcmf_net_detach(p2p_ifp->ndev, false);


I don't like this. By removing del_if from error path you assume add_if doesn't
allocate any memory and it never will.

It's quite hacky for me. If you init something, then you should also deinit it.
Otherwise it's too easy to introduce an invalid state or add a memory leak.
Please keep code simple to follow.

Re: [PATCH 1/5] brcmfmac: wrap brcmf_fws_init into bcdc layer

[Rafał Miłecki]

On 03/28/2017 12:43 PM, Arend van Spriel wrote:

From: Franky Lin 

Create a new protocol layer interface brcmf_proto_init_cb for protocol
layer to finish initialzation after core module components(fweh and
etc.) are initialized.

Signed-off-by: Franky Lin 
Change-Id: I560d2478a7c09766cf07b20d74b31dff5ca6ac7b
Reviewed-on: http://hnd-swgit.sj.broadcom.com:8080/8156


These 2 lines are rather useless.



Reviewed-by: brcm80211 ci 


Please use full names only.



Reviewed-by: Arend Van Spriel 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c  | 7 +++
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c  | 2 +-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.h | 9 +
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
index 92eafcc..bc24b00 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
@@ -417,6 +417,12 @@ static void brcmf_proto_bcdc_rxreorder(struct brcmf_if 
*ifp,
brcmf_fws_reset_interface(ifp);
 }

+static int
+brcmf_proto_bcdc_init_done(struct brcmf_pub *drvr)
+{
+   return brcmf_fws_init(drvr);
+}
+
 int brcmf_proto_bcdc_attach(struct brcmf_pub *drvr)
 {
struct brcmf_bcdc *bcdc;
@@ -443,6 +449,7 @@ int brcmf_proto_bcdc_attach(struct brcmf_pub *drvr)
drvr->proto->add_if = brcmf_proto_bcdc_add_if;
drvr->proto->del_if = brcmf_proto_bcdc_del_if;
drvr->proto->reset_if = brcmf_proto_bcdc_reset_if;
+   drvr->proto->init_done = brcmf_proto_bcdc_init_done;
drvr->proto->pd = bcdc;

drvr->hdrlen += BCDC_HEADER_LEN + BRCMF_PROT_FW_SIGNAL_MAX_TXBYTES;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 60c6c78..9886280 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -986,7 +986,7 @@ int brcmf_bus_started(struct device *dev)
}
brcmf_feat_attach(drvr);

-   ret = brcmf_fws_init(drvr);
+   ret = brcmf_proto_init_done(drvr);
if (ret < 0)
goto fail;

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.h
index 3048ed5..600fd33 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.h
@@ -47,6 +47,7 @@ struct brcmf_proto {
void (*add_if)(struct brcmf_if *ifp);
void (*del_if)(struct brcmf_if *ifp);
void (*reset_if)(struct brcmf_if *ifp);
+   int (*init_done)(struct brcmf_pub *drvr);
void *pd;
 };

@@ -145,4 +146,12 @@ static inline bool brcmf_proto_is_reorder_skb(struct 
sk_buff *skb)
drvr->proto->reset_if(ifp);
 }

+static inline int
+brcmf_proto_init_done(struct brcmf_pub *drvr)
+{
+   if (!drvr->proto->init_done)
+   return 0;
+   return drvr->proto->init_done(drvr);
+}
+
 #endif /* BRCMFMAC_PROTO_H */


So how is it any different from change in my:
[PATCH] brcmfmac: wrap brcmf_fws_(de)init into bcdc layer
? Is it only about replacing "init" with "init_done"?

I don't see why you couldn't rebase your changes on top of my patch.

Re: [PATCH 0/5] brcmfmac: network namespace support

[Rafał Miłecki]

On 03/28/2017 12:43 PM, Arend van Spriel wrote:

This series intended for 4.12 includes:
- support for network namespace
- rework fwsignal module
- small fix for suspend error code path

Arend van Spriel (3):
  brcmfmac: add support to move wiphy instance into network namespace
  brcmfmac: restore bus state when enter_D3 fails
  brcmfmac: no need for d11inf instance in brcmf_pno_start_sched_scan()

Franky Lin (2):
  brcmfmac: wrap brcmf_fws_init into bcdc layer
  brcmfmac: move brcmf_fws_deinit to bcdc layer


It seems only 1 patch matches your patchset title. Maybe try picking them more
carefully ;)

Re: [REGRESSION] mac80211: IBSS vif queue stopped when started after 11s vif

[Sven Eckelmann]

On Mittwoch, 29. März 2017 09:49:21 CEST Johannes Berg wrote:
> > But I could be completely wrong about it. It would therefore be
> > interesting for me to know who would be responsible to start the
> > queues when ieee80211_do_open rejected it for IBSS.
> 
> Well, once ieee80211_offchannel_return() is called, that should do the
> needful and end up in ieee80211_propagate_queue_wake().
> 
> Can you check what the IBSS vif's queues are (vif->hw_queue[...])?

I've just dumped the data in ieee80211_propagate_queue_wake and checked when 
the function returns. The test patch (sorry, really ugly debug printk stuff) 
is attached. The most interesting part is that

if (local->ops->wake_tx_queue)
return;

evaluates to true. The rest rest of the function is therefore always skipped 
for ath9k.

This was noticed when looking at the debug output:

root@lede:/# dmesg|grep ieee80211_propagate_queue_wake
[   20.865005] ieee80211_propagate_queue_wake:248 queue 
[   20.870839] ieee80211_propagate_queue_wake:248 queue 0001
[   20.876661] ieee80211_propagate_queue_wake:248 queue 0002
[   20.882487] ieee80211_propagate_queue_wake:248 queue 0003
[   21.794795] ieee80211_propagate_queue_wake:248 queue 
[   21.800629] ieee80211_propagate_queue_wake:248 queue 0001
[   21.806452] ieee80211_propagate_queue_wake:248 queue 0002
[   21.812278] ieee80211_propagate_queue_wake:248 queue 0003
[   21.830078] ieee80211_propagate_queue_wake:248 queue 
[   21.835918] ieee80211_propagate_queue_wake:248 queue 0001
[   21.841740] ieee80211_propagate_queue_wake:248 queue 0002
[   21.847566] ieee80211_propagate_queue_wake:248 queue 0003
[   23.320814] ieee80211_propagate_queue_wake:248 queue 
[   23.326643] ieee80211_propagate_queue_wake:248 queue 0001
[   23.332469] ieee80211_propagate_queue_wake:248 queue 0002
[   23.338294] ieee80211_propagate_queue_wake:248 queue 0003
[   41.930942] ieee80211_propagate_queue_wake:248 queue 
[   41.940709] ieee80211_propagate_queue_wake:248 queue 0002
[   46.949087] ieee80211_propagate_queue_wake:248 queue 
[   82.999021] ieee80211_propagate_queue_wake:248 queue 

Removing this is enough to fix the problem. And now you will propably say 
"hey, this is not my code". And this is the reason why I have now CC'ed the 
author of 80a83cfc434b ("mac80211: skip netdev queue control with software 
queuing"). This change in ieee80211_propagate_queue_wake is basically breaking 
the (delayed) startup of the ibss netdev queue [1] when the device was offchan 
during the ieee80211_do_open of the ibss interface.

Not sure whether removing it in ieee80211_propagate_queue_wake will have other 
odd side effects with software queuing. Maybe Michal Kazior can tell us if it 
is safe to remove it.

> However, I also don't understand the difference between encrypted and
> unencrypted here.

My best guess is timing. LEDE is not using wpa_supplicant when encryption is 
disabled.

Kind regards,
Sven

[1] https://lkml.kernel.org/r/1978424.XTv2Qph05K@bentoboxdiff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 036fa1d..9a1079f 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -517,6 +517,10 @@ int ieee80211_do_open(struct wireless_dev *wdev, bool coming_up)
 	u32 changed = 0;
 	int res;
 	u32 hw_reconf_flags = 0;
+	const char *ifname = "unknown";
+
+	if (sdata->dev)
+		ifname = sdata->dev->name;
 
 	switch (sdata->vif.type) {
 	case NL80211_IFTYPE_WDS:
@@ -745,11 +749,14 @@ int ieee80211_do_open(struct wireless_dev *wdev, bool coming_up)
 	if (sdata->vif.type == NL80211_IFTYPE_MONITOR ||
 	sdata->vif.type == NL80211_IFTYPE_AP_VLAN) {
 		/* XXX: for AP_VLAN, actually track AP queues */
+		
+		printk("%s:%u netif_tx_start_all_queues %s\n", __func__, __LINE__, ifname);
 		netif_tx_start_all_queues(dev);
 	} else if (dev) {
 		unsigned long flags;
 		int n_acs = IEEE80211_NUM_ACS;
 		int ac;
+		int started = 0;
 
 		if (local->hw.queues < IEEE80211_NUM_ACS)
 			n_acs = 1;
@@ -762,11 +769,20 @@ int ieee80211_do_open(struct wireless_dev *wdev, bool coming_up)
 int ac_queue = sdata->vif.hw_queue[ac];
 
 if (local->queue_stop_reasons[ac_queue] == 0 &&
-skb_queue_empty(>pending[ac_queue]))
+skb_queue_empty(>pending[ac_queue])) {
+		//printk("%s:%u netif_start_subqueue type %u %s\n", __func__, __LINE__, sdata->vif.type, ifname);
 	netif_start_subqueue(dev, ac);
+	started = 1;
+} else {
+		printk("%s:%u NOT netif_start_subqueue type %u stop_reasons %d queue_empty %d %s\n", __func__, __LINE__, sdata->vif.type, local->queue_stop_reasons[ac_queue], skb_queue_empty(>pending[ac_queue]), ifname);
+}
 			}
+		} else {
+			printk("%s:%u NOT netif_start_subqueue type %u cab_queue %d stop_reasons %d queue_empty %d %s\n", __func__, __LINE__, sdata->vif.type, 

Re: Please release/publish iwlwifi-7265D-26.ucode iwlwifi-7265D-25.ucode iwlwifi-7265D-24.ucode iwlwifi-7265D-23.ucode

[Luca Coelho]

On Mon, 2017-03-27 at 16:53 +0500, Artem S. Tashkinov wrote:
> Hi,
> 
> New versions of iwlwifi require the firmware files which have never been 
> released by Intel.
> 
> Please fix this bummer.
> 
> iwlwifi :02:00.0: Direct firmware load for iwlwifi-7265D-26.ucode 
> failed with error -2
> iwlwifi :02:00.0: Direct firmware load for iwlwifi-7265D-25.ucode 
> failed with error -2
> iwlwifi :02:00.0: Direct firmware load for iwlwifi-7265D-24.ucode 
> failed with error -2
> iwlwifi :02:00.0: Direct firmware load for iwlwifi-7265D-23.ucode 
> failed with error -2
> iwlwifi :02:00.0: loaded firmware version 22.361476.0 op_mode iwlmvm

We always keep our mainline driver very close to our development trees. 
In the development trees we are updating the versions periodically and
we don't know which ones we are going to release publicly.

If we don't try to load newer versions when a kernel version is
released, and later decide to publish the newer firmware versions, it
won't work.  This is the explanation. :)

And actually, we try to load these newer firmwares, but if they are not
present, we fall back to the older one.  You can see that we correctly
loaded version 22 (the last line in your traces).

Now, these error messages to look annoying.  But fortunately Luis
Rodriguez is already attempting to fix that in another patch series.

HTH.

--
Cheers,
Luca.

pull-request: iwlwifi 2017-03-29

[Luca Coelho]

Hi Kalle,

Here are some fixes for 4.11.  More details in the tag description.

I have sent this out before and kbuildbot didn't find any issues.

Cheers,
Luca.


The following changes since commit 6be3b6cce1e225f189b68b4e84fc711d19b4277b:

  ath10k: fix incorrect wlan_mac_base in qca6174_regs (2017-03-20 17:11:31 
+0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
tags/iwlwifi-for-kalle-2017-03-29

for you to fetch changes up to 4d339989acd730f17bc814b5ddb9c54e405766b6:

  iwlwifi: mvm: support ibss in dqa mode (2017-03-24 17:15:25 +0200)


iwlwifi fixes for 4.11

Here are three patches intended for 4.11.  The first one is an RCU fix
by Sari.  The second one is a fix for a potential out-of-bounds access
crash by Dan.  And finally, the third and bigger one, is a fix for
IBSS, which has been broken since DQA was enabled in the driver.


Dan Carpenter (1):
  iwlwifi: mvm: writing zero bytes to debugfs causes a crash

Liad Kaufman (1):
  iwlwifi: mvm: support ibss in dqa mode

Sara Sharon (1):
  iwlwifi: mvm: fix accessing fw_id_to_mac_id

 drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c  | 2 ++
 drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 3 ++-
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 2 +-
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c  | 9 ++---
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c   | 7 +--
 5 files changed, 16 insertions(+), 7 deletions(-)

signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2] mac80211: mesh - always do every discovery retry

[Chun-Yeow Yeoh]

I would suggest the following modification of commit messages and
code. Let me know whether this is fine.

-
I would suggest the following edition to the commit message:

Instead of stopping path discovery when a path is established, continue the
attempts to find alternative paths until we hit the dot11MeshHWMPmaxPREQretries
limit. However, this is not a standard behavior and may easily
increase the number of
broadcast PREQ frame in your network. So this feature is turned off by default.

and the remaining are removed due to misleading explanation.

Then, in the mesh_path_timer, I think that only the following is needed:

- if (mpath->flags & MESH_PATH_RESOLVED ||
- (!(mpath->flags & MESH_PATH_RESOLVING))) {
+ if (!multiple_discoveries &&
+(mpath->flags & MESH_PATH_RESOLVED ||
+ (!(mpath->flags & MESH_PATH_RESOLVING {

---
Chun-Yeow

On Wed, Mar 29, 2017 at 4:24 PM, Johannes Berg
 wrote:
> What's the outcome of this? I'm tempted to apply the patch since it's
> optional anyway ...
>
> johannes

Re: Support of rtl8723bs

[Hanno Zulla]

Hi,

it was exciting to see

https://marc.info/?l=linux-wireless=148735587909056=2

So please forgive me for asking about the current state of things.

Kind regards,

Hanno

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Dennis New]

On Wed, 29 Mar 2017 09:34:50 +0200, Johannes Berg wrote:
> On Fri, 2017-03-24 at 21:32 -0400, Dennis New wrote:
> > Ever since I upgraded to the 4.10 kernels (I don't think this
> > behavior existed in the 4.8 series), after I startup my laptop
> > (either from cold boot, or from standby), my wlan0 interface keeps
> > deauthenticating
> 
> > ...
> > 19:23:29 kernel: wlan0: authenticate with 00:11:22:33:44:55
> > 19:23:29 kernel: [ cut here ]
> > 19:23:29 kernel: WARNING: CPU: 0 PID: 18925 at
> > net/mac80211/mlme.c:287 ieee80211_determine_chantype+0x12e/0x380
> 
> This is already indicating a severe problem. I don't know how you end
> up in this situation with b43, since that doesn't have any regulatory
> magic afaict.
> 
> > 19:23:29 kernel: wlan0: associated
> > 
> > 19:24:29 kernel: wlan0: deauthenticating from 00:11:22:33:44:55 by
> > local choice (Reason: 3=DEAUTH_LEAVING)
> 
> I'm convinced that this comes from reg_check_channels().
> 
> The above WARN_ON() already told you that the channel was considered
> invalid.
> 
> Do you know what channel your AP is on?

6

> Perhaps show the output of "iw wlan0 scan dump" while it's
connected (you have 60 seconds :P)

I have been having stable connections for the past few days,
simply by putting a 60 second sleep before starting my wlan0. Although
if I /etc/init.d/net.wlan0 restart it (without the delay), it will
still do this deauth'ing.


> Can you please show the output of "iw list" and "iw phy0 channels"?

"iw phy7 channels":
Band 1:
* 2412 MHz [1] 
  Maximum TX power: 20.0 dBm
  Channel widths:
* 2417 MHz [2] 
  Maximum TX power: 20.0 dBm
  Channel widths:
* 2422 MHz [3] 
  Maximum TX power: 20.0 dBm
  Channel widths:
* 2427 MHz [4] 
  Maximum TX power: 20.0 dBm
  Channel widths:
* 2432 MHz [5] 
  Maximum TX power: 20.0 dBm
  Channel widths:
* 2437 MHz [6] 
  Maximum TX power: 20.0 dBm
  Channel widths:
* 2442 MHz [7] 
  Maximum TX power: 20.0 dBm
  Channel widths:
* 2447 MHz [8] 
  Maximum TX power: 20.0 dBm
  Channel widths:
* 2452 MHz [9] 
  Maximum TX power: 20.0 dBm
  Channel widths:
* 2457 MHz [10] 
  Maximum TX power: 20.0 dBm
  Channel widths:
* 2462 MHz [11] 
  Maximum TX power: 20.0 dBm
  Channel widths:
* 2467 MHz [12] 
  Maximum TX power: 20.0 dBm
  No IR
  Channel widths:
* 2472 MHz [13] 
  Maximum TX power: 20.0 dBm
  No IR
  Channel widths:
* 2484 MHz [14] 
  Maximum TX power: 20.0 dBm
  No IR
  Channel widths: 20MHz


"iw list":
Wiphy phy7
max # scan SSIDs: 4
max scan IEs length: 2285 bytes
max # sched scan SSIDs: 0
max # match sets: 0
max # scan plans: 1
max scan plan interval: -1
max scan plan iterations: 0
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Device supports RSN-IBSS.
Supported Ciphers:
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP-128 (00-0f-ac:4)
* CCMP-256 (00-0f-ac:10)
* GCMP-128 (00-0f-ac:8)
* GCMP-256 (00-0f-ac:9)
Available Antennas: TX 0 RX 0
Supported interface modes:
 * IBSS
 * managed
 * AP
 * AP/VLAN
 * monitor
Band 1:
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm) (no IR)
* 2472 MHz [13] (20.0 dBm) (no IR)
* 2484 MHz [14] (20.0 

Re: [PATCH v3] cfg80211: add set/get link loss profile

[Johannes Berg]

On Mon, 2017-03-06 at 15:54 +0200, Lazar, Alexei Avshalom wrote:
> 
> The supported values are:
[...]

Regardless of the documentation, I think this is a bit fishy. Why
bother with this to start with?

We once had two patches (that we ultimately gave up on) doing something
similar but simply letting userspace decide. This was centered on
mac80211's beacon loss "link loss detection", but could easily be
generalized a little bit more:

https://p.sipsolutions.net/3a594dead519b4b2.txt
https://p.sipsolutions.net/100ce7df53692daa.txt

Perhaps with some adjustments such an approach would be workable for
you?

johannes

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Johannes Berg]

> > This code was designed for regulatory changes, but the WARN_ON()
> > indicates that we got connected on a channel that we think isn't
> > actually usable. We quite possibly should reject that connection
> > there, but it seems to me it should've been rejected elsewhere
> > already...?
> 
> But this is prior to connection, right? This warning happens upon
> authenticate.

Yeah the warning happens in authentication.

> So in nl80211_authenticate() we do:
> 
> chan = nl80211_get_valid_chan(>wiphy,
>     info->attrs[NL80211_ATTR_WIPHY_FREQ]);
> 
> and in cfg80211_mlme_auth():
> 
> req.bss = cfg80211_get_bss(>wiphy, chan, bssid, ssid, ssid_len,
>      IEEE80211_BSS_TYPE_ESS,
>      IEEE80211_PRIVACY_ANY);

That might not be what's going on - the OP said he was getting this
with iw, which doesn't go through nl80211_authenticate() but
nl80211_connect().

> After that the chain is:
> 
> ieee80211_mgd_auth() ->
>   ieee80211_prep_connection() ->
>   ieee80211_prep_channel() ->
>   ieee80211_determine_chantype()

And somehow that determines that even a 20MHz no-HT channel isn't
valid.

johannes

Re: [PATCH v3 4/4] mac80211-hwsim: add length checks before allocating skb.

[Johannes Berg]

On Thu, 2017-03-23 at 16:26 -0700, gree...@candelatech.com wrote:
> From: Ben Greear 
> 
> Modify the receive-from-user-space logic to do length
> and 'is-down' checks before trying to allocate an skb.
> 
> And, if we are going to ignore the pkt due to radio idle,
> then do not return an error code to user-space.  User-space
> cannot reliably know exactly when a radio is idle or not.
> 
Makes sense, but doesn't apply separately.

johannes

Re: [PATCH v3 3/4] mac80211-hwsim: add rate-limited debugging for rx-netlink

[Johannes Berg]

On Thu, 2017-03-23 at 16:26 -0700, gree...@candelatech.com wrote:
> From: Ben Greear 
> 
> This makes it easier to understand why wmediumd (or similar)
> is getting errors when sending frames to the kernel.
> 
> Signed-off-by: Ben Greear 
> ---
>  drivers/net/wireless/mac80211_hwsim.c | 55
> +++
>  1 file changed, 43 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/net/wireless/mac80211_hwsim.c
> b/drivers/net/wireless/mac80211_hwsim.c
> index 234df8c..84dcddf 100644
> --- a/drivers/net/wireless/mac80211_hwsim.c
> +++ b/drivers/net/wireless/mac80211_hwsim.c
> @@ -137,6 +137,12 @@ static int regtest = HWSIM_REGTEST_DISABLED;
>  module_param(regtest, int, 0444);
>  MODULE_PARM_DESC(regtest, "The type of regulatory test we want to
> run");
>  
> +DEFINE_RATELIMIT_STATE(hwsim_ratelimit_state, 5 * HZ, 10);
> +int hwsim_ratelimit(void)
> +{
> + return __ratelimit(_ratelimit_state);
> +}
> +
>  static const char *hwsim_alpha2s[] = {
>   "FI",
>   "AL",
> @@ -1649,7 +1655,7 @@ static int mac80211_hwsim_config(struct
> ieee80211_hw *hw, u32 changed)
>  
>   if (conf->chandef.chan)
>   wiphy_debug(hw->wiphy,
> - "%s (freq=%d(%d - %d)/%s idle=%d ps=%d
> smps=%s)\n",
> + "%s (chandef-chan freq=%d(%d - %d)/%s
> idle=%d ps=%d smps=%s)\n",
>   __func__,
>   conf->chandef.chan->center_freq,
>   conf->chandef.center_freq1,
> @@ -1660,7 +1666,7 @@ static int mac80211_hwsim_config(struct
> ieee80211_hw *hw, u32 changed)
>   smps_modes[conf->smps_mode]);
>   else
>   wiphy_debug(hw->wiphy,
> - "%s (freq=0 idle=%d ps=%d smps=%s)\n",
> + "%s (no-chandef-chan freq=0 idle=%d
> ps=%d smps=%s)\n",

This seems unrelated?

johannes

Re: [PATCH v3 2/4] mac80211-hwsim: remove dmesg spam about get-survey.

[Johannes Berg]

On Thu, 2017-03-23 at 16:26 -0700, gree...@candelatech.com wrote:
> From: Ben Greear 
> 
> This message just fills up dmesg and/or kernel logs and does
> not provide any useful information.
> 
Agree, applied.

johannes

Re: [PATCH v3 1/4] mac80211-hwsim: notify user-space about channel change.

[Johannes Berg]

> + if (data->center_freq2)
> + if (nla_put_u32(skb, HWSIM_ATTR_CENTER_FREQ2, data-
> >center_freq2))
> + goto nla_put_failure;
> 

That could be simplified (but isn't really interesting)

> + * @HWSIM_ATTR_CENTER_FREQ2: Configured center-freq-2.  Not reported
> if value is zero.

The value 0 really just means "unused" - so this should say "if used"
or so.

> + * @HWSIM_ATTR_CH_WIDTH: Configured channel width.

That should point to  nl80211_chan_width I guess.

Anyway, all of that is minor. The biggest problem I have with this
patch upon close review is that it only handles one case, and actually
ties that case to the nl80211 API.

hwsim also can deal with channel contexts already, is there much point
in making the userspace API ignorant of that?

johannes

Re: [PATCH v2] mac80211: Use rssi_threshold even though user_mpm=1

[Johannes Berg]

On Mon, 2017-03-27 at 05:53 +0900, Masashi Honma wrote:
> On 2017/03/17 14:59, Masashi Honma wrote:
> > Previously the meshcfg.rssi_threshold did not work with user_mpm=1.
> > 
> > Signed-off-by: Masashi Honma 
> 
> Is there any comment ?

I just applied the other patch "drop new node"

johannes

Re: [PATCH 2/2] mac80211: Drop new node with weak power

[Johannes Berg]

> But we still needs this patch for a special case on SAE. Some
> hardware can use hardware encryption for mesh SAE. Then the hardware
> has a limitation of key registration. For example, some hardware
> could only save keys for 8 stations. So we need to drop stations
> itself with weak signal instead of the pathes to its.

Fair enough. I've added that to the ocmmit message and applied the
patch.

johannes

Re: [PATCH v2] mac80211: mesh - always do every discovery retry

[Johannes Berg]

What's the outcome of this? I'm tempted to apply the patch since it's
optional anyway ...

johannes

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Arend Van Spriel]

On 29-3-2017 9:46, Johannes Berg wrote:
> 
 19:23:29 kernel: wlan0: authenticate with 00:11:22:33:44:55
 19:23:29 kernel: [ cut here ]
 19:23:29 kernel: WARNING: CPU: 0 PID: 18925 at
 net/mac80211/mlme.c:287 ieee80211_determine_chantype+0x12e/0x380
>>
>> 284  while (!cfg80211_chandef_usable(sdata->local->hw.wiphy,
>> chandef,
>> 285  tracking ? 0 :
>> 286 IEEE80211_CHAN_DISABLED
>> )) {
>> 287  if (WARN_ON(chandef->width ==
>> NL80211_CHAN_WIDTH_20_NOHT)) {
>> 288  ret = IEEE80211_STA_DISABLE_HT |
>> 289IEEE80211_STA_DISABLE_VHT;
>> 290  break;
>> 291  }
>>
>>> This is already indicating a severe problem. I don't know how you
>>> end
>>> up in this situation with b43, since that doesn't have any
>>> regulatory
>>> magic afaict.
>>
>> The only way this WARN_ON can kick in is below so may be interesting
>> to log the three variables checked in 'if' statement.
> 
> Yeah we should probably extend the WARN_ON() to a WARN() with that
> information.
> 
>> Could it be a radar channel and it's waiting for CAC timeout or
>> whatever the term is ;-) ?
> 
> No. Not even tongue-in-cheek :-)
> This code was designed for regulatory changes, but the WARN_ON()
> indicates that we got connected on a channel that we think isn't
> actually usable. We quite possibly should reject that connection there,
> but it seems to me it should've been rejected elsewhere already...?

But this is prior to connection, right? This warning happens upon
authenticate. So in nl80211_authenticate() we do:

chan = nl80211_get_valid_chan(>wiphy,
  info->attrs[NL80211_ATTR_WIPHY_FREQ]);

and in cfg80211_mlme_auth():

req.bss = cfg80211_get_bss(>wiphy, chan, bssid, ssid, ssid_len,
   IEEE80211_BSS_TYPE_ESS,
   IEEE80211_PRIVACY_ANY);

After that the chain is:

ieee80211_mgd_auth() ->
ieee80211_prep_connection() ->
ieee80211_prep_channel() ->
ieee80211_determine_chantype()

Regards,
Arend

Re: [REGRESSION] mac80211: IBSS vif queue stopped when started after 11s vif

[Johannes Berg]

Hi Sven,


> But I could be completely wrong about it. It would therefore be
> interesting for me to know who would be responsible to start the
> queues when ieee80211_do_open rejected it for IBSS.

Well, once ieee80211_offchannel_return() is called, that should do the
needful and end up in ieee80211_propagate_queue_wake().

Can you check what the IBSS vif's queues are (vif->hw_queue[...])?

However, I also don't understand the difference between encrypted and
unencrypted here.

johannes

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Arend Van Spriel]

On 29-3-2017 9:34, Johannes Berg wrote:
> On Fri, 2017-03-24 at 21:32 -0400, Dennis New wrote:
>> Ever since I upgraded to the 4.10 kernels (I don't think this
>> behavior existed in the 4.8 series), after I startup my laptop
>> (either from cold boot, or from standby), my wlan0 interface keeps
>> deauthenticating
> 
>> ...
>> 19:23:29 kernel: wlan0: authenticate with 00:11:22:33:44:55
>> 19:23:29 kernel: [ cut here ]
>> 19:23:29 kernel: WARNING: CPU: 0 PID: 18925 at
>> net/mac80211/mlme.c:287 ieee80211_determine_chantype+0x12e/0x380

284 while (!cfg80211_chandef_usable(sdata->local->hw.wiphy, chandef,
285 tracking ? 0 :
286IEEE80211_CHAN_DISABLED)) {
287 if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) {
288 ret = IEEE80211_STA_DISABLE_HT |
289   IEEE80211_STA_DISABLE_VHT;
290 break;
291 }

> This is already indicating a severe problem. I don't know how you end
> up in this situation with b43, since that doesn't have any regulatory
> magic afaict.

The only way this WARN_ON can kick in is below so may be interesting to
log the three variables checked in 'if' statement.

161 chandef->chan = channel;
162 chandef->width = NL80211_CHAN_WIDTH_20_NOHT;
163 chandef->center_freq1 = channel->center_freq;
164 chandef->center_freq2 = 0;
165
166 if (!ht_cap || !ht_oper || !sta_ht_cap.ht_supported) {
167 ret = IEEE80211_STA_DISABLE_HT | IEEE80211_STA_DISABLE_VHT;
168 goto out;
169 }
170
171 chandef->width = NL80211_CHAN_WIDTH_20;

>> 19:23:29 kernel: wlan0: associated
>>
>> 19:24:29 kernel: wlan0: deauthenticating from 00:11:22:33:44:55 by
>> local choice (Reason: 3=DEAUTH_LEAVING)
>>
> 
> I'm convinced that this comes from reg_check_channels().
> 
> The above WARN_ON() already told you that the channel was considered
> invalid.
> 
> Do you know what channel your AP is on? Perhaps show the output of "iw
> wlan0 scan dump" while it's connected (you have 60 seconds :P)
> 
> Can you please show the output of "iw list" and "iw phy0 channels"?

Could it be a radar channel and it's waiting for CAC timeout or whatever
the term is ;-) ?

Regards,
Arend

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

[Johannes Berg]

On Fri, 2017-03-24 at 21:32 -0400, Dennis New wrote:
> Ever since I upgraded to the 4.10 kernels (I don't think this
> behavior existed in the 4.8 series), after I startup my laptop
> (either from cold boot, or from standby), my wlan0 interface keeps
> deauthenticating

> ...
> 19:23:29 kernel: wlan0: authenticate with 00:11:22:33:44:55
> 19:23:29 kernel: [ cut here ]
> 19:23:29 kernel: WARNING: CPU: 0 PID: 18925 at
> net/mac80211/mlme.c:287 ieee80211_determine_chantype+0x12e/0x380

This is already indicating a severe problem. I don't know how you end
up in this situation with b43, since that doesn't have any regulatory
magic afaict.

> 19:23:29 kernel: wlan0: associated
> 
> 19:24:29 kernel: wlan0: deauthenticating from 00:11:22:33:44:55 by
> local choice (Reason: 3=DEAUTH_LEAVING)
> 

I'm convinced that this comes from reg_check_channels().

The above WARN_ON() already told you that the channel was considered
invalid.

Do you know what channel your AP is on? Perhaps show the output of "iw
wlan0 scan dump" while it's connected (you have 60 seconds :P)

Can you please show the output of "iw list" and "iw phy0 channels"?

johannes

Re: [PATCH for-4.11 2/2] cfg80211: check rdev resume callback only for registered wiphy

[Johannes Berg]

On Tue, 2017-03-28 at 09:11 +0100, Arend van Spriel wrote:
> We got the following use-after-free KASAN report:
> 
[...]

Applied.

johannes

Re: [PATCH v2] nfc: don't be making arch specific unaligned decisions at driver level.

[Samuel Ortiz]

Hi Paul,

On Tue, Mar 28, 2017 at 06:55:26PM -0400, Paul Gortmaker wrote:
> On Mon, Jan 9, 2017 at 12:52 PM, Paul Gortmaker
>  wrote:
> > Currently ia64 fails building allmodconfig with variations of:
> >
> >In file included from drivers/nfc/nxp-nci/i2c.c:39:0:
> >./include/linux/unaligned/access_ok.h:62:29: error: redefinition of 
> > ‘put_unaligned_be64’
> > static __always_inline void put_unaligned_be64(u64 val, void *p)
> 
> Hi Samuel,
> 
> Do you require changes on this commit, or are you happy to queue it as is?
> Looking at the NFC git history it seems like you are the right person to ask.
I will queue it later this week, sorry for the lag.

Cheers,
Samuel.

Re: [PATCH for-4.11 2/2] cfg80211: check rdev resume callback only for registered wiphy

[Johannes Berg]

On Tue, 2017-03-28 at 16:46 +0200, Arend Van Spriel wrote:
> 
> On 28-3-2017 16:25, Johannes Berg wrote:
> > 
> > > > > - if (rdev->ops->resume) {
> > > > > - rtnl_lock();
> > > > > - if (rdev->wiphy.registered)
> > > > > - ret = rdev_resume(rdev);
> > > > > - rtnl_unlock();
> > > > > - }
> > > > > + rtnl_lock();
> > > > > + if (rdev->wiphy.registered && rdev->ops->resume)
> > > > > + ret = rdev_resume(rdev);
> > > > > + rtnl_unlock();
> > > > 
> > > > Hmm? Commit message seems ... old perhaps?
> > > 
> > > Hmmm, why? Before the patch rdev->ops was accessed before
> > > checking
> > > rdev->wiphy.registered. When rdev->wiphy.registers is false we no
> > > longer access rdev->ops after the patch. So a driver doing a
> > > wiphy_unregister() can safely kfree() the callback struct after
> > > it.
> > 
> > Oh, right. Looks like I misinterpreted things.
> 
> So apparently my choice of words was poor. Do you want me to
> rephrase?

Nah, don't worry. When I apply it I'll re-read and see if I just
confused myself or if it makes sense to reword a bit.

johannes

Re: Formatting of db.txt

[Johannes Berg]

On Tue, 2017-03-28 at 21:49 -0600, Matthew Stanger wrote:
> I also notice when I run 'iw reg get' it still shows the format which
> seems to support the antenna gain (N/A):
> country US: DFS-FCC
> (2402 - 2472 @ 40), (N/A, 25), (N/A)
> (5170 - 5250 @ 80), (N/A, 16), (N/A)
> (5250 - 5330 @ 80), (N/A, 16), (N/A)
> (5490 - 5730 @ 160), (N/A, 16), (N/A)
> (5735 - 5835 @ 80), (N/A, 23), (N/A)
> 
> If this isn't supported by the .db anymore then maybe this format
> should be updated in configuration utility.

Not really - this tool should still support older kernels.

johannes

Re: [PATCH v6 00/10] ath10k: sdio support

[Kalle Valo]

Erik Stromdahl  writes:

> Please let me know if there is anything I can help with...
>
> I will test the patches as soon as v7 is submitted.

Yeah, please pay extra attention to the upcoming v7 because I'm sure I
will break something. So careful review and testing is a good idea.

-- 
Kalle Valo