[PATCH 0/6] Constant Time Memory Comparisons Are Important

Whenever you're comparing two MACs, it's important to do this using crypto_memneq instead of memcmp. With memcmp, you leak timing information, which could then be used to iteratively forge a MAC. This is far too basic of a mistake for us to have so pervasively in the year 2017, so let's begin

[PATCH 6/6] mac80211/wpa: use constant time memory comparison for MACs

Otherwise, we enable all sorts of forgeries via timing attack. Signed-off-by: Jason A. Donenfeld Cc: Johannes Berg Cc: linux-wireless@vger.kernel.org Cc: sta...@vger.kernel.org --- net/mac80211/wpa.c | 9 + 1 file changed, 5 insertions(+), 4

Re: Question on setting key right after the EAPOL 4/4 is sent.

2017-06-09 22:18 GMT+02:00 Ben Greear : > On 06/09/2017 01:01 PM, Johannes Berg wrote: >> >> On Fri, 2017-06-09 at 06:46 -0700, Ben Greear wrote: >> However, the solution is far simpler! Once you have nl80211 PAE transport, you can easily even set the key before

LINKMODE & OPERSTATE thoughts

Hi Johannes, Let me start a separate thread on this: Also, while we're on this subject. Should the kernel auto-manage the LINKMODE and OPERSTATE flags? It would seem that it already has the information to do so, and having userspace manage this just introduces another source of latency /

Re: Question on setting key right after the EAPOL 4/4 is sent.

Hi Denis, Btw, now I finally remembered what this also fixes - the whole bridging mess :-) When we have this, we no longer need hostapd/wpas to be aware of bridging and capturing frames beneath the bridge - something that's actually a regression in Linux at some point. > Do you have any thoughts

Re: [PATCH net] mac80211: free netdev on dev_alloc_name() error

From: Johannes Berg Date: Fri, 9 Jun 2017 21:33:09 +0200 > From: Johannes Berg > > The change to remove free_netdev() from ieee80211_if_free() > erroneously didn't add the necessary free_netdev() for when > ieee80211_if_free() is called

[PATCH net] mac80211: free netdev on dev_alloc_name() error

From: Johannes Berg The change to remove free_netdev() from ieee80211_if_free() erroneously didn't add the necessary free_netdev() for when ieee80211_if_free() is called directly in one place, rather than as the priv_destructor. Add the missing call. Fixes: cf124db566e6

Re: [PATCH v2 1/3] ath10k: Use complete VHT chan width for 160MHz workaround

On 06/09/2017 04:07 AM, Sven Eckelmann wrote: From: Ben Greear The ath10k firmware doesn't announce its VHT channel width capabilities in the vht_cap information from the "service ready event" arguments. The driver must therefore check whether the 160MHz short GI bit

Re: Question on setting key right after the EAPOL 4/4 is sent.

On 06/09/2017 12:28 AM, Johannes Berg wrote: On Thu, 2017-06-08 at 19:07 -0500, Denis Kenzior wrote: Fundamentally there is a race between the genl/nl80211 socket to the kernel and the PAE socket that handles the authentication aspects. I think the only way to fix this is to make sure that

Re: Question on setting key right after the EAPOL 4/4 is sent.

Hi Johannes, We've actually discussed doing precisely this, for - among other things - this reason. Just nobody stepped up yet to propose the necessary APIs and do the remaining work to use it etc. Do you have any thoughts on what the operations should look like or do you want me to take a

[PATCH V3 3/9] nl80211: add authorized flag to CONNECT event

When the driver supports offloading of the PTK/GTK handshakes completion of that during connect changes the layer 2 control port state to authorized. This patch allows the driver to pass that state in cfg80211_connect_done() resulting in adding the new flag NL80211_ATTR_PORT_AUTHORIZED in the

[PATCH V3 9/9] brcmfmac: provide port authorized state in CONNECT event

Fill struct cfg80211_connection_params::authorized field according the supplicant state received from the device. Signed-off-by: Arend van Spriel --- .../broadcom/brcm80211/brcmfmac/cfg80211.c | 27 +- 1 file changed, 16 insertions(+),

[PATCH V3 8/9] brcmfmac: switch to using cfg80211_connect_done()

The driver used cfg80211_connect_result() which is basically a wrapper around cfg80211_connect_done() passing a subset of the information that can be passed. For upcoming functionality this is not sufficient so switching to use cfg80211_connect_done(). Reviewed-by: Hante Meuleman

[PATCH V3 2/9] cfg80211: support 4-way handshake offloading for 802.1X

From: Avraham Stern Add API for setting the PMK to the driver. For FT support, allow setting also the PMK-R0 Name. This can be used by drivers that support 4-Way handshake offload while IEEE802.1X authentication is managed by upper layers. Signed-off-by: Avraham Stern

