linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arend Van Spriel <arend.vanspriel@broadcom.com>
To: Jouni Malinen <j@w1.fi>, Eric Blau <eblau@eblau.com>
Cc: hostap@lists.infradead.org,
	linux-wireless <linux-wireless@vger.kernel.org>,
	Johannes Berg <johannes@sipsolutions.net>,
	Denis Kenzior <denkenz@gmail.com>
Subject: Re: Kernel oops / WiFi connection failure with wpa_supplicant 2.7
Date: Sat, 5 Jan 2019 20:44:11 +0100	[thread overview]
Message-ID: <41e7ccaf-c73d-b404-69fe-ad17433add37@broadcom.com> (raw)
In-Reply-To: <20190103154921.GA25015@w1.fi>

On 1/3/2019 4:49 PM, Jouni Malinen wrote:
> On Thu, Jan 03, 2019 at 10:38:32AM -0500, Eric Blau wrote:
>> Since upgrading to wpa_supplicant 2.7, myself and many others have hit
>> issues with wpa_supplicant failing to connect due to invalid arguments
>> being passed to the underlying kernel driver. Reverting to version 2.6
>> makes these issues go away.
> 
>> kernel: WARNING: CPU: 0 PID: 16169 at
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:5130
>> brcmf_cfg80211_set_pmk+0x50/0x70 [brcmfmac]
> 
> Which is this WARN_ON in the driver:
> 
>      /* expect using firmware supplicant for 1X */
>      ifp = netdev_priv(dev);
>      if (WARN_ON(ifp->vif->profile.use_fwsup != BRCMF_PROFILE_FWSUP_1X))
> 	return -EINVAL;

Yes. It means the firmware is not configured to use the 1x offload so it 
rejects the PMK setting here.

>> Notice that the oops references wpa_supplicant as the offending
>> process, although maybe the firmware or driver is at fault for
>> advertising 4-way handshake offload support.
> 
> That's not an oops and wpa_supplicant is not the "offending process", it
> is just the user space process in which context the driver hits this
> issue.

Well, I beg to differ but I will get to that.

>> Any ideas what the issue could be here? If there's anything else I can
>> do to help track down the problem, please let me know.
> 
> That should be reported to the maintainers of the kernel driver that has
> this issue:

So the issue is that the nl80211 api requires wpa_supplicant to provide 
an attribute in the NL80211_CMD_CONNECT to indicate that driver/firmware 
should do the 1x offload which is described in the second paragraph below:

/**
  * DOC: WPA/WPA2 EAPOL handshake offload
  *
  * By setting @NL80211_EXT_FEATURE_4WAY_HANDSHAKE_STA_PSK flag drivers
  * can indicate they support offloading EAPOL handshakes for WPA/WPA2
  * preshared key authentication. In %NL80211_CMD_CONNECT the preshared
  * key should be specified using %NL80211_ATTR_PMK. Drivers supporting
  * this offload may reject the %NL80211_CMD_CONNECT when no preshared
  * key material is provided, for example when that driver does not
  * support setting the temporal keys through %CMD_NEW_KEY.
  *
  * Similarly @NL80211_EXT_FEATURE_4WAY_HANDSHAKE_STA_1X flag can be
  * set by drivers indicating offload support of the PTK/GTK EAPOL
  * handshakes during 802.1X authentication. In order to use the offload
  * the %NL80211_CMD_CONNECT should have %NL80211_ATTR_WANT_1X_4WAY_HS
  * attribute flag. Drivers supporting this offload may reject the
  * %NL80211_CMD_CONNECT when the attribute flag is not present.
  *
  * For 802.1X the PMK or PMK-R0 are set by providing %NL80211_ATTR_PMK
  * using %NL80211_CMD_SET_PMK. For offloaded FT support also
  * %NL80211_ATTR_PMKR0_NAME must be provided.
  */

For testing I had modified the wpa_supplicant to add the required flag 
in CONNECT command, but it was a bit too hacky to submit. I will rebase 
those changes and clean it up.

However, there is more to it. When these offloads were introduced, we 
discussed about having a PORT_AUTHORIZED event or not. It was decided 
passing an attribute in CONNECT and ROAMED event would suffice and that 
is what was implemented in brcmfmac. However, it seems time passed and 
the need for an explicit PORT_AUTHORIZED was there (probably Denis 
knows), which wpa_supplicant now supports thus ignoring the attribute in 
the CONNECT and ROAMED events. The brcmfmac driver was not changed 
accordingly. For this there are patches pending in linux-wireless which 
are necessary to have a working connection.

Regards,
Arend

       reply	other threads:[~2019-01-05 19:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CADU241PtPeiTQWHwb=uF6Ohuua_asOwCarCAKVC8jdVVNAsByA@mail.gmail.com>
     [not found] ` <20190103154921.GA25015@w1.fi>
2019-01-05 19:44   ` Arend Van Spriel [this message]
2019-01-08 17:44     ` Kernel oops / WiFi connection failure with wpa_supplicant 2.7 Denis Kenzior
2019-01-14 20:12       ` Arend Van Spriel
2019-01-14 21:18         ` Denis Kenzior
2019-01-14 23:04           ` Arend Van Spriel
2019-01-15 13:00             ` Johannes Berg
2019-01-15 15:55             ` Denis Kenzior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41e7ccaf-c73d-b404-69fe-ad17433add37@broadcom.com \
    --to=arend.vanspriel@broadcom.com \
    --cc=denkenz@gmail.com \
    --cc=eblau@eblau.com \
    --cc=hostap@lists.infradead.org \
    --cc=j@w1.fi \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).