Hello,
recently we moved from a 4.9 kernel to 5.4 kernel and observed the following issue. To rule out that the issue was already fixed we then tried it with a 6.6 kernel and observed the same issue there, too. To sum it up, the following issue can be observed with kernel 5.4 and 6.6 but not with 4.9.
We are using a Cisco AP with EWC (C9210) and EAP-PEAP as authentication method. Additionally, a session timeout is configured in the AP (300 s) after which a rekeying is taking place. So every 5 minutes a new four-way handshake is taking place which usually is completely encrypted. However, while sniffing with an external device we saw that the fourth packet of the four-way handshake is send unencrypted by our clients, when it comes to EAP-PEAP. The first three packets are encrypted as expected. In case of the Cisco AP the attempt is then rejected with a 4WAY_HANDSHAKE_TIMEOUT leading to a completely new authentication.
On our clients we are using wpa_supplicant 2.10 with the same config on all kernels and therefore would rule out an issue in the supplicant, as it is working with the same supplicant in kernel 4.9.
As driver we are using ath9k for QCA2066 (starting at kernel 4.9) and rtw88 for RTL8822CE (backported, starting at kernel 5.4). The issue exists for both drivers for kernel 5.4 and 6.6. Furthermore, we were also able to test a proprietary driver for the RTL8822CE chipset on kernel 5.4 where the issue does not appear. However, latter driver is a full-mac driver not using the mac80211 driver in comparison to the soft-mac drivers of the mainline. Considering all the details we highly assume that the issue is to be found in the mac80211 driver.
Do you have some hints where to look at to solve the issue? Otherwise please let us know if we can provide some logs or config files.
Thanks in advance
Tobias Sperling
"Sperling, Tobias" <[email protected]> writes:
> Hello,
>
> recently we moved from a 4.9 kernel to 5.4 kernel and observed the
> following issue. To rule out that the issue was already fixed we then
> tried it with a 6.6 kernel and observed the same issue there, too. To
> sum it up, the following issue can be observed with kernel 5.4 and 6.6
> but not with 4.9.
>
> We are using a Cisco AP with EWC (C9210) and EAP-PEAP as
> authentication method. Additionally, a session timeout is configured
> in the AP (300 s) after which a rekeying is taking place. So every 5
> minutes a new four-way handshake is taking place which usually is
> completely encrypted. However, while sniffing with an external device
> we saw that the fourth packet of the four-way handshake is send
> unencrypted by our clients, when it comes to EAP-PEAP. The first three
> packets are encrypted as expected. In case of the Cisco AP the attempt
> is then rejected with a 4WAY_HANDSHAKE_TIMEOUT leading to a completely
> new authentication.
>
> On our clients we are using wpa_supplicant 2.10 with the same config
> on all kernels and therefore would rule out an issue in the
> supplicant, as it is working with the same supplicant in kernel 4.9.
> As driver we are using ath9k for QCA2066 (starting at kernel 4.9) and
QCA2066 with ath9k? ath9k is a driver for 802.11n hardware and QCA2066
is 802.11ax generation, how would that work?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
> > Hello,
> >
> > recently we moved from a 4.9 kernel to 5.4 kernel and observed the
> > following issue. To rule out that the issue was already fixed we then
> > tried it with a 6.6 kernel and observed the same issue there, too. To
> > sum it up, the following issue can be observed with kernel 5.4 and 6.6
> > but not with 4.9.
> >
> > We are using a Cisco AP with EWC (C9210) and EAP-PEAP as
> > authentication method. Additionally, a session timeout is configured
> > in the AP (300 s) after which a rekeying is taking place. So every 5
> > minutes a new four-way handshake is taking place which usually is
> > completely encrypted. However, while sniffing with an external device
> > we saw that the fourth packet of the four-way handshake is send
> > unencrypted by our clients, when it comes to EAP-PEAP. The first three
> > packets are encrypted as expected. In case of the Cisco AP the attempt
> > is then rejected with a 4WAY_HANDSHAKE_TIMEOUT leading to a
> completely
> > new authentication.
> >
> > On our clients we are using wpa_supplicant 2.10 with the same config
> > on all kernels and therefore would rule out an issue in the
> > supplicant, as it is working with the same supplicant in kernel 4.9.
> > As driver we are using ath9k for QCA2066 (starting at kernel 4.9) and
>
> QCA2066 with ath9k? ath9k is a driver for 802.11n hardware and QCA2066
> is 802.11ax generation, how would that work?
Right, somehow I collected the wrong info for the ath9k driven device. Sorry
about that. It's an AR958x adapter for the ath9k driver.
On Mon, 2024-06-10 at 13:50 +0000, Sperling, Tobias wrote:
>
> recently we moved from a 4.9 kernel to 5.4 kernel
????️
> Do you have some hints where to look at to solve the issue?
No, way too old.
Take a look at supplicant logs in how it behaves differently, I guess.
The only thing that comes to mind is that *maybe* the eapol-over-nl80211
path gets used (different kernels) and that has different behaviour in
wpa_s, but honestly, no idea.
johannes
> > recently we moved from a 4.9 kernel to 5.4 kernel
>
> ????️
:D
>
> > Do you have some hints where to look at to solve the issue?
>
> No, way too old.
That's why we also tried it with kernel 6.6, where we faced the same issue. So I'd
appreciate hints for kernel 6.6 (or probably later), too. :)
>
> Take a look at supplicant logs in how it behaves differently, I guess.
>
> The only thing that comes to mind is that *maybe* the eapol-over-nl80211
> path gets used (different kernels) and that has different behaviour in
> wpa_s, but honestly, no idea.
Thanks, will have a look there.
>
> johannes
On Tue, 2024-06-11 at 12:36 +0000, Sperling, Tobias wrote:
> > > recently we moved from a 4.9 kernel to 5.4 kernel
> >
> > ????️
>
> :D
> >
> > > Do you have some hints where to look at to solve the issue?
> >
> > No, way too old.
>
> That's why we also tried it with kernel 6.6, where we faced the same issue. So I'd
> appreciate hints for kernel 6.6 (or probably later), too. :)
Yeah but even moving 4.9->6.6 is a huge range, even bigger :)
> > Take a look at supplicant logs in how it behaves differently, I guess.
> >
> > The only thing that comes to mind is that *maybe* the eapol-over-nl80211
> > path gets used (different kernels) and that has different behaviour in
> > wpa_s, but honestly, no idea.
>
> Thanks, will have a look there.
I would certainly hope that wpa_s uses that path on the new kernel. It
wasn't in 4.9, pretty sure.
johannes
>