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. [PATCH] stats: Remove comment on valid file descriptor
(Daniel Wagner)
2. Re: [PATCH 3/3] wifi: Abort tethering enabling if bridge
creation/configuration fails (Patrik Flykt)
3. [PATCH] Remove unnecessary continue in set_tethering API
(Milind Murhekar)
4. Re: [PATCH] stats: Remove comment on valid file descriptor
(Patrik Flykt)
5. Re: [PATCH] Remove unnecessary continue in set_tethering API
(Patrik Flykt)
6. Re: [PATCH] service: Update nameservers automatically (Feng Wang)
----------------------------------------------------------------------
Message: 1
Date: Fri, 28 Oct 2016 09:38:56 +0200
From: Daniel Wagner <[email protected]>
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Subject: [PATCH] stats: Remove comment on valid file descriptor
Message-ID: <[email protected]>
From: Daniel Wagner <[email protected]>
The comment doesn't provide any real additional information. It was
documented why fd = -1 in the original commit.
---
src/stats.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/src/stats.c b/src/stats.c
index 98ce6d9ef741..eed6e8a1c09b 100644
--- a/src/stats.c
+++ b/src/stats.c
@@ -647,10 +647,6 @@ static int stats_file_history_update(struct stats_file
*data_file)
bzero(history_file, sizeof(struct stats_file));
bzero(temp_file, sizeof(struct stats_file));
- /*
- * 0 is a valid file descriptor - fd needs to be initialized
- * to -1 to handle errors correctly
- */
history_file->fd = -1;
temp_file->fd = -1;
@@ -703,10 +699,6 @@ int __connman_stats_service_register(struct
connman_service *service)
if (!file)
return -ENOMEM;
- /*
- * 0 is a valid file descriptor - fd needs to be initialized
- * to -1 to handle errors correctly
- */
file->fd = -1;
g_hash_table_insert(stats_hash, service, file);
--
2.7.4
------------------------------
Message: 2
Date: Fri, 28 Oct 2016 10:47:53 +0300
From: Patrik Flykt <[email protected]>
To: Jose Blanquicet <[email protected]>, Daniel Wagner
<[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 3/3] wifi: Abort tethering enabling if bridge
creation/configuration fails
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Tue, 2016-10-25 at 13:01 +0000, Jose Blanquicet wrote:
> Now I got your point. However, I do not know why you continue
> iterating in the loop after the first successful call, we only want
> to enable tethering on one interface (The first one that supports
> tethering). That's the reason loop return when everything went well:?
Just a side note here. This is mostly true for WiFi, as ConnMan will
attempt to use the most basic 2.4GHz channel for tethering. Currently
ConnMan has to set the channel, as wpa_supplicant isn't helping here.
Now when it comes to ethernet or gadget, there are no such limitations.
And since the API does not distinguish between > 1 devices of one
technology, all the devices of a certain technology need to enable
tethering.
Cheers,
Patrik
------------------------------
Message: 3
Date: Fri, 28 Oct 2016 14:00:47 +0530
From: Milind Murhekar <[email protected]>
To: [email protected]
Cc: [email protected], Milind Murhekar <[email protected]>
Subject: [PATCH] Remove unnecessary continue in set_tethering API
Message-ID: <[email protected]>
>> ---
>> src/technology.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/src/technology.c b/src/technology.c
>> index 17ed456..4574f1e 100644
>> --- a/src/technology.c
>> +++ b/src/technology.c
>> @@ -270,10 +270,8 @@ static int set_tethering(struct
>> connman_technology *technology,
>> if (result == -EINPROGRESS)
>> continue;
>>
>> - if (err == -EINPROGRESS || err == 0) {
>> + if (err == -EINPROGRESS || err == 0)
>> result = err;
>> - continue;
>> - }
>> }
> Why is the test unnecessary and what is the use case enabled by its
> removal?
Hi,
This patch simply removes the extra "continue" statement, which I think is not
required.
As conitnue is the last statement in the loop and loop will automatically get
continued.
The test condition is not removed.
Thanks,
Milind
------------------------------
Message: 4
Date: Fri, 28 Oct 2016 12:51:31 +0300
From: Patrik Flykt <[email protected]>
To: Daniel Wagner <[email protected]>, [email protected]
Cc: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] stats: Remove comment on valid file descriptor
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Fri, 2016-10-28 at 09:38 +0200, Daniel Wagner wrote:
> From: Daniel Wagner <[email protected]>
>
> The comment doesn't provide any real additional information. It was
> documented why fd = -1 in the original commit.
> ---
Applied, thanks!
Patrik
------------------------------
Message: 5
Date: Fri, 28 Oct 2016 12:58:20 +0300
From: Patrik Flykt <[email protected]>
To: Milind Murhekar <[email protected]>, [email protected]
Cc: [email protected]
Subject: Re: [PATCH] Remove unnecessary continue in set_tethering API
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Fri, 2016-10-28 at 14:00 +0530, Milind Murhekar wrote:
> > > ---
> > > ?src/technology.c | 4 +---
> > > ?1 file changed, 1 insertion(+), 3 deletions(-)
> > >
> > > diff --git a/src/technology.c b/src/technology.c
> > > index 17ed456..4574f1e 100644
> > > --- a/src/technology.c
> > > +++ b/src/technology.c
> > > @@ -270,10 +270,8 @@ static int set_tethering(struct
> > > connman_technology *technology,
> > > ? if (result == -EINPROGRESS)
> > > ? continue;
> > > ?
> > > - if (err == -EINPROGRESS || err == 0) {
> > > + if (err == -EINPROGRESS || err == 0)
> > > ? result = err;
> > > - continue;
> > > - }
> > > ? }
> > Why is the test unnecessary and what is the use case enabled by its
> > removal?
>
> Hi,
>
> This patch simply removes the extra "continue" statement, which I
> think is not required.
> As conitnue is the last statement in the loop and loop will
> automatically get continued.
And applied with the last sentence as the commit message (and prefixed
the subject with tethering:), thanks!
Patrik
------------------------------
Message: 6
Date: Fri, 28 Oct 2016 11:55:51 -0700
From: Feng Wang <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] service: Update nameservers automatically
Message-ID:
<cadsk2k-gp3tdz14dlt+wxgpowgrbup1bi1gbmyq4+qymqpn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Patrik,
I have question about the nameservers information update question. There
are ipv4 and ipv6 2 configurations for each service. And the name server
information is updated through d-bus in the "dns_changed" function which is
called in the service_indicate_state function when the configuration
becomes ready state.
But only the first "ready" configuration(either ipv4 or ipv6) is updated
because there is a status check in the service_indicate_state function like
below.
if (old_state == new_state)
return -EALREADY;
For example, ipv6 configuration became ready first, the
service_indicate_state function will be called and ipv6 dns server is
updated by dns_changed. Later ipv4 configuration become ready, it will NOT
call dns_changed function because the service state is already "ready".
Thus the ipv4 nameservers are NOT updated.
Can we move this dns_changed function to
"__connman_service_ipconfig_indicate_state" like below.
if (!is_connected_state(service, old_state) &&
is_connected_state(service, new_state)) {
nameserver_add_all(service, type);
dns_changed(service); /* Function moved here */
}
Thanks,
Feng
On Fri, Oct 14, 2016 at 5:33 AM, Patrik Flykt <[email protected]>
wrote:
> Automatically update nameserver information when they are appended
> or removed. Create a zero second timeout so that nameservers can
> be appended or removed in a loop one by one with only one D-Bus
> PropertyChanged signal being sent.
>
> Verify that the service is either connected or the nameservers have
> been removed when the service is inactive before sending the
> PropertyChanged signal.
> ---
>
> Hi,
>
> Here is a patch that updates nameserver info also if it changes while a
> service is connected. The issue was reported by Thomas Green a long time
> ago end of August, but at that point I had a bit wrong idea on how to fix
> the issue. So here is hopefully a solution that works in all cases.
>
> Please test,
>
> Patrik
>
>
> src/service.c | 56 ++++++++++++++++++++++++++++++
> ++++++++++++++++++++++++--
> 1 file changed, 54 insertions(+), 2 deletions(-)
>
> diff --git a/src/service.c b/src/service.c
> index ee10e6c..6877b9a 100644
> --- a/src/service.c
> +++ b/src/service.c
> @@ -92,6 +92,7 @@ struct connman_service {
> char **nameservers;
> char **nameservers_config;
> char **nameservers_auto;
> + int nameservers_timeout;
> char **domains;
> char *hostname;
> char *domainname;
> @@ -133,6 +134,7 @@ static struct connman_ipconfig
> *create_ip4config(struct connman_service *service
> int index, enum connman_ipconfig_method method);
> static struct connman_ipconfig *create_ip6config(struct connman_service
> *service,
> int index);
> +static void dns_changed(struct connman_service *service);
>
> struct find_data {
> const char *path;
> @@ -922,6 +924,24 @@ static bool is_connected_state(const struct
> connman_service *service,
> return false;
> }
>
> +static bool is_idle(struct connman_service *service)
> +{
> + switch (service->state) {
> + case CONNMAN_SERVICE_STATE_IDLE:
> + case CONNMAN_SERVICE_STATE_DISCONNECT:
> + case CONNMAN_SERVICE_STATE_FAILURE:
> + return true;
> + case CONNMAN_SERVICE_STATE_UNKNOWN:
> + case CONNMAN_SERVICE_STATE_ASSOCIATION:
> + case CONNMAN_SERVICE_STATE_CONFIGURATION:
> + case CONNMAN_SERVICE_STATE_READY:
> + case CONNMAN_SERVICE_STATE_ONLINE:
> + break;
> + }
> +
> + return false;
> +}
> +
> static bool is_connecting(struct connman_service *service)
> {
> return is_connecting_state(service, service->state);
> @@ -932,6 +952,29 @@ static bool is_connected(struct connman_service
> *service)
> return is_connected_state(service, service->state);
> }
>
> +
> +static int nameservers_changed_cb(void *user_data)
> +{
> + struct connman_service *service = user_data;
> +
> + DBG("service %p", service);
> +
> + service->nameservers_timeout = 0;
> + if ((is_idle(service) && !service->nameservers) ||
> + is_connected(service))
> + dns_changed(service);
> +
> + return FALSE;
> +}
> +
> +static void nameservers_changed(struct connman_service *service)
> +{
> + if (!service->nameservers_timeout)
> + service->nameservers_timeout = g_timeout_add_seconds(0,
> +
> nameservers_changed_cb,
> + service);
> +}
> +
> static bool nameserver_available(struct connman_service *service,
> enum connman_ipconfig_type type,
> const char *ns)
> @@ -1139,6 +1182,8 @@ int __connman_service_nameserver_append(struct
> connman_service *service,
> nameserver_add(service, CONNMAN_IPCONFIG_TYPE_ALL,
> nameserver);
> }
>
> + nameservers_changed(service);
> +
> searchdomain_add_all(service);
>
> return 0;
> @@ -1207,6 +1252,8 @@ set_servers:
> nameserver);
> }
>
> + nameservers_changed(service);
> +
> return 0;
> }
>
> @@ -4500,6 +4547,11 @@ static void service_free(gpointer user_data)
>
> reply_pending(service, ENOENT);
>
> + if (service->nameservers_timeout) {
> + g_source_remove(service->nameservers_timeout);
> + dns_changed(service);
> + }
> +
> __connman_notifier_service_remove(service);
> service_schedule_removed(service);
>
> @@ -5440,7 +5492,7 @@ static int service_indicate_state(struct
> connman_service *service)
> g_get_current_time(&service->modified);
> service_save(service);
>
> - dns_changed(service);
> + nameservers_changed(service);
> domain_changed(service);
> proxy_changed(service);
>
> @@ -5481,7 +5533,7 @@ static int service_indicate_state(struct
> connman_service *service)
>
> __connman_wpad_stop(service);
>
> - dns_changed(service);
> + nameservers_changed(service);
> domain_changed(service);
> proxy_changed(service);
>
> --
> 2.9.3
>
> _______________________________________________
> connman mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/connman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20161028/f2f7b370/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 12, Issue 33
***************************************
