January 2017 - connman

by Florent Le Saout

Hello, I'm trying to get vpn connection managed by connman. I've been looking in the documentation in the sources or website, but didn't find my answer yet. So far, I can connect to my OpenVPN server manually via connmanctl, so I guess my vpn config file is quite ok. But the remaining question is about the autoconnection and link verification. From my understanding autoconnect, reconnect etc, that we can configure in main config file only applies to technologies, but VPNs are not technologies from connman perspectives, so they are listed as service (maybe my statement here is not correct ?). My goal is to be able, as soon as I get proper network connection, either by ethernet, cellular or wifi technologies to get connected to my vpn server and in case of disconnection (so implicitly a connection check is done in background) to get reconnected. * How to setup autoconnect and reconnect with OpenVPN (also in case we change technology from ethernet to cellular for instance) ? * Regarding routes, I would like to know how to apply the routes pushed by the OpenVPN server as the default route? * Regarding DNS server, I also would like to know how to get the DNS pushed by the OpenVPN applied in resolv.conf ? If my questions are unclear feel free to ask. Below you can find more details about my setup. Thanks, Florent. ---------------------------------------------------------------------------- My setup is : * connman 1.33 * connman-vpnd * connman-plugin-vpn * openvpn 2.3.14 My VPN config file is : [global] Name = OpenVPVN Description = OepnVPN custom configuration [provider_openvpn] Type = OpenVPN Name = Custom VPN Host = MY_SERVER_IP Domain = MY_DOMAIN Networks = 192.168.1.0/255.255.255.0/10.8.0.1,192.168.0.0/255.255.0.0/10.8.0.1 OpenVPN.ConfigFile=/etc/openvpn/client-openvpn.conf My VPN config stored by connman is : connmanctl> services vpn_MY_SERVER_IP_MY_DOMAIN /net/connman/service/vpn_MY_SERVER_IP_MY_DOMAIN Type = vpn Security = [ ] State = ready Favorite = True Immutable = False AutoConnect = False Name = Custom VPN IPv4 = [ Method=fixed, Address=10.8.0.18, Netmask=255.255.255.255, Gateway=MY_SERVER_IP ] IPv4.Configuration = [ Method=fixed, Address=10.8.0.18, Netmask=255.255.255.255, Gateway=MY_SERVER_IP ] IPv6 = [ ] IPv6.Configuration = [ Method=off ] Nameservers = [ 10.8.0.1 ] Nameservers.Configuration = [ ] Timeservers = [ ] Timeservers.Configuration = [ ] Domains = [ ran.com ] Domains.Configuration = [ ] Proxy = [ Method=direct ] Proxy.Configuration = [ ] Provider = [ Host=MY_SERVER_IP, Type=openvpn ]

3 years, 10 months

2
10
0 / 0

Service remains on service list even if it is not longer available

by Jose Blanquicet

Hi, When we get disconnected because of AP we are connected to goes out of range. ConnMan keeps showing such AP in the services list even though it is not longer available (We cannot connect to it). In addition, such AP will continue in our service list even if we connect to a new one. What is the propose of keeping that AP in the services list? From our point of view it creates confusion to the user. We would prefer to not do that, what do people think? Regards, Jose Blanquicet

4 years

2
5
0 / 0

[PATCH] service: Add EnableOnlineCheck config option

by Ingo Albrecht

>Hi Lukasz, > >On 01/26/2017 06:51 PM, Lukasz Nowak wrote: >> From: Lukasz Nowak <lnowak at tycoint.com> >> >> 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. > >Isn't > > ./configure --disable-wispr > >good enough? > >Thanks, >Daniel Hi, no it isn't. In fact the online check as it is done so far (default enabled, no option to turn it off, no mention of it in the manpage, no privacy policy available for the nginx server replying on how it cycles logs) can quickly get this project into trouble. The current implementation clearly violates privacy laws (EU-wide for starters). You clearly should not only implement a user-configurable option for it, but also default it to off (default off gets you a consent of the user to the use of the online check service). I can give you more input on the why, if you require it. But this case is _very_ clear. Regards, Ingo

4 years

3
8
0 / 0

Wi-Fi specific information in connman

by Saurav Babu

Hi, There are few applications which require Wi-Fi specific informations like MAC Address, Frequency/Channel of AP. Is there any specific reason that these informations are not stored by connman? Will you accept patches which provides these specific informations to applications at upper layer? Thanks, Saurav

4 years, 1 month

4
5
0 / 0

[PATCH v4 0/8] session: Add per-interface routing

by Lukasz Nowak