[PATCH V3 0/9] nl80211: add support for PTK/GTK handshake offload

This patch series add support for offloading the PTK/GTK handshakes for WPA/WPA2-Personal and 802.1X in nl80211. The nl80211 patches have been posted as RFC. Compared to that RFC this series also adds a new flag ATTR_PORT_AUTHORIZED used in both CONNECT and ROAM notifications to indicate the

[PATCH V3 1/9] cfg80211: support 4-way handshake offloading for WPA/WPA2-PSK

From: Eliad Peller Let drivers advertise support for station-mode 4-way handshake offloading with a new NL80211_EXT_FEATURE_4WAY_HANDSHAKE_STA_PSK flag. Extend use of NL80211_ATTR_PMK attribute indicating it might be passed as part of NL80211_CMD_CONNECT command, and contain

[PATCH V3 7/9] brcmfmac: support 4-way handshake offloading for 802.1X

Adding callbacks for PMK provisioning. If firmware supports offloading it is indicated to user-space that 802.1X offload is supported. Signed-off-by: Arend van Spriel --- .../broadcom/brcm80211/brcmfmac/cfg80211.c | 61 --

[PATCH V3 4/9] nl80211: add authorized flag to ROAM event

From: Avraham Stern Drivers that initiate roaming while being connected to a network that uses 802.1X authentication need to inform user space if 802.1X authentication is further required after roaming. For example, when using the Fast transition protocol, roaming within

[PATCH V3 6/9] brcmfmac: support 4-way handshake offloading for WPA/WPA2-PSK

From: Arend van Spriel The firmware may have supplicant code built-in. This is detected by the driver and indicated in the wiphy features flags. User-space can use this flag to determine whether or not to provide the pre-shared key material in the nl80211 CONNECT command.

[PATCH] mwifiex: fixes the trivial print

We have always met the unused log be printed as following. ... [23193.523182] mwifiex_pcie :01:00.0: mwifiex_get_cfp: cannot find cfp by band 2& channel=13 freq=0 [23378.633684] mwifiex_pcie :01:00.0: mwifiex_get_cfp: cannot find cfp by band 2& channel=13 freq=0 Maybe that's

Re: [PATCH V5 1/3] brcmfmac: add support multi-scheduled scan

Arend van Spriel writes: > From: Arend Van Spriel > > This change adds support for multi-scheduled scan in the driver. It > currently relies on g-scan support in firmware and will set struct > wiphy::max_sched_scan_reqs accordingly.

Re: [PATCH V2 0/9] nl80211: add support for PTK/GTK handshake offload

On 6/9/2017 12:59 PM, Johannes Berg wrote: On Fri, 2017-06-09 at 12:34 +0200, Arend van Spriel wrote: Not trying to change your opinion ;-). Just getting it all clear. As a matter of fact I already have my wpa_s use the offload without any debug/config option. As brcmfmac can use override to

[PATCH V5 3/3] brcmfmac: add scheduled scan support for specified BSSIDs

From: Arend Van Spriel Add support to handle scheduled scan request containing BSSID in the matchsets. The firmware can send event upon finding BSSIDs and SSIDs. To get these in one event the bit REPORT_SEPARATELY needed to be removed from the flags in

[PATCH V5 1/3] brcmfmac: add support multi-scheduled scan

From: Arend Van Spriel This change adds support for multi-scheduled scan in the driver. It currently relies on g-scan support in firmware and will set struct wiphy::max_sched_scan_reqs accordingly. This is limited to 16 concurrent requests. The firmware currently

[PATCH V5 2/3] brcmfmac: add mutex to protect pno requests

From: Arend Van Spriel The request references kept in pno are accessed in user-space context and in firmware event handler context. As such we need to protect it with a lock. As both context allow sleep a mutex seems appropriate. Reviewed-by: Hante Meuleman

[PATCH v2 2/3] ath10k: Configure rxnss_override for 10.4 firmware.

From: Ben Greear QCA9984 hardware can do 4x4 at 80Mhz, but only 2x2 at 160Mhz. First, report this to user-space by setting the max-tx-speed and max-rx-speed vht capabilities. Second, if the peer rx-speed is configured, and if we are in 160 or 80+80 mode, and the peer

[PATCH v2 1/3] ath10k: Use complete VHT chan width for 160MHz workaround

From: Ben Greear The ath10k firmware doesn't announce its VHT channel width capabilities in the vht_cap information from the "service ready event" arguments. The driver must therefore check whether the 160MHz short GI bit is set and whether the driver still doesn't set

[PATCH v2 3/3] ath10k: Set rxnss_override for QCA9888

QCA9888 supports VHT80 with 2x2. But it only support 1x1 with VHT160 or VHT80+80. Inform userspace and the the QCA firmware about that limitation whenever VHT80+80 or VHT160 is configured. Signed-off-by: Sven Eckelmann --- v2: - new patch

