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.
Alexander
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