From: Lukasz Nowak <lnowak(a)tycoint.com> changes from v3: - fixed compiler warnings - marked new session config fields as experimental changes from v2: - implemented source IP rule in firewall-nftables - using "*" or "" for AllowedInterface allows any interface changes from v1: - added documentation - split firewall and session changes into separate commits - cosmetic updates after v1 review Adding a new feature to the sessions, which allows applications to direct routed traffic to a specific network interface. This requires that multiple default routes with gateways are set up, one for each interface. And then iproute and iptables rules need to be added to direct traffic based on source ip address, to the correct routing table. Applications can use bind before connect mechanism, to bind sockets to required interfaces. The application side can be tested with: ping -I <interface_ip> <target_ip> Use case for this is to have multiple network interfaces available for external traffic at the same time. It can be used to validate that a full path to an external server is working properly, by maintaining multiple tcp connections, one for each interface. Lukasz Nowak (8): session: Fix default route for ppp services session: Add AllowedInterface config parameter client: Add session AllowedInterface config firewall: Add fwmark based on source ip address session: Add source ip rule session: Remove old session rules and routes after a config change client: Add session source ip rule doc: Session multi-interface routing client/commands.c | 39 ++++++++++++ doc/session-api.txt | 23 +++++++ doc/session-overview.txt | 31 +++++++++ include/session.h | 2 + src/connman.h | 3 +- src/firewall-iptables.c | 11 +++- src/firewall-nftables.c | 108 ++++++++++++++++++++++++++----- src/session.c | 162 ++++++++++++++++++++++++++++++++++++++++++++--- 8 files changed, 353 insertions(+), 26 deletions(-) -- 2.7.4

4 years, 1 month

2
10
0 / 0

[PATCH] service: Add EnableOnlineCheck config option

by Lukasz Nowak

From: Lukasz Nowak <lnowak(a)tycoint.com> 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

4 years, 1 month

2
6
0 / 0

[PATCH] inet: Prevent glib source from being removed twice

by Slava Monich

