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
