Hi Tomasz, On Fri, Oct 21, 2011 at 09:50:58AM +0300, Tomasz Bursztyka wrote: > Hi Samuel, > > 2 questions here: > > - Wouldn't a g_supplicant_interface_disconnect() be enough ? > Because this one implicates more logics, with callbacks and so on. > Disabling the network is way faster, and prevents wpa_s looping on retries. > I did not dare to play with disconnect since, basically, it would mean > that the network _is_ connected first, which is not. > > - If not, do you need to enable back the selected network when the user > > tries > > to reconnect to the same network (via an agent API call for example) ? > Fortunately no, it's not up to connman to enable back the network :) Good.
> This behavior is wpa_s specific: > Once you "select" a network, wpa_s disables all networks (if any, like > if you are connected already for instance) and enables only the selected > one. > If 4way_handshake fails, it will retry and retry and retry ... always > failing at the same point unless you disable this network particular > selected network. Disabling the network deselects it. > (It was easier in connman to "disable selected one" through the > interface, since GSupplicantInterface owns the full path of this > particular network - because of SelectNetwork which previously got > successful). Yes, makes sense. > And about the agent api call, it's already handled: when you get the > agent error about psk, you will have 2 solutions: retry or cancel. It > just works as planned here. Ok, I wasn't sure you tested the complete thing, and was wondering what could happen when you connect to a previosuly disabled network. > I am not sure that we may need to enable selected networks at some point > because selected networks means an enabled one, so I am not convinced > about the need of g_supplicant_interface_enable_selected_network() here. I would just feel better with a symetric API. If you disable it, your API should allow you to enable it later on. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ _______________________________________________ connman mailing list [email protected] http://lists.connman.net/listinfo/connman
