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

Krishna Chaitanya chaitanya.mgit at gmail.com
Sun Sep 1 08:20:48 PDT 2019


On Sun, Sep 1, 2019 at 4:15 PM Alexander Wetzel
<alexander at wetzel-home.de> wrote:
>
>
> >> 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.
>
I agree using that option to bypass QDISC is a definite improvment.



More information about the Hostap mailing list