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. [PATCH v3] gsupplicant: Mem leak in wpa_s because
"RemoveNetwork" not called (Naveen Singh)
2. Disabling the network on Disconnect Notification (Naveen Singh)
3. Re: Wifi tether without passphrase (Patrik Flykt)
4. Re: [RFC v2] connection: Move online service to ready if
gateway is removed (Patrik Flykt)
5. connman unser systemd --user session (Vasiliy Tolstov)
6. Re: Disabling the network on Disconnect Notification
(Patrik Flykt)
7. Re: [RFC v2] connection: Move online service to ready if
gateway is removed (Patrik Flykt)
8. Re: connman unser systemd --user session (Patrik Flykt)
----------------------------------------------------------------------
Message: 1
Date: Thu, 18 Feb 2016 22:11:40 -0800
From: Naveen Singh <naveensingh0...@gmail.com>
To: conn...@ml01.01.org
Subject: [PATCH v3] gsupplicant: Mem leak in wpa_s because
"RemoveNetwork" not called
Message-ID:
<1455862300-95985-1-git-send-email-naveensingh0...@gmail.com>
From: nasingh <naveensingh0...@gmail.com>
Connman did not call netwok_remove in case AP deauthenticated client causing
wpa_s to re-allocate the ssid pointer even if the next connection attempt
is for the same SSID. This change ensures that at the time of connection
(DBUS Method call AddNetwork) if the network is found not removed, it calls
the dbus API to remove the network and once network is removed, proceed with
the connection.
Tested by running a deauth loop script at the AP end and ensure that wpa_s does
not allocate memory for struct wpa_ssid for all the subsequent
connection attempts. During the test memory usage of wpa_s is monitored.
---
gsupplicant/supplicant.c | 156 ++++++++++++++++++++++++++++++++---------------
1 file changed, 108 insertions(+), 48 deletions(-)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 342cb01..f2065b2 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -249,6 +249,50 @@ struct _GSupplicantGroup {
GSList *members;
};
+struct interface_data {
+ GSupplicantInterface *interface;
+ char *path; /* Interface path cannot be taken from interface (above) as
+ * it might have been freed already.
+ */
+ GSupplicantInterfaceCallback callback;
+ void *user_data;
+ bool network_remove_in_progress;
+ GSupplicantSSID *ssid;
+};
+
+struct interface_create_data {
+ char *ifname;
+ char *driver;
+ char *bridge;
+ GSupplicantInterface *interface;
+ GSupplicantInterfaceCallback callback;
+ void *user_data;
+};
+
+struct interface_connect_data {
+ GSupplicantInterface *interface;
+ char *path;
+ GSupplicantInterfaceCallback callback;
+ void *user_data;
+ union {
+ GSupplicantSSID *ssid;
+ GSupplicantPeerParams *peer;
+ };
+};
+
+struct interface_scan_data {
+ GSupplicantInterface *interface;
+ char *path;
+ GSupplicantInterfaceCallback callback;
+ GSupplicantScanParams *scan_params;
+ void *user_data;
+};
+
+static int network_remove(struct interface_data *data);
+static void network_remove_params(DBusMessageIter *iter, void *user_data);
+static void network_remove_result(const char *error,
+ DBusMessageIter *iter, void *user_data);
+
static inline void debug(const char *format, ...)
{
char str[256];
@@ -3476,43 +3520,6 @@ GSupplicantPeer
*g_supplicant_interface_peer_lookup(GSupplicantInterface *interf
return peer;
}
-struct interface_data {
- GSupplicantInterface *interface;
- char *path; /* Interface path cannot be taken from interface (above) as
- * it might have been freed already.
- */
- GSupplicantInterfaceCallback callback;
- void *user_data;
-};
-
-struct interface_create_data {
- char *ifname;
- char *driver;
- char *bridge;
- GSupplicantInterface *interface;
- GSupplicantInterfaceCallback callback;
- void *user_data;
-};
-
-struct interface_connect_data {
- GSupplicantInterface *interface;
- char *path;
- GSupplicantInterfaceCallback callback;
- union {
- GSupplicantSSID *ssid;
- GSupplicantPeerParams *peer;
- };
- void *user_data;
-};
-
-struct interface_scan_data {
- GSupplicantInterface *interface;
- char *path;
- GSupplicantInterfaceCallback callback;
- GSupplicantScanParams *scan_params;
- void *user_data;
-};
-
static void interface_create_data_free(struct interface_create_data *data)
{
g_free(data->ifname);
@@ -4105,7 +4112,6 @@ static void interface_add_network_result(const char
*error,
SUPPLICANT_DBG("PATH: %s", path);
- g_free(interface->network_path);
interface->network_path = g_strdup(path);
supplicant_dbus_method_call(data->interface->path,
@@ -4656,7 +4662,8 @@ int g_supplicant_interface_connect(GSupplicantInterface
*interface,
void *user_data)
{
struct interface_connect_data *data;
- int ret;
+ struct interface_data *intf_data;
+ int ret = 0;
if (!interface)
return -EINVAL;
@@ -4685,12 +4692,44 @@ int g_supplicant_interface_connect(GSupplicantInterface
*interface,
SUPPLICANT_INTERFACE ".Interface.WPS",
"ProcessCredentials", DBUS_TYPE_BOOLEAN_AS_STRING,
wps_process_credentials, wps_start, data, interface);
- } else
- ret = supplicant_dbus_method_call(interface->path,
- SUPPLICANT_INTERFACE ".Interface", "AddNetwork",
- interface_add_network_params,
- interface_add_network_result, data,
- interface);
+ } else {
+ /* By the time there is a request for connect and the network
+ * path is not NULL it means that connman has not removed the
+ * previous network pointer. This can happen in the case AP
+ * deauthenticated client and connman does not remove the
+ * previously connected network pointer. This causes supplicant
+ * to reallocate the memory for struct wpa_ssid again even if it
+ * is the same SSID. This causes memory usage of wpa_supplicnat
+ * to go high. The idea here is that if the previously connected
+ * network is not removed at the time of next connection attempt
+ * check if the network path is not NULL. In case it is non-NULL
+ * first remove the network and then once removal is
successful, add
+ * the network.
+ */
+
+ if (interface->network_path != NULL) {
+ g_free(data->path);
+ dbus_free(data);
+
+ intf_data = dbus_malloc0(sizeof(*intf_data));
+ if (!intf_data)
+ return -ENOMEM;
+
+ intf_data->interface = interface;
+ intf_data->path = g_strdup(interface->path);
+ intf_data->callback = callback;
+ intf_data->ssid = ssid;
+ intf_data->user_data = user_data;
+ intf_data->network_remove_in_progress = TRUE;
+ network_remove(intf_data);
+ } else {
+ ret = supplicant_dbus_method_call(interface->path,
+ SUPPLICANT_INTERFACE ".Interface",
"AddNetwork",
+ interface_add_network_params,
+ interface_add_network_result, data,
+ interface);
+ }
+ }
if (ret < 0) {
g_free(data->path);
@@ -4705,6 +4744,7 @@ static void network_remove_result(const char *error,
DBusMessageIter *iter, void *user_data)
{
struct interface_data *data = user_data;
+ struct interface_connect_data * connect_data;
int result = 0;
SUPPLICANT_DBG("");
@@ -4716,11 +4756,31 @@ static void network_remove_result(const char *error,
result = -ECONNABORTED;
}
- g_free(data->path);
+ g_free(data->interface->network_path);
+ data->interface->network_path = NULL;
- if (data->callback)
- data->callback(result, data->interface, data->user_data);
+ if (data->network_remove_in_progress == TRUE) {
+ data->network_remove_in_progress = FALSE;
+ connect_data = dbus_malloc0(sizeof(*connect_data));
+ if (!connect_data)
+ return;
+
+ connect_data->interface = data->interface;
+ connect_data->path = data->path;
+ connect_data->callback = data->callback;
+ connect_data->ssid = data->ssid;
+ connect_data->user_data = data->user_data;
+ supplicant_dbus_method_call(data->interface->path,
+ SUPPLICANT_INTERFACE ".Interface", "AddNetwork",
+ interface_add_network_params,
+ interface_add_network_result, connect_data,
+ connect_data->interface);
+ } else {
+ g_free(data->path);
+ if (data->callback)
+ data->callback(result, data->interface,
data->user_data);
+ }
dbus_free(data);
}
--
2.7.0.rc3.207.g0ac5344
------------------------------
Message: 2
Date: Thu, 18 Feb 2016 22:52:47 -0800
From: Naveen Singh <naveensingh0...@gmail.com>
To: connman@lists.01.org
Subject: Disabling the network on Disconnect Notification
Message-ID:
<CAGTDzKm47=m6xpOCVhHzr1DJuTkiN2H=hsosuv_cm+x8+uo...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi All
On the disconnect notification from wpa_supplicant (when the interface
state becomes G_SUPPLICANT_STATE_DISCONNECTED), connman disables the
network (SSID). This is done from interface_state function in
plugins/wifi.c:
if (g_supplicant_interface_enable_selected_network(interface,
FALSE) != 0)
DBG("Could not disable selected network");
This severely impacts wpa_supplicant's attempt of getting device
connected back to WiFi. Lot of enterprise AP now have band steering
and/or load balancing enabled as a result of which they keep sending
deauth frames to client till it picks the correct BSSID for
connection. Now if wpa_supplicant is left alone, it would properly
converge to the right BSSID where the association would stick (by
blacklisting a BSSID if it does not allow or deny the connection and
trying the next one)
But now with the very first disconnect notification, connman disables
the whole network which ends up disabling the whole SSID and
wpa_supplicant does not continue with its connection attempts.
Next time when this SSID gets enabled from connman (as a part of next
connect), the same story repeats. End result device sometimes never
get connected. The above piece of code is impacting L2 level roaming
decisions in connman. And I do not think connman has any intention or
desire to interfere in any BSSID level roaming decision of
wpa_supplicant.
Even for the AP which sends deauth with reason code 6/7/4,
wpa_supplicant has internal logic to get device connected fast. This
also gets impacted quite a bit because of disable logic.
Even logs look very confusing at the time of disconnection. You see a
successful association (because of wpa_s connection attempt) followed
by an internally generated disconnect.
I did a test by removing this code and following are the events that
happened on receiving deauth:
1) Client receives deauth frame (reason code 15)
2) wpa_supplicant blacklists the current AP and schedule a scan.
3) It generates disconnect notification to connman
4) Connman released its current IP.
5) wpa_supplicant gets the scan result and finds all the AP
advertising the same SSID.
6) It proceeds with the connection with next BSSID.
7) It connects back with this BSSID
8) Connman gets device the IP address
If deauth is received with reason code 6 or 7 or 4 then there is even
no scan and device gets connected real fast.
Let me know your thoughts on this. I will send my patch soon
Regards
Naveen
------------------------------
Message: 3
Date: Fri, 19 Feb 2016 09:01:12 +0200
From: Patrik Flykt <patrik.fl...@linux.intel.com>
To: "Lad, Prabhakar" <prabhakar.cse...@gmail.com>
Cc: connman@lists.01.org
Subject: Re: Wifi tether without passphrase
Message-ID: <1455865272.2934.16.ca...@linux.intel.com>
Content-Type: text/plain; charset="UTF-8"
On Thu, 2016-02-18 at 11:11 +0000, Lad, Prabhakar wrote:
> Hi,
>
> Is there a way to create a AP without a hotspot ? Like we have open
> networks which we can connect to them without passwords.
No. A passphrase is always needed. Withouth a WiFi passphrase all other
tethered devices will be exposed to everybody, which is not what is
wanted in a end user device.
Cheers,
Patrik
------------------------------
Message: 4
Date: Fri, 19 Feb 2016 09:13:31 +0200
From: Patrik Flykt <patrik.fl...@linux.intel.com>
To: Naveen Singh <naveensingh0...@gmail.com>
Cc: connman@lists.01.org
Subject: Re: [RFC v2] connection: Move online service to ready if
gateway is removed
Message-ID: <1455866011.2934.19.ca...@linux.intel.com>
Content-Type: text/plain; charset="UTF-8"
On Wed, 2016-02-17 at 14:52 -0800, Naveen Singh wrote:
> 1) dhcp_callback in network.c gets called from dhcp state machine
> after losing the lease.
> 2) Since it is a failure case, dhcp_failure gets called
At _this_ point the service needs to be taken to ready state.
> 3) From dhcp_failure we call __connman_ipconfig_gateway_remove which
> ends up calling __connman_connection_gateway_remove.
Yes, the above patch addresses only point 3). I'm not really sure it
will work as expected, it is possible that ConnMan anyway restores the
gateway. Needs more investigation.
> Now with your fix that you suggested even though we have cleared IPv4
> address we are still making the state as READY which probably is not
> the right thing to do. Do you think doing a state machine transition
> from dhcp_failure to CONFIGURATION is the right thing to do?
Cheers,
Patrik
------------------------------
Message: 5
Date: Fri, 19 Feb 2016 10:18:11 +0300
From: Vasiliy Tolstov <v.tols...@selfip.ru>
To: connman <connman@lists.01.org>
Subject: connman unser systemd --user session
Message-ID:
<cacaajqtmeuehktjrp6yqnfcpag0fy5a5u9kcgvdo8eezx0v...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Does it possible to run connman in systemd --user session? I don't
want to store wifi passwords in /var/lib/...
--
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru
------------------------------
Message: 6
Date: Fri, 19 Feb 2016 09:20:47 +0200
From: Patrik Flykt <patrik.fl...@linux.intel.com>
To: Naveen Singh <naveensingh0...@gmail.com>
Cc: connman@lists.01.org
Subject: Re: Disabling the network on Disconnect Notification
Message-ID: <1455866447.2934.25.ca...@linux.intel.com>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Thu, 2016-02-18 at 22:52 -0800, Naveen Singh wrote:
> Hi All
> On the disconnect notification from wpa_supplicant (when the interface
> state becomes G_SUPPLICANT_STATE_DISCONNECTED), connman disables the
> network (SSID). This is done from interface_state function in
> plugins/wifi.c:
>
> if (g_supplicant_interface_enable_selected_network(interface,
> FALSE) != 0)
> DBG("Could not disable selected network");
>
> This severely impacts wpa_supplicant's attempt of getting device
> connected back to WiFi. Lot of enterprise AP now have band steering
> and/or load balancing enabled as a result of which they keep sending
> deauth frames to client till it picks the correct BSSID for
> connection. Now if wpa_supplicant is left alone, it would properly
> converge to the right BSSID where the association would stick (by
> blacklisting a BSSID if it does not allow or deny the connection and
> trying the next one)
>
> But now with the very first disconnect notification, connman disables
> the whole network which ends up disabling the whole SSID and
> wpa_supplicant does not continue with its connection attempts.
> Next time when this SSID gets enabled from connman (as a part of next
> connect), the same story repeats. End result device sometimes never
> get connected. The above piece of code is impacting L2 level roaming
> decisions in connman. And I do not think connman has any intention or
> desire to interfere in any BSSID level roaming decision of
> wpa_supplicant.
>
> Even for the AP which sends deauth with reason code 6/7/4,
> wpa_supplicant has internal logic to get device connected fast. This
> also gets impacted quite a bit because of disable logic.
>
> Even logs look very confusing at the time of disconnection. You see a
> successful association (because of wpa_s connection attempt) followed
> by an internally generated disconnect.
>
> I did a test by removing this code and following are the events that
> happened on receiving deauth:
>
> 1) Client receives deauth frame (reason code 15)
> 2) wpa_supplicant blacklists the current AP and schedule a scan.
> 3) It generates disconnect notification to connman
At this point a properly designed API would not tell that the network
disconnected, as it obviously is looking for another AP to connect to.
wpa_supplicant does not have the worlds greatest API design in place as
we've seen with other patches in the recent past...
> 4) Connman released its current IP.
> 5) wpa_supplicant gets the scan result and finds all the AP
> advertising the same SSID.
> 6) It proceeds with the connection with next BSSID.
> 7) It connects back with this BSSID
> 8) Connman gets device the IP address
>
> If deauth is received with reason code 6 or 7 or 4 then there is even
> no scan and device gets connected real fast.
>
> Let me know your thoughts on this. I will send my patch soon
ConnMan can implement the workaround not to drop the connection when it
is obvious that wpa_supplicant will be looking for another AP to connect
to. Then again we don't want ConnMan to be stuck with connecting
forever, either.
Please propose a fix.
Cheers,
Patrik
------------------------------
Message: 7
Date: Fri, 19 Feb 2016 09:22:08 +0200
From: Patrik Flykt <patrik.fl...@linux.intel.com>
To: Naveen Singh <naveensingh0...@gmail.com>
Cc: connman@lists.01.org
Subject: Re: [RFC v2] connection: Move online service to ready if
gateway is removed
Message-ID: <1455866528.2934.27.ca...@linux.intel.com>
Content-Type: text/plain; charset="UTF-8"
On Fri, 2016-02-19 at 09:13 +0200, Patrik Flykt wrote:
> > 1) dhcp_callback in network.c gets called from dhcp state machine
> > after losing the lease.
> > 2) Since it is a failure case, dhcp_failure gets called
>
> At _this_ point the service needs to be taken to ready state.
Apparently I missed my morning coffee. The above should read "...to
configuration state and address aquisition restarted."
Cheers,
Patrik
------------------------------
Message: 8
Date: Fri, 19 Feb 2016 10:08:45 +0200
From: Patrik Flykt <patrik.fl...@linux.intel.com>
To: Vasiliy Tolstov <v.tols...@selfip.ru>
Cc: connman <connman@lists.01.org>
Subject: Re: connman unser systemd --user session
Message-ID: <1455869325.2934.31.ca...@linux.intel.com>
Content-Type: text/plain; charset="UTF-8"
On Fri, 2016-02-19 at 10:18 +0300, Vasiliy Tolstov wrote:
> Does it possible to run connman in systemd --user session? I don't
> want to store wifi passwords in /var/lib/...
You are the first one to try it out. Remember that then the program
needs more capabilities to perform its task in this case. I don't see a
problem with storing passphrases in /var/lib, they are anyway shared
with all the devices connecting to the network so...
Cheers,
Patrik
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
connman@lists.01.org
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 4, Issue 22
**************************************
