[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
3 years, 7 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 ]
3 years, 9 months
[PATCH] ofono: Fix shared usage of interface index
by Lukasz Nowak
From: Lukasz Nowak <lnowak(a)tycoint.com>
IPv4 and IPv6 share the interface index value in the network_context structure.
Because of that, they should not overwrite it with -1 every time a Settings
or IPv6.Setting modem property is received.
Problem observed when a modem was first reporting IPv4 Settings, with a valid
interface name and method dhcp. And then IPv6.Settings with method=OFF and
no interface name.
In that case, extract_ipv6_settings would wrongly set context->index = -1
causing the set_connected() fail and modem being incorrectly kept disconnected.
---
plugins/ofono.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/plugins/ofono.c b/plugins/ofono.c
index f6b2b52..78f8f19 100644
--- a/plugins/ofono.c
+++ b/plugins/ofono.c
@@ -841,7 +841,6 @@ static void extract_ipv4_settings(DBusMessageIter *array,
connman_ipaddress_free(context->ipv4_address);
context->ipv4_address = NULL;
- context->index = -1;
if (dbus_message_iter_get_arg_type(array) != DBUS_TYPE_ARRAY)
return;
@@ -944,7 +943,6 @@ static void extract_ipv6_settings(DBusMessageIter *array,
connman_ipaddress_free(context->ipv6_address);
context->ipv6_address = NULL;
- context->index = -1;
if (dbus_message_iter_get_arg_type(array) != DBUS_TYPE_ARRAY)
return;
--
2.7.4
3 years, 9 months
[PATCH] ofono: Fix segfault during modem_removed
by Lukasz Nowak
From: Lukasz Nowak <lnowak(a)tycoint.com>
Prevent sending any further dbus messages after modem_removed signal.
Sequence causing a segfault is:
- modem_removed
- remove_modem
- remove_all_contexts
- remove_cm_context
- remove_network
- connman_device_remove_network
- network_disconnect
- context_set_active
- set_property
---
plugins/ofono.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/plugins/ofono.c b/plugins/ofono.c
index 70b085a..f6b2b52 100644
--- a/plugins/ofono.c
+++ b/plugins/ofono.c
@@ -2500,16 +2500,19 @@ static void remove_modem(gpointer data)
if (modem->call_set_property) {
dbus_pending_call_cancel(modem->call_set_property);
dbus_pending_call_unref(modem->call_set_property);
+ modem->call_set_property = NULL;
}
if (modem->call_get_properties) {
dbus_pending_call_cancel(modem->call_get_properties);
dbus_pending_call_unref(modem->call_get_properties);
+ modem->call_get_properties = NULL;
}
if (modem->call_get_contexts) {
dbus_pending_call_cancel(modem->call_get_contexts);
dbus_pending_call_unref(modem->call_get_contexts);
+ modem->call_get_contexts = NULL;
}
/* Must remove the contexts before the device */
@@ -2699,6 +2702,9 @@ static int network_connect(struct connman_network *network)
DBG("%s network %p", modem->path, network);
+ if (!g_hash_table_lookup(modem_hash, modem->path))
+ return -ENODEV;
+
context = get_context_with_network(modem->context_list, network);
if (!context)
return -ENODEV;
@@ -2720,6 +2726,9 @@ static int network_disconnect(struct connman_network *network)
DBG("%s network %p", modem->path, network);
+ if (!g_hash_table_lookup(modem_hash, modem->path))
+ return -ENODEV;
+
context = get_context_with_network(modem->context_list, network);
if (!context)
return -ENODEV;
--
2.7.4
3 years, 9 months
Probably roaming right now!
by Fred Ollinger
I wanted to express gratitude for past emails which were very helpful.
I have a test that will connect and disconnect from a given access point.
WIFI=valid access point path
connmanctl connect $WIFI
# wait for connected
connmanctl disconnect $WIFI
#wait for disconnect then repeat
This test works for a few connects/disconnects then I get "Probably roaming right now!"
However, there's no DBUS signal that anything has changed aka that I'm "online".
Trying to connect again with connmanctl says I'm all ready connected. But when I check for a connection via DBUS, it says I'm not connected.
What's going on?
1. What state am I in? Connected/disconnected?
2. How can I know via DBUS what state I'm in?
3. Is there a way to prevent this from happening? Ideally, I'd like to be "online" as fast as possible like it did the first few connections.
Thanks in advance.
Frederick Ollinger
Software Engineer
Seescan, Inc.
3 years, 10 months
[PATCH] Remove IPv4.gateway key in settings if gateway is not configured
by Craig McQueen
---
src/ipconfig.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/ipconfig.c b/src/ipconfig.c
index 7fdc024..bae988c 100644
--- a/src/ipconfig.c
+++ b/src/ipconfig.c
@@ -2335,6 +2335,8 @@ int __connman_ipconfig_save(struct connman_ipconfig *ipconfig,
if (ipconfig->address->gateway)
g_key_file_set_string(keyfile, identifier,
key, ipconfig->address->gateway);
+ else
+ g_key_file_remove_key(keyfile, identifier, key, NULL);
g_free(key);
return 0;
--
2.7.4
3 years, 10 months
[PATCH v2] service: Allow removing service in idle state
by Harish Jenny K N
Changes from v1:
- updated the documentation in doc/service-api.txt
- paraphrase the commit message.
Harish Jenny K N (1):
service: Allow removing service in idle state
doc/service-api.txt | 4 ++--
src/service.c | 3 +--
2 files changed, 3 insertions(+), 4 deletions(-)
--
1.9.1
3 years, 10 months
amazing weekend
by Cliff McDiarmid
Hi friend!
We've spent a really wonderful weekend in a very nice place, please take a look at that http://6url.ru/lZrg
Pardon my monkey thumbs, Cliff McDiarmid
3 years, 10 months
difference between wifi states
by Fred Ollinger
>From the documentation there's a "ready" state and an "online" state.
While connecting to wifi using conmann, I noticed that "ready" is much faster than "online".
My question is what's the difference b/w "ready" and "online"?
If a wifi connection is "ready" can I connect to the Internet?
I'm trying to determine whether I should use "ready" or "online" to determine whether a connection is successful.
"ready" would be better because it's faster.
Thanks.
Frederick Ollinger
Software Engineer
Seescan, Inc
3 years, 10 months
Where does connman find these DNS ?
by Pierre Couderc
I find 2 unexpected (IPCV6) DNS in my resolv.conf generated by connman.
An they are in 1rst position masking my "main" DNS....
Where do they come from ? how to trace where connman find them.
I am under debian jessie.
Thabk you in advance,
PC
3 years, 10 months
