2418659_en-US

[#1]

RW612 WPA2-Enterprise reauthentication – EAPOL TX completion before PTK installation

Hi,

We are implementing WPA2-Enterprise / IEEE 802.1X on an RW612-based product using Zephyr 4.3 and Hostap/wpa_supplicant.

Initial authentication works correctly with both PEAP/MSCHAPv2 and EAP-TLS. EAP-TLS also works with a PSA/ELS-backed non-exportable private key.

We see a problem specifically during Wi-Fi in-place reauthentication.

Observed sequence:

RADIUS Access-Accept
→ EAP success
→ 4-way handshake
→ AP retransmits Message 3
→ Wi-Fi link is lost
→ device reconnects and authenticates successfully again

Our current evidence suggests a possible ordering issue between transmission of the final EAPOL-Key response and installation of the new PTK.

The PTK update appears able to proceed while the final EAPOL frame may still be queued for transmission.

We tried to find a supported mechanism to guarantee:

final EAPOL-Key frame transmission completed
BEFORE
new PTK installation

However, we could not find an EAPOL TX-completion callback, TX queue drain/fence, or equivalent API in the RW612 Wi-Fi driver/firmware path.

As a diagnostic experiment only, adding a 100 ms delay before PTK installation allowed several PEAP and EAP-TLS reauthentication attempts to complete without interruption. We do not consider a fixed delay to be a production solution.

Could you please clarify:

- Is there a supported API to know when an EAPOL data frame has actually been transmitted by the firmware?
- Is there a TX queue flush/drain or key-install fence that should be used before updating PTK?
- Is this a known limitation or known issue in the RW612 Wi-Fi driver/firmware?
- Is there a newer driver or Wi-Fi firmware version that addresses this?

Tested versions:

RW612 driver: v1.3.r52.z_up.p11
Wi-Fi firmware: 18.99.6.p47

We can provide detailed traces and a vendor issue package if needed.

Thanks. RW612 

Re: RW612 WPA2-Enterprise reauthentication – EAPOL TX completion before PTK installation

Hi @sukrusinan, hope you are doing well.

To get a better understanding on your setup and case scenario, could you please share the following information?

• Share the used base example for your application. Is it Zephyr Wi-Fi Shell?
• Has this setup worked before as-is? If it has, could you please share which modifications were implemented?
• Provide terminal logs from a failing authentication case.
• What are you using as RADIUS server? 
• What AP model are you using?

Are you able to reproduce this behavior on Zephyr latest version (4.4.2)?

Please let us know the requested information.