RE: Connman behavior with marginally stabe wifi
Hi, I personally think it is strange behavior to depend on wpa_supplicant to remove the network, for connman to auto connect to a network again. And this will not work if, for some reason, a periodic scan occurs within 2 minutes. But ok... this is the case at this moment. This however does not solve the following problem: When the network times out within wpa_supplicant, the service is indeed removed. However not all knowledge is removed because the settings are stored in /var/lib/connman/.../settings, including Failure=invalid-key. (As mentioned below, the invalid-key can occur during reconnection even though the key is correct). Now when the network appears again after a new scan, the data from /var/lib/connman/.../settings is loaded, including the Failure=invalid-key. This prevents connman from automatically reconnecting to this service. So connman will never reconnect to the network without intervention from an application. Is it perhaps an idea to have some form of configurable timeout that removes the failure (and invalid-key error) from the service, after which it re-evaluates the services list for auto connecting? This would relax the strain on picky networks, yet still allows reconnections without any interactions from other applications and without depending on the scan and flush behavior of wpa_supplicant? Regards, Thiemo -Original Message- From: connman [mailto:connman-boun...@connman.net] On Behalf Of Patrik Flykt Sent: 18 September 2014 15:24 To: connman@connman.net Subject: Re: Connman behavior with marginally stabe wifi Hi, On Thu, 2014-09-18 at 08:57 +, Thiemo van Engelen wrote: We however have problems with the wifi connection, especially when it is installed such that the wifi connection is marginally stable (and there is no ethernet connection) What we see is that when the connection is dropped (due to bad reception for example), connman tries to reconnect which can fail, in which case connman goes into the failure state with one of 2 errors: connect-failed or invalid-key. This depends on what wpa_supplicant actually reports back to ConnMan. My guess is that the connection was broken in the middle of the key exchange or similar in the second case. What we also see is that connman does not try to reconnect, once it is in the failure state. I would say that this is not the behaviour you would want from an embedded device, as connman would need some attention to come out of the failure state and retry. The other side of the coin is that if we do not disable retries to a failed network, we'd end up constantly banging on the network whenever we have a wrong passphrase or bad reception as in your case. This will lock out ConnMan from certain set of networks that allow only a limited amount of connection attempts. And since those access points put the ConnMan device on hold for quite a few hours before allowing further (re)connects, it's quite a mess. When I look at my (android) phone, it retries to connect to my home WIFI for example, even when I am at the edge of the router range. I certainly never have to go into the WIFI menu because it is in some failure state. What is the reasoning behind this failure behaviour of connman and can it perhaps be adjusted via the configuration? Or is this typically solved in the controlling application on embedded devices and if this is the case, does anyone have some pointers and what and what not to do to get it going again without user interaction? It is solved if the network is timed out by wpa_supplicant. At that point all temporary knowledge of the network and its state is cleared from ConnMan. Once it re-appears, it won't have any previous failed state associated with it and can be retried. When there is at least some form of UI, the user can always mitigate the issue by forcefully connecting to the failed network. Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
valgrind reports use of already freed memory for wifi-pending_network
Hi, came across the valgrind report below when trying to reproduce a connmand crash. Test was run against Jolla version of connmand (1.24 + some patches) so the line numbers are slightly off wrt upstream but the locations should be in the same ballpark. In the test I was periodically removing and reinstalling wlan kernel module, periodically restarting wpa supplicant (both simple sh loops) and semi-randomly connecting to and disconnecting from networks from the phone UI. Kernel module and wpa supplicant would be up barely enough to have time to scan and connect/disconnect a couple of times to some of the networks configured on the device, in an attempt to make connect/disconnect overlap with those special events. While the test is somewhat convoluted the root cause for the issue could perhaps be triggered by a simpler scenario too. It looks like wifi-pending_network has already been freed by the time the pointer is dereferenced. I get rid of this if I add reference counting to pending_network, but since reference counting it was previously removed (commit c8c5cd51) perhaps there's a more proper way to handle the issue. ==2725== Invalid read of size 4 ==2725==at 0x41520: connman_network_get_device (network.c:2161) ==2725==by 0x1FAF3: network_connect (wifi.c:1479) ==2725==by 0x217F3: disconnect_callback (wifi.c:1545) ==2725==by 0x24A5B: interface_disconnect_result (supplicant.c:4054) ==2725==by 0x29BBF: supplicant_dbus_method_call_cancel_all (dbus.c:451) ==2725==by 0x286F3: g_supplicant_interface_cancel (supplicant.c:2640) ==2725==by 0x2876B: signal_interface_removed (supplicant.c:2047) ==2725==by 0x2325F: g_supplicant_filter (supplicant.c:2630) ==2725==by 0x4976F47: dbus_connection_dispatch (dbus-connection.c:4631) ==2725==by 0x82653: message_dispatch (mainloop.c:72) ==2725==by 0x48A7A8B: g_idle_dispatch (gmain.c:5251) ==2725==by 0x48ABB1F: g_main_context_dispatch (gmain.c:3066) ==2725== Address 0x5730854 is 60 bytes inside a block of size 144 free'd ==2725==at 0x483752C: free (vg_replace_malloc.c:446) ==2725==by 0x48B36AB: g_free (gmem.c:197) ==2725==by 0x237B7: remove_network (supplicant.c:443) ==2725==by 0x48951E7: g_hash_table_remove_node (ghash.c:448) ==2725==by 0x48959D3: g_hash_table_remove_internal (ghash.c:1276) ==2725==by 0x25D8F: signal_bss_removed (supplicant.c:1803) ==2725==by 0x2325F: g_supplicant_filter (supplicant.c:2630) ==2725==by 0x4976F47: dbus_connection_dispatch (dbus-connection.c:4631) ==2725==by 0x82653: message_dispatch (mainloop.c:72) ==2725==by 0x48A7A8B: g_idle_dispatch (gmain.c:5251) ==2725==by 0x48ABB1F: g_main_context_dispatch (gmain.c:3066) ==2725==by 0x48ABE23: g_main_context_iterate.part.19 (gmain.c:3713) ==2725== BR, H. ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Connman behavior with marginally stabe wifi
Hi Thiemo, I personally think it is strange behavior to depend on wpa_supplicant to remove the network, for connman to auto connect to a network again. ConnMan does not manage any real wifi core logic, wpa_supplicant does: if a scan does not find a network (thus its BSS(s)), there is just no point telling it's still here. And this will not work if, for some reason, a periodic scan occurs within 2 minutes. But ok... this is the case at this moment. This however does not solve the following problem: When the network times out within wpa_supplicant, the service is indeed removed. However not all knowledge is removed because the settings are stored in /var/lib/connman/.../settings, including Failure=invalid-key. (As mentioned below, the invalid-key can occur during reconnection even though the key is correct). Now when the network appears again after a new scan, the data from /var/lib/connman/.../settings is loaded, including the Failure=invalid-key. This prevents connman from automatically reconnecting to this service. So connman will never reconnect to the network without intervention from an application. Is it perhaps an idea to have some form of configurable timeout that removes the failure (and invalid-key error) from the service, after which it re-evaluates the services list for auto connecting? This would relax the strain on picky networks, yet still allows reconnections without any interactions from other applications and without depending on the scan and flush behavior of wpa_supplicant? Could be yes. It could even be implemented as a plugin I think. Also, having a retry limit would be nice, so you won't end up trying and trying a network for which you really don't have the right psk anymore. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
