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. [PATCH] Teach ConnMan to select the next BSSID when two APs
with the same SSID and securcity configuration are available
(Rahul Jain)
2. Re: [PATCH 1/1] service: Sanitize hostname and domainname
(Henrik Persson)
3. FW: [PATCH] Teach ConnMan to select the next BSSID when two
APs with the same SSID and securcity configuration are available
(Rahul Jain)
4. [PATCH v2 1/1] service: Sanitize input for hostname and
domainname (Henrik Persson)
5. [[PATCH v3] 0/1] implements periodic online check (Julien Massot)
----------------------------------------------------------------------
Message: 1
Date: Mon, 18 Mar 2019 13:12:27 +0530
From: Rahul Jain <[email protected]>
To: "[email protected]" <[email protected]>
Cc: AMIT KUMAR JAISWAL <[email protected]>
Subject: [PATCH] Teach ConnMan to select the next BSSID when two APs
with the same SSID and securcity configuration are available
Message-ID:
<20190318074227epcms5p24fcdc9a105ba1211ceced2a8ef7d4274@epcms5p2>
Content-Type: text/plain; charset="utf-8"
[PATCH] Teach ConnMan to select the next BSSID when two APs (e.g. 2.4
GHz and 5 GHz) with the same SSID and securcity configuration are available.
Currently when one AP disapears ConnMan will retry to connect to the
old AP point even though there is another matching BSSID available.
So when wpa_supplicant sends a remove signal we find a matching BSSID
and use it even when it's not from the same AP.
---
gsupplicant/supplicant.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index da8c52e..bfca281 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -2206,6 +2206,7 @@ static void interface_bss_removed(DBusMessageIter *iter,
void *user_data)
GSupplicantNetwork *network;
struct g_supplicant_bss *bss = NULL;
const char *path = NULL;
+ bool is_current_network_bss = false;
dbus_message_iter_get_basic(iter, &path);
if (!path)
@@ -2219,6 +2220,7 @@ static void interface_bss_removed(DBusMessageIter *iter,
void *user_data)
if (network->best_bss == bss) {
network->best_bss = NULL;
network->signal = BSS_UNKNOWN_STRENGTH;
+ is_current_network_bss=true;
}
g_hash_table_remove(bss_mapping, path);
@@ -2230,6 +2232,10 @@ static void interface_bss_removed(DBusMessageIter *iter,
void *user_data)
if (g_hash_table_size(network->bss_table) == 0)
g_hash_table_remove(interface->network_table, network->group);
+ else {
+ if (is_current_network_bss && network->best_bss)
+ callback_network_changed(network, "");
+ }
}
static void set_config_methods(DBusMessageIter *iter, void *user_data)
--
2.7.4
------------------------------
Message: 2
Date: Mon, 18 Mar 2019 11:18:10 +0000
From: Henrik Persson <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: "[email protected]" <[email protected]>, Konrad Beckmann
<[email protected]>
Subject: Re: [PATCH 1/1] service: Sanitize hostname and domainname
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi!
On 2019-03-16 15:14, Daniel Wagner wrote:
>> If a DHCP ACK is received with non-UTF-8 data set as hostname or
>> domain-name option connman will crash on a D-Bus assert.
>
> Who is doing something like this? Everyone knows, ASCII only! :)
Well, not to point a finger at any one manufacturer but the name might
start with "aru" and end with "ba" and OUI might be F0:5C:19. ;)
>> + if (g_str_is_ascii(hostname))
>
> I am fine with the patch. In order to use g_str_is_ascii() glib 2.40
> is needed. ConnMan requests only 2.28 at this point which was released
> around 2011. I think it's save to assume no one still uses this really
> old version of glib.
>
> Glib 2.40 is not too young either (released in March 2014), so we
> don't force everyone to update to a very recent version.
>
> Please add this update to this patch as well. So we have documented
> why we update the dependency.
Ah, right. Forgot to check that.. I'll update the dependency and note
why in the commit and post v2.
--
Henrik Persson
Verisure Innovation AB
------------------------------
Message: 3
Date: Mon, 18 Mar 2019 14:49:30 +0530
From: Rahul Jain <[email protected]>
To: "[email protected]" <[email protected]>
Cc: AMIT KUMAR JAISWAL <[email protected]>
Subject: FW: [PATCH] Teach ConnMan to select the next BSSID when two
APs with the same SSID and securcity configuration are available
Message-ID:
<20190318091930epcms5p3e8c01f9044d56970c77928b10c19e4d2@epcms5p3>
Content-Type: text/plain; charset="utf-8"
[PATCH] Teach ConnMan to select the next BSSID when two APs (e.g. 2.4
GHz and 5 GHz) with the same SSID and securcity configuration are available.
Currently when one AP disapears ConnMan will retry to connect to the
old AP point even though there is another matching BSSID available.
So when wpa_supplicant sends a remove signal we find a matching BSSID
and use it even when it's not from the same AP.
---
gsupplicant/supplicant.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index da8c52e..46e1cbb 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -2206,6 +2206,7 @@ static void interface_bss_removed(DBusMessageIter *iter,
void *user_data)
GSupplicantNetwork *network;
struct g_supplicant_bss *bss = NULL;
const char *path = NULL;
+ bool is_current_network_bss = false;
dbus_message_iter_get_basic(iter, &path);
if (!path)
@@ -2219,6 +2220,7 @@ static void interface_bss_removed(DBusMessageIter *iter,
void *user_data)
if (network->best_bss == bss) {
network->best_bss = NULL;
network->signal = BSS_UNKNOWN_STRENGTH;
+ is_current_network_bss = true;
}
g_hash_table_remove(bss_mapping, path);
@@ -2230,6 +2232,10 @@ static void interface_bss_removed(DBusMessageIter *iter,
void *user_data)
if (g_hash_table_size(network->bss_table) == 0)
g_hash_table_remove(interface->network_table, network->group);
+ else {
+ if (is_current_network_bss && network->best_bss)
+ callback_network_changed(network, "");
+ }
}
static void set_config_methods(DBusMessageIter *iter, void *user_data)
--
2.7.4
------------------------------
Message: 4
Date: Mon, 18 Mar 2019 11:58:24 +0000
From: Henrik Persson <[email protected]>
To: "[email protected]" <[email protected]>
Cc: Konrad Beckmann <[email protected]>
Subject: [PATCH v2 1/1] service: Sanitize input for hostname and
domainname
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
From f9980195edb7ffab18315b880cf0ff1fb026f3b7 Mon Sep 17 00:00:00 2001
From: Henrik Persson <[email protected]>
Date: Mon, 18 Mar 2019 12:20:34 +0100
Subject: [PATCH v2 1/1] service: Sanitize input for hostname and domainname
If a DHCP ACK is received with non-UTF-8 data set as hostname or
domain-name option connman will crash on a D-Bus assert. This patch
sanitizes data in service.c and only allows ASCII characters (since
they shouldn't be anything else) for __connman_service_set_hostname()
and __connman_service_set_domainname().
Since the fix involves using g_str_is_ascii() we also need to bump
Glib dependency to 2.40 (which was released in March 2014).
---
configure.ac | 4 ++--
src/service.c | 12 ++++++++++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index 0bb2a6d9..a6e14b76 100644
--- a/configure.ac
+++ b/configure.ac
@@ -221,8 +221,8 @@ fi
AC_DEFINE_UNQUOTED([STATS_MAX_FILE_SIZE], (${stats_max_file_size}), [Maximal
size of a statistics round robin file])
-PKG_CHECK_MODULES(GLIB, glib-2.0 >= 2.28, dummy=yes,
- AC_MSG_ERROR(GLib >= 2.28 is required))
+PKG_CHECK_MODULES(GLIB, glib-2.0 >= 2.40, dummy=yes,
+ AC_MSG_ERROR(GLib >= 2.40 is required))
AC_SUBST(GLIB_CFLAGS)
AC_SUBST(GLIB_LIBS)
diff --git a/src/service.c b/src/service.c
index ea1905bf..7ae252ec 100644
--- a/src/service.c
+++ b/src/service.c
@@ -2638,7 +2638,11 @@ void __connman_service_set_hostname(struct
connman_service *service,
return;
g_free(service->hostname);
- service->hostname = g_strdup(hostname);
+
+ if (g_str_is_ascii(hostname))
+ service->hostname = g_strdup(hostname);
+ else
+ service->hostname = NULL;
}
const char *__connman_service_get_hostname(struct connman_service *service)
@@ -2656,7 +2660,11 @@ void __connman_service_set_domainname(struct
connman_service *service,
return;
g_free(service->domainname);
- service->domainname = g_strdup(domainname);
+
+ if (g_str_is_ascii(domainname))
+ service->domainname = g_strdup(domainname);
+ else
+ service->domainname = NULL;
domain_changed(service);
}
--
2.17.1
------------------------------
Message: 5
Date: Mon, 18 Mar 2019 14:41:41 +0100
From: Julien Massot <[email protected]>
To: [email protected]
Subject: [[PATCH v3] 0/1] implements periodic online check
Message-ID: <[email protected]>
From: Julien Massot <[email protected]>
Changes since v3:
* Address Daniel's comment in patch 2/2
* Remove warning log for online failure
* Use a define for the maximum timeout
* Previous patch 1/2 already accepted
Changes since v2:
* Address Daniel's comment in patch 1/2
* drop the linear backoff to something more incremental
* inspired by Sailfish OS.
This patch set implements a periodic retry on online check.
That's something I have in my ConnMan tree for years, and may
have interrest to land mainline.
So if we fail our online check just after ready state, we will retry
periodically.
Once the online check succeed we stop probing the network.
That should be interresting for software which wait for internet connection
on boot.
I didn't test the ipv6 case so I will be happy if someone can give it a try.
Online checking is still not perfect since Internet connection may drop, after
a successful online check happen.
Julien Massot (1):
service: retry online check permanently until success
src/service.c | 48 +++++++++++++++++++++++++-----------------------
1 file changed, 25 insertions(+), 23 deletions(-)
--
2.21.0
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 41, Issue 19
***************************************
