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. An question for "ServicesChanged" (Zheng, Wu)
2. RE: An question for "ServicesChanged" (Thomas Green)
3. [PATCH] service: Add AutoConnectAllTechnologies option
(Ioan-Adrian Ratiu)
4. Re: [PATCH] service: Add AutoConnectAllTechnologies option
(Marcel Holtmann)
----------------------------------------------------------------------
Message: 1
Date: Wed, 24 Aug 2016 07:44:58 +0000
From: "Zheng, Wu" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: An question for "ServicesChanged"
Message-ID:
<2cf57a644018a745b8fe029c7223e16e1306d...@shsmsx102.ccr.corp.intel.com>
Content-Type: text/plain; charset="us-ascii"
Hi upstream,
To get the wifi services list from the "ServicesChanged" signal of
net.connman.Manager ,
I meet an question.
1. If the connman find the new services,
the connman will send the all items of services via the "ServicesChanged"
signal of net.connman.Manager.
2. If the connman find the existed services with the services' items
changed,
the connman will not send the items of services via the "ServicesChanged"
signal of net.connman.Manager.
the user only gets the "ServicesChanged" signal of net.connman.Manager and not
get the services' items.
The root cause is that in the function of "service_append_added_foreach",
only the services' items of "services_notify->add" is added to the
"ServicesChanged" signal of net.connman.Manager.
If the services have exist, the services can't be added to
"services_notify->add".
Therefore, any items' modification of the existed services can't be sent to the
user via the "ServicesChanged" signal of net.connman.Manager.
Is it right?
If so, the user only use the "GetProperties" of "net.connman.Manager" to get
the items of existed services
when the user get the "ServicesChanged" signal of net.connman.Manager.
Best Regards
Zheng Wu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20160824/9b33f51e/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 24 Aug 2016 14:31:03 +0000
From: Thomas Green <[email protected]>
To: "[email protected]" <[email protected]>
Subject: RE: An question for "ServicesChanged"
Message-ID:
<c2bc44d770753c45aaac42695fb5be020125599...@slc-exmb01.corp.srelay.com>
Content-Type: text/plain; charset="us-ascii"
Once a service has been added with the ServicesChanged signal, if anything for
that servicechanges a PropertyChanged signal will be sent for that service.
You will need to catch that signal for the service and deal with it
appropriately.
From: connman [mailto:[email protected]] On Behalf Of Zheng, Wu
Sent: Wednesday, August 24, 2016 1:45 AM
To: [email protected]
Subject: An question for "ServicesChanged"
Hi upstream,
To get the wifi services list from the "ServicesChanged" signal of
net.connman.Manager ,
I meet an question.
1. If the connman find the new services,
the connman will send the all items of services via the "ServicesChanged"
signal of net.connman.Manager.
2. If the connman find the existed services with the services' items
changed,
the connman will not send the items of services via the "ServicesChanged"
signal of net.connman.Manager.
the user only gets the "ServicesChanged" signal of net.connman.Manager and not
get the services' items.
The root cause is that in the function of "service_append_added_foreach",
only the services' items of "services_notify->add" is added to the
"ServicesChanged" signal of net.connman.Manager.
If the services have exist, the services can't be added to
"services_notify->add".
Therefore, any items' modification of the existed services can't be sent to the
user via the "ServicesChanged" signal of net.connman.Manager.
Is it right?
If so, the user only use the "GetProperties" of "net.connman.Manager" to get
the items of existed services
when the user get the "ServicesChanged" signal of net.connman.Manager.
Best Regards
Zheng Wu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20160824/a4ce0462/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 24 Aug 2016 17:45:45 +0300
From: Ioan-Adrian Ratiu <[email protected]>
To: [email protected]
Subject: [PATCH] service: Add AutoConnectAllTechnologies option
Message-ID: <[email protected]>
Add a new option that enables auto-connecting all technologies which
contain AutoConnect=true, regradless of PreferredTechnologies setting.
The default AutoConnectAllTechnologies = false keeps the current
behaviour intact, i.e. if a higher preffered technology is already
connected, others will not connect automatically.
This setting has no effect if SingleConnectedTechnologies is enabled.
Based on work originally by Collin Richards <[email protected]>
Signed-off-by: Ioan-Adrian Ratiu <[email protected]>
---
src/main.c | 14 ++++++++++++++
src/main.conf | 6 ++++++
src/service.c | 9 +++++++--
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/src/main.c b/src/main.c
index f44a2ed..8bfe915 100644
--- a/src/main.c
+++ b/src/main.c
@@ -76,6 +76,7 @@ static struct {
char **tethering_technologies;
bool persistent_tethering_mode;
bool enable_6to4;
+ bool auto_connect_all;
} connman_settings = {
.bg_scan = true,
.pref_timeservers = NULL,
@@ -90,11 +91,13 @@ static struct {
.tethering_technologies = NULL,
.persistent_tethering_mode = false,
.enable_6to4 = false,
+ .auto_connect_all = false,
};
#define CONF_BG_SCAN "BackgroundScanning"
#define CONF_PREF_TIMESERVERS "FallbackTimeservers"
#define CONF_AUTO_CONNECT "DefaultAutoConnectTechnologies"
+#define CONF_AUTO_CONNECT_ALL "AutoConnectAllTechnologies"
#define CONF_PREFERRED_TECHS "PreferredTechnologies"
#define CONF_FALLBACK_NAMESERVERS "FallbackNameservers"
#define CONF_TIMEOUT_INPUTREQ "InputRequestTimeout"
@@ -110,6 +113,7 @@ static const char *supported_options[] = {
CONF_BG_SCAN,
CONF_PREF_TIMESERVERS,
CONF_AUTO_CONNECT,
+ CONF_AUTO_CONNECT_ALL,
CONF_PREFERRED_TECHS,
CONF_FALLBACK_NAMESERVERS,
CONF_TIMEOUT_INPUTREQ,
@@ -283,6 +287,13 @@ static void parse_config(GKeyFile *config)
g_clear_error(&error);
+ boolean = __connman_config_get_bool(config, "General",
+ CONF_AUTO_CONNECT_ALL, &error);
+ if (!error)
+ connman_settings.auto_connect_all = boolean;
+
+ g_clear_error(&error);
+
str_list = __connman_config_get_string_list(config, "General",
CONF_PREFERRED_TECHS, &len, &error);
@@ -544,6 +555,9 @@ bool connman_setting_get_bool(const char *key)
if (g_str_equal(key, CONF_ENABLE_6TO4))
return connman_settings.enable_6to4;
+ if (g_str_equal(key, CONF_AUTO_CONNECT_ALL))
+ return connman_settings.auto_connect_all;
+
return false;
}
diff --git a/src/main.conf b/src/main.conf
index acceda3..919ad2c 100644
--- a/src/main.conf
+++ b/src/main.conf
@@ -101,3 +101,9 @@
# quality. See RFC6343. Default value is false (as recommended by RFC6343
# section 4.1).
# Enable6to4 = false
+#
+# Always connect all technologies that have autoconnect set to true. Default
+# behavior (AutoConnectAllTechnologies = false) will connect a technology
+# only if it is at a higher preference than any which is already connected.
+# This setting has no effect if SingleConnectedTechnologies is enabled.
+# AutoConnectAllTechnologies = false
diff --git a/src/service.c b/src/service.c
index 37af5fc..b613a3c 100644
--- a/src/service.c
+++ b/src/service.c
@@ -3757,6 +3757,7 @@ static bool auto_connect_service(GList *services,
struct connman_service *service = NULL;
bool ignore[MAX_CONNMAN_SERVICE_TYPES] = { };
bool autoconnecting = false;
+ bool auto_connect_all =
connman_setting_get_bool("AutoConnectAllTechnologies");
GList *list;
DBG("preferred %d sessions %d reason %s", preferred, active_count,
@@ -3776,8 +3777,12 @@ static bool auto_connect_service(GList *services,
if (service->pending ||
is_connecting(service) ||
is_connected(service)) {
- if (!active_count)
- return true;
+ if (!active_count) {
+ if (auto_connect_all)
+ continue;
+ else
+ return true;
+ }
ignore[service->type] = true;
autoconnecting = true;
--
2.9.3
------------------------------
Message: 4
Date: Wed, 24 Aug 2016 11:05:09 -0400
From: Marcel Holtmann <[email protected]>
To: Ioan-Adrian Ratiu <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] service: Add AutoConnectAllTechnologies option
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Adrian,
> Add a new option that enables auto-connecting all technologies which
> contain AutoConnect=true, regradless of PreferredTechnologies setting.
> The default AutoConnectAllTechnologies = false keeps the current
> behaviour intact, i.e. if a higher preffered technology is already
> connected, others will not connect automatically.
>
> This setting has no effect if SingleConnectedTechnologies is enabled.
actually Patrik and I discussed this and this should be designed as
AlwaysConnectedTechnologies option. See his response to the original patch.
Regards
Marcel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 10, Issue 28
***************************************
