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] Proposal for ConnMan session API extensions
(Achtzehn Andreas (CM/ENA4))
2. [PATCH] service: Add EnableOnlineCheck config option
(Lukasz Nowak)
----------------------------------------------------------------------
Message: 1
Date: Thu, 26 Jan 2017 16:44:23 +0000
From: "Achtzehn Andreas (CM/ENA4)" <[email protected]>
To: Daniel Wagner <[email protected]>, Lukasz Nowak
<[email protected]>, "Nakamura, Yusuke (ADITJ/SWG)"
<[email protected]>
Cc: "[email protected]" <[email protected]>, "Hoyer Marko
(ADITG/SWG)" <[email protected]>, "EXTERNAL Thorwirth Bjoern
(Brunel, CM-CI1/ERN5-E)" <[email protected]>,
"Ishikawa, Tetsuri (ADITJ/SWG)" <[email protected]>
Subject: Re: [RFC] Proposal for ConnMan session API extensions
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi Daniel,
Sorry for not getting back earlier. Comments are inline.
On Sun Jan 22 11:47:43 PST 2017 Daniel Wagner wrote:
> On 01/16/2017 02:00 PM, Nakamura, Yusuke (ADITJ/SWG) wrote:
>> We would like to propose two extensions to the session API interface of
>> ConnMan. The first extension enables a service differentiation for
>> processes run by the same user.It allows ConnMan to differentiate
>> between bearer usage permissions and the respective priorities based on
>> the requested service type.
>
> That should also be possible with the current code. You might need to
> write your own session plugin for this though. It is quite hard to
> support all types of application/user identification out of the box
> because it depends heavily on the system integrator's choices.
> [...]
> When we were discussing the initial API design, the exact same proposal
> for application identification was on the table. Marcel convinced me
> that this is a rather bad idea. Mainly because you need to trust the
> application to provide the correct ID. There is nothing which stops any
> random application to set the magic ID to get full connectivity.
We principally would not trust the provided service information alone. The idea
is to have the authentication of the application still implemented through
UID/GID/LSM, but allow the application to select from different operational
contexts. To elaborate on the example of the web browser, the browser would
know that it's now acting as facebook client and would inform ConnMan so in
session establishment phase or through a Change call. Then, ConnMan may apply a
different list of AllowedBearers (the selection and/or priority ordering may
change) and connect the application to a different bearer. Naturally, the
service tag will not be a security feature as the application may freely select
from the defined service scopes. Nevertheless, it would ease bearer management
for our application case (relieving the application from manually changing the
AllowedBearer list).
The modification would require an optional setting ("service"), for which we
would require to adjust also the session.c.
> I do not really follow the argumentation on the numbers of IP addresses
> and bearers. Are you trying to match several 'virtual machines' with one
> session? A Session is thought to be only used by one entity, until now
> that would a single application.
The different IP addresses would allow us to have several concurrent service
paths from a single entitity, similar to Lukasz patch for a local application
that would then use, e.g., bind-before-connect. The reason for having different
IPs is exactly about the concurrency issue that we foresee when a single user
has multiple paths open at the same time (different apps, etc.).
One more subtle difference is that our source IP extension would act on the
forwarding behavior of the host running ConnMan. In Lukasz patch the rule is
applied to a netfilter chain that is acting on local processes instead. Our
proposal may therefore be used for implementing, e.g., a webservice on a router
running ConnMan which would enable forwarding after authentication (just one
example). This also changes the meaning of "source IP" in our case. For Lukasz
patch the source IP apparently matches a local interface on the host running
ConnMan, while for us it's (as Lukasz I think pointed out already) an arbitrary
source IP.
Thanks,
Andreas
------------------------------
Message: 2
Date: Thu, 26 Jan 2017 17:51:24 +0000
From: Lukasz Nowak <[email protected]>
To: [email protected]
Subject: [PATCH] service: Add EnableOnlineCheck config option
Message-ID: <[email protected]>
From: Lukasz Nowak <[email protected]>
Global config option, which allows to enable/disable (enabled by default)
use of http get in wispr to transition a default service from READY to
ONLINE state.
---
doc/connman.conf.5.in | 10 ++++++++++
src/main.c | 14 ++++++++++++++
src/main.conf | 10 ++++++++++
src/service.c | 32 +++++++++++++++++++++++++++++++-
4 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/doc/connman.conf.5.in b/doc/connman.conf.5.in
index 9b28aad..17e8c8d 100644
--- a/doc/connman.conf.5.in
+++ b/doc/connman.conf.5.in
@@ -136,6 +136,16 @@ See RFC6343. Default value is false (as recommended by
RFC6343 section 4.1).
Set DHCP option 60 (Vendor Class ID) to the given string. This option can
be used by DHCP servers to identify specific clients without having to
rely on MAC address ranges, etc
+.TP
+.BI EnableOnlineCheck=true\ \fR|\fB\ false
+Enable use of http get as on online status check.
+When a service is in a READY state, and is selected as default,
+ConnMan will issue an HTTP GET request to verify that end-to-end
+connectivity is successful. Only then the service will be
+transitioned to ONLINE state.
+If this setting is false, a default service will transition from
+READY to ONLINE state as soon as a correct IP config is available
+(e.g from DHCP or manual). Default value is true.
.SH "EXAMPLE"
The following example configuration disables hostname updates and enables
ethernet tethering.
diff --git a/src/main.c b/src/main.c
index 915c17e..b3e6bc9 100644
--- a/src/main.c
+++ b/src/main.c
@@ -78,6 +78,7 @@ static struct {
bool persistent_tethering_mode;
bool enable_6to4;
char *vendor_class_id;
+ bool enable_online_check;
} connman_settings = {
.bg_scan = true,
.pref_timeservers = NULL,
@@ -94,6 +95,7 @@ static struct {
.persistent_tethering_mode = false,
.enable_6to4 = false,
.vendor_class_id = NULL,
+ .enable_online_check = true,
};
#define CONF_BG_SCAN "BackgroundScanning"
@@ -111,6 +113,7 @@ static struct {
#define CONF_PERSISTENT_TETHERING_MODE "PersistentTetheringMode"
#define CONF_ENABLE_6TO4 "Enable6to4"
#define CONF_VENDOR_CLASS_ID "VendorClassID"
+#define CONF_ENABLE_ONLINE_CHECK "EnableOnlineCheck"
static const char *supported_options[] = {
CONF_BG_SCAN,
@@ -128,6 +131,7 @@ static const char *supported_options[] = {
CONF_PERSISTENT_TETHERING_MODE,
CONF_ENABLE_6TO4,
CONF_VENDOR_CLASS_ID,
+ CONF_ENABLE_ONLINE_CHECK,
NULL
};
@@ -394,6 +398,13 @@ static void parse_config(GKeyFile *config)
connman_settings.vendor_class_id = vendor_class_id;
g_clear_error(&error);
+
+ boolean = __connman_config_get_bool(config, "General",
+ CONF_ENABLE_ONLINE_CHECK, &error);
+ if (!error)
+ connman_settings.enable_online_check = boolean;
+
+ g_clear_error(&error);
}
static int config_init(const char *file)
@@ -574,6 +585,9 @@ bool connman_setting_get_bool(const char *key)
if (g_str_equal(key, CONF_ENABLE_6TO4))
return connman_settings.enable_6to4;
+ if (g_str_equal(key, CONF_ENABLE_ONLINE_CHECK))
+ return connman_settings.enable_online_check;
+
return false;
}
diff --git a/src/main.conf b/src/main.conf
index d619413..1b7d3d9 100644
--- a/src/main.conf
+++ b/src/main.conf
@@ -102,6 +102,16 @@
# section 4.1).
# Enable6to4 = false
+# Enable use of http get as on online status check.
+# When a service is in a READY state, and is selected as default,
+# ConnMan will issue an HTTP GET request to verify that end-to-end
+# connectivity is successful. Only then the service will be
+# transitioned to ONLINE state.
+# If this setting is false, a default service will transition from
+# READY to ONLINE state as soon as a correct IP config is available
+# (e.g from DHCP or manual). Default value is true.
+# EnableOnlineCheck = true
+
# 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
diff --git a/src/service.c b/src/service.c
index 4e97a15..787ad10 100644
--- a/src/service.c
+++ b/src/service.c
@@ -5912,6 +5912,32 @@ int __connman_service_online_check_failed(struct
connman_service *service,
return EAGAIN;
}
+static gboolean no_wispr_callback(gpointer user_data)
+{
+ struct connman_service *service = user_data;
+ int refcount = service->refcount - 1;
+
+ DBG("service %p", service);
+
+ connman_service_unref(service);
+ if (refcount == 0) {
+ DBG("Service %p already removed", service);
+ return FALSE;
+ }
+
+ if (service->state_ipv4 == CONNMAN_SERVICE_STATE_READY)
+ __connman_service_ipconfig_indicate_state(service,
+ CONNMAN_SERVICE_STATE_ONLINE,
+ CONNMAN_IPCONFIG_TYPE_IPV4);
+
+ if (service->state_ipv6 == CONNMAN_SERVICE_STATE_READY)
+ __connman_service_ipconfig_indicate_state(service,
+ CONNMAN_SERVICE_STATE_ONLINE,
+ CONNMAN_IPCONFIG_TYPE_IPV6);
+
+ return FALSE;
+}
+
int __connman_service_ipconfig_indicate_state(struct connman_service *service,
enum connman_service_state new_state,
enum connman_ipconfig_type type)
@@ -5981,7 +6007,11 @@ int __connman_service_ipconfig_indicate_state(struct
connman_service *service,
case CONNMAN_SERVICE_STATE_CONFIGURATION:
break;
case CONNMAN_SERVICE_STATE_READY:
- if (type == CONNMAN_IPCONFIG_TYPE_IPV4) {
+ if (!connman_setting_get_bool("EnableOnlineCheck"))
+ {
+ g_idle_add(no_wispr_callback,
connman_service_ref(service));
+ }
+ else if (type == CONNMAN_IPCONFIG_TYPE_IPV4) {
check_proxy_setup(service);
service_rp_filter(service, true);
} else {
--
2.7.4
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 15, Issue 34
***************************************