If GIOFunc callback returns FALSE, the event source is removed by glib. We either call g_source_remove or return FALSE from the callback. If we do both, the source is getting removed twice which glib considers a critical error. --- src/inet.c | 49 ++++++++++++++++++++++++++++--------------------- 1 file changed, 28 insertions(+), 21 deletions(-) diff --git a/src/inet.c b/src/inet.c index 553b57a..2c860cf 100644 --- a/src/inet.c +++ b/src/inet.c @@ -1252,13 +1252,12 @@ static gboolean rs_timeout_cb(gpointer user_data) return FALSE; } -static int icmpv6_recv(int fd, gpointer user_data) +static int icmpv6_recv(int fd, struct xs_cb_data *data) { struct msghdr mhdr; struct iovec iov; unsigned char chdr[CMSG_BUF_LEN]; unsigned char buf[1540]; - struct xs_cb_data *data = user_data; struct nd_router_advert *hdr; struct sockaddr_in6 saddr; ssize_t len; @@ -1280,7 +1279,6 @@ static int icmpv6_recv(int fd, gpointer user_data) len = recvmsg(fd, &mhdr, 0); if (len < 0) { cb(NULL, 0, data->user_data); - xs_cleanup(data); return -errno; } @@ -1291,7 +1289,6 @@ static int icmpv6_recv(int fd, gpointer user_data) return 0; cb(hdr, len, data->user_data); - xs_cleanup(data); return len; } @@ -1299,17 +1296,21 @@ static int icmpv6_recv(int fd, gpointer user_data) static gboolean icmpv6_event(GIOChannel *chan, GIOCondition cond, gpointer data) { int fd, ret; + struct xs_cb_data *xs_data = data; DBG(""); if (cond & (G_IO_NVAL | G_IO_HUP | G_IO_ERR)) - return FALSE; + goto remove; fd = g_io_channel_unix_get_fd(chan); - ret = icmpv6_recv(fd, data); + ret = icmpv6_recv(fd, xs_data); if (ret == 0) return TRUE; +remove: + xs_data->watch_id = 0; + xs_cleanup(xs_data); return FALSE; } @@ -1667,13 +1668,12 @@ void __connman_inet_ipv6_stop_recv_rs(void *context) xs_cleanup(context); } -static int icmpv6_rs_recv(int fd, gpointer user_data) +static int icmpv6_rs_recv(int fd, struct xs_cb_data *data) { struct msghdr mhdr; struct iovec iov; unsigned char chdr[CMSG_BUF_LEN]; unsigned char buf[1540]; - struct xs_cb_data *data = user_data; struct nd_router_solicit *hdr; struct sockaddr_in6 saddr; ssize_t len; @@ -1712,17 +1712,20 @@ static gboolean icmpv6_rs_event(GIOChannel *chan, GIOCondition cond, gpointer data) { int fd, ret; + struct xs_cb_data *xs_data = data; DBG(""); if (cond & (G_IO_NVAL | G_IO_HUP | G_IO_ERR)) - return FALSE; + goto remove; fd = g_io_channel_unix_get_fd(chan); - ret = icmpv6_rs_recv(fd, data); + ret = icmpv6_rs_recv(fd, xs_data); if (ret == 0) return TRUE; +remove: + xs_data->watch_id = 0; return FALSE; } @@ -1797,13 +1800,12 @@ static gboolean ns_timeout_cb(gpointer user_data) return FALSE; } -static int icmpv6_nd_recv(int fd, gpointer user_data) +static int icmpv6_nd_recv(int fd, struct xs_cb_data *data) { struct msghdr mhdr; struct iovec iov; unsigned char chdr[CMSG_BUF_LEN]; unsigned char buf[1540]; - struct xs_cb_data *data = user_data; struct nd_neighbor_advert *hdr; struct sockaddr_in6 saddr; ssize_t len; @@ -1825,7 +1827,6 @@ static int icmpv6_nd_recv(int fd, gpointer user_data) len = recvmsg(fd, &mhdr, 0); if (len < 0) { cb(NULL, 0, &data->addr.sin6_addr, data->user_data); - xs_cleanup(data); return -errno; } @@ -1844,7 +1845,6 @@ static int icmpv6_nd_recv(int fd, gpointer user_data) return 0; cb(hdr, len, &data->addr.sin6_addr, data->user_data); - xs_cleanup(data); return len; } @@ -1853,17 +1853,21 @@ static gboolean icmpv6_nd_event(GIOChannel *chan, GIOCondition cond, gpointer data) { int fd, ret; + struct xs_cb_data *xs_data = data; DBG(""); if (cond & (G_IO_NVAL | G_IO_HUP | G_IO_ERR)) - return FALSE; + goto remove; fd = g_io_channel_unix_get_fd(chan); - ret = icmpv6_nd_recv(fd, data); + ret = icmpv6_nd_recv(fd, xs_data); if (ret == 0) return TRUE; +remove: + xs_data->watch_id = 0; + xs_cleanup(xs_data); return FALSE; } @@ -2188,9 +2192,8 @@ static gboolean inet_rtnl_timeout_cb(gpointer user_data) return FALSE; } -static int inet_rtnl_recv(GIOChannel *chan, gpointer user_data) +static int inet_rtnl_recv(GIOChannel *chan, struct inet_rtnl_cb_data *rtnl_data) { - struct inet_rtnl_cb_data *rtnl_data = user_data; struct __connman_inet_rtnl_handle *rth = rtnl_data->rtnl; struct nlmsghdr *h = NULL; struct sockaddr_nl nladdr; @@ -2262,7 +2265,7 @@ static int inet_rtnl_recv(GIOChannel *chan, gpointer user_data) rtnl_data->callback(h, rtnl_data->user_data); - inet_rtnl_cleanup(rtnl_data); + return 1; } return 0; @@ -2272,16 +2275,20 @@ static gboolean inet_rtnl_event(GIOChannel *chan, GIOCondition cond, gpointer user_data) { int ret; + struct inet_rtnl_cb_data *rtnl_data = user_data; DBG(""); if (cond & (G_IO_NVAL | G_IO_HUP | G_IO_ERR)) - return FALSE; + goto remove; - ret = inet_rtnl_recv(chan, user_data); + ret = inet_rtnl_recv(chan, rtnl_data); if (ret != 0) return TRUE; +remove: + rtnl_data->watch_id = 0; + inet_rtnl_cleanup(rtnl_data); return FALSE; } -- 1.9.1

4 years, 1 month

2
5
0 / 0

[RFC] wifi: make max connection retries configurable

by Mans Rullgard

