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: Monitoring online status (Patrik Flykt)
2. [PATCH] timeserver: Update nameservers when DNS changed.
(Antoine Aubert)
3. Re: Service remains on service list even if it is not longer
available (Jose Blanquicet)
4. [PATCH 0/5] Avoid to keep service in list if AP is not found
during scan ([email protected])
5. [PATCH 1/5] Revert "device: Use network's connectable flag"
([email protected])
6. [PATCH 2/5] Revert "plugins/wifi: Marking network's
Connectable flag as true." ([email protected])
7. [PATCH 3/5] Revert "network: connectable flag in network
structure" ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Fri, 17 Feb 2017 10:02:44 +0200
From: Patrik Flykt <[email protected]>
To: Antoine Aubert <[email protected]>, Daniel Wagner
<[email protected]>, [email protected]
Subject: Re: Monitoring online status
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Wed, 2017-02-15 at 17:05 +0100, Antoine Aubert wrote:
> On the other side, I add a 60min polling time callback
Unfortunately this is a can of worms. 60 min detection is the next
point to argue about. Of course people then want a very accurate online
status, which brings this timer down to, what, tens of seconds? And to
really move status back and forth between online and ready states. On
another note, online status cannot verify connectivity to the
destination desired by the application, as this destination may have
its own set of rules from where access is allowed.
The only networks where this is a perceived problem are those where
connectivity is sporadic for one reason or another. All networks that
work in a stable manner and are designed to allow Internet connectivity
with minimum fuss have no problem in letting ConnMan move to the online
state properly. If the connectivity is sporadic, then ready is actually
the correct state to be in from the start. There is no loss of features
in ConnMan, the same set of functionality is available in both ready
and online states, so from an application perspective this is not a lot
of a problem either.
A bigger point of failure than re-checking for online status is the
presence of a captive portal. When the online check fails, ConnMan
detects the captive portal and sends a RequestBrowser method call to
the Agent. If there is no Agent or the Agent does not implement this
feature, then the connection status stays as ready. I have not heard of
any Agent UI that implements RequestBrowser to this day, unfortunately
[1].
Yet another almost equally big cause failure is to be in a network
walled up with a proxy and not having pacrunner installed. This also
causes the state to stay as ready. With pacrunner installed, ConnMan
will go to state online as the proxy is either detected or configured
in advance. In this setup, applications need to be compiled against
libproxy, and libproxy needs to be configured with pacrunner as the
back end. For example Fedora implements pacrunner support already, and
there a proxy is not a problem for ConnMan or the libproxy enabled
applications.
Cheers,
Patrik
[1] I did try this for the Gnome Shell extension, though. I got stuck
at the part where I was unable to embed a GTK WebKit WebView into a
Clutter -something, run out of my javascript mojo and did not find the
correct APIs/objects to do this.
------------------------------
Message: 2
Date: Fri, 17 Feb 2017 14:37:31 +0100
From: Antoine Aubert <[email protected]>
To: [email protected]
Subject: [PATCH] timeserver: Update nameservers when DNS changed.
Message-ID: <[email protected]>
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
------------------------------
Message: 3
Date: Fri, 17 Feb 2017 13:53:01 +0000
From: Jose Blanquicet <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected], "MANIEZZO Marco (MM)"
<[email protected]>, [email protected], Patrik Flykt
<[email protected]>
Subject: Re: Service remains on service list even if it is not longer
available
Message-ID:
<CAFC8iJKoBVr4+ZudEtsRkbXbiPOsYW-BMb-hr=o2pzst5h8...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Wed, Feb 8, 2017 at 8:55 AM, Jose Blanquicet wrote:
>>>> 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?
Well, it has not been easy to follow the code but I think I got
something. Now, looking into details what Naveen developed, I noticed
that the connectable flag he introduced is exactly what prevents
ConnMan to remove the service from the services list. He described the
issue as:
"On receiving a deauth with reason code 6, 7 or 4 wpa_supplicant will
immediately try to connect back. Now with current implementation of
connman, a disconnect notification will cause network to get disabled
and connection procedure would stop. This also impacts the roaming
time in case disconnect is because of any other reason code. The act
of disabling network severly affects wpa_s connection state machine as
it would generate a deauth to current network when half way the
connection was done."
I completely agree and he solved it in commit
6245582d0dc9a3f47a6880dabf437ee7c351caef by avoiding to disable the
network profile on wpa_s, which indeed decreased the re-connection
time and save D-Bus calls as he said (I saw in the mailing list
archives that it was a long discussion with Patrik).
>From my point of view, the issue was completely solved at that point
and there was not need of the next patches where he introduced the
connectable flag which prevent service to be removed even though it is
not found in the scan. Trying to understand why he did so, I followed
the discussion on the mailing list archives [1] (Then the patch was
split into three). I more or less agree with such patch, well more
less than more because there should be no way that wpa_s tells ConnMan
it is connected to a BSS which it has not already sent a "BSSAdded"
signal indicating such BSS entered into the range. Therefore, by the
time of a success connection, the service state machine will indeed
move because ConnMan is already aware of such BSS thus the service
will already exist and ConnMan is prepared for a soon success
connection. However, if we want to be very very precise, we could add
a callback from gsupplicant to WiFi plugin when wpa_s notifies we are
associated in order to ensure the state machines are prepared for a
soon connection BUT without avoiding to remove the service. I will
send a patch set doing so, we tested it and it works for us. Please
let me know what do you think.
[1] https://lists.01.org/pipermail/connman/2016-April/000583.html
Thanks,
Jose Blanquicet
------------------------------
Message: 4
Date: Fri, 17 Feb 2017 14:03:29 +0000
From: [email protected]
To: [email protected]
Cc: [email protected], [email protected],
[email protected], Jose Blanquicet
<[email protected]>
Subject: [PATCH 0/5] Avoid to keep service in list if AP is not found
during scan
Message-ID:
<1487340214-5410-1-git-send-email-jose.blanquicet-melen...@magnetimarelli.com>
From: Jose Blanquicet <[email protected]>
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
------------------------------
Message: 5
Date: Fri, 17 Feb 2017 14:03:30 +0000
From: [email protected]
To: [email protected]
Cc: [email protected], [email protected],
[email protected], Jose Blanquicet
<[email protected]>
Subject: [PATCH 1/5] Revert "device: Use network's connectable flag"
Message-ID:
<1487340214-5410-2-git-send-email-jose.blanquicet-melen...@magnetimarelli.com>
From: Jose Blanquicet <[email protected]>
This reverts commit 9aad337b765dc6ae195e5f21d7764a71b2e82801.
---
src/device.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/device.c b/src/device.c
index 2e1a3cd..88de0e7 100644
--- a/src/device.c
+++ b/src/device.c
@@ -671,8 +671,7 @@ static void mark_network_unavailable(gpointer key, gpointer
value,
struct connman_network *network = value;
if (connman_network_get_connected(network) ||
- connman_network_get_connecting(network) ||
- connman_network_get_connectable(network))
+ connman_network_get_connecting(network))
return;
connman_network_set_available(network, false);
@@ -689,9 +688,6 @@ static gboolean remove_unavailable_network(gpointer key,
gpointer value,
if (connman_network_get_available(network))
return FALSE;
- if (connman_network_get_connectable(network))
- return FALSE;
-
return TRUE;
}
--
1.9.1
------------------------------
Message: 6
Date: Fri, 17 Feb 2017 14:03:31 +0000
From: [email protected]
To: [email protected]
Cc: [email protected], [email protected],
[email protected], Jose Blanquicet
<[email protected]>
Subject: [PATCH 2/5] Revert "plugins/wifi: Marking network's
Connectable flag as true."
Message-ID:
<1487340214-5410-3-git-send-email-jose.blanquicet-melen...@magnetimarelli.com>
From: Jose Blanquicet <[email protected]>
This reverts commit ff9decb006ba69e83f47401a57cd7f4a5d5ba9f7.
---
plugins/wifi.c | 31 -------------------------------
1 file changed, 31 deletions(-)
diff --git a/plugins/wifi.c b/plugins/wifi.c
index f8d88fa..a721101 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -2113,21 +2113,7 @@ static int network_connect(struct connman_network
*network)
wifi->pending_network = network;
g_free(ssid);
} else {
-
- /*
- * This is the network that is going to get plumbed into wpa_s
- * Mark the previous network that is plumbed in wpa_s as not
- * connectable and then the current one as connectable.
- * This flag will be used to ensure that the network that is
- * sitting in wpa_s never gets marked unavailable even though
- * the scan did not find this network.
- */
- if (wifi->network) {
- connman_network_set_connectable(wifi->network, false);
- }
-
wifi->network = connman_network_ref(network);
- connman_network_set_connectable(wifi->network, true);
wifi->retries = 0;
return g_supplicant_interface_connect(interface, ssid,
@@ -2151,7 +2137,6 @@ static void disconnect_callback(int result,
GSupplicantInterface *interface,
}
if (wifi->network) {
- connman_network_set_connectable(wifi->network, false);
connman_network_set_connected(wifi->network, false);
wifi->network = NULL;
}
@@ -2781,22 +2766,6 @@ static void network_removed(GSupplicantNetwork *network)
if (!connman_network)
return;
- /*
- * wpa_s did not find this network in last scan and hence it generated
- * this callback. In case if this is the network with which device
- * was connected to, even though network_removed was called, wpa_s
- * will keep trying to connect to the same network and once the
- * network is back, it will proceed with the connection. Now if
- * connman would have removed this network from network hash table,
- * on a successful connection complete indication service state
- * machine will not move. End result would be only a L2 level
- * connection and no IP address. This check ensures that even if the
- * network_removed gets called for the previously connected network
- * do not remove it from network hash table.
- */
- if (wifi->network == connman_network)
- return;
-
wifi->networks = g_slist_remove(wifi->networks, connman_network);
connman_device_remove_network(wifi->device, connman_network);
--
1.9.1
------------------------------
Message: 7
Date: Fri, 17 Feb 2017 14:03:32 +0000
From: [email protected]
To: [email protected]
Cc: [email protected], [email protected],
[email protected], Jose Blanquicet
<[email protected]>
Subject: [PATCH 3/5] Revert "network: connectable flag in network
structure"
Message-ID:
<1487340214-5410-4-git-send-email-jose.blanquicet-melen...@magnetimarelli.com>
From: Jose Blanquicet <[email protected]>
This reverts commit b7d20de51c5293fc28bb840e95a11b31747f51d8.
---
include/network.h | 5 -----
src/network.c | 13 -------------
2 files changed, 18 deletions(-)
diff --git a/include/network.h b/include/network.h
index 5d44669..4fc20c1 100644
--- a/include/network.h
+++ b/include/network.h
@@ -103,11 +103,6 @@ bool connman_network_get_connected(struct connman_network
*network);
bool connman_network_get_associating(struct connman_network *network);
-bool connman_network_get_connectable(struct connman_network *network);
-
-int connman_network_set_connectable(struct connman_network *network,
- bool connectable);
-
void connman_network_clear_hidden(void *user_data);
int connman_network_connect_hidden(struct connman_network *network,
char *identity, char* passphrase, void *user_data);
diff --git a/src/network.c b/src/network.c
index 5b7ef55..4f881aa 100644
--- a/src/network.c
+++ b/src/network.c
@@ -50,7 +50,6 @@ struct connman_network {
bool available;
bool connected;
bool roaming;
- bool connectable;
uint8_t strength;
uint16_t frequency;
char *identifier;
@@ -830,18 +829,6 @@ static gint compare_priority(gconstpointer a,
gconstpointer b)
return driver2->priority - driver1->priority;
}
-int connman_network_set_connectable(struct connman_network *network,
- bool connectable)
-{
- network->connectable = connectable;
- return 0;
-}
-
-bool connman_network_get_connectable(struct connman_network *network)
-{
- return network->connectable;
-}
-
/**
* connman_network_driver_register:
* @driver: network driver definition
--
1.9.1
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 16, Issue 19
***************************************
