Question on setting key right after the EAPOL 4/4 is sent.
denkenz at gmail.com
Thu Jun 8 17:07:11 PDT 2017
On 06/08/2017 06:43 PM, Ben Greear wrote:
> On 06/08/2017 04:36 PM, Denis Kenzior wrote:
>> Hi Ben,
>>> The problem I see is that sometimes (and quite often when I am using
>>> of vdevs and thus the NIC is busy), the keys are set before the EAPOL
>>> hits the air. When the key is set, the NIC will no longer transmit the
>>> frame because of key-length issues in the tx-descriptor (ath10k wave-2
>>> in this case).
>> We have encountered something similar. In our case we were seeing PAE
>> packets (e.g. 4WayHandshake packet 1 of 4) before seeing the connect
>> events on nl80211.
>>> I suspect that there is a fundamental race between the EAPOL packet-tx
>>> logic and the key-set logic, but supplicant appears to act as though
>>> they are natually synchronized.
>> Fundamentally there is a race between the genl/nl80211 socket to the
>> kernel and the PAE socket that handles the authentication aspects. I
>> think the only way to
>> fix this is to make sure that PAE flows over the genl/nl80211 socket
>> to preserve the proper order of events. However there are lots of
>> dragons in the kernel
>> side of this and we haven't been brave enough to venture into the
>> depths yet :)
> I think that would just push the problem lower. Probably a real fix
> would be to somehow propagate
> the tx-status for the specific packet back to the supplicant and only
> then it would know that the
> key could be set.
Having userspace track individual packets in the kernel sounds wrong to
me. This also won't help with the packets being received out-of-order.
It would be nice if both the RX and TX ordering was preserved. Hence my
thinking about running PAE over NL80211. It would then be up to the
kernel / drivers to guarantee that the various packets are ordered
Regardless of the solution, we're happy to help in order to get this fixed.
More information about the Hostap