> > > > 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 I guess you were on the right track. For now we disabled the control_port via driver option in the supplicant conf, because the wpa_s logs were pointing to that and now the 4/4 frame of the 4-way handshake is encrypted as expected. Looking to the supplicant the problematic code is in the following function. When WPA_DRIVER_FLAGS_CONTROL_PORT is set, during rekeying at the time of frame 4/4 the (new) PTK is not yet installed and therefore, leading to the frame being unencrypted. The additional check for PTK being installed is probably to prevent some race conditions. At least that's what I think after reading the commit messages of when control port was introduced. int wpa_ether_send(struct wpa_supplicant *wpa_s, const u8 *dest, u16 proto, const u8 *buf, size_t len) { [...] if (wpa_s->drv_flags & WPA_DRIVER_FLAGS_CONTROL_PORT) { int encrypt = wpa_s->wpa && wpa_sm_has_ptk_installed(wpa_s->wpa); return wpa_drv_tx_control_port(wpa_s, dest, proto, buf, len, !encrypt); } if (wpa_s->l2) { return l2_packet_send(wpa_s->l2, dest, proto, buf, len); } return -1; } Currently I don't really get the relation of PTK of the 4-way handshake and the PEAP session key of the TLS handshake. Latter encryption should be applied independently of the PTK being installed or not or am I wrong? Searching in the IEEE802.11 standard didn't help me to find an answer to that question. So I'd assume there's a bug in the wpa_supplicant or what's your impression? Or is disabling of control_port already considered as a proper solution?