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

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

[James Prestwood]

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.

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.

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

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

[Baochen Qiang]

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?

> 
> 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
> 

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

[James Prestwood]

[-- 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) {

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

[Baochen Qiang]

On 9/25/2024 7:33 PM, James Prestwood wrote:
> 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?
any comment on this query?

>>
>> 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.
Thanks, I found another way to do the decryption.

> 
>>
>>> 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
I checked all the action frames after decrypt the PCAP, but still not able to find a 'neighbor report' frame. next will study IWD code to understand how such a frame is triggered.

and again, if not possible to share the complete PCAP, can you share the individual 'neighbor report request' frame ? you can simply copy it in wireshark.

>>
>>> 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
>>>

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

[James Prestwood]

Hi,

On 9/25/24 8:16 PM, Baochen Qiang wrote:
>
> On 9/25/2024 7:33 PM, James Prestwood wrote:
>> 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?
> any comment on this query?
Yes, my home network is 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.
> Thanks, I found another way to do the decryption.
Out of curiosity how did you do this? I couldn't find any other way to 
decrypt WPA3 connections in wireshark except adding the PMK directly, 
even when capturing the 4-way handshake.
>
>>>> 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
> I checked all the action frames after decrypt the PCAP, but still not able to find a 'neighbor report' frame. next will study IWD code to understand how such a frame is triggered.
>
> and again, if not possible to share the complete PCAP, can you share the individual 'neighbor report request' frame ? you can simply copy it in wireshark.

Immediately after connecting you should see one of two possibilities.

1. If IWD did not receive a response you would see:

iwd[694]: src/station.c:station_early_neighbor_report_cb() ifindex: 6, 
error: -110(Connection timed out)

2. If a neighbor report was sent back by the AP you would see:

src/station.c:station_early_neighbor_report_cb() ifindex: 13, error: 0()
src/station.c:parse_neighbor_report() Neighbor report received for 
xx:xx:xx:xx:xx:xx ch 44 (oper class 22), MD not set

I just re-ran the test and now, for some reason, I am entirely unable to 
see the actual request go out. In the case of both ath11k and ath10k I 
see no request and but I do sometimes see a response. For iwlwifi I was 
able to capture a request/response but for the most part I don't see any 
request either, but always a response. Maybe the request is going out at 
some other data rate that my monitor card is unable to capture reliably? 
Not sure on that one.

So as far as seeing a request from ath11k, I'm unable to get one at 
least on my home network. Getting a capture on the corporate network may 
take me some more time.

Thanks,

James

>
>>>> 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
>>>>

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

[Baochen Qiang]

On 9/26/2024 8:31 PM, James Prestwood wrote:
> Hi,
> 
> On 9/25/24 8:16 PM, Baochen Qiang wrote:
>>
>> On 9/25/2024 7:33 PM, James Prestwood wrote:
>>> 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 
how do you tell if the 'neighbor report request' was unencrypted? did you check the 'protected' flag in sniffer?

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
and how do you tell if it is always encrypted?


>>>>> could.
>>>> is your home network also WPA3?
>> any comment on this query?
> Yes, my home network is 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.
>> Thanks, I found another way to do the decryption.
> Out of curiosity how did you do this? I couldn't find any other way to decrypt WPA3 connections in wireshark except adding the PMK directly, even when capturing the 4-way handshake.
I dumped the TK:

	@@ -2055,6 +2062,8 @@ static void netdev_set_tk(struct handshake_state *hs, uint8_t key_index,
	        if (!netdev_copy_tk(tk_buf, tk, cipher, hs->authenticator))
	                goto invalid_key;
	
	+       l_util_hexdump(false, tk_buf, 16, do_debug, "tk: ");
	+
	        msg = nl80211_build_new_key_pairwise(netdev->index, cipher, addr,
	                                        tk_buf, crypto_cipher_key_len(cipher),
                                        key_index);

>>
>>>>> 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
>> I checked all the action frames after decrypt the PCAP, but still not able to find a 'neighbor report' frame. next will study IWD code to understand how such a frame is triggered.
>>
>> and again, if not possible to share the complete PCAP, can you share the individual 'neighbor report request' frame ? you can simply copy it in wireshark.
> 
> Immediately after connecting you should see one of two possibilities.
> 
> 1. If IWD did not receive a response you would see:
> 
> iwd[694]: src/station.c:station_early_neighbor_report_cb() ifindex: 6, error: -110(Connection timed out)
> 
> 2. If a neighbor report was sent back by the AP you would see:
> 
> src/station.c:station_early_neighbor_report_cb() ifindex: 13, error: 0()
> src/station.c:parse_neighbor_report() Neighbor report received for xx:xx:xx:xx:xx:xx ch 44 (oper class 22), MD not set
> 
> I just re-ran the test and now, for some reason, I am entirely unable to see the actual request go out. In the case of both ath11k and ath10k I see no request and but I do sometimes see a response. For iwlwifi I was able to capture a request/response but for the most part I don't see any request either, but always a response. Maybe the request is going out at some other data rate that my monitor card is unable to capture reliably? Not sure on that one.
> 
> So as far as seeing a request from ath11k, I'm unable to get one at least on my home network. Getting a capture on the corporate network may take me some more time.
here is the sequence I saw in sniffer:
#1 AP send M3
#2 station send 'neighbor report request' without encryption, though 'protected' flag is set
#3 station send out M4

is this the same with what you saw?

> 
> Thanks,
> 
> James
> 
>>
>>>>> 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
>>>>>

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

[James Prestwood]

On 9/26/24 10:59 PM, Baochen Qiang wrote:
>
> On 9/26/2024 8:31 PM, James Prestwood wrote:
>> Hi,
>>
>> On 9/25/24 8:16 PM, Baochen Qiang wrote:
>>> On 9/25/2024 7:33 PM, James Prestwood wrote:
>>>> 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
> how do you tell if the 'neighbor report request' was unencrypted? did you check the 'protected' flag in sniffer?
>
> 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
> and how do you tell if it is always encrypted?

I think what I saw here was because the capture was done through the AP 
vendor was automatically decrypted or something. The frame was still 
marked as protected, but I never had to add the PMK to get wireshark to 
parse it correctly.

On my home network when I was referring to "always encrypted" it was 
because the frames always had the CCMP IV and the content of the frame 
itself was not visibly a neighbor report/request, just a string of hex 
values. Once I added the PMK and decrypted it wireshark could parse it.

>
>
>>>>>> could.
>>>>> is your home network also WPA3?
>>> any comment on this query?
>> Yes, my home network is 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.
>>> Thanks, I found another way to do the decryption.
>> Out of curiosity how did you do this? I couldn't find any other way to decrypt WPA3 connections in wireshark except adding the PMK directly, even when capturing the 4-way handshake.
> I dumped the TK:
>
> 	@@ -2055,6 +2062,8 @@ static void netdev_set_tk(struct handshake_state *hs, uint8_t key_index,
> 	        if (!netdev_copy_tk(tk_buf, tk, cipher, hs->authenticator))
> 	                goto invalid_key;
> 	
> 	+       l_util_hexdump(false, tk_buf, 16, do_debug, "tk: ");
> 	+
> 	        msg = nl80211_build_new_key_pairwise(netdev->index, cipher, addr,
> 	                                        tk_buf, crypto_cipher_key_len(cipher),
>                                          key_index);
>
>>>>>> 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
>>> I checked all the action frames after decrypt the PCAP, but still not able to find a 'neighbor report' frame. next will study IWD code to understand how such a frame is triggered.
>>>
>>> and again, if not possible to share the complete PCAP, can you share the individual 'neighbor report request' frame ? you can simply copy it in wireshark.
>> Immediately after connecting you should see one of two possibilities.
>>
>> 1. If IWD did not receive a response you would see:
>>
>> iwd[694]: src/station.c:station_early_neighbor_report_cb() ifindex: 6, error: -110(Connection timed out)
>>
>> 2. If a neighbor report was sent back by the AP you would see:
>>
>> src/station.c:station_early_neighbor_report_cb() ifindex: 13, error: 0()
>> src/station.c:parse_neighbor_report() Neighbor report received for xx:xx:xx:xx:xx:xx ch 44 (oper class 22), MD not set
>>
>> I just re-ran the test and now, for some reason, I am entirely unable to see the actual request go out. In the case of both ath11k and ath10k I see no request and but I do sometimes see a response. For iwlwifi I was able to capture a request/response but for the most part I don't see any request either, but always a response. Maybe the request is going out at some other data rate that my monitor card is unable to capture reliably? Not sure on that one.
>>
>> So as far as seeing a request from ath11k, I'm unable to get one at least on my home network. Getting a capture on the corporate network may take me some more time.
> here is the sequence I saw in sniffer:
> #1 AP send M3
> #2 station send 'neighbor report request' without encryption, though 'protected' flag is set
> #3 station send out M4
>
> is this the same with what you saw?
When I was able to capture the neighbor report request (rarely) it was 
after M4, not before. If you're seeing it prior to M4 that seems 
strange, unless the kernel/ath11k is doing some odd queuing?
>
>> Thanks,
>>
>> James
>>
>>>>>> 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
>>>>>>

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

[Baochen Qiang]

On 9/27/2024 7:53 PM, James Prestwood wrote:
> I think what I saw here was because the capture was done through the AP vendor was automatically decrypted or something. The frame was still marked as protected, but I never had to add the PMK to get wireshark to parse it correctly.
this is exactly what I see. there is no automatic decryption here, it is only because the frame is NOT encrypted, though 'protected' bit set.

> 
> On my home network when I was referring to "always encrypted" it was because the frames always had the CCMP IV and the content of the frame itself was not visibly a neighbor report/request, just a string of hex values. Once I added the PMK and decrypted it wireshark could parse it.
is this tested still with IWD?

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

[James Prestwood]

On 9/28/24 7:14 PM, Baochen Qiang wrote:
>
> On 9/27/2024 7:53 PM, James Prestwood wrote:
>> I think what I saw here was because the capture was done through the AP vendor was automatically decrypted or something. The frame was still marked as protected, but I never had to add the PMK to get wireshark to parse it correctly.
> this is exactly what I see. there is no automatic decryption here, it is only because the frame is NOT encrypted, though 'protected' bit set.
>
>> On my home network when I was referring to "always encrypted" it was because the frames always had the CCMP IV and the content of the frame itself was not visibly a neighbor report/request, just a string of hex values. Once I added the PMK and decrypted it wireshark could parse it.
> is this tested still with IWD?
Yes, only with IWD.

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

[Baochen Qiang]

On 9/27/2024 7:53 PM, James Prestwood wrote:
>> here is the sequence I saw in sniffer:
>> #1 AP send M3
>> #2 station send 'neighbor report request' without encryption, though 'protected' flag is set
>> #3 station send out M4
>>
>> is this the same with what you saw?
> When I was able to capture the neighbor report request (rarely) it was after M4, not before. If you're seeing it prior to M4 that seems strange, unless the kernel/ath11k is doing some odd queuing?
yeah... firmware has some odd assumption on the sequence of key install, causing such behavior.

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

[James Prestwood]

On 9/28/24 7:16 PM, Baochen Qiang wrote:
>
> On 9/27/2024 7:53 PM, James Prestwood wrote:
>>> here is the sequence I saw in sniffer:
>>> #1 AP send M3
>>> #2 station send 'neighbor report request' without encryption, though 'protected' flag is set
>>> #3 station send out M4
>>>
>>> is this the same with what you saw?
>> When I was able to capture the neighbor report request (rarely) it was after M4, not before. If you're seeing it prior to M4 that seems strange, unless the kernel/ath11k is doing some odd queuing?
> yeah... firmware has some odd assumption on the sequence of key install, causing such behavior.
>
Do you think maybe this has something to do with it? Its just a timing 
issue (both in my case and when you see it before M4) and in some cases 
the keys aren't fully installed and the request either gets dropped or 
just isn't encrypted correctly?

Like I said originally, its not like this issue is severe, we can just 
request a neighbor report later and that does work. It was just an 
observation and didn't seem right.

Thanks,

James