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. Re: [PATCH] ntp: clear ADJ_MAXERROR to keep STA_UNSYNC
cleared after jump adjust (Daniel Wagner)
2. Re: [PATCH v3 2/3] service: Implement
AlwaysConnectedTechnologies (Daniel Wagner)
3. Re: [PATCH v3 3/3] main.conf: document
AlwaysConnectedTechnologies option (Daniel Wagner)
4. Re: [RFC v0 02/10] service: Connect() should not block
(Slava Monich)
5. [PATCH v3] service: Block auto connect when connection is in
progress (Saurav Babu)
6. Re: [RFC v0 02/10] service: Connect() should not block
(Daniel Wagner)
7. Support fro strongswan in Connman (Florent Le Saout)
8. Re: [RFC v0 05/10] iwd: Track D-Bus API (Denis Kenzior)
----------------------------------------------------------------------
Message: 1
Date: Thu, 10 Nov 2016 13:53:01 +0100
From: Daniel Wagner <[email protected]>
To: Alexander Kochetkov <[email protected]>
Cc: Patrik Flykt <[email protected]>, [email protected]
Subject: Re: [PATCH] ntp: clear ADJ_MAXERROR to keep STA_UNSYNC
cleared after jump adjust
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Alexander,
>> For testing that I made automatic test. But for running test fast
>> linux kernel should be patched also.
>
> Cool! This should go into ./tests so we don't loose it.
Absolutely, this would be extremly helpful. Alexander would you mind to
cook a patch for this.
Thanks a lot!
Daniel
------------------------------
Message: 2
Date: Thu, 10 Nov 2016 14:33:40 +0100
From: Daniel Wagner <[email protected]>
To: Ioan-Adrian Ratiu <[email protected]>, [email protected],
[email protected]
Subject: Re: [PATCH v3 2/3] service: Implement
AlwaysConnectedTechnologies
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Just nitpicking
On 11/09/2016 05:52 PM, Ioan-Adrian Ratiu wrote:
> Add a new function which returns true if a service type is in the list
> of technologies to always autoconnect. Call that function at various
> points in the auto_connect_service to ensure that service type always
> connects regardless of any preffered technologies settings and correctly
> handles session logic.
> ---
> src/service.c | 24 ++++++++++++++++++++----
> 1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/src/service.c b/src/service.c
> index f6a76f6..092c48c 100644
> --- a/src/service.c
> +++ b/src/service.c
> @@ -3750,6 +3750,19 @@ static GList *preferred_tech_list_get(void)
> return tech_data.preferred_list;
> }
>
> +static bool always_connect(enum connman_service_type type)
> +{
> + unsigned int *always_connected_techs =
> + connman_setting_get_uint_list("AlwaysConnectedTechnologies");
> + int i;
> +
> + for (i = 0; always_connected_techs && always_connected_techs[i]; i++)
> + if (always_connected_techs[i] == type)
> + return true;
> +
> + return false;
> +}
> +
> static bool auto_connect_service(GList *services,
> enum connman_service_connect_reason reason,
> bool preferred)
> @@ -3757,6 +3770,7 @@ static bool auto_connect_service(GList *services,
> struct connman_service *service = NULL;
> bool ignore[MAX_CONNMAN_SERVICE_TYPES] = { };
> bool autoconnecting = false;
> +
no newline here.
> GList *list;
>
> DBG("preferred %d sessions %d reason %s", preferred, active_count,
> @@ -3776,8 +3790,8 @@ static bool auto_connect_service(GList *services,
> if (service->pending ||
> is_connecting(service) ||
> is_connected(service)) {
> - if (!active_count)
> - return true;
> + if (!active_count && !always_connect(service->type))
> + return true;
see below.
>
> ignore[service->type] = true;
> autoconnecting = true;
> @@ -3799,7 +3813,9 @@ static bool auto_connect_service(GList *services,
> CONNMAN_SERVICE_STATE_IDLE)
> continue;
>
> - if (autoconnecting && !active_sessions[service->type]) {
> + if (autoconnecting &&
> + !active_sessions[service->type] &&
> + !always_connect(service->type)) {
The above condition and also this one are getting hard to decipher. I
suggest to move this into a small helper function with a comment
explains what this is supposed to do, e.g.
bool service_has_users(...)
{
/*
* Test if there is no session wanting this service
* nor it belongs to the technology which should always
* be connected.
*/
return X && Y;
}
> DBG("service %p type %s has no users", service,
> __connman_service_type2string(service->type));
> continue;
> @@ -3810,7 +3826,7 @@ static bool auto_connect_service(GList *services,
>
> __connman_service_connect(service, reason);
>
> - if (!active_count)
> + if (!active_count && always_connect(service->type))
> return true;
>
> ignore[service->type] = true;
>
cheers,
daniel
------------------------------
Message: 3
Date: Thu, 10 Nov 2016 14:34:22 +0100
From: Daniel Wagner <[email protected]>
To: Ioan-Adrian Ratiu <[email protected]>, [email protected],
[email protected]
Subject: Re: [PATCH v3 3/3] main.conf: document
AlwaysConnectedTechnologies option
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 11/09/2016 05:52 PM, Ioan-Adrian Ratiu wrote:
> By default it's not used and it's list is empty.
You should also update the man page if you touch the
main.conf file.
Thanks,
Daniel
------------------------------
Message: 4
Date: Thu, 10 Nov 2016 17:15:33 +0300
From: Slava Monich <[email protected]>
To: [email protected]
Subject: Re: [RFC v0 02/10] service: Connect() should not block
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 10/11/16 15:43, Daniel Wagner wrote:
> From: Daniel Wagner <[email protected]>
>
> According the documentation the Connect() call should never block.
>
> For a network we don't have a passphrase yet we ask via the agent the user
> for one. From connect_service() we call __connman_service_connect()
> which will eventually call connman_agent_queue_message(). The last
> function creates a new DBus message and queues it up into the dbus
> layer. Unforntatly, that message wont be sent until the pending
> message (connect_service) has been handled. The result is we wait
> until a timer expires before moving on. With returning an empty D-Bus
> message we unblock the dbus layer and everytying moves on.
Hi Daniel,
The documentation says this to me about Connect():
This method call will only return in case of an
error or when the service is fully connected. So
setting a longer D-Bus timeout might be a really
good idea.
I read it as "Connect() call does block, possibly for a long time".
If I understand your patch correctly, this is quite a significant change
of behaviour. By replying to the D-Bus message you are telling the
client that the connect request has been handled (successfully) when in
fact it's not handled yet and may even fail.
Also, you are keeping a reference to the incoming D-Bus message in
service->pending, right? Then reply_pending() will at some point reply
to it again which is pointless at best.
Pending messages should not block anything. D-Bus services are allowed
to have quite a large number of simultaneous pending requests. If
there's a problem with gdbus code, it should be fixed in gdbus.
Cheers,
-Slava
------------------------------
Message: 5
Date: Thu, 10 Nov 2016 20:30:24 +0530
From: Saurav Babu <[email protected]>
To: [email protected]
Cc: [email protected], Saurav Babu <[email protected]>
Subject: [PATCH v3] service: Block auto connect when connection is in
progress
Message-ID:
<[email protected]>
In the following scenario:
1. Device is connected to AP in non hidden mode.
2. Connection is initated to AP in hidden mode.
connman disconnects old service and tries to connect to new service. But
for connecting hidden service it first scans the hidden AP and when
network is added for hidden AP then connection is tried. In the meantime
normal AP got disconnected and was tried to autoconnect even before
hidden AP was scanned successfully.
This patch blocks auto connect when any service connection is in
progress and unblocks autoconnection after connection is started
or hidden wifi scan is completed and hidden AP is not found in the
scan list.
---
v3: Defer auto connect of services when one service is connecting
Allow auto connect of services when service connection fails with error
src/connman.h | 2 ++
src/network.c | 4 ++++
src/service.c | 22 ++++++++++++++++++++--
3 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/src/connman.h b/src/connman.h
index ce3ef8d..945518b 100644
--- a/src/connman.h
+++ b/src/connman.h
@@ -796,6 +796,8 @@ void __connman_service_notify(struct connman_service
*service,
int __connman_service_counter_register(const char *counter);
void __connman_service_counter_unregister(const char *counter);
+void __connman_service_enable_autoconnect(bool autoconnect);
+
#include <connman/peer.h>
int __connman_peer_init(void);
diff --git a/src/network.c b/src/network.c
index 2e423bc..e24970d 100644
--- a/src/network.c
+++ b/src/network.c
@@ -1370,6 +1370,8 @@ void connman_network_clear_hidden(void *user_data)
DBG("user_data %p", user_data);
+ __connman_service_enable_autoconnect(true);
+
/*
* Hidden service does not have a connect timeout so
* we do not need to remove it. We can just return
@@ -1389,6 +1391,8 @@ int connman_network_connect_hidden(struct connman_network
*network,
DBG("network %p service %p user_data %p", network, service, user_data);
+ __connman_service_enable_autoconnect(true);
+
if (!service)
return -EINVAL;
diff --git a/src/service.c b/src/service.c
index f6a76f6..316581a 100644
--- a/src/service.c
+++ b/src/service.c
@@ -48,6 +48,7 @@ static unsigned int autoconnect_timeout = 0;
static unsigned int vpn_autoconnect_timeout = 0;
static struct connman_service *current_default = NULL;
static bool services_dirty = false;
+static bool allow_autoconnect = true;
struct connman_stats {
bool valid;
@@ -3849,6 +3850,9 @@ void __connman_service_auto_connect(enum
connman_service_connect_reason reason)
if (autoconnect_timeout != 0)
return;
+ if (!allow_autoconnect)
+ return;
+
if (!__connman_session_policy_autoconnect(reason))
return;
@@ -4025,6 +4029,8 @@ static DBusMessage *connect_service(DBusConnection *conn,
index = __connman_service_get_index(service);
+ allow_autoconnect = false;
+
for (list = service_list; list; list = list->next) {
struct connman_service *temp = list->data;
@@ -4042,8 +4048,10 @@ static DBusMessage *connect_service(DBusConnection *conn,
err = -EINPROGRESS;
}
- if (err == -EINPROGRESS)
+ if (err == -EINPROGRESS) {
+ allow_autoconnect = true;
return __connman_error_operation_timeout(msg);
+ }
service->ignore = false;
@@ -4060,8 +4068,10 @@ static DBusMessage *connect_service(DBusConnection *conn,
service->pending = NULL;
}
- if (err < 0)
+ if (err < 0) {
+ allow_autoconnect = true;
return __connman_error_failed(msg, -err);
+ }
return g_dbus_create_reply(msg, DBUS_TYPE_INVALID);
}
@@ -5231,6 +5241,9 @@ static void request_input_cb(struct connman_service
*service,
service_complete(service);
__connman_connection_update_gateway();
}
+
+ if (!service->hidden)
+ allow_autoconnect = true;
}
static void downgrade_connected_services(void)
@@ -5921,6 +5934,11 @@ static void prepare_8021x(struct connman_service
*service)
service->phase2);
}
+void __connman_service_enable_autoconnect(bool autoconnect)
+{
+ allow_autoconnect = autoconnect;
+}
+
static int service_connect(struct connman_service *service)
{
int err;
--
1.9.1
------------------------------
Message: 6
Date: Thu, 10 Nov 2016 17:05:28 +0100
From: Daniel Wagner <[email protected]>
To: Slava Monich <[email protected]>, [email protected]
Subject: Re: [RFC v0 02/10] service: Connect() should not block
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Slava,
> I read it as "Connect() call does block, possibly for a long time".
>
> If I understand your patch correctly, this is quite a significant change
> of behaviour. By replying to the D-Bus message you are telling the
> client that the connect request has been handled (successfully) when in
> fact it's not handled yet and may even fail.
You are absolutely right. I confused it with the Session.Connect().
> Pending messages should not block anything. D-Bus services are allowed
> to have quite a large number of simultaneous pending requests. If
> there's a problem with gdbus code, it should be fixed in gdbus.
Yep, that just might be the case.
Thanks,
Daniel
------------------------------
Message: 7
Date: Thu, 10 Nov 2016 17:16:50 +0100
From: Florent Le Saout <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Support fro strongswan in Connman
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi,
I'm using Strongswan for IPsec and connman as network manager.
It seems that there is no support for strongswan in Connman ?
If so then is there any plan to integrate it at some point, or any work
on that already ongoing ?
Thanks,
Florent.
------------------------------
Message: 8
Date: Thu, 10 Nov 2016 10:46:59 -0600
From: Denis Kenzior <[email protected]>
To: Daniel Wagner <[email protected]>, [email protected]
Cc: Daniel Wagner <[email protected]>
Subject: Re: [RFC v0 05/10] iwd: Track D-Bus API
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Daniel,
> +static const char *state2string(enum iwd_device_state state)
> +{
> + switch (state) {
> + case IWD_DEVICE_STATE_CONNECTED:
> + return "connected";
> + case IWD_DEVICE_STATE_DISCONNECTED:
> + return "disconnected";
> + case IWD_DEVICE_STATE_CONNECTING:
> + return "connecting";
> + case IWD_DEVICE_STATE_DISCONNECTING:
> + return "disconnecting";
> + default:
> + break;
> + }
> +
> + return "unkonwn";
typo
> +}
> +
<snip>
> +static void device_property_change(GDBusProxy *proxy, const char *name,
> + DBusMessageIter *iter, void *user_data)
> +{
> + struct iwd_device *iwdd;
> + const char *path;
> +
> + path = g_dbus_proxy_get_path(proxy);
> + iwdd = g_hash_table_lookup(devices, path);
> + if (!iwdd)
> + return;
> +
> + if (!strcmp(name, "Name")) {
> + const char *name;
> +
> + dbus_message_iter_get_basic(iter, &name);
> + g_free(iwdd->name);
> + iwdd->name = g_strdup(name);
> +
> + DBG("%p name %s", path, iwdd->name);
> + } else if (!strcmp(name, "Address")) {
> + const char *address;
> +
> + dbus_message_iter_get_basic(iter, &address);
> + g_free(iwdd->address);
> + iwdd->address = g_strdup(address);
> +
> + DBG("%p address %s", path, iwdd->address);
I don't imagine we will ever notify PropertyChanged for Address or Name.
Though I suppose it doesn't hurt to have it here
> + } else if (!strcmp(name, "State")) {
> + const char *state;
> +
> + dbus_message_iter_get_basic(iter, &state);
> + iwdd->state = string2state(state);
> +
> + DBG("%s state %s", path, state2string(iwdd->state));
> + } else if (!strcmp(name, "Powered")) {
> + dbus_bool_t powered;
> +
> + dbus_message_iter_get_basic(iter, &powered);
> + iwdd->powered = powered;
> +
> + DBG("%s powered %d", path, iwdd->powered);
> +
extraneous line?
> + } else if (!strcmp(name, "Scanning")) {
> + dbus_bool_t scanning;
> +
> + dbus_message_iter_get_basic(iter, &scanning);
> + iwdd->scanning = scanning;
> +
> + DBG("%s scanning %d", path, iwdd->scanning);
> + }
> +}
> +
> +static void network_property_change(GDBusProxy *proxy, const char *name,
> + DBusMessageIter *iter, void *user_data)
> +{
> + struct iwd_network *iwdn;
> + const char *path;
> +
> + path = g_dbus_proxy_get_path(proxy);
> + iwdn = g_hash_table_lookup(networks, path);
> + if (!iwdn)
> + return;
> +
> + if (!strcmp(name, "Name")) {
> + const char *name;
> +
> + dbus_message_iter_get_basic(iter, &name);
> + g_free(iwdn->name);
> + iwdn->name = g_strdup(name);
> +
> + DBG("%p name %s", path, iwdn->name);
Same here, the Name == SSID, so I don't think it would ever change.
We'd create a brand new Network object in this case.
> + } else if (!strcmp(name, "Connected")) {
> + dbus_bool_t connected;
> +
> + dbus_message_iter_get_basic(iter, &connected);
> + iwdn->connected = connected;
> +
> + DBG("%s connected %d", path, iwdn->connected);
> + } else if (!strcmp(name, "Type")) {
> + const char *type;
> +
> + dbus_message_iter_get_basic(iter, &type);
> + g_free(iwdn->type);
> + iwdn->type = g_strdup(type);
> +
> + DBG("%p type %s", path, iwdn->type);
Same comment as above.
> + }
> +}
> +
Regards,
-Denis
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 13, Issue 11
***************************************
