Hi Johannes,
On 09/14/2017 01:36 PM, Johannes Berg wrote:
Hi Denis,
I'd actually only Cc'ed you to see if you were actually working on
EAPOL-over-nl80211 :-)
Curious, isn't sending a PMKID for a non-roaming case not strictly
per spec? Is this just to avoid running 802.1x?
I don't think so, what makes you? In -2016 9.4.2.25.5 for example, the
spec says:
The PMKID Count and List fields are used only in the RSNE in the
(Re)Association Request frame to an AP and in FT authentication
sequence frames.
Why should it only be valid in roaming? You might turn off and on wifi
and still have a PMKSA.
Yep, but I seem to recall there was some vague language that said the AP
would delete the PMKSA if the client disconnected. Sorry, getting back
on track:
How does this mesh with operstates outlined in
Documentation/networking/operstates.txt? Are you treating the
'roaming' case as 802.1x 'reauthentication'?
I think we have to, because otherwise DHCP/IPv6 could happen again
after roaming - we really can't set the oper state to dormant during
the roaming.
Okay, I can buy this interpretation...
Assuming this assessment is correct, this opens up another
possibility:
tracking the PORT_AUTHORIZED state with a separate event:
* new connection case - no PMKSA (usage)
- CONNECT event
- [if !eapol-over-nl: toggle oper state up]
Doesn't this go against operstates.txt, Section 4?
Why?
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?
Also, I must be dense, but why is the behavior different between
eapol-over-nl and not?
Because for EAPOL-over-data, we actually have to have IF_OPER_UP to be
able to TX/RX the EAPOL frames.
Okay. But then wouldn't userspace now have to deal with two different
behaviors now?
- 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 ..?
* new connection case - PMKSA usage
- CONNECT event
- [if !eapol-over-nl: toggle oper state up]
- initialize 1X state machines/timeouts
- AUTHORIZED event
- stop 1X state machine/timeouts
- [if eapol-over-nl: toggle oper state up]
* roaming case - no PMKSA (usage)
- ROAM event
- [no touching oper state]
My understanding is that oper state goes back to dormant in case we
re-associate. At least we needed to set it back to UP after a fast
transition?
Like I said above, I really don't think we should/can do this, I think
we'd lose at least IPv6 connectivity in the meantime?
So I agree that OPERSTATE_UP should not change on a roam. I think we're
both in agreement here.
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.
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.
Regards,
-Denis
