Re: SAE authentication frames in client mode

On Thu, Sep 20, 2018 at 11:12 AM Jouni Malinen wrote: > On Thu, Sep 20, 2018 at 12:55:10AM +0200, Mathy Vanhoef wrote: > > That figure only appears to be an example. It doesn't say an exchange > > must ("shall") follow that order. So I don't see where the standard >

Re: SAE authentication frames in client mode

> > If that is the case, this would conflict with the SAE handshake as > > defined in the 802.11-2016 standard. That's because when the AP > > receives a Commit frame, the AP is allowed to send both a Commit and > > Confirm frame (see 12.4.8.6.3). So according to the standard, the > > client must

SAE authentication frames in client mode

Hello, It seems that in client mode, the Linux kernel only accepts an authentication frame after sending one itself. Is this interpretation correct? If that is the case, this would conflict with the SAE handshake as defined in the 802.11-2016 standard. That's because when the AP receives a

Re: [PATCH] mac80211: ignore SA Query Requests with unknown payload data

> I also think we shouldn't necessarily punt too short or otherwise > malformed frames to userspace, what's the point? We currently > drop/ignore those, and can continue to do so afaict? Agreed, we should drop too short or malformed frames. > An easier alternative might be to push

[PATCH] mac80211: ignore SA Query Requests with unknown payload data

Operating Channel Information (OCI) element as payload data. The kernel should ignore these frames, since it does not know how to properly handle them. Instead, let userspace process these frames. Signed-off-by: Mathy Vanhoef --- For background on Operating Channel Validation, see: https

Re: [PATCH 4/7] brcmfmac: obtain feature info using 'cap' firmware command

On Fri, Jan 1, 2016 at 8:05 AM, Arend van Spriel <ar...@broadcom.com> wrote: > On 12/29/2015 09:58 PM, Mathy Vanhoef wrote: >> >> On Mon, Dec 14, 2015 at 2:39 PM, Arend van Spriel <ar...@broadcom.com> >> wrote: >>> >>> Several features in the d

Re: [PATCH V2 4/7] brcmfmac: obtain feature info using 'cap' firmware command

for 43362 */ > + if (drvr->bus_if->chip == BRCM_CC_43362_CHIP_ID) > + ifp->drvr->feat_flags &= ~BIT(BRCMF_FEAT_MBSS); > brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_RSDB, "rsdb_mode"); > brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_TDLS, "tdls_enable"); > > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Reviewed-by: Mathy Vanhoef <vanho...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/7] brcmfmac: Add support for scheduled scan mac randomization

On Mon, Dec 14, 2015 at 2:39 PM, Arend van Spriel wrote: > From: Hante Meuleman > > Scheduled scan be requested to use mac randomization. This patch > checks the flags and enables the randomization if desired. The driver also needs to advertise support

Re: [PATCH 4/7] brcmfmac: obtain feature info using 'cap' firmware command

On Mon, Dec 14, 2015 at 2:39 PM, Arend van Spriel wrote: > Several features in the driver directly map to a firmware feature > listed in response of the 'cap' firmware command. For those features > this response will be examined instead of attempting individual > firmware

[PATCH] mac80211: properly set CCK flag in radiotap

Fix a regression introduced by commit a5e70697d0c4 (mac80211: add radiotap flag and handling for 5/10 MHz) where the IEEE80211_CHAN_CCK channel type flag was incorrectly replaced by the IEEE80211_CHAN_OFDM flag. This commit fixes that by using the CCK flag again. Signed-off-by: Mathy Vanhoef

[PATCH] brcmfmac: kill URB when request timed out

Kill the submitted URB in brcmf_usb_dl_cmd if the request timed out. This assures the URB is never submitted twice. It also prevents a possible use-after-free of the URB transfer buffer if a timeout occurs. Signed-off-by: Mathy Vanhoef vanho...@gmail.com --- For a discussion about this patch

Re: [PATCH] brcmfmac: unlink URB when request timed out

Using usb_kill_urb() instead of usb_unlink_urb() seems to work without any problems. On 11/11/2014 06:05 AM, Arend van Spriel wrote: On 10-11-14 17:08, Mathy Vanhoef wrote: On 11/10/2014 06:18 AM, Arend van Spriel wrote: On 09-11-14 19:10, Mathy Vanhoef wrote: From: Mathy Vanhoef vanho

Re: [PATCH] brcmfmac: unlink URB when request timed out

On 11/11/2014 01:00 PM, Arend van Spriel wrote: On 11-11-14 18:35, Mathy Vanhoef wrote: Using usb_kill_urb() instead of usb_unlink_urb() seems to work without any problems. Ok, as usb_kill_urb() assures the completion handler is called there is no need to check the ctl_completed flag, ie

Re: [PATCH] brcmfmac: unlink URB when request timed out

On 11/10/2014 04:08 AM, Oliver Neukum wrote: On Sun, 2014-11-09 at 13:10 -0500, Mathy Vanhoef wrote: From: Mathy Vanhoef vanho...@gmail.com Unlink the submitted URB in brcmf_usb_dl_cmd if the request timed out. This assures the URB is never submitted twice, preventing a driver crash. Hi

Re: [PATCH] brcmfmac: unlink URB when request timed out

On 11/10/2014 06:18 AM, Arend van Spriel wrote: On 09-11-14 19:10, Mathy Vanhoef wrote: From: Mathy Vanhoef vanho...@gmail.com Unlink the submitted URB in brcmf_usb_dl_cmd if the request timed out. This assures the URB is never submitted twice, preventing a driver crash. Hi Mathy, What