[PATCH] wpa_supplicant: Send EAPoL-Key frames over NL80211 where available
alexander at wetzel-home.de
Sun Sep 1 03:45:01 PDT 2019
>> Normally there are next no buffers in the tx path. When you hand over a
>> frame to the kernel it's - according what I remember when investigating
>> the issue - an atomic operation till the skb reaches mac80211 or
>> whatever other driver we use. And the few "buffers" we have are fully
>> driver controlled and we basically can just make sure those are flushed
>> when we replace the key. The only potential issue I see are traffic
>> shapers but then I think I eapol frames bypass them already.
> the issue of race b/w set_key and send_m4 probably caused the delays in
> socket_queues/QDISC for M4, can you please elaborate on how EAPoL
> bypasses QDISC?
> I don't see PACKET_QDISC_BYPASS being set for l2_packet_send.
I had some hope that eapol packets would have a build in fast lane but
you are right: They get added to the QDISC queue and processed like any
But why do we not just set PACKET_QDISC_BYPASS for eapol frames?
Just tried it and it seems to work as it should: fine.
We could allow this setsockopt() call to fail, so all kernels < 3.14
would continue to push the eapol packets through the QDISC. But starting
with 3.14 drivers flushing their queues prior to deleting a key can be
sure the eapol frame has been send.
The only potential down side I can find is the - required - lack of
buffers. The driver could therefore refuse to accept the eapol packet
which should cause a disconnect instead a queued and later send eapol frame.
Using the control port for eapol would of course still better, but using
PACKET_QDISC_BYPASS when this is not working looks like a good fallback
and an improvement compared to as things are today.
More information about the Hostap