On 13 09:35:13, Johannes Berg wrote: > On Fri, 2025-05-09 at 22:42 +0200, Jan Hendrik Farr wrote: > > > Could you do trace and sniffer at the same time? According to the trace > > > there was no authentication frame from the AP. In the sniffer capture it > > > _is_ there, of course, but I'd like to look at the timing. > > > > > > Ok, I did another capture. > > > > 1. iwd only knows credentials for a single SSID: kepler_test > > 2. kepler_test is the only SSID broadcasting on 6GHz channel 37 (or any > > 6GHz channel) > > 3. I captured 802.11 frames using a second device > > 4. I did a trace on the client in question > > 5. I captured dmesg and iwd logs > > 6. All captures were done simultaneously > > > > I'm confused now, this all looks fine from a driver perspective. > > We send SAE commit, receive SAE commit, send SAE confirm, never receive > a response. There's no response in sniffer nor tracing data, so that > matches up. There are a couple of retries of the confirm response, but > that seems OK. There is a an SAE confirm sent by the AP. It's frame 170 in capture2.pcapng. It's also retried a number of times after that. There is however no ACK from the client in response to it and it also never shows up in iwd. The SAE confirm by the AP (frame 170) is before the SAE confirm by the STA (frame 174) however. In all cases where the connection actually works (maybe every 10th attempt or so) this happens to be in the opposite order (first SAE confirm by the STA, then SAE confirm by the AP). This is making me think that the order is causing this issue somewhere in the stack. The spec [1] seems to allow the SAE confirms to come in any order. 12.4.5.1 says that "[a] party confirms after it has committed and its peer has committed". So the AP does not have to wait for the confrim from STA before sending it's own confirm. [1] https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7786995 Best Regards Jan > > Seems like maybe iwd builds an SAE confirm that the AP doesn't like, try > wpa_supplicant I guess. > > johannes
