Hi Jouni, Thanks for your explanation. > > 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. Ok, I understood that particular case but if I keep the network profiles always empty (i.e. Always remove them after disconnecting) and I keep track of WPS status using WPS.Event signal, I think there is no way that the network which wpa_supplicant connects to after "success" in WPS.Event is not the one I just received the credentials. Do you agree? Of course, if in the meanwhile there is an attempt from user to connect to another network (Create new network profile and select it), the WPS status must be clean. > 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. On most of test we have done so far, at the end of the WPS operations there is only one network profile created. Although it's true that during the process one more network profile is created but it is automatically deleted by wpa_supplicant itself. So I just would have to remember that one, which is the same I will receive in Interface.PropertyChanged as "CurrentNetwork". Do you also agree here? Cheers, Jose Blanquicet VISITA IL NOSTRO SITO WEB! - VISIT OUR WEB SITE! www.magnetimarelli.com Confidential Notice: This message - including its attachments - may contain proprietary, confidential and/or legally protected information and is intended solely for the use of the designated addressee(s) above. If you are not the intended recipient be aware that any downloading, copying, disclosure, distribution or use of the contents of the above information is strictly prohibited. If you have received this communication by mistake, please forward the message back to the sender at the email address above, delete the message from all mailboxes and any other electronic storage medium and destroy all copies. Disclaimer Notice: Internet communications cannot be guaranteed to be safe or error-free. Therefore we do not assure that this message is complete or accurate and we do not accept liability for any errors or omissions in the contents of this message. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
