linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Larry Finger <Larry.Finger@lwfinger.net>
To: Rui Salvaterra <rsalvaterra@gmail.com>
Cc: "Kalle Valo" <kvalo@codeaurora.org>, "Michael Büsch" <m@bues.ch>,
	linux-wireless@vger.kernel.org, b43-dev@lists.infradead.org
Subject: Re: [BUG?] b43: can't connect to WPA3 network (nohwcrypt=1)
Date: Fri, 22 May 2020 16:06:27 -0500	[thread overview]
Message-ID: <8252e6a1-b83c-64eb-2503-2686374216ae@lwfinger.net> (raw)
In-Reply-To: <CALjTZvZV4kwLgoTijxsC2AYcxGeT1R_fsTdh3Gb=M03Rn_RsAg@mail.gmail.com>

On 5/22/20 3:40 PM, Rui Salvaterra wrote:
> On Fri, 22 May 2020 at 19:02, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>
>> Rui,
>>
>> Does this one-line
>> patch work for WPA3 without setting the nohwcrypt option?
> 
> Ok, so it "works", but I don't know what actually happened (I didn't
> do any performance testing yet). I got this relevant output on my
> kmsg…
> 
> rui@mcnugget:~$ dmesg | awk '(/80211/ || /b43/ || /wlan0/)'
> [    0.000000] Kernel command line: BOOT_IMAGE=/vmlinux-5.7.0-rc6+
> root=UUID=849bbef3-007e-491e-b187-9e259680c2e2 ro mitigations=off
> b43.qos=0 b43.verbose=3 usbhid.mousepoll=16 quiet splash
> [    0.035705] b43-pci-bridge 0001:10:12.0: enabling device (0004 -> 0006)
> [    0.210299] b43-pci-bridge 0001:10:12.0: Sonics Silicon Backplane
> found on PCI device 0001:10:12.0
> [    3.361908] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
> [    3.454235] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
> [    3.454259] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision
> 8, Version 0
> [    3.485125] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> [   28.697945] b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:07)
> [   28.730381] b43-phy0 debug: Chip initialized
> [   28.731389] b43-phy0 debug: 32-bit DMA initialized
> [   28.731400] b43-phy0 debug: QoS disabled
> [   28.792272] b43-phy0 debug: Wireless interface started
> [   28.820318] b43-phy0 debug: Adding Interface type 2
> [   33.944771] wlan0: authenticate with 04:f0:21:24:28:44
> [   33.970449] wlan0: send auth to 04:f0:21:24:28:44 (try 1/3)
> [   34.026222] wlan0: authenticate with 04:f0:21:24:28:44
> [   34.026241] wlan0: send auth to 04:f0:21:24:28:44 (try 1/3)
> [   34.028522] wlan0: authenticated
> [   34.043256] wlan0: associate with 04:f0:21:24:28:44 (try 1/3)
> [   34.046946] wlan0: RX AssocResp from 04:f0:21:24:28:44 (capab=0x431
> status=30 aid=1)
> [   34.046964] wlan0: 04:f0:21:24:28:44 rejected association
> temporarily; comeback duration 1000 TU (1024 ms)
> [   35.122051] wlan0: associate with 04:f0:21:24:28:44 (try 2/3)
> [   35.125547] wlan0: RX AssocResp from 04:f0:21:24:28:44 (capab=0x431
> status=0 aid=1)
> [   35.125808] wlan0: associated
> [   35.268256] b43-phy0 debug: Using hardware based encryption for
> keyidx: 0, mac: 04:f0:21:24:28:44
> [   35.268762] b43-phy0 debug: Using hardware based encryption for
> keyidx: 2, mac: ff:ff:ff:ff:ff:ff
> [   35.358586] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-22)
> [   35.358977] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [   87.283220] wlan0: failed to set key (4, ff:ff:ff:ff:ff:ff) to hardware (-22)
> [   87.283521] b43-phy0 debug: Using hardware based encryption for
> keyidx: 1, mac: ff:ff:ff:ff:ff:ff
> rui@mcnugget:~$
> 
> Meanwhile, iw list shows all the possible software cyphers:
> 
>      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)
>          * CMAC (00-0f-ac:6)
>          * CMAC-256 (00-0f-ac:13)
>          * GMAC-128 (00-0f-ac:11)
>          * GMAC-256 (00-0f-ac:12)
> 
> What I'm not sure is if b43 is doing all the cyphers it supports in
> hardware and falling back to software just for the unsupported ones,
> or if it's doing everything in software.
It will do supported ciphers in hardware, and unsupported using software. The 
patch tells mac80211 that we will accept the newer ciphers, then in the 
set_key() callback, we tell it whether the current type will be handled in 
hardware. Operations will be transparent. I will keep the nohwcrypt option just 
in case someone has a hardware malfunction that prohibits hardware use for all 
ciphers, but it will not be needed in cases like yours. Performance will be as 
you did earlier.

Thanks for testing.

Larry



  reply	other threads:[~2020-05-22 21:06 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19 14:18 [BUG?] b43: can't connect to WPA3 network (nohwcrypt=1) Rui Salvaterra
2020-05-19 20:30 ` Larry Finger
2020-05-19 20:36   ` Rui Salvaterra
2020-05-19 23:13     ` Rui Salvaterra
2020-05-20  0:16       ` Larry Finger
2020-05-20  8:24         ` Rui Salvaterra
2020-05-20 10:55           ` Rui Salvaterra
2020-05-20 20:08             ` Larry Finger
2020-05-20 20:28               ` Rui Salvaterra
2020-05-20 20:56                 ` Larry Finger
2020-05-21  8:35                   ` Rui Salvaterra
2020-05-21  9:07                     ` Rui Salvaterra
2020-05-21 10:46                       ` Michael Büsch
2020-05-21 11:30                         ` Rui Salvaterra
2020-05-21 11:40                           ` Michael Büsch
2020-05-21 14:10                             ` Larry Finger
2020-05-21 14:52                             ` Rui Salvaterra
2020-05-21 16:17                               ` Rui Salvaterra
2020-05-21 18:59                                 ` Larry Finger
2020-05-21 19:19                                   ` Rui Salvaterra
2020-05-21 20:23                                     ` Rui Salvaterra
2020-05-21 21:47                                       ` Larry Finger
2020-05-22 10:19                                         ` Michael Büsch
2020-05-22 11:49                                           ` Kalle Valo
2020-05-22 13:46                                             ` Rui Salvaterra
2020-05-22 18:02                                               ` Larry Finger
2020-05-22 20:04                                                 ` Rui Salvaterra
2020-05-22 20:40                                                 ` Rui Salvaterra
2020-05-22 21:06                                                   ` Larry Finger [this message]
2020-05-23  0:35                                                     ` Rui Salvaterra
2020-05-23 21:17                                                     ` Rafał Miłecki
2020-05-25  6:56                                                       ` Kalle Valo
2020-05-22 17:15                                             ` Larry Finger

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=8252e6a1-b83c-64eb-2503-2686374216ae@lwfinger.net \
    --to=larry.finger@lwfinger.net \
    --cc=b43-dev@lists.infradead.org \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=m@bues.ch \
    --cc=rsalvaterra@gmail.com \
    /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).