From: Stefan Sperling <stsp@stsp.name>
Subject: Re: qwx(4) crypto offloading
To: Kevin Lo <kevlo@kevlo.org>
Cc: tech@openbsd.org
Date: Mon, 27 May 2024 17:28:27 +0200

On Fri, May 24, 2024 at 02:32:14PM +0800, Kevin Lo wrote:
> On Thu, May 23, 2024 at 04:27:53PM +0200, Stefan Sperling wrote:
> > 
> > With the patch below, qwx(4) offloads CCMP and TKIP to hardware.
> > The performance benefit is small with 11a/b/g modes but becomes
> > significant once 11n/11ac speeds will be enabled eventually.
> > 
> > Also, there is a firmware bug which prevents reception of broadcast
> > and multicast frames when crypto is done in software. This is why
> > ARP and IPv6 are kind of broken on qwx right now, and this diff should
> > fix these issues on WPA networks at least.
> > 
> > So far I have only tested CCMP-only (WPA2/AES). In ifconfig such
> > networks show up as: wpaciphers cmmp wpagroupcipher ccmp
> > 
> > There are several other cases which still need to be tested:
> > 1) wpaciphers cmmp wpagroupcipher tkip
> > 2) wpaprotos wpa1 wpaciphers tkip wpagroupcipher tkip
> > 3) WEP  (not sure if anyone ever tested qwx with WEP before?)
> > 
> > Due to time constraints I would appreciate help with testing the above.
> > If you have an OpenBSD hostap then setting up all of these combinations
> > can be done with ifconfig. For APs from other vendors the non-CCMP modes
> > will usually be called something like "WPA1" or something that is not "AES".
> > In any case, ifconfig qwx0 will display the config provided by the AP.
> 
> Thanks for the work!  Both cases "wpaciphers ccmp wpagroupcipher ccmp" and
> "wpaciphers ccmp wpagroupcipher tkip" work well for me.
> I confirm that ARP issue is resolved.
> 
> Cases 2 and 3 doesn't work.
> qwx0: flags=808843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF4> mtu 1500
>         lladdr 00:0e:8e:xx:xx:xx
>         index 2 priority 4 llprio 3
>         groups: wlan
>         media: IEEE802.11 autoselect (OFDM6 mode 11a)
>         status: no network
>         ieee80211: join puffy chan 36 bssid 00:0a:52:xx:xx:xx -52dBm wpakey wpaprotos wpa1 wpaakms psk wpaciphers tkip wpagroupcipher tkip
> 
> qwx0: flags=808843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF4> mtu 1500
>         lladdr 00:0e:8e:xx:xx:xx
>         index 2 priority 4 llprio 3
>         groups: wlan
>         media: IEEE802.11 autoselect (OFDM6 mode 11a)
>         status: active
>         ieee80211: nwid puffy chan 36 bssid 00:0a:52:xx:xx:xx -58dBm nwkey

Thanks for testing Kevin!

A WEP AP is receiving unencrypted packets from qwx, as shown by netstat -W.
So WEP is not working because software crypto is only used during Tx if the
frame_mode is "RAW". But with offloading the ath11k driver defaults to
frame_mode "NATIVE WIFI" instead. I don't understand what difference these
frame modes make from the firmware's perspective.

WEP can be fixed with the change below. However, it breaks WPA2 for
some reason. I don't know if WPA2 not working in RAW mode is a driver
or a firmware issue. But I will give up now. I plan to write a new diff
which offloads all of the ciphers because that seems easier on this crazy
hardware.

diff /usr/src
commit - 7cb71619920688a04ffa06cd1aa374fc5f590796
path + /usr/src
blob - c03a0d614c20a3e2f3a0f662d27b545232e19048
file + sys/dev/ic/qwx.c
--- sys/dev/ic/qwx.c
+++ sys/dev/ic/qwx.c
@@ -184,7 +184,7 @@ qwx_init(struct ifnet *ifp)
 
 	sc->fw_mode = ATH11K_FIRMWARE_MODE_NORMAL;
 	sc->crypto_mode = ATH11K_CRYPT_MODE_HW;
-	sc->frame_mode = ATH11K_HW_TXRX_NATIVE_WIFI;
+	sc->frame_mode = ATH11K_HW_TXRX_RAW;
 	ic->ic_state = IEEE80211_S_INIT;
 	sc->ns_nstate = IEEE80211_S_INIT;
 	sc->scan.state = ATH11K_SCAN_IDLE;