PTK0 Rekeying Problems

For Developers
1

I am working with WPA2 Enterprise and the Archer C7, Archer A7 and Armor Z2.

It appears reasonably well known that PTK0 rekeying is broken on these devices and doesn't always work, so I have set:

        option eap_reauth_period '0'

in /etc/config/wireless to disable the rekeying. So far so good, but unfortunately I have recently noticed that the iPhoneX still requests a PTK0 rekey, which results in the iPhoneX having an unstable connection.

Having searched around it would appear that the next suggestion is to use the option wpa_deny_ptk0_rekey and set it to 2 which results in a PTK0 being turned into a disconnect. You can't set this option in /etc/config/wireless because it isn't passed on to the config file used by hostapd, but I managed to work around that.

So far so good, but having changed the configuration to disconnect any device that tries to do a PTK0 rekey I have found a Windows PC that is completely unable to the network, in this case I get the following log messages ...

Thu Jul 23 08:37:28 2020 daemon.info hostapd: wlan-5g: STA 28:7f:cf:ee:fb:65 IEEE 802.11: authenticated
Thu Jul 23 08:37:28 2020 daemon.info hostapd: wlan-5g: STA 28:7f:cf:ee:fb:65 IEEE 802.11: associated (aid 1)
Thu Jul 23 08:37:28 2020 daemon.notice hostapd: wlan-2g: Prune association for 28:7f:cf:ee:fb:65
Thu Jul 23 08:37:28 2020 daemon.notice hostapd: wlan-5g: CTRL-EVENT-EAP-STARTED 28:7f:cf:ee:fb:65
Thu Jul 23 08:37:28 2020 daemon.notice hostapd: wlan-5g: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
Thu Jul 23 08:37:28 2020 daemon.notice hostapd: WPA: PTK0 rekey not allowed, disconnect 28:7f:cf:ee:fb:65
Thu Jul 23 08:37:33 2020 daemon.info hostapd: wlan-5g: STA 28:7f:cf:ee:fb:65 IEEE 802.11: deauthenticated due to local deauth request
Thu Jul 23 08:37:58 2020 daemon.info hostapd: wlan-2g: STA 28:7f:cf:ee:fb:65 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Thu Jul 23 08:38:28 2020 daemon.info hostapd: wlan-5g: STA 28:7f:cf:ee:fb:65 IEEE 802.11: authenticated
Thu Jul 23 08:38:28 2020 daemon.info hostapd: wlan-5g: STA 28:7f:cf:ee:fb:65 IEEE 802.11: associated (aid 1)
Thu Jul 23 08:38:28 2020 daemon.notice hostapd: wlan-5g: CTRL-EVENT-EAP-STARTED 28:7f:cf:ee:fb:65
Thu Jul 23 08:38:28 2020 daemon.notice hostapd: wlan-5g: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
Thu Jul 23 08:38:28 2020 daemon.notice hostapd: WPA: PTK0 rekey not allowed, disconnect 28:7f:cf:ee:fb:65
Thu Jul 23 08:38:28 2020 daemon.info hostapd: wlan-2g: STA 28:7f:cf:ee:fb:65 IEEE 802.11: authenticated
Thu Jul 23 08:38:28 2020 daemon.info hostapd: wlan-2g: STA 28:7f:cf:ee:fb:65 IEEE 802.11: associated (aid 5)
Thu Jul 23 08:38:28 2020 daemon.notice hostapd: wlan-5g: Prune association for 28:7f:cf:ee:fb:65
Thu Jul 23 08:38:28 2020 daemon.notice hostapd: wlan-2g: CTRL-EVENT-EAP-STARTED 28:7f:cf:ee:fb:65
Thu Jul 23 08:38:28 2020 daemon.notice hostapd: wlan-2g: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
Thu Jul 23 08:38:28 2020 daemon.notice hostapd: WPA: PTK0 rekey not allowed, disconnect 28:7f:cf:ee:fb:65
Thu Jul 23 08:38:30 2020 daemon.info hostapd: wlan-5g: STA 28:7f:cf:ee:fb:65 IEEE 802.11: authenticated
Thu Jul 23 08:38:30 2020 daemon.info hostapd: wlan-5g: STA 28:7f:cf:ee:fb:65 IEEE 802.11: associated (aid 1)
Thu Jul 23 08:38:30 2020 daemon.notice hostapd: wlan-2g: Prune association for 28:7f:cf:ee:fb:65
Thu Jul 23 08:38:30 2020 daemon.notice hostapd: wlan-5g: CTRL-EVENT-EAP-STARTED 28:7f:cf:ee:fb:65
Thu Jul 23 08:38:30 2020 daemon.notice hostapd: wlan-5g: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
Thu Jul 23 08:38:30 2020 daemon.notice hostapd: WPA: PTK0 rekey not allowed, disconnect 28:7f:cf:ee:fb:65
Thu Jul 23 08:38:33 2020 daemon.info hostapd: wlan-2g: STA 28:7f:cf:ee:fb:65 IEEE 802.11: authenticated
Thu Jul 23 08:38:33 2020 daemon.info hostapd: wlan-2g: STA 28:7f:cf:ee:fb:65 IEEE 802.11: associated (aid 5)
Thu Jul 23 08:38:33 2020 daemon.notice hostapd: wlan-5g: Prune association for 28:7f:cf:ee:fb:65
Thu Jul 23 08:38:33 2020 daemon.notice hostapd: wlan-2g: CTRL-EVENT-EAP-STARTED 28:7f:cf:ee:fb:65
Thu Jul 23 08:38:33 2020 daemon.notice hostapd: wlan-2g: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
Thu Jul 23 08:38:33 2020 daemon.notice hostapd: WPA: PTK0 rekey not allowed, disconnect 28:7f:cf:ee:fb:65
Thu Jul 23 08:38:34 2020 daemon.info hostapd: wlan-2g: STA 28:7f:cf:ee:fb:65 IEEE 802.11: authenticated
Thu Jul 23 08:38:34 2020 daemon.info hostapd: wlan-2g: STA 28:7f:cf:ee:fb:65 IEEE 802.11: associated (aid 5)
Thu Jul 23 08:38:34 2020 daemon.notice hostapd: wlan-5g: Prune association for 28:7f:cf:ee:fb:65
Thu Jul 23 08:38:34 2020 daemon.notice hostapd: wlan-2g: CTRL-EVENT-EAP-STARTED 28:7f:cf:ee:fb:65
Thu Jul 23 08:38:34 2020 daemon.notice hostapd: wlan-2g: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
Thu Jul 23 08:38:34 2020 daemon.notice hostapd: WPA: PTK0 rekey not allowed, disconnect 28:7f:cf:ee:fb:65

