On 23-2-2017 11:36, Arend Van Spriel wrote:
> On 22-2-2017 13:24, Jithu Jance wrote:
>> Hi Jouni, Johannes et al.,
>>
>> On Wed, Feb 22, 2017 at 1:27 AM, Arend Van Spriel
>> <arend.vanspriel@xxxxxxxxxxxx> wrote:
>>> On 21-2-2017 13:37, Johannes Berg wrote:
>>>>
>>>>> What I am also missing is how to deal with NL80211_CMD_CONNECTED
>>>>> event signalling. Should that be given after (un)successful
>>>>> completion of the 4-way handshake or should we have a separate event
>>>>> for that?
>>>>
>>>> That's a good point. I don't think a new event really works well, but
>>>> perhaps we should extend the NL80211_TIMEOUT_* values with this? It's
>>>> not strictly a timeout, I guess, but it's not a direct rejection of the
>>>> association either.
>>>>
>>>> Any thoughts?
>>>
>>> I discussed about the event mechanism with Jithu which is who asked me
>>> to look at their patches for this feature. His suggestion was to have a
>>> "port authorized" event after successful handshake as it will help in
>>> key mgmt offload cases. He gave the following example: Suppose you are
>>> doing a fresh 8021x followed by 4way handshake offload. Right now there
>>> is no event to indicate to the upper layer that the 4way handshake have
>>> been completed successfully. So the only thing to do in wpa_supplicant
>>> is to consider it completed and if not be hit with deauth.
>>
>> In wpa_supplicant terms, I was looking for an event notification to move the
>> wpa_state from WPA_ASSOCIATED to WPA_COMPLETED. :)
>
> Currently in wpa_supplicant_event_assoc() the 4-way handshake offload is
> handled as below:
>
> if ((wpa_s->drv_flags & WPA_DRIVER_FLAGS_4WAY_HANDSHAKE) &&
> wpa_key_mgmt_wpa_psk(wpa_s->key_mgmt)) {
> /*
> * We are done; the driver will take care of RSN 4-way
> * handshake.
> */
> wpa_supplicant_cancel_auth_timeout(wpa_s);
> wpa_supplicant_set_state(wpa_s, WPA_COMPLETED);
> eapol_sm_notify_portValid(wpa_s->eapol, TRUE);
> eapol_sm_notify_eap_success(wpa_s->eapol, TRUE);
> } else if ((wpa_s->drv_flags & WPA_DRIVER_FLAGS_4WAY_HANDSHAKE) &&
> wpa_key_mgmt_wpa_ieee8021x(wpa_s->key_mgmt)) {
> /*
> * The driver will take care of RSN 4-way handshake, so
> we need
> * to allow EAPOL supplicant to complete its work without
> * waiting for WPA supplicant.
> */
> eapol_sm_notify_portValid(wpa_s->eapol, TRUE);
> } else if (ft_completed) {
>
> So for 4-way hs offload for wpa/wpa2-psk it already calls
> eapol_sm_notify_eap_success() and reading the documentation of that
> function:
>
> /**
> * eapol_sm_notify_eap_success - Notification of external EAP success
> trigger
> * @sm: Pointer to EAPOL state machine allocated with eapol_sm_init()
> * @success: %TRUE = set success, %FALSE = clear success
> *
> * Notify the EAPOL state machine that external event has forced EAP
> state to
> * success (success = %TRUE). This can be cleared by setting success =
> %FALSE.
> *
> * This function is called to update EAP state when WPA-PSK key
> handshake has
> * been completed successfully since WPA-PSK does not use EAP state machine.
> */
> void eapol_sm_notify_eap_success(struct eapol_sm *sm, Boolean success)
>
> So the code in wpa_supplicant_event_assoc() is either lying or the assoc
> event should come after driver has completed successfully. To me it
> seems worth it to have NL80211_CMD_EAP_COMPLETED event carrying the
> result or indeed give the CONNECTED event later in the driver.
Ehm. Looking at the code in wpa_supplicant_event_assoc() it would be
better to use NL80211_CMD_EAPOL_PORT_VALID event to cover both
WPA/WPA2-PSK and 8021X.
Regards,
Arend
> Regards,
> Arend
>
