Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. R: [RFC 1/2] Storage based service retrieval (MANIEZZO Marco (MM))
2. Re: R: [RFC 1/2] Storage based service retrieval (Patrik Flykt)
3. Re: [RFC 1/2] Storage based service retrieval (Patrik Flykt)
4. [PATCH] gsupplicant: Fix Potential crash issue in case of
dbus_malloc0() fail (Milind Ramesh Murhekar)
5. Re: [RFC 1/2] Storage based service retrieval (Marcel Holtmann)
6. Re: [RFC 1/2] Storage based service retrieval (Patrik Flykt)
----------------------------------------------------------------------
Message: 1
Date: Mon, 1 Feb 2016 08:42:58 +0000
From: "MANIEZZO Marco (MM)" <[email protected]>
To: Marcel Holtmann <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: R: [RFC 1/2] Storage based service retrieval
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hello Marcel,
Thank you for your answer. I will extend the GetKnownServices to also retrieve
Services listed in .config files.
Related to deletion, currently if you manual delete the .config file, connman
will automatically delete (STORAGEDIR)/service_folder/settings after, that's
ok. The problem is that the Remove method is not deleting neither .config nor
folders/settings. Since .config Services are immutable should I fix the Remove
method of the Service to allow deletion of only the
(STORAGEDIR)/service_folder/settings if present (keeping the .config file), or
also the entry in the .config file (and the .config file also if only one entry
is present) ?
Thanks,
Marco
-----Messaggio originale-----
Da: Marcel Holtmann [mailto:[email protected]]
Inviato: luned? 1 febbraio 2016 08:56
A: MANIEZZO Marco (MM)
Cc: [email protected]
Oggetto: Re: [RFC 1/2] Storage based service retrieval
Hi Marco,
> I'm proposing changes related to the attached discussion, on retrieval of
> stored services information, in two RFC proposals:
>
> RFC (1): Add a method GetKnownServices to the Manager that has similar
> behavior of GetServices but the source is not the active services list but
> the services stored in STORAGEDIR.
I am fine with this approach.
> RFC (2): Deletion of stored service: as far as I understood, provisioned
> services (the one with a .config file) cannot be deleted with Remove method
> of Service, but after testing of the WiFi technology I saw that it is not
> possible to remove (STORAGEDIR)/service_folder/settings even if there is no
> .config file, with the Remove method of a Service. This will lead to an
> increasing storage unless manually file deletion is done. The RFC then is to
> change the _connman_service_remove function to actually delete folders and
> files, when possible, meaning I would preserve current conditions to return
> false in _connman_service_remove and moreover the .config files in
> (STORAGEDIR) won't be touched.
Sounds like a bug to me. .config provided services are immutable. If they are
removed, its temporary / dynamic settings should be removed as well. There is
no point in keeping it.
> This email is to start with the RFC (1) modifications and see if my ideas are
> approved, because I made some assumptions that I hope are not a
> misunderstanding:
>
> a) currently from Service component, using Storage component it is
> possible to access only information stored in
> (STORAGEDIR)/service_folder/settings and not
> (STORAGEDIR)/files.config. The latter is only accessed by Config
> component
> b) the user can create a .config file in STORAGEDIR containing the
> information of connection (including passphrase for WiFi) of the services he
> already knows, so connman can connect (or autoconnect) to them without
> interaction. If a connection is made to these services with success, then a
> corresponding folder with a settings file will be created in (STORAGEDIR)/,
> that will reflects the .config file. Until a connection is done, only the
> .config file will exists. For services that don't have a .config file, after
> the user succeeds to connect to them the (STORAGEDIR)/service_folder/settings
> will be created.
>
> Basing on the above assumption, mainly for (a) which would require further
> modifications, the GetKnownServices only retrieves the services that have
> (STORAGEDIR)/service_folder/settings; it will not read the content of the
> .config files. For our personal usage this is not a limitation because we
> won't have .config files, moreover the Remove method won't be able to remove
> them, but I'm open to change if you have suggestions.
>
> Here's my proposal for RFC (1):
>
> client/commands.c | 13 ++++++++++++
> doc/connmanctl.1.in | 11 ++++++++++
> doc/manager-api.txt | 18 ++++++++++++++++
> src/connman.h | 1 +
> src/manager.c | 23 +++++++++++++++++++++
> src/service.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> tools/manager-api.c | 33 ++++++++++++++++++++++++++++++
> 7 files changed, 158 insertions(+)
>
>
> diff --git a/client/commands.c b/client/commands.c index
> db24d16..313174a 100644
> --- a/client/commands.c
> +++ b/client/commands.c
> @@ -348,6 +348,17 @@ static int object_properties(DBusMessageIter *iter,
> return 0;
> }
>
> +static int cmd_known_services(char *args[], int num, struct
> +connman_option *options) {
> + if (num > 1)
> + return -E2BIG;
> +
> + return __connmanctl_dbus_method_call(connection,
> + CONNMAN_SERVICE, CONNMAN_PATH,
> + "net.connman.Manager",
> "GetKnownServices",
> + services_list, NULL,
> +NULL, NULL); }
> +
> static int cmd_services(char *args[], int num, struct connman_option
> *options) {
> char *service_name = NULL; @@ -2549,6 +2560,8 @@ static
> const struct {
> lookup_tether },
> { "services", "[<service>]", service_options, cmd_services,
> "Display services", lookup_service_arg },
> + { "known-services", NULL, NULL, cmd_known_services,
> + "Display known services", NULL },
> { "peers", "[peer]", NULL, cmd_peers,
> "Display peers", lookup_peer_arg },
> { "scan", "<technology>", NULL, cmd_scan,
> diff --git a/doc/connmanctl.1.in b/doc/connmanctl.1.in index
> 0f891bd..fe7359c 100644
> --- a/doc/connmanctl.1.in
> +++ b/doc/connmanctl.1.in
> @@ -12,6 +12,7 @@ SYNOPSIS
> .BI tether \ technology\ \fRon|off\ |
> .BI tether\fR\ wifi\ on|off\ ssid\ passphrase\fR\ | .BR services \
> [\fIservice\fR]\ |
> +.BR known-services\fR\ |
> .BI peers \ peer\fR\ |
> .BI scan \ technology\fR\ |
> .RI \fBconnect \ service | peer \ |
> @@ -103,6 +104,16 @@ Only the service path (e.g.
> wifi_6834534139723_managed_none) is accepted as a parameter.
> .PP
> .TP
> +.B known-services
> +Returns a sorted list of tuples with service object path and
> +dictionary of service properties, for the known services having their
> +own directory in STORAGEDIR; it does not read .config files in root
> +STORAGEDIR. With this principle, it will return only services that have been
> connected at least one time.
> +This list will not contain sensitive information like passphrases etc.
> +The object path can be used as string to retrieve main properties
> +concatenated (for WiFi it includes SSID an security of the AP).
> +.PP
> +.TP
> .BI scan \ technology
> Scans for new services on the given technology.
> .PP
> diff --git a/doc/manager-api.txt b/doc/manager-api.txt index
> 31e137c..509eac9 100644
> --- a/doc/manager-api.txt
> +++ b/doc/manager-api.txt
> @@ -45,6 +45,24 @@ Methods dict GetProperties()
> and dictionary of peer
> properties
>
> Possible Errors:
> [service].Error.InvalidArguments
> +
> + array{object,dict} GetKnownServices()
> + [experimental]
> +
> + Returns a sorted list of tuples
> with service
> + object path and dictionary of
> service properties,
> + for the known services having
> their own directory in
> + STORAGEDIR; it does not read
> .config files in root STORAGEDIR.
> + With this principle, it will
> return only services that
> + have been connected at least
> one time.
I think this is a wrong description. It should return all known services to the
system. It does not matter if they are ever have been connected or not. So yes,
it needs to read .config as well.
Also such detail does not belong into this API description. I would rather like
to see that in config description file.
Regards
Marcel
________________________________
VISITA IL NOSTRO NUOVO SITO WEB! - VISIT OUR NEW 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.
------------------------------
Message: 2
Date: Mon, 01 Feb 2016 12:32:36 +0200
From: Patrik Flykt <[email protected]>
To: "MANIEZZO Marco (MM)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: R: [RFC 1/2] Storage based service retrieval
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Mon, 2016-02-01 at 08:42 +0000, MANIEZZO Marco (MM) wrote:
> Related to deletion, currently if you manual delete the .config file,
> connman will automatically delete (STORAGEDIR)/service_folder/settings
> after, that's ok. The problem is that the Remove method is not
> deleting neither .config nor folders/settings. Since .config Services
> are immutable should I fix the Remove method of the Service to allow
> deletion of only the (STORAGEDIR)/service_folder/settings if present
> (keeping the .config file), or also the entry in the .config file (and
> the .config file also if only one entry is present) ?
Since the services coming from a .config file are immutable, they cannot
be removed. They will (or should) be removed only when the .config file
disappears from the file system.
The only applied setting for an immutable service from a .config file is
AutoConnect. Allowing Remove() method call to remove only this setting
on immutable settings makes little sense as the service is not removed.
Cheers,
Patrik
------------------------------
Message: 3
Date: Mon, 01 Feb 2016 12:50:40 +0200
From: Patrik Flykt <[email protected]>
To: "MANIEZZO Marco (MM)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [RFC 1/2] Storage based service retrieval
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Mon, 2016-02-01 at 07:27 +0000, MANIEZZO Marco (MM) wrote:
> + array{object,dict} GetKnownServices()
> [experimental]
> +
> + Returns a sorted list of tuples
> with service
> + object path and dictionary of
> service properties,
> + for the known services having
> their own directory in
> + STORAGEDIR; it does not read
> .config files in root STORAGEDIR.
> + With this principle, it will
> return only services that
> + have been connected at least
> one time.
>+
> + This list will not contain
> sensitive information
> + like passphrases etc.
> +
> + The object path can be used as
> string to retrieve main
> + properties concatenated (for
> WiFi it includes SSID an
> + security of the AP).
This is not going to work as expected. As documented, this method call
will return a service object path, also for those saved/known services
that are not available at the time. But only the service that are
available have registered object paths, i.e. the ones only stored on
disc will return non-existent ones which cannot then be modified or even
removed.
GetKnownServices() should return a object path that can be used for
configuration even when the service is absent. Accessing the stored
services must be done with as little memory and cpu as possible. The
worst case might be 2000+ saved services on some systems and we rather
not have the device break down with that.
Patrik
------------------------------
Message: 4
Date: Mon, 01 Feb 2016 16:58:19 +0530
From: Milind Ramesh Murhekar <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: [PATCH] gsupplicant: Fix Potential crash issue in case of
dbus_malloc0() fail
Message-ID: <[email protected]>
Return if dbus_malloc0() allocation fails.
---
gsupplicant/supplicant.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 342cb01..6a62026 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -2804,6 +2804,9 @@ static void signal_peer_found(const char *path,
DBusMessageIter *iter)
g_hash_table_replace(peer_mapping, peer->path, interface);
property_data = dbus_malloc0(sizeof(struct peer_property_data));
+ if (!property_data)
+ return;
+
property_data->peer = peer;
dbus_message_iter_next(iter);
@@ -2861,6 +2864,9 @@ static void signal_peer_changed(const char *path,
DBusMessageIter *iter)
}
property_data = dbus_malloc0(sizeof(struct peer_property_data));
+ if (!property_data)
+ return;
+
property_data->peer = peer;
supplicant_dbus_property_foreach(iter, peer_property, property_data);
--
1.9.1
------------------------------
Message: 5
Date: Mon, 1 Feb 2016 14:18:44 +0100
From: Marcel Holtmann <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [RFC 1/2] Storage based service retrieval
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Patrik,
>> Related to deletion, currently if you manual delete the .config file,
>> connman will automatically delete (STORAGEDIR)/service_folder/settings
>> after, that's ok. The problem is that the Remove method is not
>> deleting neither .config nor folders/settings. Since .config Services
>> are immutable should I fix the Remove method of the Service to allow
>> deletion of only the (STORAGEDIR)/service_folder/settings if present
>> (keeping the .config file), or also the entry in the .config file (and
>> the .config file also if only one entry is present) ?
>
> Since the services coming from a .config file are immutable, they cannot
> be removed. They will (or should) be removed only when the .config file
> disappears from the file system.
>
> The only applied setting for an immutable service from a .config file is
> AutoConnect. Allowing Remove() method call to remove only this setting
> on immutable settings makes little sense as the service is not removed.
calling Remove on an immutable service (provided by a .config) essentially
means resetting that service to its defaults. If that is not working, then it
is a bug.
Regards
Marcel
------------------------------
Message: 6
Date: Mon, 01 Feb 2016 15:25:35 +0200
From: Patrik Flykt <[email protected]>
To: Marcel Holtmann <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [RFC 1/2] Storage based service retrieval
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Mon, 2016-02-01 at 14:18 +0100, Marcel Holtmann wrote:
> calling Remove on an immutable service (provided by a .config)
> essentially means resetting that service to its defaults. If that is
> not working, then it is a bug.
Ok, in this case the current implementation may (or may not) have a bug
with Remove().
Cheers,
Patrik
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 4, Issue 1
*************************************