It appears that this particular device wants to rekey immediately upon connection and the refusal to accept that rekey prevents any connection at all.

Disconnecting all rekeys doesn't seem like a great solution in the first place, but perhaps we need to allow rekeys during the first few seconds of a connection?

2

I don't like adding yet another workaround.
Where do we stop? With a config file telling how to handle each and every MAC on rekey?

But here we have a comparable simple solution and should not need any workarounds, just more recent code and your router(s) can rekey:

The ath9k driver does not really need any change to fix PTK0 rekeys, only a mac80211 module from kernel 4.20 or newer. (You will always get warnings that these may not work but for the ath9k driver that message can be ignored).

So any mac80211 version >=4.20 or applying this patchset must work: PTK0 rekey patch set
Since the git master has a fixed mac80211 version since ages you can also simply try that.
(It may also be time to get these fixes into the stable version, too...)

Disabling HW crypto on the router also bypasses the problems, but that will hurt throughput quite hard. So it's probably only something for some quick tests to confirm that the devices where you can't disable PTK0 rekey are itself able to do so.

3

You are of course right. Shortly after sending my email I realised I
had 4.19 on three of my 6 routers and I read something on-line which
said it was fixed in 4.20. I subsequently replaced the kernel on those
routers with 5.4.52 and the problem vanished. I should probably have
replied to say I had worked out the problem, but as nobody replied I let
sleeping dogs lie.

Thanks,
Michael