Re: ath11k/WCN6855 neighbor report request made immediately after connection gets no response (with MFP)

[James Prestwood <prestwoj@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2298 bytes --]

Hi Baochen,

On 9/25/24 3:07 AM, Baochen Qiang wrote:
>
> On 9/19/2024 8:21 PM, James Prestwood wrote:
>> Hi,
>>
>> I noticed an issue when we started putting ath11k clients on a WPA3 network which seems to be related to the fact that management frame protection is enabled (works fine on WPA2 no MFP). Immediately after an initial association a neighbor report request goes out and we get no response from the AP. After getting a PCAP in one case we noticed the neighbor report request went out unencrypted, though still had the CCMP IV parameter. The content of the request was the unencrypted request, and something like 15 bytes of 0x00 padding. I will say, this initial PCAP was made through the AP vendor so perhaps it automatically added the right keys to decrypt the frame, this could be a red herring. I tried on my home network and it was hit or miss, sometimes I would get a response but sometimes I wouldn't, but I did see the frame was always encrypted in my home network case though when adding the PMK directly in wireshark I couldn't decrypt it, where on other hardware like iwlwifi I could.
> is your home network also WPA3?
>
> and how did you get the PMK? is it generated by IWD and printed as debug message?

I actually had to modify IWD to print out the PMK after it derived it. 
WPA3 makes this a huge pain since the PMK differs between SAE exchanges.

I've attached an IWD diff that prints out the PMK, which can be added to 
wireshark if that helps.

>
>> Some time after the connection neighbor reports work fine. I'm not sure of a time frame or delay required that gets them working, but it makes me suspect that ath11k doesn't have the keys fully added in the firmware before userspace gets signaled as "connected". Running the same scenario on ath10k or iwlwifi has no issues. This neighbor report request immediately after connecting is IWD's default behavior, so its relatively easy to test by just restarting IWD.
> I captured a WPA3 SAE PCAP too, but only can find some unencrypted ADDBA req/resp frames. for those encrypted action frames I am still struggling to decrypt them
>
>> Since the neighbor reports work fine after some time its not really a critical issue but I wanted to bring it up just in case.
>>
>> Thanks,
>>
>> James
>>

[-- Attachment #2: print-pmk.patch --]
[-- Type: text/x-patch, Size: 909 bytes --]

diff --git a/src/sae.c b/src/sae.c
index 97c0af05..f2cebe09 100644
--- a/src/sae.c
+++ b/src/sae.c
@@ -857,6 +857,20 @@ static bool sae_verify_confirm(struct sae_sm *sm, const uint8_t *frame)
        return true;
 }
 
+#include <stdio.h>
+
+static void print_pmk(uint8_t *pmk)
+{
+       unsigned int i;
+
+       printf("PMK: ");
+
+       for (i = 0; i < 32; i++)
+               printf("%02x", pmk[i]);
+
+       printf("\n");
+}
+
 static int sae_process_confirm(struct sae_sm *sm, const uint8_t *from,
                                const uint8_t *frame, size_t len)
 {
@@ -880,6 +894,8 @@ static int sae_process_confirm(struct sae_sm *sm, const uint8_t *from,
        handshake_state_set_pmkid(sm->handshake, sm->pmkid);
        handshake_state_set_pmk(sm->handshake, sm->pmk, 32);
 
+       print_pmk(sm->pmk);
+
        sm->state = SAE_STATE_ACCEPTED;
 
        if (!sm->handshake->authenticator) {