Hi Johannes,
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.
Do you have any thoughts on what the operations should look like or do
you want me to take a stab in the dark at this?
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.
Fair enough, but at least the kernel can do its best to make sure that
such races do not manifest themselves out into userspace. E.g. making
sure that PAE events arrive after the connect events, etc.
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.
Makes sense. Should PAE packets always be sent unencrypted? Or should
userspace be notified whether PAE was received unencrypted and send a
response with the same flag?
Also, while we're on this subject. Should the kernel auto-manage the
LINKMODE and OPERSTATE flags? It would seem that it already has the
information to do so, and having userspace manage this just introduces
another source of latency / possibility of race conditions, etc.
Regards,
-Denis
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
