wpa_supplicant automatically re-connect to previous AP in networks list

[Jouni Malinen]

On Mon, Dec 19, 2016 at 01:13:12PM +0000, Blanquicet-Melendez Jose (MM) wrote:
> This is our scenario:
> 
> 1. Connect to an AP using WPS. After this, there is a new network on this interface marked as "Current".
> 2. Disconnect from it. At this point, the network is still there when we do list_networks but now it is inactive.
> 3. Start a new WPS Session.
> 4. Let it go in time-out (2 min).
> 5. wpa_supplicant automatically re-connect to previous AP, the one corresponding to the network still present in list_networks.
> 
> Is this a desired behavior?

Yes, that's the way WPS is supposed to work.. All the network profiles
provisioned with WPS work in the same way as network profiles that are
added to the configuration explicitly.

> From our point of view it is not because we just previously disconnected from it, it means that we do not want to be connected to that AP. Now, the question here is, should not wpa_supplicant mark that network in such a way that it does not re-connect after user specifically asked to get disconnected? Or instead, should we remove that network after doing disconnect as we do for WPA2? Otherwise, is there another way to do it?

You would need to either remove that network after it should not be used
anymore or mark it disabled if it might be needed again in the future.

> If the correct way to avoid that behavior is by removing the network after the disconnection, how can we get the network's path? For WPA2 it is gotten because we pass through Interface.AddNetwork(). Instead, this method is not called for WPS thus we think that this could be obtained from property "CurrentNetwork" when we receive the signal Interface.PropertyChanged, of course after a "success" in signal Interface.WPS.Event. Would it be correct? Or what could you suggest us?

There is no guarantees that the network that wpa_supplicant connects to
after WPS provisioning is the one for which a credential was provisioned
since that network might not be available at that time (even though it
is in most common use cases). In addition, WPS provisioning can result
in provisioning multiple network profiles, so if you do not want to
connect to any of them in the future, you'd need to track all the added
networks.

If I understood your use case correctly, it would like the best approach
would be to figure out all the added network profiles whenever going
through WPS operations (e.g., using the NetworkAdded signal) and
remember those externally until such time that the connection is not
desired anymore.

-- 
Jouni Malinen                                            PGP id EFC895FA