Send connman mailing list submissions to
connman@lists.01.org
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
connman-requ...@lists.01.org
You can reach the person managing the list at
connman-ow...@lists.01.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: [PATCH] wifi: Clean up connected flag after disconnecting
(Jose Blanquicet)
2. Re: [PATCH] wifi: Clean up connected flag after disconnecting
(Patrik Flykt)
3. [PATCH] gsupplicant: Fix memory leak (Jose Blanquicet)
4. Re: [PATCH] wifi: Clean up connected flag after disconnecting
(Patrik Flykt)
----------------------------------------------------------------------
Message: 1
Date: Thu, 15 Sep 2016 11:39:17 +0200
From: Jose Blanquicet <blanqui...@gmail.com>
To: connman@lists.01.org
Subject: Re: [PATCH] wifi: Clean up connected flag after disconnecting
Message-ID:
<cafc8ijk39udm5+-xmer7rzbzj8_i2rvhjzk_tgkhc+vmt2t...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
> After disconnecting, wifi->connected value is not coherent with the
> actual interface state and it does not allow to start auto-scan. In
> addition, this patch will also help future patches to make decisions
> based on this flag.
To be precise, it only happens when we are disconnecting from previous
WPS successful association. It is because in
supplicant.c:interface_disconnect_result() we do not have to remove
the network and then disconnect callback
(wifi.c:disconnect_callback()) is called faster and before signal
"PropertiesChanged" is received which indicates "State" changed to
"disconnected". Therefore, when this signal is handled in
wifi.c:interface_state() the wifi->network was already removed by
disconnect_callback() and then interface_state() will intermediately
return without reseting wifi->connected flag to false. The other flags
like network->connected and wifi->disconnecting are correctly reseted
in wifi.c:disconnect_callback() but wifi->connected is missing.
This is a consequence of the fix done in
c82fe8682b742005086fd28b8681521f09747e9f because before it
wifi.c:disconnect_callback() was not even called.
> NOTE: After checking the use of this flag I did not see any place where
> this modification could create regressions or problems with roaming in
> interface_state(), there is something I am missing?
I have been testing it and it has not given me any problem so far.
> ---
> plugins/wifi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/plugins/wifi.c b/plugins/wifi.c
> index 9d56671..206bf48 100644
> --- a/plugins/wifi.c
> +++ b/plugins/wifi.c
> @@ -2145,6 +2145,7 @@ static void disconnect_callback(int result,
> GSupplicantInterface *interface,
> }
>
> wifi->disconnecting = false;
> + wifi->connected = false;
>
> if (wifi->pending_network) {
> network_connect(wifi->pending_network);
> --
> 1.9.1
>
------------------------------
Message: 2
Date: Thu, 15 Sep 2016 12:48:29 +0300
From: Patrik Flykt <patrik.fl...@linux.intel.com>
To: Jose Blanquicet <blanqui...@gmail.com>, connman@lists.01.org
Subject: Re: [PATCH] wifi: Clean up connected flag after disconnecting
Message-ID: <1473932909.14271.13.ca...@linux.intel.com>
Content-Type: text/plain; charset="UTF-8"
On Thu, 2016-09-15 at 11:39 +0200, Jose Blanquicet wrote:
> Hi,
>
> > After disconnecting, wifi->connected value is not coherent with the
> > actual interface state and it does not allow to start auto-scan. In
> > addition, this patch will also help future patches to make
> > decisions
> > based on this flag.
>
> To be precise, it only happens when we are disconnecting from
> previous
> WPS successful association. It is because in
> supplicant.c:interface_disconnect_result() we do not have to remove
> the network and then disconnect callback
> (wifi.c:disconnect_callback()) is called faster and before signal
> "PropertiesChanged" is received which indicates "State" changed to
> "disconnected". Therefore, when this signal is handled in
> wifi.c:interface_state() the wifi->network was already removed by
> disconnect_callback() and then interface_state() will intermediately
> return without reseting wifi->connected flag to false. The other
> flags
> like network->connected and wifi->disconnecting are correctly reseted
> in wifi.c:disconnect_callback() but wifi->connected is missing.
>
> This is a consequence of the fix done in
> c82fe8682b742005086fd28b8681521f09747e9f because before it
> wifi.c:disconnect_callback() was not even called.
>
> > NOTE: After checking the use of this flag I did not see any place
> > where
> > this modification could create regressions or problems with roaming
> > in
> > interface_state(), there is something I am missing?
>
> I have been testing it and it has not given me any problem so far.
Works for me too. I'll add the above more precise description to the
commit message.
Cheers,
Patrik
------------------------------
Message: 3
Date: Thu, 15 Sep 2016 12:07:00 +0200
From: Jose Blanquicet <blanqui...@gmail.com>
To: connman@lists.01.org
Subject: [PATCH] gsupplicant: Fix memory leak
Message-ID: <1473934020-11212-1-git-send-email-blanqui...@gmail.com>
Memory allocated to store Wi-Fi Display information needs to be freed.
The number of lost blocks is proportional to the number of found peers.
The following valgrind report was got when there were two peers in range:
==10427== 18 bytes in 2 blocks are definitely lost in loss record 48 of 181
==10427== at 0x4C2CC70: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10427== by 0x4E85668: g_malloc0 (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==10427== by 0x423C7C: peer_property (supplicant.c:2926)
==10427== by 0x42983C: supplicant_dbus_property_foreach (dbus.c:145)
==10427== by 0x429951: property_get_all_reply (dbus.c:184)
==10427== by 0x514A501: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.7.6)
==10427== by 0x514D730: dbus_connection_dispatch (in
/lib/x86_64-linux-gnu/libdbus-1.so.3.7.6)
==10427== by 0x483C8F: message_dispatch (mainloop.c:72)
==10427== by 0x4E7FCE4: g_main_context_dispatch (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==10427== by 0x4E80047: g_main_context_iterate.isra.24 (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==10427== by 0x4E80309: g_main_loop_run (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==10427== by 0x41001C: main (main.c:706)
---
gsupplicant/supplicant.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 0a3815d..7200041 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -764,6 +764,7 @@ static void remove_peer(gpointer data)
g_free(peer->path);
g_free(peer->name);
g_free(peer->identifier);
+ g_free(peer->widi_ies);
g_free(peer);
}
--
1.9.1
------------------------------
Message: 4
Date: Thu, 15 Sep 2016 13:09:50 +0300
From: Patrik Flykt <patrik.fl...@linux.intel.com>
To: Jose Blanquicet <blanqui...@gmail.com>, connman@lists.01.org
Subject: Re: [PATCH] wifi: Clean up connected flag after disconnecting
Message-ID: <1473934190.14271.14.ca...@linux.intel.com>
Content-Type: text/plain; charset="UTF-8"
On Tue, 2016-09-13 at 16:30 +0200, Jose Blanquicet wrote:
> After disconnecting, wifi->connected value is not coherent with the
> actual interface state and it does not allow to start auto-scan. In?
> addition, this patch will also help future patches to make decisions
> based on this flag.
Applied, thanks! As said, updated the commit message with the more
detailed one provided later in this mail thread.
Patrik
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
connman@lists.01.org
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 11, Issue 17
***************************************
