On Wed, 2023-01-18 at 09:54 -0800, James Prestwood wrote: > > > > Basically I don't understand why userspace expects some event. It > > asked > > for authentication, and you got it. That's all. I don't see userspace > > asking for association, or anything else, so what would it be waiting > > for? > > I should have explained this better. I dug up the old thread from the > original report and IIRC this is the sequence of events: > > 1. Begin reassociation to new BSS via CMD_CONNECT. > Oh, CMD_CONNECT, OK. > This results in the > kernel sending many events to remove the current BSS in favor of the > new one: > > 2. Receive DEL_STATION, DEAUTHENTICATE, DISCONNECT, NEW_STATION So far, so good. > 3. Then a CMD_AUTHENTICATE, with a success status. Sure, that's what we see. > 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. > 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? 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). johannes
