[PATCH rtw-next] wifi: rtw89: do BIP in software when not in station mode

[PATCH rtw-next] wifi: rtw89: do BIP in software when not in station mode

[V schurink]

rtw89_cam_sec_key_add() installs the AES-CMAC key (BIP, 802.11w PMF)
in hardware. rtw89_core_tx_update_sec_key() has no case for
WLAN_CIPHER_SUITE_AES_CMAC, and the driver does not set
IEEE80211_KEY_FLAG_GENERATE_MMIE. Thus, an AP with PMF sends each
protected group-addressed management frame without an MMIE, for
example a broadcast deauthentication. For each frame, the driver logs
"key cipher not supported 1027078". PMF clients discard these frames.

An AP sends these frames. Thus, return -EOPNOTSUPP for AES-CMAC when
the interface is not a station, so that mac80211 does BIP in software.
A station only receives these frames, so it keeps the IGTK in
hardware. This does not change WoWLAN, which uses the IGTK of a
station.

BIP in hardware does not work for an AP on RTL8922A. The test used
IEEE80211_KEY_FLAG_GENERATE_MMIE and RTW89_SEC_KEY_TYPE_BIP_CCMP128 in
the TX descriptor. The client did not accept the protected broadcast
deauthentication.

Tested on RTL8912AU (RTL8922A, USB) in AP mode with hostapd 2.10,
WPA2-PSK and SAE, ieee80211w=1. The client accepts the protected
broadcast deauthentication, and the driver does not log the warning.

Fixes: 940cd99625de ("wifi: rtw89: wow: support 802.11w PMF IGTK rekey")
Signed-off-by: V schurink <spam@acio.nl>
---
 drivers/net/wireless/realtek/rtw89/cam.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtw89/cam.c b/drivers/net/wireless/realtek/rtw89/cam.c
