On Tue, Mar 29, 2022 at 03:23:18PM -0700, James Prestwood wrote: > I have observed some behavior related to OWE where hostapd and the > station cannot connect if the associate request ACK is never received > by the station: > > 1. Station sends Association request > 2. Hostapd receives this, derives its side of the keys and replies > 3. Station never receives an ACK from the association request, kernel > retransmits. Just to be clear here.. What you describe here is not the link layer retransmission of the frame which happens when the ACK frame is not received, but a transmission of a completely new Association Request frame. Those are two very different things, i.e., the former would have been dropped as a duplicate frame while the latter results in this issue. IMHO, the main issue is indeed here, i.e., the kernel should not have sent a new Association Request frame (a different sequence number, not the link layer retransmission done by the hardware/firmware) in this type of a case where there is potentially changing keying material in the frame. We have had similar issues with mac80211 and SAE authentication and the best way to avoid these is to prevent mac80211 from doing those retries on its own. > 4. Hostapd receives the retransmit, treats it as a new association and > re-derives the keys. This "retransmit" is the second Association Request frame, i.e., not just a link layer retransmission of the first one due to missing ACK frame. This is supposed to be processed as a new association and yes, in the case of OWE, it would indeed result in going through DH processing again. > 5. Station gets hostapd's first Association response via CMD_CONNECT, > unknown what ever happened to the second association response, likely > dropped by the kernel since it already sent CMD_CONNECT to userspace. This would be fixed by removing that mac80211 retry-with-new-frame behavior for OWE. > 6. Now the STA derives its keys based on hostapd's first association > response, and hostapd derived its keys based on its second. This > results in the 4-way failing. While obviously undesired, this is the expected behavior in this type of a sequence.. > I can think of only two possible ways to fix this: > > a) Have the kernel tell userspace of the retransmit, and of a new > association response (an additional CMD_CONNECT event?). This assumes > the second response actually made it and wasn't lost. This would end up > being quite a burden on both the kernel and userspace to handle this > case. Better would be... I don't think I would call this a fix, but more like a way of hiding the real issue (that mac80211-generated retransmit). While this is really a two completely distinct association attempts and as such, would need two CONNECT events, this looks quite strange from the view point of having only a single CONNECT command going to the kernel. Furthermore, there would be a race condition on finding out when the "correct" CONNECT event is received. > b) Have hostapd treat additional association requests as retransmits. > For OWE specifically you can all but guarantee it was a retransmit if > the DH IE is identical. This is not a fix either, but a workaround for badly behaving stations. It might be justifiable to do this anyway, though, if there is a significant number of deployed station devices that support OWE with this incorrect behavior. But the real fix is: c) Stop mac80211 from sending OWE (Re)Association Request frame retries with new frames (different seq#). > I can't seem to find anything in 802.11 about retransmitting management > frames, so hostapd isn't doing anything wrong as far as the spec is > concerned... But I think the behavior could be improved by treating > identical associate requests as retransmits. This is not IEEE 802.11 retransmission (those link level retries which maintain the same seq#) but two distinct association attempts as far as the standard is concerned. That should not be done and instead, the retries should depend on the real link layer retries that have a clearly defined duplicate detection mechanism that prevent this type of issues. If the station wants to try to associate again, it can certainly do so even if it were pretty pointless in this case, but the current Linux kernel interface does not handle it correctly. Such two attempts of association should result in two reports of the result to the user space. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
