Hi Samuel, > > > + if (bssid) > > > + g_key_file_set_string(keyfile, identifier, > > > + "BSSID", bssid); > > > + } > > > + > > > case CONNMAN_SERVICE_TYPE_WIMAX: > > > case CONNMAN_SERVICE_TYPE_BLUETOOTH: > > > case CONNMAN_SERVICE_TYPE_CELLULAR: > > > @@ -1585,6 +1611,15 @@ update: > > > g_free(str); > > > } > > > > > > + security = security2string(service->security); > > > + if (security) > > > + g_key_file_set_string(keyfile, service->identifier, > > > + "Security", > > > + security2string(service->security)); > > > + else > > > + g_key_file_set_string(keyfile, service->identifier, > > > + "Security", "none"); > > > + > > > if (service->passphrase != NULL) > > > g_key_file_set_string(keyfile, service->identifier, > > > "Passphrase", service->passphrase); > > > > Do we really need to store BSSID and security details. > Hidden networks apart, how do you plan to reconnect to a secure network > without having stored the passphrase ? Is Carrick going to ask for it > everytime ?
we do store the passphrase for all networks. What is the difference between hidden and normal networks. > > My plan is that > > we only re-connect to a hidden network if we find it during a scan. And > > once scanned we have the BSSID and security details. They will actually > > match perfectly with group name. Since for hidden networks we use the > > address in the group name. > Right now the only way to connect to an hidden SSID is to call join_network() > which set's the group name based on the SSID it gets. So after being connected > your newly created service will not be of the "hidden_BSSID" form. otoh, we > can not build a group name based on the BSSID from join_network() since we > dont know it at that time. We could avoid setting the group name when calling > join_network() and doing it once we're actually connected but that's quite > tricky since the wpa_s dbus API doesnt let us know about the BSSID we got when > association is completed. That seems to be a problem, but that is how we should do it. > Also, another issue here is that we sometimes get probe responses from hidden > APs, straight from the scan list. Those are no longer hidden and will appear > on the UI. If the user connects from here, the stored service will definitely > not be of the "hidden_BSSID" form, but will contain the SSID hexed string. > Next time connmand starts, if the hidden SSID doesnt give us a probe response, > we'll certainly wont be able to match anything. That is pretty bad. We not be able to fix any of these without fixing wpa_supplicant to probe scan all hidden SSID its finds and do the name caching. > So, all in all, this was the less ugly solution I could find for the above > constraints. The last problem is likely to happen when connmand starts over a > non refreshed mac80211 scan list, so we may consider this as an unsupported > corner case ? ConnMan will at least scan once after its started. That is expected and we need that for smart choices around our environment anyway. Regards Marcel _______________________________________________ connman mailing list [email protected] http://lists.connman.net/listinfo/connman
