Clarification about p2p_states in wpa_supplicant

[Jouni Malinen]

On Wed, Feb 01, 2012 at 03:31:47AM -0800, Neeraj Kumar Garg wrote:
> 1)      Inside wpa_supplicant_scan(), we drop the sta scan if p2p is in progress. But p2p_in_progress function returns false if p2p state is P2P_PROVISIONING. There could be a LegacySTA scan going on when P2P state is in provisioning. And that will fail the p2p connection. In concurrent mode of LegacySTA and p2p, we are hitting this condition. Is it safe to generate a patch for p2p_in_progress function which returns true if p2p_state != P2P_IDLE? Or you had something else in mind as you have specifically allowed P2P_PROVISIONING state.

wpa_supplicant_scan() is used in during the P2P provisioning step, so
that change does not sound safe.. The main reason for this code is to
delay station mode scans when there could be remain-on-channel or P2P
scans (e.g., P2P Search) in progress since those share the same driver
interface, but are handled bit differently within wpa_supplicant.

Legacy STA (or well, any station-style interface) doing a scan should
not break another interface from doing a scan. Could you please provide
a wpa_supplicant debug log showing what exactly happens here in the
error case?

> 2)      There is no p2p state to take care of time between P2P_GROUP_FORMATION_SUCCESS and P2P_GROUP_STARTED at p2p client side. We are hitting one condition (very rarely) where GROUP_FORMATION_SUCCESS event comes and then supplicant gets 0 scan results [scan has been triggered for association after WPS completion], and then supplicant never initiates the association to GO. So P2P_GROUP_STARTED is never generated and a p2p interface is left behind [in case if use_p2p_group_interface=1 was used].

Hmm.. Isn't the interface left scanning at that point? I.e., it could
eventually get connected. Or are you saying that this gets somehow stuck
and the interface that does not really do anything is left behind? If
you happen to have a wpa_supplicant debug log showing this, I would like
to see some more details.

> To take care of this,  shall we introduce a time out for not getting the scan results and then informing the application/cli about P2P_GROUP_NOT_STARTED.

I did consider the case of not being able to connect to the GO after the
provisioning step, but decided to leave the P2P client scanning in
that case until it finds the GO. Please note that this was done before
the group-idle and auto-removal cases were implemented. I guess it
would be reasonable to use similar mechanism (i.e., make sure those gets
started properly to catch this) to handle the case where even the first
association to get the data connection up fails. I kind of assume it
did, but if not, that sounds like something that should be fixed.

-- 
Jouni Malinen                                            PGP id EFC895FA