On Wed, 2023-01-18 at 19:08 +0100, Johannes Berg wrote: > On Wed, 2023-01-18 at 09:54 -0800, James Prestwood wrote: > > > <snip> > > > 4. At this point the firmware decides its not gonna continue and > > calls > > __ieee80211_disconnect which is a no-op when not associated. > > > > This is also completely irrelevant to the state. The firmware doesn't > "decide not to continue". Something else already decided it doesn't > want > to continue. This is entirely driven from the top - be it the > net/wireless/sme.c for CMD_CONNECT, or userspace for CMD_AUTHENTICATE > and CMD_ASSOCIATE. Well, we see this: iwlwifi 0000:00:14.3: Not associated and the session protection is over already... So _something_ happens in the driver/firmware causing this event to be generated, thats all I'm saying. But yes, it really doesn't matter why but rather how mac80211 handles it. > > > We assumed > > either CMD_ASSOCIATE or CMD_CONNECT will come after > > CMD_AUTHENTICATE, > > or a CMD_DEAUTH if there was a problem. > > Yeah for CMD_CONNECT I guess that's reasonable. In fact you really > shouldn't even look at the authenticate/associate even in these cases > since they're not guaranteed (e.g. if you have a fullmac device), > they > only happen as a consequence of the mac80211 implementation, not by > design. > > So I think you're just looking in the wrong place - the real question > is > why the association sequence in net/wireless/sme.c doesn't continue > (or > abort) at this point? I think I narrowed down this "why" pretty well. A connection loss event happens between a successful authentication but before association. Since __ieee80211_disconnect does not take this state into account the kernel haults the reassociation and never informs userspace. Maybe my solution/fix is incorrect, but its at least a starting point. > > The whole "firmware event" thing is completely incidental and an > implementation detail. The firmware decides nothing. All that happens > here is that the firmware decided to no longer wait for the > association > to happen (but that wasn't even started), and a driver bug that > basically just prints the wrong message - it says it's expecting to > be > associated but it can't actually expect that since we never even > transmitted an association request. > > > I will say, we do see a CMD_DEL_STATION event here which we never > > processed in this case. > > And you probably shouldn't anyway, again more of an implementation > detail, not really by design. > > > But again, I would expect a CMD_DEAUTHENTICATE > > since we successfully authenticated, right? > > No, you can't expect that, you could be authenticated with the AP for > an > indefinite amount of time, or never hear the deauth frame (if it ever > sends one). Ok, so at least a CMD_CONNECT event right? Maybe I'm giving nl80211 too much credit, but the CMD_AUTH/ASSOC/CONNECT APIs have always seemed symmetric in terms of events, in that if you issue one of these commands you will get an event in return. So I would expect CMD_CONNECT to generate a CMD_CONNECT event. > > johannes
