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: [RFC 0/3] Reload nameservers when necessary (Patrik Flykt)
2. Re: Provision 802.1X config (Patrik Flykt)
3. Re: Online check fails for working Internet connection
(Patrik Flykt)
4. Re: Tethering - using different subnets (Patrik Flykt)
5. Re: Provision 802.1X config (Lichtinger, Bernhard)
6. [RFC v2] service: Update nameservers and timeservers with
changes in IP (Patrik Flykt)
----------------------------------------------------------------------
Message: 1
Date: Thu, 08 Dec 2016 09:23:12 +0200
From: Patrik Flykt <[email protected]>
To: M?ns Rullg?rd <[email protected]>
Cc: [email protected]
Subject: Re: [RFC 0/3] Reload nameservers when necessary
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Wed, 2016-12-07 at 16:13 +0000, M?ns Rullg?rd wrote:
> These patches fix my problem.
Good, now we know the cause of this.
Looking at this once more, the trigger should actually be with
settings_changed() in src/service.c. Do you see the updated IP address
being sent in a D-Bus signal as well? If yes, then that is a better
place to handle this event.
Cheers,
Patrik
------------------------------
Message: 2
Date: Thu, 08 Dec 2016 09:30:48 +0200
From: Patrik Flykt <[email protected]>
To: "Lichtinger, Bernhard" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: Provision 802.1X config
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Wed, 2016-12-07 at 17:37 +0000, Lichtinger, Bernhard wrote:
> Hi,
>
> I am looking for a way to provision a 802.1X configuration for wifi
> from user space. So far I found that I can put a file with the
> service config in /var/lib/connman and it works.
Just for the record, I assume you have read doc/config-format.txt and
are adding a file into /var/lib/connman/foobar.conf.
> 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.
> In the list archive I found a patch series which was applied in
> February 2011 to implement a D-Bus method "manager.ProvisionService".
> But this method was later removed again, I couldn't find any hint
> when and why. I was looking for exactly such a thing.
The same information was easier to comprehend in a .config file, so the
D-Bus method call was removed.
> Is there any possibility that a user can "import" a provisioned
> config?
>
> I am trying to build a CAT-Tool for SailfishOS which imports an XML
> config file with all the complicated 802.1X settings and converts it
> into a connman service config (https://cat.eduroam.org/doc/).?
Cheers,
Patrik
------------------------------
Message: 3
Date: Thu, 08 Dec 2016 10:02:45 +0200
From: Patrik Flykt <[email protected]>
To: Robert Tiemann <[email protected]>, [email protected]
Subject: Re: Online check fails for working Internet connection
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Thu, 2016-12-01 at 13:36 +0100, Robert Tiemann wrote:
> Hi!
>
> On 12/01/2016 08:17 AM, Daniel Wagner wrote:
>
> > The online test was always only one shot IIRC. Probably because no
> > one dared to dive into the testing :)
>
> Testing this feature is quite some effort as it seems. There are so
> many cases to consider.
So the main reason why the online check is done only once is that it
has only and "advisory" role. ConnMan itself does not differentiate
between 'ready' and 'online' in any way. If ConnMan gets to 'online'
state, that is only a hint to the user that every connection should now
be working. Even the proxy ones - provided that the applications then
is able to use for example pacrunner as there might still be a proxy
preventing regular non-http PAC aware applications from functioning
properly. Normally nobody runs pacrunner, meaning that if the host
needs a proxy, the connection will still stay at 'ready'.
So yes, it's end of 2016 now and there are still too many obstacles on
the road to 'online' for a normal Internet connected device. Looking
only on the 'online' state should therefore (unfortunately) not be the
only road to happines. Here one should really influence upstream
libproxy to adopt pacrunner support and all the applications to use
libproxy to get properly past proxies. Fedora has already done that and
demonstrated it working.
> > Uff, yes those side effects need to addressed.
>
> I am currently searching for the reason that causes this behavior. It
> is possible that it is by some bad interaction between my application
> and ConnMan; at least I cannot reproduce it with ConnMan alone. So
> maybe it's just My Fault.
>
> > I think starting from the mer version is a good idea since theirs
> > changes are already in 'production'. I would really appreciate if
> > you could cook a nice patch (set) and send it for review and
> > testing.
>
> I can try. It will take me some time to start this, right now I need
> something that just works. Maybe I can begin working on this during
> the next week, but I cannot promise anything.
First of all, the tests need to run for both IPv4 and IPv6. If either
of them report 'online' it should be ok, shouldn't it? Except that IPv4
might not be able to connect as successfully as IPv6, since only IPv6
got to 'online' for some reason or another.
Then there is also the negative testing that needs to be done. The
device should really not be fooled into thinking that it's still
'online' when upstream connectivity broke behind the first router. Now
how often should this check then be made?
And with all the continuous testing multiplied by the number of ConnMen
out there, ip{v4,v6}.connman.net will need to take the additional load.
Vendor specific connectivity services are not really an option, they
cannot be proved to be working with proper connectivity by upstream. If
some other servers are used besides connman.net, no bugs about not
getting to 'online' state can be accepted anymore.
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.
Cheers,
Patrik
------------------------------
Message: 4
Date: Thu, 08 Dec 2016 10:10:40 +0200
From: Patrik Flykt <[email protected]>
To: Usman S <[email protected]>, [email protected]
Subject: Re: Tethering - using different subnets
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Wed, 2016-11-30 at 10:10 +0100, Daniel Wagner wrote:
> > As mentioned
> > in the patch, the same block will be only offered if it was not
> > allocated for any other device.? Should we think of a way where we
> > maintain the offered blocks for a particular device so that next
> > time the same is offered or more freedom to the application in
> > choosing its subnet?
>
> Of course we could implement something like this but I would like to?
> know why is that so important? Is it because you have static IP?
> addresses assigned to devices which use the uplink?
And let's not forget that sooner or later an uplink service will end up
issuing an IP on a subnet that clashes with a pre-defined tethering
subnet. These cases are now detected, and tethering restarted with a
different subnet in order to provide Internet connectivity as the
primary target for ConnMan. Finding the hosts on the tethered subnet
has been left as an excersise for mDNS.
Cheers,
Patrik
------------------------------
Message: 5
Date: Thu, 8 Dec 2016 08:50:51 +0000
From: "Lichtinger, Bernhard" <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Provision 802.1X config
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
>> I am looking for a way to provision a 802.1X configuration for wifi
>> from user space. So far I found that I can put a file with the
>> service config in /var/lib/connman and it works.
>
> Just for the record, I assume you have read doc/config-format.txt and
> are adding a file into /var/lib/connman/foobar.conf.
Yes, that was what I did.
>
>> 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.
>
>> In the list archive I found a patch series which was applied in
>> February 2011 to implement a D-Bus method "manager.ProvisionService".
>> But this method was later removed again, I couldn't find any hint
>> when and why. I was looking for exactly such a thing.
>
> The same information was easier to comprehend in a .config file, so the
> D-Bus method call was removed.
Thank you for answering my questions.
Regards,
Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5128 bytes
Desc: not available
URL:
<http://lists.01.org/pipermail/connman/attachments/20161208/44eb210a/attachment-0001.p7s>
------------------------------
Message: 6
Date: Thu, 8 Dec 2016 10:53:07 +0200
From: Patrik Flykt <[email protected]>
To: [email protected]
Subject: [RFC v2] service: Update nameservers and timeservers with
changes in IP
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
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?
Cheers,
Patrik
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);
}
--
2.10.2
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 14, Issue 13
***************************************
