Rafał Miłecki <zajec5@xxxxxxxxx> writes: > On Fri, 22 May 2020 at 23:06, Larry Finger <Larry.Finger@xxxxxxxxxxxx> wrote: >> On 5/22/20 3:40 PM, Rui Salvaterra wrote: >> > On Fri, 22 May 2020 at 19:02, Larry Finger <Larry.Finger@xxxxxxxxxxxx> 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. > > Nice work Larry, thank you! Indeed, this is a perfect solution. -- https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
