Re: Connecting to an AP with wrong password
Hi, On Mon, Nov 17, 2014 at 5:30 PM, Thangamanimaran, Radhakris (R.) rthan...@visteon.com wrote: Hi, I am using connman 1.24 with wpa_supplicant to realize WiFi station mode functionalities. When I try to connect to an AP along with a wrong password, the connection fails (which is understandable) but connman keeps retrying with the same password. The application above connman doesn't get any specific indication that the connection failed because of wrong password, so that user can be notified. Please let me know your recommendation to handle this use case, so that the application can notify end user to retry with the correct password again. Thanks Consider upgrading, this is from the 1.25 release notes: * Incorrect passphrases are now handled properly when an agent requests a retry and after a reconnect attempt (Patrik Flykt) --Richard ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Issue doing Connect on a failed service
Hi, Currently there is an issue in connman when Connect is issued for a failed service. 1. In connect service the incoming DBusMessage is assigned to service-pending. 2. __connman_service_connect is called which will call __connman_service_clear_error. state_ipv4 and state_ipv6 is set to unknown. In the following call to service_inidicate_state, its found that we transition to idle from failure, resulting in a call to __connman_service_disconnect. 3. In disconnect reply_pending is called which will take the DBusMessage and reply with an error. This is new behaviour since the commit: 127d216001076d2b73a352a019f00d49bae30835 I'm not 100% sure what issue the commit fixed. I guess we could go back and let service_indicate_state only call disconnect in idle if previous state wasnt disconnected OR failure. But that might roll back the fix of the commit. We could also avoid to attach the message (step 1.) but a lot of other error checks would than fail... Happy for any input :-) --Richard ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] gsupplicant: Do P2P detection after interface property load
On Thu, Aug 7, 2014 at 8:21 AM, Tomasz Bursztyka tomasz.burszt...@linux.intel.com wrote: When interface was already created in wpa_supplicant, p2p detection was failing. Thus, calling p2p detection after interface property has been signaled fixes this detection failure. Wpa_supplicant should not create interface before ConnMan asks for it. The only case when it does so, is when it creates the virtual p2p interface, on that one we don't care to check any support. What if connman is restarted while wpa_supplicant is still running? --Richard ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH v2] device: Make sure the device is up and running before enabling it
On Thu, Aug 7, 2014 at 11:05 AM, Tomasz Bursztyka
tomasz.burszt...@linux.intel.com wrote:
It can happen that, after a unproper ConnMan exit, a device is still up.
Once ConnMan is restarted cleanup_devices() will put this device down.
But then, it will never set it up again.
04:08:45 connmand[254]: src/device.c:__connman_device_init()
04:08:45 connmand[254]: src/inet.c:__connman_inet_get_address_netmask()
index 2
04:08:45 connmand[254]: src/device.c:cleanup_devices() cleaning up wlan0
index 2
(...)
04:08:45 connmand[254]: wlan0 {newlink} index 2 operstate 2 DOWN
(...)
04:08:45 connmand[254]: plugins/wifi.c:wifi_newlink() index 2 flags 36866
change 0
04:08:45 connmand[254]: src/technology.c:__connman_technology_add_device()
device 0x35e8a8 type WiFi
04:08:45 connmand[254]: src/technology.c:technology_get() type 3
04:08:45 connmand[254]: src/technology.c:technology_find() type 3
04:08:45 connmand[254]: src/device.c:__connman_device_enable() device
0x35e8a8
Reported by Richard Röjfors richard.rojf...@gmail.com
Ack from me, now connman can be restarted in my setup without leaving the
wifi interface down.
---
src/device.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/device.c b/src/device.c
index a97d790..1a5f0e6 100644
--- a/src/device.c
+++ b/src/device.c
@@ -185,6 +185,10 @@ int __connman_device_enable(struct connman_device
*device)
if (device-powered_pending == PENDING_NONE device-powered)
return -EALREADY;
+ err = connman_inet_ifup(device-index);
+ if (err 0 err != -EALREADY)
+ return err;
+
device-powered_pending = PENDING_ENABLE;
err = device-driver-enable(device);
--
1.8.5.5
___
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
Issue while recovering
Hi, I mentioned this briefly on the mailinglist. If connman dies of some reason (crash or I kill it), my init system will restart connman. But connman fails to connect again (well it works if I also make sure wpa_supplicant is restarted). When connman dies I'm connected to wifi, which I expect to be reconnected to when connman is restarted. A while after the restart my application gets tired and issues a scan, then connman returns NoCarrier, then the application start to toggle power on wifi... Before connman gets killed rfkill output looks like this: # rfkill list 0: phy0: wlan Soft blocked: no Hard blocked: no Afterwards: # rfkill list 0: phy0: wlan Soft blocked: yes Hard blocked: no And the log output: http://pastebin.com/ecyTPitc Since wpa_supplicant and connman runs in different processes I'm not completely sure if the order is correct if events happens in the two processes at the same second. Thanks, Richard ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Issue while recovering
Hi again, I did a new log dump with some more debug. Also I fixed my application, it was hammering connman a bit too much. Actually connman returns already powered WHILE powering on, so my app believed in connman and started to scan. Now it only listens to property changes, so it wont start to scan too early, which makes the log much cleaner The issue remains, the interface get stuck disabled... power off and on cures the situation. This new paste shows this: http://pastebin.com/qAH0mHjR Until it was powered off rfkill was like this: rfkill list 0: phy0: wlan Soft blocked: no Hard blocked: no ifconfig only showed the lo interface, so the interface was down After I powered off: # rfkill list 0: phy0: wlan Soft blocked: yes Hard blocked: no ifconfig still considered the interface down After power on again: # rfkill list 0: phy0: wlan Soft blocked: no Hard blocked: no And ifconfig considered the interface up. //Richard On Wed, Aug 6, 2014 at 2:50 PM, Richard Röjfors richard.rojf...@gmail.com wrote: Hi, I mentioned this briefly on the mailinglist. If connman dies of some reason (crash or I kill it), my init system will restart connman. But connman fails to connect again (well it works if I also make sure wpa_supplicant is restarted). When connman dies I'm connected to wifi, which I expect to be reconnected to when connman is restarted. A while after the restart my application gets tired and issues a scan, then connman returns NoCarrier, then the application start to toggle power on wifi... Before connman gets killed rfkill output looks like this: # rfkill list 0: phy0: wlan Soft blocked: no Hard blocked: no Afterwards: # rfkill list 0: phy0: wlan Soft blocked: yes Hard blocked: no And the log output: http://pastebin.com/ecyTPitc Since wpa_supplicant and connman runs in different processes I'm not completely sure if the order is correct if events happens in the two processes at the same second. Thanks, Richard ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH] gsupplicant: Null check DBusMessageIter to avoid abort
Depending on how dbus is built it might abort when passing null pointers to it.
This patch checks an iter while parsing dbus errors, the iter might be NULL,
for instance when an operation is aborted.
This trace shows the issue:
0 0xb6c24144 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
1 0xb6c27c0c in __GI_abort () at abort.c:89
2 0xb6e73ca8 in _dbus_abort () at
/work/my-arch/dbus/1.6.18-r0/dbus-1.6.18/dbus/dbus-sysdeps.c:94
3 0xb6e6b1b8 in _dbus_warn_check_failed (format=0xb6e77d44 dbus message
iterator is NULL\n) at
/work/my-arch/dbus/1.6.18-r0/dbus-1.6.18/dbus/dbus-internals.c:290
4 0xb6e5a728 in _dbus_message_iter_check (iter=0x0) at
/work/my-arch/dbus/1.6.18-r0/dbus-1.6.18/dbus/dbus-message.c:727
5 0xb6e5b734 in dbus_message_iter_get_arg_type (iter=iter@entry=0x0) at
/work/my-arch/dbus/1.6.18-r0/dbus-1.6.18/dbus/dbus-message.c:2065
6 0x00025398 in parse_supplicant_error (iter=iter@entry=0x0) at
gsupplicant/supplicant.c:3799
7 0x00025430 in interface_add_network_result (error=optimized out, iter=0x0,
user_data=0x175b620) at gsupplicant/supplicant.c:3878
8 0x0002adac in supplicant_dbus_method_call_cancel_all
(caller=caller@entry=0x1739d98) at gsupplicant/dbus.c:445
9 0x00029480 in g_supplicant_interface_cancel
(interface=interface@entry=0x1739d98) at gsupplicant/supplicant.c:3020
10 0x00029898 in g_supplicant_interface_remove (interface=0x1739d98,
callback=callback@entry=0x0, user_data=user_data@entry=0x0) at
gsupplicant/supplicant.c:3487
11 0x00020df0 in wifi_disable (device=0x17306b0) at plugins/wifi.c:1134
12 0x0002f94c in __connman_device_disable (device=0x17306b0) at src/device.c:248
13 0x0005d450 in technology_affect_devices (enable_device=optimized out,
technology=optimized out, technology=optimized out) at src/technology.c:630
14 0x0005d4d8 in technology_disable (technology=0x1738600) at
src/technology.c:780
15 0x0005e634 in set_powered (powered=false, msg=0x1732aa0,
technology=0x1738600) at src/technology.c:802
16 set_property (conn=optimized out, msg=0x1732aa0, data=0x1738600) at
src/technology.c:937
17 0x00077878 in process_message (connection=connection@entry=0x1730440,
message=message@entry=0x1732aa0, iface_user_data=0x1738600,
iface_user_data@entry=0x1, method=0x8610c technology_methods+24,
method=0x8610c technology_methods+24)
at gdbus/object.c:259
18 0x00077cb8 in generic_message (connection=0x1730440,
message=message@entry=0x1732aa0, user_data=user_data@entry=0x173b248) at
gdbus/object.c:1070
19 0xb6e61260 in _dbus_object_tree_dispatch_and_unlock (tree=0x17301f8,
message=message@entry=0x1732aa0, found_object=found_object@entry=0xbec56bbc)
at /work/my-arch/dbus/1.6.18-r0/dbus-1.6.18/dbus/dbus-object-tree.c:862
20 0xb6e51ad0 in dbus_connection_dispatch
(connection=connection@entry=0x1730440) at
/work/my-arch/dbus/1.6.18-r0/dbus-1.6.18/dbus/dbus-connection.c:4672
21 0x00074404 in message_dispatch (data=0x1730440) at gdbus/mainloop.c:72
22 0xb6ebf870 in g_idle_dispatch (source=optimized out, callback=0x743f4
message_dispatch, user_data=optimized out)
at /work/my-arch/glib-2.0/1_2.38.2-r0/glib-2.38.2/glib/gmain.c:5251
23 0xb6ec2bd4 in g_main_dispatch (context=0x172e028) at
/work/my-arch/glib-2.0/1_2.38.2-r0/glib-2.38.2/glib/gmain.c:3066
24 g_main_context_dispatch (context=context@entry=0x172e028) at
/work/my-arch/glib-2.0/1_2.38.2-r0/glib-2.38.2/glib/gmain.c:3642
25 0xb6ec2f60 in g_main_context_iterate (context=0x172e028,
block=block@entry=1, dispatch=dispatch@entry=1, self=optimized out)
at /work/my-arch/glib-2.0/1_2.38.2-r0/glib-2.38.2/glib/gmain.c:3713
26 0xb6ec3430 in g_main_loop_run (loop=0x172e1e8) at
/work/my-arch/glib-2.0/1_2.38.2-r0/glib-2.38.2/glib/gmain.c:3907
27 0x000148f8 in main (argc=496656, argv=0x7cc18) at src/main.c:688
---
gsupplicant/supplicant.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 534944b..8c1db01 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -3796,7 +3796,8 @@ static int parse_supplicant_error(DBusMessageIter *iter)
* invalid message format but this error should be interpreted as
* invalid-key.
*/
- while (dbus_message_iter_get_arg_type(iter) == DBUS_TYPE_STRING) {
+ while (iter
+ dbus_message_iter_get_arg_type(iter) == DBUS_TYPE_STRING) {
dbus_message_iter_get_basic(iter, key);
if (strncmp(key, psk, 3) == 0 ||
strncmp(key, wep_key, 7) == 0 ||
--
1.9.1
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] gsupplicant: Allocate memory for data that is to be used in callback
On Mon, May 19, 2014 at 1:51 PM, Richard Röjfors richard.rojf...@gmail.com wrote: Hi, On Fri, May 16, 2014 at 10:06 AM, Patrik Flykt patrik.fl...@linux.intel.com wrote: When gsupplicant is handed interface data, allocate memory for the supplied strings as the caller might free them at any point. Create a helper function freeing the strings and the structure itself. --- This should fix Richard Röjfors' problems. Thanks, I'll test this and let you know the results. :-) It did fix my problems... or well I didn't get totally cured, but my connman problems are gone ;) --Richard ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] gsupplicant: Allocate memory for data that is to be used in callback
Hi, On Fri, May 16, 2014 at 10:06 AM, Patrik Flykt patrik.fl...@linux.intel.com wrote: When gsupplicant is handed interface data, allocate memory for the supplied strings as the caller might free them at any point. Create a helper function freeing the strings and the structure itself. --- This should fix Richard Röjfors' problems. Thanks, I'll test this and let you know the results. :-) --Richard ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Crash using HEAD
Hi, I started using: 74dbbc974550aac32610e5bf6448e93811e06ff8http://git.kernel.org/cgit/network/connman/connman.git/commit/?id=74dbbc974550aac32610e5bf6448e93811e06ff8 Now I experience this crash 100% of the times when wifi is to be enabled: 00:40:30 connmand[991]: src/technology.c:set_property() property Powered 00:40:30 connmand[991]: src/technology.c:technology_enable() technology 0x203bdc8 enable 00:40:30 connmand[991]: src/device.c:__connman_device_enable() device 0x201a990 00:40:30 connmand[991]: plugins/wifi.c:wifi_enable() device 0x201a990 0x203bd78 00:40:30 connmand[991]: src/technology.c:technology_save() technology 0x203bdc8 type 3 name WiFi 00:40:30 connmand[991]: src/storage.c:storage_load() Loading /media/data/connman/settings 00:40:30 connmand[991]: plugins/wifi.c:interface_create_callback() result -5 ifname (null), wifi 0x203bd78 00:40:33 connmand[991]: src/technology.c:set_property() conn 0x201a450 00:40:33 connmand[991]: src/technology.c:set_property() property Powered 00:40:33 connmand[991]: src/technology.c:technology_enable() technology 0x203bdc8 enable 00:40:34 connmand[991]: src/device.c:device_pending_reset() device 0x201a990 00:40:36 connmand[991]: src/technology.c:set_property() conn 0x201a450 00:40:36 connmand[991]: src/technology.c:set_property() property Powered 00:40:36 connmand[991]: src/technology.c:technology_enable() technology 0x203bdc8 enable 00:40:39 connmand[991]: src/technology.c:set_property() conn 0x201a450 00:40:39 connmand[991]: src/technology.c:set_property() property Powered 00:40:39 connmand[991]: src/technology.c:technology_enable() technology 0x203bdc8 enable 00:40:42 connmand[991]: src/technology.c:set_property() conn 0x201a450 00:40:42 connmand[991]: src/technology.c:set_property() property Powered 00:40:42 connmand[991]: src/technology.c:technology_enable() technology 0x203bdc8 enable 00:40:42 connmand[991]: src/device.c:__connman_device_enable() device 0x201a990 00:40:42 connmand[991]: plugins/wifi.c:wifi_enable() device 0x201a990 0x203bd78 00:40:42 connmand[991]: src/technology.c:technology_save() technology 0x203bdc8 type 3 name WiFi 00:40:42 connmand[991]: src/storage.c:storage_load() Loading /var/data/connman/settings 00:40:42 connmand[991]: Aborting (signal 6) [/usr/sbin/connmand] The settings file contained: [global] OfflineMode=false [WiFi] Enable=true Tethering=false [Wired] Enable=true Tethering=false I removed it, the same thing happened (and the file was recreated with the same content) //Richard ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Crash using HEAD
On Thu, May 15, 2014 at 8:52 AM, Richard Röjfors richard.rojf...@gmail.com wrote: Hi, I started using: 74dbbc974550aac32610e5bf6448e93811e06ff8 Now I experience this crash 100% of the times when wifi is to be enabled: This does not happen on: c84651f6686e67027033d86af03c4d13122dc48c --Richard ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Crash using HEAD
On Thu, May 15, 2014 at 9:12 AM, Michael Trimarchi mich...@amarulasolutions.com wrote: I started using: 74dbbc974550aac32610e5bf6448e93811e06ff8 Now I experience this crash 100% of the times when wifi is to be enabled: This does not happen on: c84651f6686e67027033d86af03c4d13122dc48c Can you try to git bisect? Yeah, its just a few commits in between so it will be fairly quick... but right now I have no access to the target device, so it will happen later today. --Richard ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Crash using HEAD
On Thu, May 15, 2014 at 9:12 AM, Michael Trimarchi mich...@amarulasolutions.com wrote: Hi I started using: 74dbbc974550aac32610e5bf6448e93811e06ff8 Now I experience this crash 100% of the times when wifi is to be enabled: This does not happen on: c84651f6686e67027033d86af03c4d13122dc48c The commit causing the crash is this one, the previous commits work. commit 74dbbc974550aac32610e5bf6448e93811e06ff8 Author: Patrik Flykt patrik.fl...@linux.intel.com Date: Tue May 6 12:41:14 2014 +0300 wifi: Don't fetch interface name from device structure Update the code to use connman_inet_ifname() when fetching the interface name. This prevents the wifi plugin from using a previous interface name should an interface rename event have happened. --Richard ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
The online check and state
Hi, I have looked at the online state and have some questions regarding its purpose. As I see it, this is just an intermediate state shortly after IP configuration is finished. Then if the internet access is lost or gained after that point is not reflected in the state. For instance I see if I reboot my access point, the online check fails, because the access point is not ready to forward data to the internet when the local wifi is available. So the network will never be considered online. I modified the code to retry the check once, the second check succeeds and I'm online. And the same goes if the uplink to the network disappears connman won't detect that and consider still consider the service online. So my conclusion is that the online state is not actually reflecting the real state. So what is the purpose of this check, more than wispr handling? Would it be stupid the schedule the check like every 10 seconds or so to really check the current state? Thanks in advance, Richard ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
