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

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 > >

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

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

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

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,

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

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,

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

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),

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

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

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

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: > > > >

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

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,

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

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)

[RESEND] ath9k failure to authenticate WPA2 client mode

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

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

> > >   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

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

> 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

Re: compile driver for rtl8192su

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 .

Re: compile driver for rtl8192su

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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(+)

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

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

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

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

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

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) + *

Re: Support of rtl8723bs

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

compile driver for rtl8192su

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

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

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

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

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. >

Get Number of Pending Wifi Frames in Mesh ALM calc

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

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

> 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

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

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

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

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

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

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

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

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

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

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:

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

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

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

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 >

pull-request: iwlwifi 2017-03-29

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

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

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

Re: Support of rtl8723bs

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

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

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

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

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

> > 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...? > >

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

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

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

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 > --- >  

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

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.

> + 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

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

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

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

> 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

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

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

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 >> >>

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

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

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

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 >>

Re: wlan0 keeps deauthenticating DEAUTH_LEAVING about every minute

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:

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

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.

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: >

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

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); >

Re: Formatting of db.txt

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) >

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

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