On Thu, Sep 12, 2019 at 09:20:02PM +0200, Alexander Wetzel wrote: > Let wpa_supplicant/hostapd generated control frames bypass the QDISC > when the linux kernel supports the feature, to make sure the frames > are reaching the driver and are not delayed or dropped by QDISC. What impact would this have on reliability of sending out the EAPOL frames in cases where there is significant traffic load on the interface? Documentation for PACKET_QDISC_BYPASS seems to imply that this option is targeted for traffic testing applications and as a side effect, this increases packet drops when transmit queues are busy. Would all those drops be frames that go through qdisc or would this also apply for the frames that go out through the socket that uses PACKET_QDISC_BYPASS (i.e., these EAPOL frames)? > This fixes a potential race when rekeying a connection under load: > Without that an EAPOL#4 frame send out by wpa_supplicant may not have > reached the driver when switching over to the new key, causing the AP to > disconnect the STA. It would seem to me that it would be better to send and receive EAPOL frames using nl80211 commands/events (i.e., same mechanism that is used to perform authentication/association and key configuration) to get matching behavior for all these management operations. > The intend of this patch is to make sure the eapol#4 frame has at least > reached the driver when we replace the key. Based on PACKET_QDISC_BYPASS documentation, I'm not convinced this "makes sure" of that.. Using nl80211 commands for sending EAPOL-Key msg 4/4 and setting the key on the other hand would make that pretty clear (or would provide clear error reporting if that is not the case). > Now this is is just the quick & easy fix to make sure EAPOL#4 is at > least in the driver queues when we replace the key, as discussed here: > http://lists.infradead.org/pipermail/hostap/2019-September/040514.html That other patch, i.e., EAPOL-over-nl80211 would seem to be a better direction to finally get working. Was anyone still working on that or can I assume that no one is going to address my comment on it (use it more consistently for all EAPOL frames rather than have a special case for EAPOL-Key)? -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
