Support 11w protected management frames #676
Conversation
Action frames decryption is offload to hw
|
Thank you! |
| @@ -495,7 +495,8 @@ iwn_attach(struct iwn_softc *sc, struct pci_attach_args *pa) | |||
| IEEE80211_C_MONITOR | /* monitor mode supported */ | |||
| IEEE80211_C_SHSLOT | /* short slot time supported */ | |||
| IEEE80211_C_SHPREAMBLE | /* short preamble supported */ | |||
| IEEE80211_C_PMGT; /* power saving supported */ | |||
| IEEE80211_C_PMGT | /* power saving supported */ | |||
| IEEE80211_C_MFP; /* management frame protection 11w supported */ | |||
There was a problem hiding this comment.
Not all of the DVM cards' firmwares support 11w, original iwlwifi code says:
/*
* Enable 11w if advertised by firmware and software crypto
* is not enabled (as the firmware will interpret some mgmt
* packets, so enabling it with software crypto isn't safe)
*/
if (priv->fw->ucode_capa.flags & IWL_UCODE_TLV_FLAGS_MFP &&
!iwlwifi_mod_params.swcrypto)
ieee80211_hw_set(hw, MFP_CAPABLE);
There was a problem hiding this comment.
You made a good point.
I quickly checked my N 6205 card, the tlv_feature_flags is 0x0b, and it doesn't include the bit IWN_UCODE_TLV_FLAGS_MFP (1<<2). It looks like the firmware doesn't tell support 11w, and it is actually working on my setup. It is unclear to me what's the best way to determine this feature flag.
I'll leave the code for iwn as is without testing the firmware feature flags for now. May be there are some corner cases to be discovered.
There was a problem hiding this comment.
I think I know why the dvm firmware doesn't support 11w. The firmware doesn't support install igtk hw keys.
In the current implementation, group key and the new igtk are done in software crypto in the net80211 stack for both iwn and iwm. Unicast key is handled in firmware. With this hybrid approach, we can consider the driver is MFP capable.
| @@ -384,7 +386,7 @@ ieee80211_kdf(const u_int8_t *key, size_t key_len, const u_int8_t *label, | |||
| HMAC_SHA256_Init(&ctx, key, key_len); | |||
| iter = htole16(i); | |||
| HMAC_SHA256_Update(&ctx, (u_int8_t *)&iter, sizeof iter); | |||
| HMAC_SHA256_Update(&ctx, label, label_len); | |||
| HMAC_SHA256_Update(&ctx, label, strlen((const char*)label)); | |||
There was a problem hiding this comment.
If this is wrong, what about ieee80211_prf?
There was a problem hiding this comment.
This is one of the most confusing part. I didn't read the original 11w specification. I learnt this from reading the wpa_supplicant.
There are 2 major differences compare between HMAC-SHA1 PRF vs HMAC-SHA256 KDF/PRF.
- When using the
Pairwise key expansionlabel, there are differences counting the string length. In SHA1 PRF, the label is taken asPairwise key expansion\0. In SHA256 PRF, the label is taken asPairwise key expansion. This one-byte difference is causing incorrect key being generated. - The SHA256 KDF is also taken the number of output bits as part of its data, where the SHA1 PRF doesn't. This make difference since SHA256 KDF is expecting the output PTK to be 48 bytes, the previous code is passing as 64 bytes. Note, this PTK length should also depend on the cipher chosen.
|
Well, I believe you are right, I compiled here for those people who want to test, and my internal group members may also test it. I will test it later(maybe one or few weeks, sorry for my busy work and life). @pigworlds BTW, can you port this change back to OpenBSD team? I think they will interest on it. |
|
@pigworlds Hi, Finally I have test environment. I am using ac7260 and openwrt with raspberry pi. |
This is an interesting combination with ac7260 and rpi. I'll take a while to replicate your setup. I think the rpi is using broadcom's wifi chip. Will you able to connect to the access point using other devices? From the logs, it appears the driver received 4way_msg3 and is rejecting it by deauth. This can happen either I am unable to access the airportitlwm.log. Is it working or not working in the airport version? I'd like to see it because there might have difference between Apple's RSN supplicant and OpenBSD's one. |
Yes, It is Broadcom chip, rpi model 3B, I am also wondering if it is a Broadcom driver issue on OpenWrt.
Tested with Android phone, Ubuntu 21.04 they all failed, only succeed on Windows 10.
It behaves the same, different IE caused the key negotiations failed, but if I turn off What's your card model of the targeting AP machine? |
My main AP is this below
The R7800 is using I have another |
|
@pigworlds I will try another machine with Atheros/Intel cards to test again later. |
I got my rpi 3b openwrt setup and have exactly the same IE_DIFFERENT issue. It is odd only Windows can connect. Looking at raspberrypi/linux#3619, it appears even rpi4 doesn't have the built-in MFP support today. In order to get MFP on rpi4, you need the latest firmware from broadcom/cypress and apply a patch set to the kernel/wpa_supplicant to support MFP. This might work on rpi3 but I haven't got chance to try it. |
|
People using Xiaomi ax6000 and TPLink which enables 11w as optional by default, this patch seems to works fine. |
|
This is a great news. |
|
Hi @pigworlds Thanks again for the contribution. I finally got some time to test this PR. Here's my setup: APs:
Clients:
Driver:
Using the setup above, I was able to connect to the APs with With brcmfmac, it sometimes takes a few tries to reconnect, other times I had to restart hostapd (The fimware itlwm uses also crashes during assoc in this case). With iwlwifi, if itlwm manages to trigger a firmware crash on the AP (yes, the firmware used by iwlwifi crashes), the AP can be reconnected at itlwm's second attempt (1st attempt fails with a association timeout since the AP just crashed). For comparison, both the iPad and the phone can connect and reconnect to the same AP with I also took a chance and compared 11w and SAE support on other platforms. Only did a few rounds and data may likely contain errors, will redo everything when I have time.
|
|
Hi @williambj1 Thanks a lot looking into this! Glad you got an RPi4 setup to support PMF :-) A couple of notes:
From what I see, when you disconnect from the current network, the itlwm driver doesn't send deauth/disassoc frame to AP. It transitions to SCAN state if I recall correctly. I think this is can explain many of the behaviors you see. When PMF is disabled on the AP, AP allow the station to leave without deauth and join again immediately. This is why it works currently. When PMF is enabled on the AP, it is expecting the station to send encrypted deauth frame to AP before it is leaving the network. When the station doesn't send deauth frame, AP would send SA query to the station to check if it is still alive, in this case the driver won't answer. Or it waits the SA query timeout occurred before allow the same station to join again. This is why you see unable to reconnect in the second time after sleep/disconnect. You could retry after a minute. You could probably see the deauth error code from either the driver logs, or the AP logs. In some case if firmware crash or hostapd crash on AP, it may reset the SA and allow the station to join.
I noticed some odd behaviors in Windows as well. It seems the WiFi profile is associated with the WPA version and don't like to mix WPA2/WPA3. If you use the same SSID name, switch from WPA2 to WPA3 or from WPA3 to WPA2, Windows isn't happy with it. You could try to create different SSID, one for WPA2, one for WPA3. Windows should able to connected to WPA3 AP.
It looks like you got a lot of fun making firmware crash ;-) I will probably scratch my head and no clue about the crash. You can still share the crash logs in case it helps.
Many thanks again! |
Thank you for remind me and pointed out the bug, I also noticed the behavior long time ago, driver will receive DEAUTH frame from the old AP after switching to the another AP for a while, maybe I can try to fix it. |
Add 11w protected management frames support to
iwnandiwm. Doesn't supportiwxyet.IGTK is installed using sw crypto. It appears
iwxis using hw crypto. I don't have card usingiwx, so I haven't enabled IEEE80211_C_MFP for it. Hope this doesn't break anything.Add support for WPA HMAC-SHA256 in AirportItlwm and itlwm.
There are bug fixes in the ieee80211_kdf which calculated the wrong key when used for WPA HMAC-SHA256.
I've tested this change using AC 9560, N 6205, and targeting AP running OpenWrt 21.02.0. The Encryption is set to WPA2-PSK/WPA3-SAE mixed mode. The 802.11w Management Frame Protection is set to Optional or Required.