Re: [PATCH V2 0/9] nl80211: add support for PTK/GTK handshake offload

On Fri, 2017-06-09 at 12:34 +0200, Arend van Spriel wrote: > Not trying to change your opinion ;-). Just getting it all clear. As > a matter of fact I already have my wpa_s use the offload without any  > debug/config option. As brcmfmac can use override to disable > firmware features I also do

Re: [PATCH V2 0/9] nl80211: add support for PTK/GTK handshake offload

On 6/9/2017 11:08 AM, Johannes Berg wrote: Hi Arend, Sorry about the delay. No problem. Then you have to support NEW_KEY (AP case) and then using NEW_KEY to detect whether or not a wpa_s configuration option to not use offloaded 4-way-HS can be used will not work correctly. I don't

Re: ath10k: Configure rxnss_override for 10.4 firmware.

On Mittwoch, 15. Februar 2017 01:26:58 CEST Kalle Valo wrote: > Ben Greear wrote: > > From: Ben Greear > > > > QCA9984 hardware can do 4x4 at 80Mhz, but only 2x2 at 160Mhz. [] > Does not apply: > > error: patch failed:

Re: [PATCH 07/11] wireless: ipw2x00: convert to use DRIVER_ATTR_RW

On Fri, Jun 09, 2017 at 12:25:44PM +0300, Kalle Valo wrote: > Greg Kroah-Hartman writes: > > > We are trying to get rid of DRIVER_ATTR(), and the ipw2x00 driver's > > attributes can be trivially changed to use DRIVER_ATTR_RW(). > > > > Cc: Stanislav Yakovlev

Re: [PATCH 07/11] wireless: ipw2x00: convert to use DRIVER_ATTR_RW

Greg Kroah-Hartman writes: > We are trying to get rid of DRIVER_ATTR(), and the ipw2x00 driver's > attributes can be trivially changed to use DRIVER_ATTR_RW(). > > Cc: Stanislav Yakovlev > Cc: Kalle Valo > Cc:

Re: [PATCH 05/14] mwifiex: re-register wiphy across reset

On Mon, 2017-06-05 at 18:54 +0300, Kalle Valo wrote: > > BTW, since you're taking an interest in this code now, can I > > trouble you with a question? Looking at mwifiex_uninit_sw() (after > > this patchset), you can see a loop like this: > > > > /* Stop data */ > > for (i = 0; i

Re: [PATCH V2 0/9] nl80211: add support for PTK/GTK handshake offload

Hi Arend, Sorry about the delay. > > Then you have to support NEW_KEY (AP case) and then using NEW_KEY > > to > > detect whether or not a wpa_s configuration option to not use > > offloaded > > 4-way-HS can be used will not work correctly. > > > > I don't really see that this is a sensible

[PATCH 07/11] wireless: ipw2x00: convert to use DRIVER_ATTR_RW

We are trying to get rid of DRIVER_ATTR(), and the ipw2x00 driver's attributes can be trivially changed to use DRIVER_ATTR_RW(). Cc: Stanislav Yakovlev Cc: Kalle Valo Cc: Cc: Signed-off-by:

Re: [linux-wireless] [mac80211] Does IEEE80211_IBSS_MAX_STA_ENTRIES (in net/mac80211/ibss.c) work?

On Thu, 2017-06-08 at 12:50 +0800, Xuebing Wang wrote: > Hi community, > > Does IEEE80211_IBSS_MAX_STA_ENTRIES (in net/mac80211/ibss.c) work? Yes, as far as it's supposed to :) > I hard-code it to be 2 (from original 128), and update kernel for > one node, and start IBSS network with 5 nodes.

Re: [PATCH] wireless: wlcore: spi: remove unnecessary variable

"Gustavo A. R. Silva" writes: > Remove unnecessary variable and refactor the code. > > Addresses-Coverity-ID: 1365000 > Signed-off-by: Gustavo A. R. Silva I'll remove "wireless:" from the prefix. -- Kalle Valo

Re: Question on setting key right after the EAPOL 4/4 is sent.

On Thu, 2017-06-08 at 19:07 -0500, Denis Kenzior wrote: > > > Fundamentally there is a race between the genl/nl80211 socket to > > > the > > > kernel and the PAE socket that handles the authentication > > > aspects.  I > > > think the only way to > > > fix this is to make sure that PAE flows over

Re: Wifi-Event for when initial 4-way completes?

Hello Ben, Yes, you are right. There is a case when wpa supplicant is in connected state but the last EAPOL to AP was lost. Client won't be able to communicate and AP will deauthenticate after a while or not. It's easily reproducible with a frame corrupter patch I have sent some time