index 22f21a0..58a7e8f 100644
--- a/drivers/net/wireless/realtek/rtw89/cam.c
+++ b/drivers/net/wireless/realtek/rtw89/cam.c
@@ -514,6 +514,12 @@ int rtw89_cam_sec_key_add(struct rtw89_dev *rtwdev,
 		ext_key = true;
 		break;
 	case WLAN_CIPHER_SUITE_AES_CMAC:
+		/* TX does not support BIP. An AP sends group-addressed robust
+		 * management frames, so let mac80211 do BIP in software there.
+		 * A station only receives them; keep its IGTK in hardware.
+		 */
+		if (vif->type != NL80211_IFTYPE_STATION)
+			return -EOPNOTSUPP;
 		hw_key_type = RTW89_SEC_KEY_TYPE_BIP_CCMP128;
 		break;
 	default:
-- 
2.53.0
---
Also discussed in the out-of-tree repository:
https://github.com/morrownr/rtw89/pull/135

RE: [PATCH rtw-next] wifi: rtw89: do BIP in software when not in station mode

[Ping-Ke Shih]

V schurink <spam@acio.nl> wrote:
> rtw89_cam_sec_key_add() installs the AES-CMAC key (BIP, 802.11w PMF)
> in hardware. rtw89_core_tx_update_sec_key() has no case for
> WLAN_CIPHER_SUITE_AES_CMAC, and the driver does not set
> IEEE80211_KEY_FLAG_GENERATE_MMIE. Thus, an AP with PMF sends each
> protected group-addressed management frame without an MMIE, for
> example a broadcast deauthentication. For each frame, the driver logs
> "key cipher not supported 1027078". PMF clients discard these frames.
> 
> An AP sends these frames. Thus, return -EOPNOTSUPP for AES-CMAC when
> the interface is not a station, so that mac80211 does BIP in software.
> A station only receives these frames, so it keeps the IGTK in
> hardware. This does not change WoWLAN, which uses the IGTK of a
> station.
> 
> BIP in hardware does not work for an AP on RTL8922A. The test used
> IEEE80211_KEY_FLAG_GENERATE_MMIE and RTW89_SEC_KEY_TYPE_BIP_CCMP128 in
> the TX descriptor. The client did not accept the protected broadcast
> deauthentication.
> 
> Tested on RTL8912AU (RTL8922A, USB) in AP mode with hostapd 2.10,
> WPA2-PSK and SAE, ieee80211w=1. The client accepts the protected
> broadcast deauthentication, and the driver does not log the warning.

We made a RFT patch [1]. Please try if it can work to you.

I think the reason why your try in github doesn't work is missing to
trim MIC space of MMIC.

[1] https://lore.kernel.org/linux-wireless/20261029014857.9753-1-pkshih@realtek.com/T/#u

> 
> Fixes: 940cd99625de ("wifi: rtw89: wow: support 802.11w PMF IGTK rekey")
> Signed-off-by: V schurink <spam@acio.nl>
> ---
>  drivers/net/wireless/realtek/rtw89/cam.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/net/wireless/realtek/rtw89/cam.c b/drivers/net/wireless/realtek/rtw89/cam.c
> index 22f21a0..58a7e8f 100644
> --- a/drivers/net/wireless/realtek/rtw89/cam.c
> +++ b/drivers/net/wireless/realtek/rtw89/cam.c
> @@ -514,6 +514,12 @@ int rtw89_cam_sec_key_add(struct rtw89_dev *rtwdev,
>                 ext_key = true;
>                 break;
>         case WLAN_CIPHER_SUITE_AES_CMAC:
> +               /* TX does not support BIP. An AP sends group-addressed robust
> +                * management frames, so let mac80211 do BIP in software there.
> +                * A station only receives them; keep its IGTK in hardware.
> +                */

The first line of block comment should be empty. Even, I think this comment
is not necessary. The change blow says that, or it should be 'vif == IFTYPE_AP'
to match the comment. 

> +               if (vif->type != NL80211_IFTYPE_STATION)
> +                       return -EOPNOTSUPP;
>                 hw_key_type = RTW89_SEC_KEY_TYPE_BIP_CCMP128;
>                 break;
>         default:
> --
> 2.53.0
> ---
> Also discussed in the out-of-tree repository:
> https://github.com/morrownr/rtw89/pull/135

Re: [PATCH rtw-next] wifi: rtw89: do BIP in software when not in station mode

[V. S.]

Ping-Ke Shih <pkshih@realtek.com> wrote:
> A RFT patch for test purpose.
>
> It needs software generate MMIC header but excluding 8-byte MIC space.

Thank you. The patch works on my device.

Test setup:
- RTL8912AU (RTL8922A, USB) in AP mode, firmware 0.35.80.3.
- Raspberry Pi 5, kernel 6.18, out-of-tree rtw89 from
  morrownr/rtw89 with this patch applied.
- hostapd 2.10, WPA2-PSK/CCMP, ieee80211w=1.
- Client: Intel Meteor Lake CNVi (iwlwifi), connected with MFP.

Test: I sent a protected broadcast deauthentication with
"hostapd_cli deauthenticate ff:ff:ff:ff:ff:ff" and read the kernel
log of the client. I did the test in the sequence A/B/B/A, with
A = BIP in software (my patch) and B = this RFT patch.

  driver             client log                          delay
  A  BIP software    deauthenticated from <AP> (Reason 2)  < 0.01 s
  B  RFT, run 1      deauthenticated from <AP> (Reason 2)    0.15 s
  B  RFT, run 2      deauthenticated from <AP> (Reason 2)    0.02 s
  A  BIP software    deauthenticated from <AP> (Reason 2)    0.12 s

The delay is the time between the hostapd command on the AP and the
client log. The two clocks use NTP, but the delay values are not
exact.

With the RFT patch, the client accepts the protected broadcast frame
at once, and the driver does not log "key cipher not supported". My
earlier test of BIP in hardware did not trim the 8-byte MIC space, and
the client did not accept the frame. Thus, your diagnosis is correct.

Tested-by: V schurink <spam@acio.nl>

Please drop my patch "wifi: rtw89: do BIP in software when not in
station mode". This patch replaces it.

One note: mac80211 increments key->tx_pn when it writes the IPN into
the MMIE, and rtw89_core_tx_update_sec_key() increments it again for
sec_seq. Thus, the PN increases by 2 for each frame. This did not
cause a problem in my test. I do not know which value the hardware
uses for the MIC.


On Thu, Oct 29, 2026 at 2:57 AM Ping-Ke Shih <pkshih@realtek.com> wrote:
>
> V schurink <spam@acio.nl> wrote:
> > rtw89_cam_sec_key_add() installs the AES-CMAC key (BIP, 802.11w PMF)
> > in hardware. rtw89_core_tx_update_sec_key() has no case for
> > WLAN_CIPHER_SUITE_AES_CMAC, and the driver does not set
> > IEEE80211_KEY_FLAG_GENERATE_MMIE. Thus, an AP with PMF sends each
> > protected group-addressed management frame without an MMIE, for
> > example a broadcast deauthentication. For each frame, the driver logs
> > "key cipher not supported 1027078". PMF clients discard these frames.
> >
> > An AP sends these frames. Thus, return -EOPNOTSUPP for AES-CMAC when
> > the interface is not a station, so that mac80211 does BIP in software.
> > A station only receives these frames, so it keeps the IGTK in
> > hardware. This does not change WoWLAN, which uses the IGTK of a
> > station.
> >
> > BIP in hardware does not work for an AP on RTL8922A. The test used
> > IEEE80211_KEY_FLAG_GENERATE_MMIE and RTW89_SEC_KEY_TYPE_BIP_CCMP128 in
> > the TX descriptor. The client did not accept the protected broadcast
> > deauthentication.
> >
> > Tested on RTL8912AU (RTL8922A, USB) in AP mode with hostapd 2.10,
> > WPA2-PSK and SAE, ieee80211w=1. The client accepts the protected
> > broadcast deauthentication, and the driver does not log the warning.
>
> We made a RFT patch [1]. Please try if it can work to you.
>
> I think the reason why your try in github doesn't work is missing to
> trim MIC space of MMIC.
>
> [1] https://lore.kernel.org/linux-wireless/20261029014857.9753-1-pkshih@realtek.com/T/#u
>
> >
> > Fixes: 940cd99625de ("wifi: rtw89: wow: support 802.11w PMF IGTK rekey")
> > Signed-off-by: V schurink <spam@acio.nl>
> > ---
> >  drivers/net/wireless/realtek/rtw89/cam.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/net/wireless/realtek/rtw89/cam.c b/drivers/net/wireless/realtek/rtw89/cam.c
> > index 22f21a0..58a7e8f 100644
> > --- a/drivers/net/wireless/realtek/rtw89/cam.c
> > +++ b/drivers/net/wireless/realtek/rtw89/cam.c
> > @@ -514,6 +514,12 @@ int rtw89_cam_sec_key_add(struct rtw89_dev *rtwdev,
> >                 ext_key = true;
> >                 break;
> >         case WLAN_CIPHER_SUITE_AES_CMAC:
> > +               /* TX does not support BIP. An AP sends group-addressed robust
> > +                * management frames, so let mac80211 do BIP in software there.
> > +                * A station only receives them; keep its IGTK in hardware.
> > +                */
>
> The first line of block comment should be empty. Even, I think this comment
> is not necessary. The change blow says that, or it should be 'vif == IFTYPE_AP'
> to match the comment.
>
> > +               if (vif->type != NL80211_IFTYPE_STATION)
> > +                       return -EOPNOTSUPP;
> >                 hw_key_type = RTW89_SEC_KEY_TYPE_BIP_CCMP128;
> >                 break;
> >         default:
> > --
> > 2.53.0
> > ---
> > Also discussed in the out-of-tree repository:
> > https://github.com/morrownr/rtw89/pull/135
>

RE: [PATCH rtw-next] wifi: rtw89: do BIP in software when not in station mode

[Ping-Ke Shih]

V. S. <spam@acio.nl> wrote: 
> Ping-Ke Shih <pkshih@realtek.com> wrote:
> 
> Tested-by: V schurink <spam@acio.nl>

Could you provide your full name? I'd Cc (with Cc or Reported-by tag) you in
my format patch. Maybe also include the github link:

https://github.com/morrownr/rtw89/pull/135

> 
> One note: mac80211 increments key->tx_pn when it writes the IPN into
> the MMIE, and rtw89_core_tx_update_sec_key() increments it again for
> sec_seq. Thus, the PN increases by 2 for each frame. This did not
> cause a problem in my test. I do not know which value the hardware
> uses for the MIC.

As commit 79a6c9a4f3c4 ("rtw89: support hardware generate security header"),
which introduces chip->hw_sec_hdr for newer chips supporting hardware
security header, the key flag IEEE80211_KEY_FLAG_GENERATE_IV is unset, so
driver increases the PN.

I plan to check the key flag to decide if it is necessary to increase PN.

Ping-Ke

Re: [PATCH rtw-next] wifi: rtw89: do BIP in software when not in station mode

[V. S.]

Ping-Ke Shih <pkshih@realtek.com> wrote:
> Could you provide your full name? I'd Cc (with Cc or Reported-by tag) you in
> my format patch. Maybe also include the github link:
>
> https://github.com/morrownr/rtw89/pull/135

My full name is Vincent Schurink. YOu can the following tags:

Reported-by: Vincent Schurink <spam@acio.nl>
Tested-by: Vincent Schurink <spam@acio.nl>
Link: https://github.com/morrownr/rtw89/pull/135

The original bug report is this issue:
https://github.com/morrownr/rtw89/issues/114

> I plan to check the key flag to decide if it is necessary to increase PN.

Thank you. For AES-CMAC with IEEE80211_KEY_FLAG_GENERATE_MMIE,
mac80211 writes the IPN into the MMIE in
ieee80211_crypto_aes_cmac_encrypt(). I can test the next version on
the same device if you need someone to test that.

On Sun, Nov 1, 2026 at 3:36 AM Ping-Ke Shih <pkshih@realtek.com> wrote:
>
> V. S. <spam@acio.nl> wrote:
> > Ping-Ke Shih <pkshih@realtek.com> wrote:
> >
> > Tested-by: V schurink <spam@acio.nl>
>
> Could you provide your full name? I'd Cc (with Cc or Reported-by tag) you in
> my format patch. Maybe also include the github link:
>
> https://github.com/morrownr/rtw89/pull/135
>
> >
> > One note: mac80211 increments key->tx_pn when it writes the IPN into
> > the MMIE, and rtw89_core_tx_update_sec_key() increments it again for
> > sec_seq. Thus, the PN increases by 2 for each frame. This did not
> > cause a problem in my test. I do not know which value the hardware
> > uses for the MIC.
>
> As commit 79a6c9a4f3c4 ("rtw89: support hardware generate security header"),
> which introduces chip->hw_sec_hdr for newer chips supporting hardware
> security header, the key flag IEEE80211_KEY_FLAG_GENERATE_IV is unset, so
> driver increases the PN.
>
> I plan to check the key flag to decide if it is necessary to increase PN.
>
> Ping-Ke
>