itlwm Support 11w protected management frames

Add 11w protected management frames support to iwn and iwm. Doesn't support iwx yet.

IGTK is installed using sw crypto. It appears iwx is using hw crypto. I don't have card using iwx, 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.

Sep 13 '21 07:09 pigworlds

@zxystd This is a complete fix to a previous Pull Request #637.

Sep 13 '21 07:09 pigworlds

Thank you! With a fast review seems there is no problem on the code, but sorry for that I don't have time and test environment(I can't touch my OpenWRT machine) in a short term, so I just compiled this changes here to somebody who can test.

Sep 14 '21 01:09 zxystd

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). itlwm.kext.zip AirportItlwm Big Sur.zip AirportItlwm Catalina.zip AirportItlwm Monterey.zip

@pigworlds BTW, can you port this change back to OpenBSD team? I think they will interest on it.

Sep 14 '21 10:09 zxystd

@pigworlds Hi, Finally I have test environment. I am using ac7260 and openwrt with raspberry pi. Tested with itlwm.kext and it is not working properly, is there anything wrong on my test configuration? itlwm.log airportitlwm.log WiFi configuration

Nov 02 '21 13:11 zxystd

@pigworlds Hi, Finally I have test environment. I am using ac7260 and openwrt with raspberry pi. Tested with itlwm.kext and it is not working properly, is there anything wrong on my test configuration? itlwm.log airportitlwm.log

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 IEEE80211_REASON_RSN_DIFFERENT_IE or IEEE80211_REASON_BAD_PAIRWISE_CIPHER. Need to take a look to reproducing the issue. The log also shows akms=8 mean it is set to use IEEE80211_AKM_SHA256_PSK. This part seems correct.

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.

Nov 02 '21 21:11 pigworlds

I think the rpi is using broadcom's wifi chip.

Yes, It is Broadcom chip, rpi model 3B, I am also wondering if it is a Broadcom driver issue on OpenWrt.

Will you able to connect to the access point using other devices?

Tested with Android phone, Ubuntu 21.04 they all failed, only succeed on Windows 10.

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.

It behaves the same, different IE caused the key negotiations failed, but if I turn off 11w, it works. AirportItlwm.log

What's your card model of the targeting AP machine?

Nov 02 '21 23:11 zxystd

What's your card model of the targeting AP machine?

My main AP is this below


Model	Netgear Nighthawk X4S R7800
Architecture	ARMv7 Processor rev 0 (v7l)
Firmware Version	OpenWrt 21.02.0 r16279-5cc0535800 / LuCI openwrt-21.02 branch git-21.231.26241-422c175
Kernel Version	5.4.143

The R7800 is using ath10k driver.

I have another TP-Link ARCHER-A7 v5 with DD-WRT also works. It seems also using ath10k driver.

Nov 03 '21 04:11 pigworlds

@pigworlds I will try another machine with Atheros/Intel cards to test again later.

Nov 03 '21 08:11 zxystd

@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 https://github.com/raspberrypi/linux/issues/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.

Nov 04 '21 22:11 pigworlds

People using Xiaomi ax6000 and TPLink which enables 11w as optional by default, this patch seems to works fine.

Nov 10 '21 04:11 zxystd

This is a great news.

Nov 10 '21 19:11 pigworlds

Hi @pigworlds

Thanks again for the contribution. I finally got some time to test this PR. Here's my setup:

APs:

Raspberry Pi 4B
- Self compiled OpenWrt v21.02.1
  - Linux Kernel 5.4.154 (brcmfmac patched with rebased cypress patches v5.4.18-2021_0527)
  - hostapd b102f19bcc53c7f7db3951424d4d46709b4f1986 (The latest version in OpenWrt's source tree, merged with cypress' patch v5.10.9-2021_1020. The one shipped in v21.02.1 can't create 5GHz hotspots)
  - Cypress firmware from v5.10.9-2021_1020
Intel 9260NGW (iwm)
- Original OpenWrt v21.02.1
  - iwlwifi and firmware installed from opkg
  - hostapd-OpenSSL installed from opkg

Clients:

Intel 9560NGW (iwm)
iPad Air 3 (iPadOS 14.8.1)
Xiaomi 6 (Lineage OS 18.1, rooted)

Driver:

itlwm with code in the PR merged into the master branch 43e1209985f6c0413b6920f1cdf68c5e29daa9cc. The airport version for Monterey is used during the tests.

Using the setup above, I was able to connect to the APs with ieee80211w=2 when they are enabled for the first time. However, itlwm almost always fails to reconnect to the AP (wake from sleep or manually disconnect and reconnect).

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 ieee80211w=2, the firmware used by 9260 and iwlwifi doesn't crash.

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.

Client	9560NGW (AirportItlwm with PR)	9560NGW (Ubuntu 21.10)	9560NGW (Windows 10)	iPad Air 3	Xiaomi 6
WPA2 Only + 11w=0	Y	Y	Y	Y	Y
WPA2 Only + 11w=1	Y	Y	Y	Y	Y
WPA2 Only + 11w=2	Y	N	Y	Y	Y
WPA2/3 + 11w=0	Y	Y	Y	Y	Y
WPA2/3 + 11w=1	Y	Y	Y	Y	Y
WPA2/3 + 11w=2	Y	N	Y	Y	Y
WPA3 Only + 11w=0	N	N	N	N	N
WPA3 Only + 11w=1	N	Y	N	Y	Y
WPA3 Only + 11w=2	N	N	N	Y	Y

Looks like WPA3 support is completely broken in Windows? Did reinstall the latest drivers from Intel.
Can't connect to 11w=2 on Ubuntu, more tests needed.
WPA3 Only with 11w=0 seems to be an invalid combination.

Jan 24 '22 13:01 williambj1

Hi @williambj1 Thanks a lot looking into this!

Glad you got an RPi4 setup to support PMF :-)

A couple of notes:

Using the setup above, I was able to connect to the APs with ieee80211w=2 when they are enabled for the first time. However, itlwm almost always fails to reconnect to the AP (wake from sleep or manually disconnect and reconnect).

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.

Looks like WPA3 support is completely broken in Windows? Did reinstall the latest drivers from Intel.

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. You could also delete the wireless network profile before switch from WPA2 to WPA3 on Windows if you want to keep the same SSID.

The fimware itlwm uses also crashes during assoc in this case the firmware used by iwlwifi crashes

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.

There is one change https://github.com/OpenIntelWireless/itlwm/commit/2156b3dec670da4b7076d4f4f84319110efa403f that disables MFP in the Airport driver. May be this PR need a bit rework to enable the MFP bit for the capability negotiation.
Regarding WPA3 support, because the handshake is done at the higher layer, I naively think this can be easily supported at one point. Later I found this is not the case.
I found the Apple's supplicant doesn't support WPA3. You can't enable some bits to let Airport to do the WPA3 handshake for you. The WPA3 handshake depend on large chunk of ECC/DragonFly computation that is not a good idea to bring into kernel mode. It make sense to follows the wpa_supplicant model and bring the handshake to user mode, although this won't work with Airport integration. The WPA3 handshake is happening before association and 4-way handshake. The state machine in the 80211 stack need some changes to support this.
I think OpenBSD is in the same boat. I would wait for those smart devs to figure out their way to support WPA3.

Many thanks again!

Jan 25 '22 06:01 pigworlds

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.

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.

Jan 25 '22 06:01 zxystd