On Sun, Dec 29, 2019 at 7:10 PM Alexander Wetzel <alexander@xxxxxxxxxxxxxx> wrote: > > > 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)? > > > > First, I do not think the patch should be merged as it is. PTK rekeying > is at the moment mostly broken and this patch is just replacing one > broken solution with a less broken one. I was hoping for some discussion > here how to generally handle that. That did not happen so far. > > Second, I'll soon have a quite radical patch ready to address the PTK > rekey issues with what seems to be the only solution: Make rekeying > optional and use reconnects by default as replacement. There are just > too many broken implementations in the wild which in at least one case > enable plain text attacks on the outgoing PTK: Ath9k with mac80211 from > a kernel < 4.20 can repeat lost MPDUs but skips the encryption... > Generally all cards using HW crypto and mac80211 likely have some issues > with a kernel 4.20, which more or less added proper rekey support, > handling the corner cases. (ath10k is the known exception so far.) > But quite many authors seem to have missed at least some of the corner > cases PTK rekeying with only keyid 0 has I invite anyone believing that > rekey is working in his setup to set the rekey intervall to 30s and try > a download. Even with an AP able to handle that error free many devices > - probably most if my samples are representative - will have have > issues. Most common are download aborts, caused to to a reconnect due to > an error during rekeying. Making that to the default action and allow > users knowing what they do to override it seems to be the best way out > of the PTK rekey mess. > > But pack to this patch here: > The patch would disconnect a STA when the socket refuse to accept the > MPDU. Now the easy fix would be to simply ignore send errors and trust > that one of the retransmits will be accepted and can get through. > But this should only be a fallback strategy when we can't use CONTROL PORT. > > That said the current solution using QDISC is probably worse then just > hoping the HW is accepting the first send attempt. Short of a really > loaded connection the driver should be able to accept the MPDU. And when > the driver can't only the drives with special PTK rekeying hacks can > hope to rekey the PTK when we are using QDISC. > > The price of using QDISC is, that when the send call returns one skb has > probably been send out, but next to sure not our EAPOL frame we just > added at the end of the queue. Assuming die QDISC queues are filled it > may take quite some time the MPDU is OTA and has therefore a very good > chance to get encrypted with the new key. Which will never be decrypted > by the AP and also cause a disconnect. > > Setting PACKET_QDISC_BYPASS on the socket is just "jumping" QDISC. > - We lose retransmits handling when the HW is busy and not accepting > skb's. (Which is kind of dangerous to outsource in the first place) > + We get the guarantee that the skb is at least in a driver buffer when > the send call returns (instead of a QDISC bufer) > > > >> 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. > > > > Yes, but CONTROL PORT is optionally and many drivers are not > implementing it. > > >> 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). > > > > I checked the code, not the documentation. The ioctl can only return > when the skb has been either accepted by the driver or hit an error > somewhere. > > >> 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)? > > > > If nobody is else is I'll sooner or more likely later pick that up. > I just fear the final patch will be quite invasive when done proper and > is merging the eapol paths from hostapd and wpa_supplicant. Sorry, it went out of my radar, I can pick that up. This patch + flushing EAPoL in the driver rekeying works fine. > And while it should be the preferred path when available so far only > mac80211 is supporting it from the in-tree drivers. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
