Hi Ben,
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
lots
of vdevs and thus the NIC is busy), the keys are set before the EAPOL
4/4
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
appropriately.
Regardless of the solution, we're happy to help in order to get this fixed.
Regards,
-Denis
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
