Hello,
recently we faced an issue with the wpa_supplicant during rekeying.
In a wireshark trace we noticed that in an EAP-PEAP session the 4/4 frame of
the 4-way handshake was sent unencrypted. In the debug messages we saw
the following message:
nl80211: Send over control port dest=xxxx proto=0x888e len=99 no_encrypt=1
which then led us to the following section of code. We are using the
nl80211/mac80211 drivers which having WPA_DRIVER_FLAGS_CONTROL_PORT
set in recent kernels. So during rekeying the new PTK is not yet installed leading
to the 4/4 frame being unencrypted. However, after some discussion in the kernel
wireless mailinglist, this seems to be wrong as the frame should be encrypted
using the old PTK. So we assume this is a bug in the wpa_supplicant. What's
your impression?
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;
}
Just as side note, some APs will reject the unencrypted frame with a
4WAY_HANDSHAKE_TIMEOUT leading to a completely new authentication.
And as temporary workaround control_port can be disabled in the supplicant conf.
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
