Re: [PATCH ath-next 1/3] wifi: ath10k: set the PMF peer flag on WCN3990

[Nagashima, Shunsuke]

Hi Loic,

On Tue, Nov 3, 2026 at 2:46 PM Loic Poulain wrote:
> If Linux-firmware ships 01387, someone will need to confirm that the
> MFP capability addition works with that specific firmware version. For
> QCM2290, I can probably test it myself and provide a Tested-by tag if
> you can describe the expected testing procedure.
>
> Yes, to Jeff.

Thanks. Then I'll start with the qcm2290 file only, and leave the
shared 01387 file until someone can test it on a db845c or an axolotl.
Note that qrb4210/firmware-5.bin is a link to the qcm2290 file, so the
change covers both.

Test procedure:

1. With the current file, dmesg shows these features (crc32 a79c5b24):
     wowlan,mgmt-tx-by-reference,non-bmi,single-chan-info-per-channel
   Connect to a 5 GHz WPA3-SAE AP (PMF on) and run iperf3 to a wired
   host, up and down (-R). Do the same with WPA2 on the same AP.

2. Make the new file (qca-swiss-army-knife ath10k-fwencoder):
  F=wowlan,mgmt-tx-by-ref,non-bmi,single-chan-info-per-channel,mfp-support
  cp firmware-5.bin firmware-5.mfp.bin
  ath10k-fwencoder --modify --timestamp=1706616060 \
      --features=$F firmware-5.mfp.bin
   md5sum: 58982403c9c56a4b888fe0ab3104d7de. Only one byte changes
   (offset 33, 0x00 -> 0x10). Without --timestamp the tool writes the
   current time and the md5sum changes.

3. Put it in place of ath10k/WCN3990/hw1.0/qcm2290/firmware-5.bin and
   reboot (ath10k reads the features only at probe). dmesg should show
   these features (crc32 f9e8f071):
     wowlan,mfp,mgmt-tx-by-reference,non-bmi,single-chan-info-per-channel

4. Repeat the iperf3 runs. Also disconnect and reconnect to the WPA3 AP
   about 10 times, note how long each reconnect takes, and check dmesg
   for "firmware crashed".

On my comma four (WLAN.HL.2.0.c10-00459), adding only this bit to
its firmware-5.bin, with the kernel unchanged, took WPA3 from 22.6-31.6
Mbit/s up and 21.6-21.7 down to 273.8-287.7 up and 242.5-243.7 down,
close to WPA2. Without the bit, ADDBA Requests went out unprotected and
no Block Ack was set up, and with one AP a reconnect took about 24 s;
with the bit it took 1-5 s.

A failure would be an association failure or a firmware crash. If WPA3
is already close to WPA2 with the current file, please tell me too:
then this firmware may not need the bit, and the test only shows that
it does no harm. A monitor-mode capture is optional; with the new file
the ADDBA Request frames should be protected.

If it works, I'll send the file to the ath10k list, to Jeff with you
in CC, with your Tested-by.

I worked through this with Claude (AI). English is hard for me, so AI
helped write the English. I ran all the device tests myself on my comma
four.

Thanks,
Shunsuke Nagashima <shunsuke@xxxxxxxxxx>