Hi, > Yep, but I seem to recall there was some vague language that said the > AP would delete the PMKSA if the client disconnected. Ok, not sure about that. But even if the AP does, we could try to send it and it just can't use it :) > operstates.txt states that for new connections, operstate should be > dormant until 802.1x is complete & successful. So the !eapol-over- > nl condition would violate that, no? As I just wrote in my other email, I think I'm totally confused regarding this, and the supplicant already does it correctly - and you can ignore the whole "!eapol-over-nl" conditions, and just read it like what I thought we could only do in the eapol-over-nl case. No idea how I ended up with the idea that you could only send data frames when the netdev was IF_OPER_UP - that doesn't seem to have any basis in reality. > > > > - initialize 1X state machines/timeouts > > > > - 1X handshake > > > > - send PMK to device for 4-way-HS > > > > - AUTHORIZED event > > > > - [if eapol-over-nl: toggle oper state up] > > > > > > Given your explanation above, should this be [if !eapol-over-nl ..? > So I agree that OPERSTATE_UP should not change on a roam. I think > we're both in agreement here. Great. > My earlier point is that software roams need to have the exact same > behavior as well. And my understanding is that when we try to > Fast-Transition (e.g. issue a CMD_ASSOCIATE), operstate is no longer > UP. I'm not sure - I don't know what the state machine in wpa_s goes through here. Probably easier to test than try to reason about the code... > At the very least there's lots of confusion with what is supposed to > happen with operstate and when. So if we can work out & document a > consistent behavior, I'm all for it. :-) johannes