If when connecting to a wifi network, the authentication phase fails, connman draws the conclusion that the wifi password was wrong. This is a correct conclusion when wifi reception is good, but this can also occur on marginal wifi reception. This adds the setting FavoriteMaxRetries allowing the number of connection attempts to be changed from the default of 2. The effect can be observed by temporarily changing the psk of an access point after the connection has been established, thus causing it to drop. Restoring the original psk before the maximum retries have been reached lets the connection be reestablished. In a location with intermittent reception, allowing unlimited retries is useful to avoid connman permanently disabling the network. Signed-off-by: Mans Rullgard <mans(a)mansr.com> --- doc/connman.conf.5.in | 5 +++++ include/setting.h | 1 + plugins/wifi.c | 4 ++-- src/main.c | 15 +++++++++++++++ 4 files changed, 23 insertions(+), 2 deletions(-) diff --git a/doc/connman.conf.5.in b/doc/connman.conf.5.in index 9b28aada468a..e4a8174964d2 100644 --- a/doc/connman.conf.5.in +++ b/doc/connman.conf.5.in @@ -145,5 +145,10 @@ ethernet tethering. AllowHostnameUpdates = false TetheringTechnologies = ethernet,wifi,bluetooth,gadget .fi +.TP +.BI FavoriteMaxRetries=retries +Maximum number of times to attempt connecting to a known wifi service in +case of authentication failure. Set to negative to retry indefinitely. +Default value is 2. .SH "SEE ALSO" .BR connman (8) diff --git a/include/setting.h b/include/setting.h index a88202176f5e..3cb06101394a 100644 --- a/include/setting.h +++ b/include/setting.h @@ -34,6 +34,7 @@ unsigned int *connman_setting_get_uint_list(const char *key); unsigned int connman_timeout_input_request(void); unsigned int connman_timeout_browser_launch(void); +int connman_favorite_max_retries(void); #ifdef __cplusplus } diff --git a/plugins/wifi.c b/plugins/wifi.c index f8d88fa3ada0..558ccfbcb3cd 100644 --- a/plugins/wifi.c +++ b/plugins/wifi.c @@ -61,7 +61,6 @@ #define CLEANUP_TIMEOUT 8 /* in seconds */ #define INACTIVE_TIMEOUT 12 /* in seconds */ -#define FAVORITE_MAXIMUM_RETRIES 2 #define BGSCAN_DEFAULT "simple:30:-45:300" #define AUTOSCAN_DEFAULT "exponential:3:300" @@ -2357,7 +2356,8 @@ static bool handle_4way_handshake_failure(GSupplicantInterface *interface, wifi->retries++; if (connman_service_get_favorite(service)) { - if (wifi->retries < FAVORITE_MAXIMUM_RETRIES) + int max_retries = connman_favorite_max_retries(); + if (max_retries < 0 || wifi->retries < max_retries) return true; } diff --git a/src/main.c b/src/main.c index 915c17ec43a5..e0cba99b36ef 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; + int favorite_max_retries; } 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, + .favorite_max_retries = 2, }; #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_FAVORITE_MAX_RETRIES "FavoriteMaxRetries" 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_FAVORITE_MAX_RETRIES, NULL }; @@ -253,6 +257,7 @@ static void parse_config(GKeyFile *config) char *vendor_class_id; gsize len; int timeout; + int retries; if (!config) { connman_settings.auto_connect = @@ -393,6 +398,11 @@ static void parse_config(GKeyFile *config) if (!error) connman_settings.vendor_class_id = vendor_class_id; + retries = g_key_file_get_integer(config, "General", + CONF_FAVORITE_MAX_RETRIES, &error); + if (!error) + connman_settings.favorite_max_retries = retries; + g_clear_error(&error); } @@ -618,6 +628,11 @@ unsigned int connman_timeout_browser_launch(void) return connman_settings.timeout_browserlaunch; } +int connman_favorite_max_retries(void) +{ + return connman_settings.favorite_max_retries; +} + int main(int argc, char *argv[]) { GOptionContext *context; -- 2.11.0

4 years, 1 month

3
16
0 / 0

Re: [RFC] Proposal for ConnMan session API extensions

by Achtzehn Andreas (CM/ENA4)

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

4 years, 1 month

2
2
0 / 0

Auto-connect from wpa_supplicant and ConnMan does not become aware

by Jose Blanquicet

Hi, These are the steps to replicate this issue: 1. Connect to an AP (AP1) using WPS. After this, wpa_supplicant has new network profile on this interface marked as "Current", which is not tracked by ConnMan as is done for WPA2 connections. 2. Disconnect from it. At this point, the network profile is still present in wpa_supplicant but now it is inactive. 3. Try to connect to another AP (AP2) using WPS. 4. Let it go in time-out (2 min). 5. wpa_supplicant automatically re-connect to previous AP, the one corresponding to the network profile stored after the previous connection (AP1). The issue is that ConnMan is not aware of such a connection thus it continue showing WiFi Technology as "Disconnected" when it is not true any more. I checked why it is happening and I found that actually this only happens when first connection (Step 1) is done using WPS. It is because when ConnMan uses WPA2, first creates a profile network (AddNetwork() in terms of wpa_supplicant) and keeps track of it in order to delete it after a disconnection. Instead, for WPS, it is not created any profile network because it is automatically created by wpa_supplicant after receiving the WPS Credentials. Therefore, when ConnMan disconnects from AP1, it does not remove the network profile which is later used to automatic reconnection by wpa_supplicant. I asked if such a reconnection is a desired behaviour in wpa_supplican mailing list and Jouni confirmed this is how it should works and suggested a solution (http://lists.infradead.org/pipermail/hostap/2016-December/036844.html). He told that we need to keep track of the created network profiles during WPS provisioning (Yes, they may be more than one) and then mark them as disabled or delete them. What do you think? Regards, Jose Blanquicet

4 years, 1 month

2
4
0 / 0

2021

2020

2019

2018

2017

2016

2015

connman January 2017