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] gsupplicant: Use ConfigFile when recreating an
interface ([email protected])
2. Re: Auto-connect from wpa_supplicant and ConnMan does not
become aware (Jose Blanquicet)
3. Service remains on service list even if it is not longer
available (Jose Blanquicet)
4. [PATCH] inet: Prevent glib source from being removed twice
(Slava Monich)
5. [PATCH] inet: Don't close file descriptor twice (Slava Monich)
----------------------------------------------------------------------
Message: 1
Date: Fri, 27 Jan 2017 09:05:27 +0000
From: [email protected]
To: [email protected], [email protected]
Subject: [PATCH] gsupplicant: Use ConfigFile when recreating an
interface
Message-ID:
<1485507927-3216-1-git-send-email-jose.blanquicet-melen...@magnetimarelli.com>
From: Jose Blanquicet <[email protected]>
Currently, each time ConnMan removes a wpa_s interface the configuration of the
wpa_s for that interface is lost (See use cases below), such configuration is
present in the file passed to wpa_s using "-c" option. It is due to wpa_s
did not provide the configuration file path to the applications on top of it
(ConnMan in this case) in order to allow them to recreate interfaces with the
same configuration they were initially created.
In order to solve this we proposed a patch to wpa_s community, that patch aimed
to expose the configuration file path as a D-Bus interface property. It was
applied (b44d9c7) and delivered on last wpa_s release (2.6). Now, ConnMan has
the possibility to recreate interfaces with the correct configuration file path
in order to solve the described issue.
Two use cases are the following:
1. Enable/Disable WiFi: All wpa_s interfaces are removed then config information
is lost for all of them.
2. Tethering: When enabling, the selected wpa_s interface is removed and
recreated with the bridge "tether". Also when disabling, again the tethering
wpa_s interface is removed and recreated without bridge. After
enabling/disabling tethering the config information of that interface is lost.
This patch aims to solve the just described issue by using the new interface's
property exposed by wpa_s via D-Bus in order to always recreate the interfaces
with the appropriate configuration. This modification only has effect if wpa_s
is updated to release 2.6 or at least includes commit b44d9c7 (Applied on
2016-08-23), otherwise ConnMan will simply do not send any ConfigFile while
creating a new interface as it has been doing so far.
---
gsupplicant/supplicant.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 8890447..36c4dd5 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -143,6 +143,7 @@ static GHashTable *bss_mapping;
static GHashTable *peer_mapping;
static GHashTable *group_mapping;
static GHashTable *pending_peer_connection;
+static GHashTable *config_file_table;
struct _GSupplicantWpsCredentials {
unsigned char ssid[32];
@@ -2223,6 +2224,15 @@ static void interface_property(const char *key,
DBusMessageIter *iter,
g_free(interface->bridge);
interface->bridge = g_strdup(str);
}
+ } else if (g_strcmp0(key, "ConfigFile") == 0) {
+ const char *str = NULL;
+
+ dbus_message_iter_get_basic(iter, &str);
+ if (str && strlen(str) > 0 && interface->ifname) {
+ SUPPLICANT_DBG("New {%s, %s}", interface->ifname, str);
+ g_hash_table_replace(config_file_table,
+ g_strdup(interface->ifname), g_strdup(str));
+ }
} else if (g_strcmp0(key, "CurrentBSS") == 0) {
interface_bss_added_without_keys(iter, interface);
} else if (g_strcmp0(key, "CurrentNetwork") == 0) {
@@ -2456,6 +2466,7 @@ static void signal_name_owner_changed(const char *path,
DBusMessageIter *iter)
g_hash_table_remove_all(bss_mapping);
g_hash_table_remove_all(peer_mapping);
g_hash_table_remove_all(group_mapping);
+ g_hash_table_remove_all(config_file_table);
g_hash_table_remove_all(interface_table);
callback_system_killed();
}
@@ -3725,6 +3736,7 @@ static void interface_create_params(DBusMessageIter
*iter, void *user_data)
{
struct interface_create_data *data = user_data;
DBusMessageIter dict;
+ char *config_file = NULL;
SUPPLICANT_DBG("");
@@ -3741,6 +3753,14 @@ static void interface_create_params(DBusMessageIter
*iter, void *user_data)
supplicant_dbus_dict_append_basic(&dict, "BridgeIfname",
DBUS_TYPE_STRING, &data->bridge);
+ config_file = g_hash_table_lookup(config_file_table, data->ifname);
+ if (config_file) {
+ SUPPLICANT_DBG("[%s] ConfigFile %s", data->ifname, config_file);
+
+ supplicant_dbus_dict_append_basic(&dict, "ConfigFile",
+ DBUS_TYPE_STRING, &config_file);
+ }
+
supplicant_dbus_dict_close(iter, &dict);
}
@@ -5557,6 +5577,8 @@ int g_supplicant_register(const GSupplicantCallbacks
*callbacks)
NULL, NULL);
pending_peer_connection = g_hash_table_new_full(g_str_hash, g_str_equal,
NULL, NULL);
+ config_file_table = g_hash_table_new_full(g_str_hash, g_str_equal,
+ g_free, g_free);
supplicant_dbus_setup(connection);
@@ -5625,6 +5647,11 @@ void g_supplicant_unregister(const GSupplicantCallbacks
*callbacks)
g_supplicant_filter, NULL);
}
+ if (config_file_table) {
+ g_hash_table_destroy(config_file_table);
+ config_file_table = NULL;
+ }
+
if (bss_mapping) {
g_hash_table_destroy(bss_mapping);
bss_mapping = NULL;
--
1.9.1
------------------------------
Message: 2
Date: Fri, 27 Jan 2017 09:30:10 +0000
From: Jose Blanquicet <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: Auto-connect from wpa_supplicant and ConnMan does not
become aware
Message-ID:
<cafc8ij+ae2dthrm5lzu+kw_0gganwowqty3u5ukjehxvckf...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Wed, Jan 4, 2017 at 1:27 PM, Jose Blanquicet wrote:
> On Tue, Jan 3, 2017 at 5:44 PM, Daniel Wagner wrote:
>>> I asked if such a reconnection is a desired behaviour in wpa_supplican
>>> mailing list and Jouni confirmed this is how it should works and
>>> suggested a solution
>>> (http://lists.infradead.org/pipermail/hostap/2016-December/036844.html).
>>> He told that we need to keep track of the created network profiles
>>> during WPS provisioning (Yes, they may be more than one) and then mark
>>> them as disabled or delete them. What do you think?
>>
>>
>> If wpa_supplicant behavior is supposed to be correct, then there aren't many
>> options. Hopefully this isn't too complex to add to wifi.c. That file is
>> already a bit big but well, not much choice.
>>
>> Are you going to work on this?
>
> Well, I think maybe it would need to be implemented at lower lever
> than wifi.c, it means into gsupplicant.c level because it concerns
> D-Bus signals, network profiles and stuff strictly related to
> wpa_supplicant. However, I have not looked at this into details yet
> thus I am not completely sure.
>
> And yes, maybe it would not be so complex but only once you know
> how/when does wpa_supplicant send those networks profile information
> for WPS in order to avoid to clutter non-WPS stuff and auto-connect
> implementation. So, I will start studying wpa_supplicant a little bit
> more and ask for more details to Jouni. Then, I will see if it is
> quick enough to be done now, otherwise I will need to postpone also
> this.
We found a way to simulate AP which generates multiple WPS credentials
on a single WPS provisioning step. It can be done by using hostapd,
one will need to enable CONFIG_TESTING_OPTION into the config file and
run ?set wps_testing_dummy_cred 1? from hostap_cli before doing
"wpa_pbc / wps_pin".
We worked on a patch and we will put it together with the series we
have been working for RFC of WPS connections.
Regards,
Jose Blanquicet
------------------------------
Message: 3
Date: Fri, 27 Jan 2017 15:28:24 +0000
From: Jose Blanquicet <[email protected]>
To: [email protected]
Subject: Service remains on service list even if it is not longer
available
Message-ID:
<CAFC8iJKM=zzwuc61zsgjifu_rxn9puhu75vfpey-41n0arh...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
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?
Regards,
Jose Blanquicet
------------------------------
Message: 4
Date: Fri, 27 Jan 2017 19:43:39 +0200
From: Slava Monich <[email protected]>
To: [email protected]
Subject: [PATCH] inet: Prevent glib source from being removed twice
Message-ID: <[email protected]>
If GIOFunc callback returns FALSE, the event source is removed
by glib. We either call g_source_remove or remove FALSE from the
callback. If we do both, the source is getting removed twice which
glib considers a critical error.
---
src/inet.c | 66 +++++++++++++++++++++++++++++++++++---------------------------
1 file changed, 37 insertions(+), 29 deletions(-)
diff --git a/src/inet.c b/src/inet.c
index 8e88054..f2b5b72 100644
--- a/src/inet.c
+++ b/src/inet.c
@@ -1252,13 +1252,12 @@ static gboolean rs_timeout_cb(gpointer user_data)
return FALSE;
}
-static int icmpv6_recv(int fd, gpointer user_data)
+static int icmpv6_recv(int fd, struct xs_cb_data *data)
{
struct msghdr mhdr;
struct iovec iov;
unsigned char chdr[CMSG_BUF_LEN];
unsigned char buf[1540];
- struct xs_cb_data *data = user_data;
struct nd_router_advert *hdr;
struct sockaddr_in6 saddr;
ssize_t len;
@@ -1280,7 +1279,6 @@ static int icmpv6_recv(int fd, gpointer user_data)
len = recvmsg(fd, &mhdr, 0);
if (len < 0) {
cb(NULL, 0, data->user_data);
- xs_cleanup(data);
return -errno;
}
@@ -1291,26 +1289,30 @@ static int icmpv6_recv(int fd, gpointer user_data)
return 0;
cb(hdr, len, data->user_data);
- xs_cleanup(data);
return len;
}
-static gboolean icmpv6_event(GIOChannel *chan, GIOCondition cond, gpointer
data)
+static gboolean icmpv6_event(GIOChannel *chan, GIOCondition cond,
+ gpointer user_data)
{
int fd, ret;
+ struct xs_cb_data *data = user_data;
DBG("");
if (cond & (G_IO_NVAL | G_IO_HUP | G_IO_ERR))
- return FALSE;
+ goto remove;
fd = g_io_channel_unix_get_fd(chan);
ret = icmpv6_recv(fd, data);
if (ret == 0)
- return TRUE;
+ return G_SOURCE_CONTINUE;
- return FALSE;
+remove:
+ data->watch_id = 0;
+ xs_cleanup(data);
+ return G_SOURCE_REMOVE;
}
/* Adapted from RFC 1071 "C" Implementation Example */
@@ -1667,13 +1669,12 @@ void __connman_inet_ipv6_stop_recv_rs(void *context)
xs_cleanup(context);
}
-static int icmpv6_rs_recv(int fd, gpointer user_data)
+static int icmpv6_rs_recv(int fd, struct xs_cb_data *data)
{
struct msghdr mhdr;
struct iovec iov;
unsigned char chdr[CMSG_BUF_LEN];
unsigned char buf[1540];
- struct xs_cb_data *data = user_data;
struct nd_router_solicit *hdr;
struct sockaddr_in6 saddr;
ssize_t len;
@@ -1709,21 +1710,24 @@ static int icmpv6_rs_recv(int fd, gpointer user_data)
}
static gboolean icmpv6_rs_event(GIOChannel *chan, GIOCondition cond,
- gpointer data)
+ gpointer user_data)
{
int fd, ret;
+ struct xs_cb_data *data = user_data;
DBG("");
if (cond & (G_IO_NVAL | G_IO_HUP | G_IO_ERR))
- return FALSE;
+ goto remove;
fd = g_io_channel_unix_get_fd(chan);
ret = icmpv6_rs_recv(fd, data);
if (ret == 0)
- return TRUE;
+ return G_SOURCE_CONTINUE;
- return FALSE;
+remove:
+ data->watch_id = 0;
+ return G_SOURCE_REMOVE;
}
int __connman_inet_ipv6_start_recv_rs(int index,
@@ -1797,13 +1801,12 @@ static gboolean ns_timeout_cb(gpointer user_data)
return FALSE;
}
-static int icmpv6_nd_recv(int fd, gpointer user_data)
+static int icmpv6_nd_recv(int fd, struct xs_cb_data *data)
{
struct msghdr mhdr;
struct iovec iov;
unsigned char chdr[CMSG_BUF_LEN];
unsigned char buf[1540];
- struct xs_cb_data *data = user_data;
struct nd_neighbor_advert *hdr;
struct sockaddr_in6 saddr;
ssize_t len;
@@ -1825,7 +1828,6 @@ static int icmpv6_nd_recv(int fd, gpointer user_data)
len = recvmsg(fd, &mhdr, 0);
if (len < 0) {
cb(NULL, 0, &data->addr.sin6_addr, data->user_data);
- xs_cleanup(data);
return -errno;
}
@@ -1844,27 +1846,30 @@ static int icmpv6_nd_recv(int fd, gpointer user_data)
return 0;
cb(hdr, len, &data->addr.sin6_addr, data->user_data);
- xs_cleanup(data);
return len;
}
static gboolean icmpv6_nd_event(GIOChannel *chan, GIOCondition cond,
- gpointer data)
+ gpointer user_data)
{
int fd, ret;
+ struct xs_cb_data *data = user_data;
DBG("");
if (cond & (G_IO_NVAL | G_IO_HUP | G_IO_ERR))
- return FALSE;
+ goto remove;
fd = g_io_channel_unix_get_fd(chan);
ret = icmpv6_nd_recv(fd, data);
if (ret == 0)
- return TRUE;
+ return G_SOURCE_CONTINUE;
- return FALSE;
+remove:
+ data->watch_id = 0;
+ xs_cleanup(data);
+ return G_SOURCE_REMOVE;
}
int __connman_inet_ipv6_do_dad(int index, int timeout_ms,
@@ -2188,9 +2193,8 @@ static gboolean inet_rtnl_timeout_cb(gpointer user_data)
return FALSE;
}
-static int inet_rtnl_recv(GIOChannel *chan, gpointer user_data)
+static int inet_rtnl_recv(GIOChannel *chan, struct inet_rtnl_cb_data
*rtnl_data)
{
- struct inet_rtnl_cb_data *rtnl_data = user_data;
struct __connman_inet_rtnl_handle *rth = rtnl_data->rtnl;
struct nlmsghdr *h = NULL;
struct sockaddr_nl nladdr;
@@ -2262,7 +2266,7 @@ static int inet_rtnl_recv(GIOChannel *chan, gpointer
user_data)
rtnl_data->callback(h, rtnl_data->user_data);
- inet_rtnl_cleanup(rtnl_data);
+ return 1;
}
return 0;
@@ -2272,17 +2276,21 @@ static gboolean inet_rtnl_event(GIOChannel *chan,
GIOCondition cond,
gpointer user_data)
{
int ret;
+ struct inet_rtnl_cb_data *rtnl_data = user_data;
DBG("");
if (cond & (G_IO_NVAL | G_IO_HUP | G_IO_ERR))
- return FALSE;
+ goto remove;
- ret = inet_rtnl_recv(chan, user_data);
+ ret = inet_rtnl_recv(chan, rtnl_data);
if (ret != 0)
- return TRUE;
+ return G_SOURCE_CONTINUE;
- return FALSE;
+remove:
+ rtnl_data->watch_id = 0;
+ inet_rtnl_cleanup(rtnl_data);
+ return G_SOURCE_REMOVE;
}
int __connman_inet_rtnl_talk(struct __connman_inet_rtnl_handle *rtnl,
--
1.9.1
------------------------------
Message: 5
Date: Fri, 27 Jan 2017 20:48:52 +0200
From: Slava Monich <[email protected]>
To: [email protected]
Subject: [PATCH] inet: Don't close file descriptor twice
Message-ID: <[email protected]>
Channels created by __connman_inet_rtnl_talk shouldn't close the
file descriptor, it's done by __connman_inet_rtnl_close.
---
src/inet.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/inet.c b/src/inet.c
index 8e88054..553b57a 100644
--- a/src/inet.c
+++ b/src/inet.c
@@ -2310,7 +2310,6 @@ int __connman_inet_rtnl_talk(struct
__connman_inet_rtnl_handle *rtnl,
inet_rtnl_timeout_cb, data);
data->channel = g_io_channel_unix_new(rtnl->fd);
- g_io_channel_set_close_on_unref(data->channel, TRUE);
g_io_channel_set_encoding(data->channel, NULL, NULL);
g_io_channel_set_buffered(data->channel, FALSE);
--
1.9.1
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 15, Issue 35
***************************************
