On 06/09/2017 12:28 AM, Johannes Berg wrote:
On Thu, 2017-06-08 at 19:07 -0500, Denis Kenzior wrote:
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.
Correct.
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 :)
We've actually discussed doing precisely this, for - among other things
- this reason. Just nobody stepped up yet to propose the necessary APIs
and do the remaining work to use it etc.
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.
That's actually possible today, with the wifi-ack sockopt. It's not
really a full solution though I think, there are other issues to solve.
We also discussed this at the last workshop, IIRC.
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.
That's actually not possible, since ordering set_key operations vs.
transmitted packets isn't something that's easily done by drivers.
However, the solution is far simpler! Once you have nl80211 PAE
transport, you can easily even set the key before transmitting the
packet and simply indicate that this particular packet should _not_ be
encrypted regardless of key presence.
My ath10k firmware cannot deal with a case like this:
pkt is enqueued before key is set
key is set
pkt is transmitted (incorrectly)
This is because of how the tid's header-length variables are set up and modified
when the keys are set, and I don't see any good way to fix this.
Stock ath10k firmware goes to great lengths to parse EAPOL frames and try to work around
it in that manner, but that breaks .11r (or used to, I haven't tried stock firmware lately)
and adds more complexity to the code.
From a patch someone sent to hostapd list last night, it seems we could get the tx-status for
the EAPOL 4/4, and in that case, we *know* the pkt has been transmitted, so we can then
set the key safely it would seem?
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
