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: dnsproxy feature doesn't resolve for local domain (Leo Mar)
2. Re: Question about "MoveBefore" and notifications (l.genevet)
3. Persistent service ordering (Maxime CHEVALLIER)
4. [PATCH v2] service: Add AlwaysConnectedTechnologies option
(Ioan-Adrian Ratiu)
----------------------------------------------------------------------
Message: 1
Date: Mon, 12 Sep 2016 13:24:40 +0530
From: Leo Mar <[email protected]>
To: Justin Maggard <[email protected]>
Cc: [email protected]
Subject: Re: dnsproxy feature doesn't resolve for local domain
Message-ID:
<cagokkohxjkhjfh7nsqasugltbcpicxy96n0dwndtveozo8b...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
Thanks, It's the same issue. But it seems there is no updates later on this
issue.
Can anybody help me out on information about this issue fixed or not?
Regards,
Maruthi
On Thu, Sep 8, 2016 at 10:38 PM, Justin Maggard <[email protected]>
wrote:
> I'd guess it's the same issue described here:
>
> https://www.mail-archive.com/[email protected]/msg17355.html
>
> -Justin
>
> On Thu, Sep 8, 2016 at 5:00 AM, Leo Mar <[email protected]> wrote:
> > Hi All,
> >
> > I would like to know whether "search domain option" is being handled from
> > connman's internal dns proxy?
> > As connman by default runs with dnsproxy enabled, /etc/resolv.conf
> entries
> > will be like below
> >
> > # Generated by Connection Manager
> > nameserver 127.0.0.1
> > nameserver ::1
> >
> > So even domain names got from DHCP server is not added in
> /etc/resolv.conf.
> > But this domain name can be seen in service configuration settings from
> > list-services which connman handled internally
> >
> > Timeservers.Configuration = [ ]
> > Domains = [ mydomain.example ]
> > Domains.Configuration = [ ]
> >
> >
> > When we try to ping to subdomains in local network, It will not work as
> > expected like for example if we have a server "mydomain.example" at
> > 192.168.1.10 with a subdomain "myhost.mydomain.example". It is expected
> to
> > "ping myhost" to send it's packages to 192.168.1.10 which is not
> happening
> > in connman. if connman is started with -r option (disable dnsproxy) "ping
> > myhost" is working properly.
> >
> > I have tried using connman 1.25 and now with 1.33 also same behavior.
> >
> > Can someone help me in explaining is it the expected behavior or an
> issue in
> > connman dnsproxy handling?
> >
> > Regards,
> >
> > _______________________________________________
> > 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/20160912/bfbba1e2/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 12 Sep 2016 14:01:40 +0200
From: "l.genevet" <[email protected]>
To: Patrik Flykt <[email protected]>, [email protected]
Subject: Re: Question about "MoveBefore" and notifications
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
We finally updated with the latest connman and ofono version, and the
issue is not reproduced anymore :
- after a moveBefore, the services are reordered according to the
default route.
Thanks for the support,
Lidwine
On 09/08/2016 15:48, Patrik Flykt wrote:
> Hi,
>
> On Mon, 2016-08-01 at 14:50 +0200, l.genevet wrote:
>> I am working on an connman integrated in an embedded system for home
>> automation. We are using Connman 1.23
> Ouch. Please upgrade to latest, we have fixed a few metric tons of bugs
> since then. ConnMan 1.33 is 100% API compatible with 1.23, and if you
> discover that it isn't, it's our fault and we will fix it immediately.
>
> Latest oFono releases also contain bug fixes.
>
>> with an Ofono plugin to be able to switch to a GSM modem in case of
>> an issue with the ethernet interface.
>>
>> If we are not able to ping our server even if the ethernet service is
>> ready, we would like to force the switch to the GSM. For that, we use
>> the connman Service MoveBefore API.
>>
>> After MoveBefore :
>> - the GSM interface is used.
>> - the default route is up to date.
>> But
>> - connman does not notify a change of State on the ethernet or the
>> GSM
>> interface.
>> - the services are not reordered after the switch.
> The problem with MoveBefore and MoveAfter is that they don't
> unfortunately keep services ordered forever. And the services are
> ordered internally by ConnMan every time a state changes or a new
> service is discovered, which can mean pretty much immediately.
>
> The ServicesChanged signal contains the latest order, the topmost entry
> is the one with the default route set if it is in states 'ready' or
> 'online'. But ServicesChanged are sent with a delay, meaning that
> ConnMan has enough time to decide to re-sort the services list and end
> up with the same order as before the switch before sending out the
> signal... So currently MoveBefore/MoveAfter are not that useful and
> require a bit more coding to get properly done.
>
>> Is this seems like a normal behaviour ?
>>
>> Are there any other way to be notified via connman that the default
>> route has changed?
>> I saw that IPv4 "Gateway" field of the ethernet interface disappears
>> once MoveBefore GSM has changed -> can I use that information to be
>> sure
>> ethernet does not have the default route anymore?
> Individual services should send out information for any changed
> property, please try with the latest version and see if your problem
> persists.
>
> Cheers,
>
> Patrik
------------------------------
Message: 3
Date: Mon, 12 Sep 2016 14:47:59 +0200
From: Maxime CHEVALLIER <[email protected]>
To: <[email protected]>
Subject: Persistent service ordering
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi all,
I am currently having issues with service ordering on connman 1.33 :
We have 2 technologies available : ethernet and cellular, none of which
can access the web to perform the online check.
The cellular interface accesses a private cellular network
( we can nslookup connman.net but not ping or wget it ),
and the ethernet interface is connected to a local network.
In our usecase, we want to put the cellular service before the ethernet
one to get the default route on cellular, but when using move-before,
connman reorders the ethernet service every time there is a change on
a service.
We tried the following /etc/connman/main.conf :
[General]
NetworkInterfaceBlacklist=uap0,uap1,wfd0
PreferredTechnologies=cellular,ethernet,wifi,bluetooth
We unfortunately get the same behaviour, with ethernet switching back
to
first service moments after the "move-before".
I might have missed something while configuring my system, is there a
correct way to 'force' the cellular service to always get the
default route ?
I have seen recently some other threads with similar issues, sorry if
this
was answered before.
Thanks,
Regards,
Maxime
------------------------------
Message: 4
Date: Mon, 12 Sep 2016 17:50:36 +0300
From: Ioan-Adrian Ratiu <[email protected]>
To: [email protected]
Subject: [PATCH v2] service: Add AlwaysConnectedTechnologies option
Message-ID: <[email protected]>
Add a new list option that enables auto-connecting all technologies
which also contain AutoConnect=true regradless of the setting for
PreferredTechnologies. The default AlwaysConnectedTechnologies value
is empty which keeps the current behaviour intact, i.e. if a higher
preffered technology is already connected, others will not autoconnect.
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 | 18 ++++++++++++++++++
src/main.conf | 7 +++++++
src/service.c | 22 ++++++++++++++++++++--
3 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/src/main.c b/src/main.c
index fdb4f72..462ac15 100644
--- a/src/main.c
+++ b/src/main.c
@@ -67,6 +67,7 @@ static struct {
char **pref_timeservers;
unsigned int *auto_connect;
unsigned int *preferred_techs;
+ unsigned int *always_connected_techs;
char **fallback_nameservers;
unsigned int timeout_inputreq;
unsigned int timeout_browserlaunch;
@@ -81,6 +82,7 @@ static struct {
.pref_timeservers = NULL,
.auto_connect = NULL,
.preferred_techs = NULL,
+ .always_connected_techs = NULL,
.fallback_nameservers = NULL,
.timeout_inputreq = DEFAULT_INPUT_REQUEST_TIMEOUT,
.timeout_browserlaunch = DEFAULT_BROWSER_LAUNCH_TIMEOUT,
@@ -95,6 +97,7 @@ static struct {
#define CONF_BG_SCAN "BackgroundScanning"
#define CONF_PREF_TIMESERVERS "FallbackTimeservers"
#define CONF_AUTO_CONNECT "DefaultAutoConnectTechnologies"
+#define CONF_ALWAYS_CONNECTED_TECHS "AlwaysConnectedTechnologies"
#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_ALWAYS_CONNECTED_TECHS,
CONF_PREFERRED_TECHS,
CONF_FALLBACK_NAMESERVERS,
CONF_TIMEOUT_INPUTREQ,
@@ -295,6 +299,17 @@ static void parse_config(GKeyFile *config)
g_clear_error(&error);
str_list = __connman_config_get_string_list(config, "General",
+ CONF_ALWAYS_CONNECTED_TECHS, &len, &error);
+
+ if (!error)
+ connman_settings.always_connected_techs =
+ parse_service_types(str_list, len);
+
+ g_strfreev(str_list);
+
+ g_clear_error(&error);
+
+ str_list = __connman_config_get_string_list(config, "General",
CONF_FALLBACK_NAMESERVERS, &len, &error);
if (!error)
@@ -572,6 +587,9 @@ unsigned int *connman_setting_get_uint_list(const char *key)
if (g_str_equal(key, CONF_PREFERRED_TECHS))
return connman_settings.preferred_techs;
+ if (g_str_equal(key, CONF_ALWAYS_CONNECTED_TECHS))
+ return connman_settings.always_connected_techs;
+
return NULL;
}
diff --git a/src/main.conf b/src/main.conf
index acceda3..d619413 100644
--- a/src/main.conf
+++ b/src/main.conf
@@ -101,3 +101,10 @@
# quality. See RFC6343. Default value is false (as recommended by RFC6343
# section 4.1).
# Enable6to4 = false
+
+# List of technologies with AutoConnect = true which are always connected
+# regardless of PreferredTechnologies setting. Default value is empty and
+# will connect a technology only if it is at a higher preference than any
+# other which is already connected.
+# This setting has no effect if SingleConnectedTechnologies is enabled.
+# AlwaysConnectedTechnologies =
diff --git a/src/service.c b/src/service.c
index 37af5fc..98acd14 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;
}
+bool __connman_service_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;
+
GList *list;
DBG("preferred %d sessions %d reason %s", preferred, active_count,
@@ -3776,8 +3790,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
(__connman_service_always_connect(service->type))
+ continue;
+ else
+ return true;
+ }
ignore[service->type] = true;
autoconnecting = true;
--
2.9.3
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 11, Issue 14
***************************************
