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: Online check fails for working Internet connection
(Daniel Wagner)
2. Re: Provision 802.1X config (Daniel Wagner)
3. Re: Provision 802.1X config (Slava Monich)
4. Re: Provision 802.1X config (Patrik Flykt)
5. Re: [RFC, v2] service: Update nameservers and timeservers
with changes in IP (M?ns Rullg?rd)
----------------------------------------------------------------------
Message: 1
Date: Thu, 8 Dec 2016 10:55:58 +0100
From: Daniel Wagner <[email protected]>
To: Patrik Flykt <[email protected]>, Robert Tiemann
<[email protected]>, [email protected]
Subject: Re: Online check fails for working Internet connection
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 12/08/2016 09:02 AM, Patrik Flykt wrote:
> So, after opening said can of worms, I think the better option is to
> try once only. The stable networks with no proxy issues will show up as
> 'online', with the others that should be Internet connected and are
> still marked only as 'ready' thereby show a hint that something in the
> network still need to be evaluated for perfect connectivity.
Basically that boils down to: the 'online' state is a complete useless
information, because
1) ready -> online: no positive retries
2) online -> ready: no negative retries
I don't think it has to be like this. I agree this is not easy to solve,
especially with IPv4 and IPv6. At least some Android phones seem to do
this (constant checking if the link is usable) and I do like this feature.
What about starting with something which doesn't drive our current state
machine but instead just does reporting.
cheers,
daniel
------------------------------
Message: 2
Date: Thu, 8 Dec 2016 11:02:28 +0100
From: Daniel Wagner <[email protected]>
To: "Lichtinger, Bernhard" <[email protected]>, Patrik Flykt
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Provision 802.1X config
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 12/08/2016 09:50 AM, Lichtinger, Bernhard wrote:
>>> But /var/lib/connman as only writeable by root.
>>
>> It is left as a problem for the distributor which user or group IDs
>> have write access to this directory. So in your case you want a
>> different user or group ID to be able to write in the /var/lib/connman/
>> top level directory. In order for that ID not to be able to mess around
>> with other settings, the directory should perhaps have the sticky bit
>> (t) set.
>
> Ok. Then I will try to convince the Sailfish guys to change that.
One thing which could also be done is having a service/config daemon
with a D-Bus API (or something like that) which can write to that
directory.
cheers,
daniel
------------------------------
Message: 3
Date: Thu, 8 Dec 2016 12:12:38 +0200
From: Slava Monich <[email protected]>
To: [email protected]
Subject: Re: Provision 802.1X config
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 08/12/16 12:02, Daniel Wagner wrote:
>
> On 12/08/2016 09:50 AM, Lichtinger, Bernhard wrote:
>>>> But /var/lib/connman as only writeable by root.
>>>
>>> It is left as a problem for the distributor which user or group IDs
>>> have write access to this directory. So in your case you want a
>>> different user or group ID to be able to write in the /var/lib/connman/
>>> top level directory. In order for that ID not to be able to mess around
>>> with other settings, the directory should perhaps have the sticky bit
>>> (t) set.
>>
>> Ok. Then I will try to convince the Sailfish guys to change that.
>
> One thing which could also be done is having a service/config daemon
> with a D-Bus API (or something like that) which can write to that
> directory.
>
That sounds like connman to me.
-Slava
------------------------------
Message: 4
Date: Thu, 08 Dec 2016 12:21:01 +0200
From: Patrik Flykt <[email protected]>
To: Daniel Wagner <[email protected]>, "Lichtinger, Bernhard"
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Provision 802.1X config
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Thu, 2016-12-08 at 11:02 +0100, Daniel Wagner wrote:
> On 12/08/2016 09:50 AM, Lichtinger, Bernhard wrote:
> > > > But /var/lib/connman as only writeable by root.
> > >
> > > It is left as a problem for the distributor which user or group
> > > IDs have write access to this directory. So in your case you want
> > > a different user or group ID to be able to write in the
> > > /var/lib/connman/ top level directory. In order for that ID not
> > > to be able to mess around with other settings, the directory
> > > should perhaps have the sticky bit (t) set.
> >
> > Ok. Then I will try to convince the Sailfish guys to change that.
>
> One thing which could also be done is having a service/config daemon?
> with a D-Bus API (or something like that) which can write to that?
> directory.
Yes, that is actually a good idea.
Cheers,
Patrik
------------------------------
Message: 5
Date: Thu, 08 Dec 2016 12:09:02 +0000
From: M?ns Rullg?rd <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: [email protected]
Subject: Re: [RFC, v2] service: Update nameservers and timeservers
with changes in IP
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
Patrik Flykt <[email protected]> writes:
> When the IP address changes, nameservers need to be removed and
> re-added in order for them to pick up the changed IP address. The
> same applies to timeservers, restart the query for those as well.
>
> Reported by M?ns Rullg?rd.
> ---
>
> Much less messing around with the code if implemented this way.
>
> Can you still test that it works identically to v1?
This seems to work as well.
> src/service.c | 21 ++++++++++++++-------
> 1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/src/service.c b/src/service.c
> index 737a39f..ee87ad5 100644
> --- a/src/service.c
> +++ b/src/service.c
> @@ -1961,19 +1961,26 @@ static void settings_changed(struct connman_service
> *service,
> {
> enum connman_ipconfig_type type;
>
> - if (!allow_property_changed(service))
> - return;
> -
> type = __connman_ipconfig_get_config_type(ipconfig);
>
> - if (type == CONNMAN_IPCONFIG_TYPE_IPV4)
> - connman_dbus_property_changed_dict(service->path,
> + if (allow_property_changed(service)) {
> + if (type == CONNMAN_IPCONFIG_TYPE_IPV4)
> + connman_dbus_property_changed_dict(service->path,
> CONNMAN_SERVICE_INTERFACE, "IPv4",
> append_ipv4, service);
> - else if (type == CONNMAN_IPCONFIG_TYPE_IPV6)
> - connman_dbus_property_changed_dict(service->path,
> + else if (type == CONNMAN_IPCONFIG_TYPE_IPV6)
> + connman_dbus_property_changed_dict(service->path,
> CONNMAN_SERVICE_INTERFACE, "IPv6",
> append_ipv6, service);
> + }
> +
> + if (is_connected_state(service, service->state) &&
> + service == __connman_service_get_default()) {
> + nameserver_remove_all(service, type);
> + nameserver_add_all(service, type);
> +
> + __connman_timeserver_sync(service);
> + }
>
> __connman_notifier_ipconfig_changed(service, ipconfig);
> }
--
M?ns Rullg?rd
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 14, Issue 14
***************************************
