[PATCH 0/5] Avoid to keep service in list if AP is not found during scan
by blanquicet＠gmail.com
From: Jose Blanquicet <jose.blanquicet-melendez(a)magnetimarelli.com>
This patch set does not remove any auto-connect/roaming functionality,
it aims to avoit keeping service in the list after AP deauthenticate
us and it is not found in the scan.
The first three patches revert the patches that add the connectable
flag because such implementation prevents ConnMan to remove the service
from the services list when it is no longer in range, resulting in a
confusion for users because they will continue seeing a service in their
list when it is not actually available.
Doing so, ConnMan will remove the service as other services and then,
once it comes back, wpa_s will notify ConnMan about it through a
"BSSAdded" signal which will start auto-connect procedure and state
machines would continue correctly. In case wpa_s does not send such
signal before notifying we got connected, which should not happen, the
last two patches of this set introduce a notification named
"network_associated" which should handle this border case. I tested it
by simulating ConnMan do not process "BSSAdded" signals and it worked,
it means that state machines moved correctly and connection trigger
from wpa_s completed successfully.
I do not think I could trigger all use cases thus I would appreciate if
people could test auto-connect and roaming use cases. Mainly
auto-connect when AP is who deauthenticate STA. For instance, Saurav
Babu in the scenario he recently mentioned when AP blocks STA's MAC
address.
Jose Blanquicet (5):
Revert "device: Use network's connectable flag"
Revert "plugins/wifi: Marking network's Connectable flag as true."
Revert "network: connectable flag in network structure"
gsupplicant: Add callback to notify the associated network
wifi: Set current network in case of reconnection
gsupplicant/gsupplicant.h | 1 +
gsupplicant/supplicant.c | 25 +++++++++++++++
include/network.h | 5 ---
plugins/wifi.c | 82 +++++++++++++++++++++++++++++------------------
src/device.c | 6 +---
src/network.c | 13 --------
6 files changed, 78 insertions(+), 54 deletions(-)
--
1.9.1
2 years, 8 months
Connman to control OpenVPN connection
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 ]
2 years, 9 months
[PATCH] technology: Deny P2P finding if technology is disabled
by blanquicet＠gmail.com
From: Jose Blanquicet <jose.blanquicet-melendez(a)magnetimarelli.com>
Currently, when a scan is requested, it is only check if device is powered. It
prevents to start scanning or finding if WiFi technology is disabled. However,
when WiFi technolgy is enabled but P2P technology is not, the P2P finding
can be started anyway. This patch prevents it by adding an additional control
on the technology status only in case the technology where scan was requested is
P2P, doing so the return values for WiFi technology will not change.
---
src/technology.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/technology.c b/src/technology.c
index 4574f1e..d2f0ae2 100644
--- a/src/technology.c
+++ b/src/technology.c
@@ -1077,6 +1077,10 @@ static DBusMessage *scan(DBusConnection *conn, DBusMessage *msg, void *data)
DBG("technology %p request from %s", technology,
dbus_message_get_sender(msg));
+ if (technology->type == CONNMAN_SERVICE_TYPE_P2P &&
+ !technology->enabled)
+ return __connman_error_permission_denied(msg);
+
dbus_message_ref(msg);
technology->scan_pending =
g_slist_prepend(technology->scan_pending, msg);
--
1.9.1
2 years, 11 months
[PATCH] main: Make --noplugin option repeatable
by Slava Monich
---
src/main.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/main.c b/src/main.c
index 915c17e..651b3e2 100644
--- a/src/main.c
+++ b/src/main.c
@@ -511,6 +511,21 @@ static bool parse_debug(const char *key, const char *value,
return true;
}
+static bool parse_noplugin(const char *key, const char *value,
+ gpointer user_data, GError **error)
+{
+ if (option_noplugin) {
+ char *prev = option_noplugin;
+
+ option_noplugin = g_strconcat(prev, ",", value, NULL);
+ g_free(prev);
+ } else {
+ option_noplugin = g_strdup(value);
+ }
+
+ return true;
+}
+
static GOptionEntry options[] = {
{ "config", 'c', 0, G_OPTION_ARG_STRING, &option_config,
"Load the specified configuration file "
@@ -524,7 +539,7 @@ static GOptionEntry options[] = {
"Specify networking interface to ignore", "DEV" },
{ "plugin", 'p', 0, G_OPTION_ARG_STRING, &option_plugin,
"Specify plugins to load", "NAME,..." },
- { "noplugin", 'P', 0, G_OPTION_ARG_STRING, &option_noplugin,
+ { "noplugin", 'P', 0, G_OPTION_ARG_CALLBACK, &parse_noplugin,
"Specify plugins not to load", "NAME,..." },
{ "wifi", 'W', 0, G_OPTION_ARG_STRING, &option_wifi,
"Specify driver for WiFi/Supplicant", "NAME" },
--
1.9.1
2 years, 11 months
[PATCH] gsupplicant: Do not modify ConfigMethods if they are already set
by blanquicet＠gmail.com
From: Jose Blanquicet <jose.blanquicet-melendez(a)magnetimarelli.com>
If ConnMan does not allow to configure the value to be set to ConfigMethods,
then it should not modify the ones that were configured on wpa_s.
With this patch ConnMan will first verify if the ConfigMethods were already set
on wpa_s before setting its ones. Doing so, ConnMan will not change the
configuration users already set at wpa_s level.
---
gsupplicant/supplicant.c | 39 ++++++++++++++++++++++++++++++++-------
1 file changed, 32 insertions(+), 7 deletions(-)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 36c4dd5..4a1d147 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -2111,10 +2111,37 @@ static void interface_bss_removed(DBusMessageIter *iter, void *user_data)
static void set_config_methods(DBusMessageIter *iter, void *user_data)
{
- const char *config_methods = "push_button";
+ dbus_message_iter_append_basic(iter, DBUS_TYPE_STRING, user_data);
+}
+
+static void wps_property(const char *key, DBusMessageIter *iter,
+ void *user_data)
+{
+ GSupplicantInterface *interface = user_data;
+
+ if (!interface)
+ return;
+
+ SUPPLICANT_DBG("key: %s", key);
+
+ if (g_strcmp0(key, "ConfigMethods") == 0) {
+ const char *config_methods = "push_button", *str = NULL;
+
+ dbus_message_iter_get_basic(iter, &str);
+ if (str && strlen(str) > 0) {
+ // It was already set at wpa_s level, don't modify it.
+ SUPPLICANT_DBG("%s", str);
+ return;
+ }
+
+ supplicant_dbus_property_set(interface->path,
+ SUPPLICANT_INTERFACE ".Interface.WPS",
+ "ConfigMethods", DBUS_TYPE_STRING_AS_STRING,
+ set_config_methods, NULL, &config_methods, NULL);
+
+ SUPPLICANT_DBG("No value. Set %s", config_methods);
+ }
- dbus_message_iter_append_basic(iter, DBUS_TYPE_STRING,
- &config_methods);
}
static void interface_property(const char *key, DBusMessageIter *iter,
@@ -2143,11 +2170,9 @@ static void interface_property(const char *key, DBusMessageIter *iter,
debug_strvalmap("Mode capability", mode_capa_map,
interface->mode_capa);
-
- supplicant_dbus_property_set(interface->path,
+ supplicant_dbus_property_get_all(interface->path,
SUPPLICANT_INTERFACE ".Interface.WPS",
- "ConfigMethods", DBUS_TYPE_STRING_AS_STRING,
- set_config_methods, NULL, NULL, NULL);
+ wps_property, interface, interface);
if (interface->ready)
callback_interface_added(interface);
--
1.9.1
2 years, 11 months
[PATCH] timeserver: Update nameservers when DNS changed.
by Antoine Aubert
When the IP address changes, DNS provided by the DHCP may change.
We should update namerver list.
Bug seen on various internet provider box. During xDSL syncronisation,
the first DNS server is a fake one. Later, a renew set another DNS.
---
src/timeserver.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/timeserver.c b/src/timeserver.c
index f0d33e5..0e555a7 100644
--- a/src/timeserver.c
+++ b/src/timeserver.c
@@ -291,6 +291,8 @@ static void ts_recheck_enable(void)
int __connman_timeserver_sync(struct connman_service *default_service)
{
struct connman_service *service;
+ char **nameservers;
+ int i;
if (default_service)
service = default_service;
@@ -314,6 +316,17 @@ int __connman_timeserver_sync(struct connman_service *default_service)
if (resolv_id > 0)
g_resolv_cancel_lookup(resolv, resolv_id);
+ g_resolv_flush_nameservers(resolv);
+
+ nameservers = connman_service_get_nameservers(service);
+ if (!nameservers)
+ return -EINVAL;
+
+ for (i = 0; nameservers[i]; i++)
+ g_resolv_add_nameserver(resolv, nameservers[i], 53, 0);
+
+ g_strfreev(nameservers);
+
g_slist_free_full(ts_list, g_free);
ts_list = __connman_timeserver_get_all(service);
--
2.9.3
2 years, 11 months
None
by Daniel Wagner
Hi,
I pestered Marcel for a release a bit during ELC last week. He agreed to
do one. A soon it is done patches will will get applied again. Sorry for
the inconvenience.
Thanks,
Daniel
2 years, 11 months
Create statistics file and service folder strictly only after successful connect
by Jose Blanquicet
Hi,
We noticed that the service directory and the statistics file are
created even if the connection is not successful because for example
user entered an incorrect key.
I think that it is because before starting the connection process,
ConnMan tries to read the statistics file in
service.c:service_connect(). Doing so, the function
__connman_stats_service_register() will create the directory and the
file if they do not exists. I saw that commit 50fb779bc95 already
tried to solved this but it still happens.
To solve this, I propose to either do the same of 50fb779bc95 in
service_connect():
- if (__connman_stats_service_register(service) == 0) {
+ if (!service->new_service &&
+
__connman_stats_service_register(service) == 0) {
Or, maybe better, why ConnMan needs to access the file that early?
Shouldn't it be done when service goes into CONFIGURATION state or
READY state for new services? If it does not break any statistics
feature, I would suggest to completely remove that piece of code from
service_connect():
- if (__connman_stats_service_register(service) == 0) {
- __connman_stats_get(service, false,
- &service->stats.data);
- __connman_stats_get(service, true,
- &service->stats_roaming.data);
- }
What do yo think?
Regards,
Jose Blanquicet
2 years, 11 months
[PATCH v2 1/1] doc: add online check information
by Ingo Albrecht
Add new info from connman.net server admin to README.
Mention the online check in the manual so that end users have a reference why the client
opens an external route.
---
diff --git a/README b/README
index 1e066ce7..2cc1cb6a 100644
--- a/README
+++ b/README
@@ -389,7 +389,10 @@ During the online check procedure, ConnMan will temporarily install
a host route to both the ipv4.connman.net and ipv6.connman.net so that
the online check query can be directed via the correct network
interface which the connected service is using. This host route is
-automatically removed when the online check is done.
+automatically removed when the online check is done. While ConnMan has no
+option to skip or disable the online check, note that the server expressly
+does not log any connection information, including IPv4/6 addresses of
+connecting clients.
ConnMan sends this very minimal information in http header when doing
the online check request (example):
diff --git a/doc/connman.conf.5.in b/doc/connman.conf.5.in
index 9b28aada..c113ac3c 100644
--- a/doc/connman.conf.5.in
+++ b/doc/connman.conf.5.in
@@ -145,5 +145,15 @@ ethernet tethering.
AllowHostnameUpdates = false
TetheringTechnologies = ethernet,wifi,bluetooth,gadget
.fi
+.SH "NOTES"
+When a service is connected, ConnMan tries to detect if it has internet
+connectivity or not. During this online check procedure, ConnMan will
+temporarily install a host route to both ipv4.connman.net and
+ipv6.connman.net so that the online check query can be directed via the
+correct network interface which the connected service is using.
+
+Currently there is no option to skip or disable this online check. ConnMan,
+however, limits transmitted data to a minimum. See the ConnMan README for
+more information.
.SH "SEE ALSO"
2 years, 11 months
Monitoring online status
by Antoine Aubert
Hi,
Does connman can monitor 'online' service status ? When 'internet' can't
be reached ? i.e loosing xDSL sync ...
As I understand, once service became online (and all stuff checked), It
never go backward, until hardware event. (unpluged ...) Am I wrong ?
May we use wispr to check connectivity ? By polling ?
Regards,
--
Antoine Aubert
a.aubert(a)overkiz.com
2 years, 12 months
