Hi Marcel,
On Tue, Jul 07, 2009 at 10:35:08AM -0700, Marcel Holtmann wrote:
> Hi Samuel,
>
> > We need to save most of the wifi network settings in order to autconnect to
> > secure and hidden networks.
> > ---
> > src/service.c | 35 +++++++++++++++++++++++++++++++++++
> > 1 files changed, 35 insertions(+), 0 deletions(-)
> >
> > diff --git a/src/service.c b/src/service.c
> > index 9fefac8..24ee710 100644
> > --- a/src/service.c
> > +++ b/src/service.c
> > @@ -1526,6 +1526,7 @@ static int service_save(struct connman_service
> > *service)
> > gchar *pathname, *data = NULL;
> > gsize length;
> > gchar *str;
> > + const char *security;
> >
> > DBG("service %p", service);
> >
> > @@ -1559,6 +1560,31 @@ update:
> > case CONNMAN_SERVICE_TYPE_ETHERNET:
> > break;
> > case CONNMAN_SERVICE_TYPE_WIFI:
> > + if (service->network) {
> > + char *identifier = service->identifier;
> > + const void *ssid;
> > + const char *bssid;
> > + unsigned int ssid_len = 0;
> > +
> > + ssid = connman_network_get_blob(service->network,
> > + "WiFi.SSID",
> > + &ssid_len);
> > +
> > + bssid = connman_network_get_string(service->network,
> > + "Address");
> > +
> > + if (ssid) {
> > + g_key_file_set_value(keyfile, identifier,
> > + "SSID", ssid);
> > + g_key_file_set_integer(keyfile, identifier,
> > + "SSID_len", ssid_len);
> > + }
>
> I don't like this. Especially since we don't know what encoding our
> filesystems uses. Can we convert the SSID into a hex string like we do
> for the service object path and just store that one. Also please prefix
> this with WiFi.SSID so we have a clean namespace here.
Sure, will do that.
> > + 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 ?
> 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.
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.
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 ?
Cheers,
Samuel.
> Regards
>
> Marcel
>
>
> _______________________________________________
> connman mailing list
> [email protected]
> http://lists.connman.net/listinfo/connman
--
Intel Open Source Technology Centre
http://oss.intel.com/
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
