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. Propagate only property changes of the connected BSS
(Jose Blanquicet)
2. [PATCH] gsupplicant: Propagate only property changes of the
connected BSS ([email protected])
3. Connman - DHCP client for cellular networks
(Eswaran Vinothkumar (BEG/PJ-IOT-EL))
----------------------------------------------------------------------
Message: 1
Date: Fri, 14 Jul 2017 09:32:21 +0000
From: Jose Blanquicet <[email protected]>
To: [email protected]
Subject: Propagate only property changes of the connected BSS
Message-ID:
<1500024741-15208-1-git-send-email-jose.blanquicet-melen...@magnetimarelli.com>
Hi,
Please read the commit message of the patch before this to get contextualised.
An additional reason behind this patch is to resume the discussion about the
supported IEEE standards 8021.11. Some time ago, we proposed the idea of add a
new Service's property which provides information about the supported IEEE std
802.11 (a, b, g, n, ac, ...) by a WiFi network. At that time, Marcel exposed the
reasons why he did not agree about the way we wanted to implement it. Now, after
having got more experience on ConnMan we rebuild the idea but the aim of the
modification remains the same; we want to add this information in order to
provide to the user more precise information about the performances he could
achieve and ease him to decide which is the most suitable network, if he can
choose.
To develop this proposal, we would like to follow what is done for the signal
strength, it means to update this new Service property with what the best BSS of
the corresponding WiFi network supports. It would make complete sense because at
the end, that would be the BSS to which we will connect. Therefore, each time a
best BSS is updated because there is another with higher signal strength then
the supported IEEE standards will also be updated thus we will always show
reliable information.
What do you think?
Regards,
Jose Blanquicet
Jose Blanquicet (1):
gsupplicant: Propagate only property changes of the connected BSS
gsupplicant/supplicant.c | 118 ++++++++++++++++++++++++++++++++---------------
1 file changed, 81 insertions(+), 37 deletions(-)
--
1.9.1
------------------------------
Message: 2
Date: Fri, 14 Jul 2017 09:33:12 +0000
From: [email protected]
To: [email protected]
Subject: [PATCH] gsupplicant: Propagate only property changes of the
connected BSS
Message-ID:
<1500024792-15292-1-git-send-email-jose.blanquicet-melen...@magnetimarelli.com>
From: Jose Blanquicet <[email protected]>
A ConnMan service is a WiFi network identified by the SSID, security (none, wep,
psk and ieee8021x) and mode (managed, adhoc, ap). This WiFi network could be
composed by multiple BSSs but it is shown as a single service by ConnMan. The
properties of that network correspond to the best BSS (Currently, only the
signal strength). The best BSS is the one with the highest signal strength. Now,
the issue is that ConnMan is selecting the best BSS by itself and it could cause
a misalignment with wpa_s; in particular when roaming. For instance, if ConnMan
updates the best BSS because there is a BSS with higher signal strength than the
current one but wpa_s takes too much time to roaming or even worse it never does
the roaming because such feature is not enabled in wpa_s; on both cases, ConnMan
will incorrectly start propagating the signal strength of the its best BSS but
actually we are associated to another one. Therefore, in these cases, the signal
strength the user will see for that network comes from the BSS with the highest
signal not from the one he are actually associated.
This patch makes ConnMan memorize the WiFi network it gets associated
(current_network). Then, from this point forward, the best BSS of that network
will only be updated if wpa_s signals a disassociation or we got associated with
another BSS (roaming).
With this patch, ConnMan is now able to distinguish at gsupplicant level which
is the BSS it is actually associated to because it will be always the best BSS
of the associated network. This is useful for future developments.
---
gsupplicant/supplicant.c | 118 ++++++++++++++++++++++++++++++++---------------
1 file changed, 81 insertions(+), 37 deletions(-)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 2d5055769152..4f79012252e5 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -189,6 +189,7 @@ struct _GSupplicantInterface {
GHashTable *bss_mapping;
void *data;
const char *pending_peer_path;
+ GSupplicantNetwork *current_network;
struct added_network_information network_info;
};
@@ -1628,7 +1629,12 @@ done:
network->wps_capabilities |= bss->wps_capabilities;
}
- if (bss->signal > network->signal) {
+ /*
+ * Do not change best BSS if we are connected. It will be done through
+ * CurrentBSS property in case of misalignment with wpa_s or roaming.
+ */
+ if (network != interface->current_network &&
+ bss->signal > network->signal) {
network->signal = bss->signal;
network->best_bss = bss;
callback_network_changed(network, "Signal");
@@ -2088,6 +2094,75 @@ static void update_network_signal(GSupplicantNetwork
*network)
SUPPLICANT_DBG("New network signal %d", network->signal);
}
+static void interface_current_bss(GSupplicantInterface *interface,
+ DBusMessageIter *iter)
+{
+ GSupplicantNetwork *network;
+ struct g_supplicant_bss *bss;
+ const char *path;
+
+ dbus_message_iter_get_basic(iter, &path);
+ if (g_strcmp0(path, "/") == 0) {
+ interface->current_network = NULL;
+ return;
+ }
+
+ interface_bss_added_without_keys(iter, interface);
+
+ network = g_hash_table_lookup(interface->bss_mapping, path);
+ if (!network)
+ return;
+
+ bss = g_hash_table_lookup(network->bss_table, path);
+ if (!bss)
+ return;
+
+ interface->current_network = network;
+
+ if (bss != network->best_bss) {
+ /*
+ * This is the case where either wpa_s got associated
+ * to a BSS different than the one ConnMan considers
+ * the best, or we are roaming.
+ */
+ SUPPLICANT_DBG("Update best BSS for %s", network->name);
+
+ network->best_bss = bss;
+
+ if (network->signal != bss->signal) {
+ SUPPLICANT_DBG("New network signal %d dBm",
+ bss->signal);
+
+ network->signal = bss->signal;
+ callback_network_changed(network, "Signal");
+ }
+ }
+
+ /*
+ * wpa_s could notify about CurrentBSS in any state once
+ * it got associated. It is not sure such notification will
+ * arrive together with transition to ASSOCIATED state.
+ * In fact, for networks with security WEP or OPEN, it
+ * always arrives together with transition to COMPLETED.
+ */
+ switch (interface->state) {
+ case G_SUPPLICANT_STATE_UNKNOWN:
+ case G_SUPPLICANT_STATE_DISABLED:
+ case G_SUPPLICANT_STATE_DISCONNECTED:
+ case G_SUPPLICANT_STATE_INACTIVE:
+ case G_SUPPLICANT_STATE_SCANNING:
+ case G_SUPPLICANT_STATE_AUTHENTICATING:
+ case G_SUPPLICANT_STATE_ASSOCIATING:
+ return;
+ case G_SUPPLICANT_STATE_ASSOCIATED:
+ case G_SUPPLICANT_STATE_4WAY_HANDSHAKE:
+ case G_SUPPLICANT_STATE_GROUP_HANDSHAKE:
+ case G_SUPPLICANT_STATE_COMPLETED:
+ callback_network_associated(network);
+ break;
+ }
+}
+
static void interface_bss_removed(DBusMessageIter *iter, void *user_data)
{
GSupplicantInterface *interface = user_data;
@@ -2270,42 +2345,7 @@ static void interface_property(const char *key,
DBusMessageIter *iter,
g_strdup(interface->ifname), g_strdup(str));
}
} else if (g_strcmp0(key, "CurrentBSS") == 0) {
- GSupplicantNetwork *network;
- const char *path = NULL;
-
- dbus_message_iter_get_basic(iter, &path);
- if (g_strcmp0(path, "/") == 0)
- return;
-
- interface_bss_added_without_keys(iter, interface);
-
- network = g_hash_table_lookup(interface->bss_mapping, path);
- if (!network)
- return;
-
- /*
- * wpa_s could notify about CurrentBSS in any state once
- * it got associated. It is not sure such notification will
- * arrive together with transition to ASSOCIATED state.
- * In fact, for networks with security WEP or OPEN, it
- * always arrives together with transition to COMPLETED.
- */
- switch (interface->state) {
- case G_SUPPLICANT_STATE_UNKNOWN:
- case G_SUPPLICANT_STATE_DISABLED:
- case G_SUPPLICANT_STATE_DISCONNECTED:
- case G_SUPPLICANT_STATE_INACTIVE:
- case G_SUPPLICANT_STATE_SCANNING:
- case G_SUPPLICANT_STATE_AUTHENTICATING:
- case G_SUPPLICANT_STATE_ASSOCIATING:
- return;
- case G_SUPPLICANT_STATE_ASSOCIATED:
- case G_SUPPLICANT_STATE_4WAY_HANDSHAKE:
- case G_SUPPLICANT_STATE_GROUP_HANDSHAKE:
- case G_SUPPLICANT_STATE_COMPLETED:
- callback_network_associated(network);
- break;
- }
+ interface_current_bss(interface, iter);
} else if (g_strcmp0(key, "CurrentNetwork") == 0) {
interface_network_added(iter, interface);
} else if (g_strcmp0(key, "BSSs") == 0) {
@@ -2741,6 +2781,10 @@ static void signal_bss_changed(const char *path,
DBusMessageIter *iter)
return;
}
+ /* Consider only property changes of the connected BSS */
+ if (network == interface->current_network && bss != network->best_bss)
+ return;
+
if (bss->signal == network->signal)
return;
--
1.9.1
------------------------------
Message: 3
Date: Fri, 14 Jul 2017 12:11:09 +0000
From: "Eswaran Vinothkumar (BEG/PJ-IOT-EL)"
<[email protected]>
To: "[email protected]" <[email protected]>
Subject: Connman - DHCP client for cellular networks
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I am currently working on an embedded project where we are using TELIT 910 EUG
Modem chip. We are using Yocto as the build system.
Versions Used: Connman:1.34 and Ofono:1.20
To establish the internet connection I am using the python scripts within the
ofono/test directory as follows:
/usr/lib/ofono/test/enable-modem
/usr/lib/ofono/test/online-modem
/usr/lib/ofono/test/set-roaming-allowed
/usr/lib/ofono/test/register-auto
/usr/lib/ofono/test/enable-gprs
/usr/lib/ofono/test/create-internet-context web.vodafone.de vodafone vodafone
/activate-context
/process-context-settings
After this I could see that the device gets the IP address, gateway and
nameserver as shown below,
ofono_start_gsm.sh[192]: Interface is wwan0
ofono_start_gsm.sh[192]: IP address is 10.249.29.20
ofono_start_gsm.sh[192]: Gateway is 10.249.29.21
ofono_start_gsm.sh[192]: Nameserver is 10.105.144.254
At this point I excepted Connman to connect to the internet but it doesn't. I
am seeing the following error message from Connman:
connmand[176]: Online check failed for 0x1ce7c80 Vodafone.
Also ping and wget didn't work. The output of ip route and /etc/resolv.conf are
as follows:
route -n
Kernel IP routing table
Destination Gateway Genmask
Flags Metric Ref Use Iface
0.0.0.0 10.166.199.10 0.0.0.0
UG 0 0 0 wwan0
10.105.144.254 10.166.199.10 255.255.255.255 UGH
0 0 0 wwan0
10.166.199.8 0.0.0.0 255.255.255.252 U
0 0 0 wwan0
10.166.199.10 0.0.0.0 255.255.255.255 UH
0 0 0 wwan0
192.168.1.0 0.0.0.0 255.255.255.0
U 0 0 0 eth0
192.168.1.255 0.0.0.0 255.255.255.255 UH
0 0 0 eth0
cat /etc/resolv-conf.connman
# Generated by Connection Manager
nameserver ::1
nameserver 127.0.0.1
The contents of ip route and resolv.conf looked strange for me. I looked into
Connman documents and the mailing list discussions, it seems like expected
behavior from connman.
As a test case, I manually started the DHCP client on wwan0. After that I
could see that the device is connected to the internet. I checked with ping
and wget. Also have downloaded some files to test the internet connection.
The output of ip route and /etc/resolv.conf are as follows:
route -n
Kernel IP routing table
Destination Gateway Genmask Flags
Metric Ref Use Iface
0.0.0.0 10.166.250.1 0.0.0.0 UG
0 0 0 wwan0
10.166.250.0 0.0.0.0 255.255.255.240 U 0
0 0 wwan0
192.168.1.0 0.0.0.0 255.255.255.0 U
0 0 0 eth0
192.168.1.255 0.0.0.0 255.255.255.255 UH 0
0 0 eth0
cat /etc/resolv.conf
nameserver 10.105.16.254
nameserver 10.105.144.254
I have the following question. Is this the expected behavior? Do I need to run
dhclient or missing some configuration in Connman? I have read in the mailing
list that the connman has internet DHCP client and running another might cause
confusion.
After running connmanctl services I could see the connection is listed as AR
(Ready state). I expected it to be in AO(online state)
*AR Wired ethernet_0001c01df20b_cable
*AR Vodafone cellular_204046850339628_context1
I tried disconnecting the service and connecting it back.
connmanctl disconnect cellular_204046850339628_context1 --> successfully
disconnects the connection
connmanctl connect cellular_204046850339628_context1 --> again the connman
fails with the message Online check failed for 0x1ce7c80 Vodafone. Running
dhclient manually again fixes this issue.
I am puzzled about the issue here. Let me know if you need some more log
messages. Any help on the topic is appreciated.
Mit freundlichen Gr??en / Best regards
Vinothkumar Eswaran
BEG-PT/PJ-IOT1
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20170714/e52f0a36/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 21, Issue 3
**************************************
