[PATCH] wpa_supplicant: Send EAPoL-Key frames over NL80211 where available

Alexander Wetzel 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 
other packets.

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 mailing list