On 02/04/15 13:46, Tomasz Bursztyka wrote: > Hi Slava, > >>>> It appears that the client is responsible for removing network >>>> configurations it has created, which makes sense to me. In an >>>> environment with unstable wifi reception, connman may end up creating >>>> hundreds of those in just one day of normal usage. >>> Well this is true if it always fail connecting to hundreds different >>> networks yes (and only at SelectNetwork). >>> That's the only possibility. So indeed there is a bug, but unlikely >>> to happen. >> >> Try this: connect to wifi, walk out of the wifi range, wait for connman >> to realize that, return back into the range, wait for connman to >> re-connect and compare 'wpa_cli list_net' before and after the exercise. >> What do you get? > > Ah, That's another bug then! > If we detect that we got disconnected, the wifi plugins will need to > cleanup. > Actually, it cleanups if the user disconnects, but not this way round. > Check interface_state() in wifi_plugins. This will need a separate patch.
Well, it actually kind of works. When wifi signal is lost, wifi plugin does some sort of cleanup like this: #1 0x0003d8cc in free_network () at src/device.c:378 #2 0x4031b1e8 in g_hash_table_remove_node () at ghash.c:448 #3 0x4031b9d4 in g_hash_table_remove_internal () at ghash.c:1276 #4 0x0003ea20 in connman_device_remove_network () at src/device.c:905 #5 0x000201c4 in network_removed () at plugins/wifi.c:2064 #6 0x0002388c in callback_network_removed () at gsupplicant/supplicant.c:445 #7 remove_network () at gsupplicant/supplicant.c:523 #8 0x4031b1e8 in g_hash_table_remove_node () at ghash.c:448 #9 0x4031b9d4 in g_hash_table_remove_internal () at ghash.c:1276 #10 0x00025e04 in interface_bss_removed () at gsupplicant/supplicant.c:1809 #11 signal_bss_removed () at gsupplicant/supplicant.c:2252 #12 0x0002332c in g_supplicant_filter () at gsupplicant/supplicant.c:2636 #13 0x40481f50 in dbus_connection_dispatch () from /usr/lib/libdbus-1.so.3 #14 0x000833a0 in message_dispatch () at gdbus/mainloop.c:72 #15 0x4032da8c in g_idle_dispatch () at gmain.c:5251 #16 0x40331b20 in g_main_dispatch () at gmain.c:3066 #17 g_main_context_dispatch () at gmain.c:3642 #18 0x40331e24 in g_main_context_iterate () at gmain.c:3713 #19 0x4033248c in g_main_loop_run () at gmain.c:3906 #20 0x00014b9c in main () at src/main.c:761 There are some corner cases that I have been unable to catch so far, which result in connman_service holding a reference to connman_network in connecting/associating state (albeit with driver pointer being NULL) but those are quite rare. That sort of things happens once in a new weeks of normal usage (which involves periodic switching between mobile data and various wifi networks) but once it does happen, connman is unable to recover and needs to be restarted. That's quite annoying for the end-users of the device. But normally things get cleaned up all right, except that wpa_supplicant configuration doesn't get removed, which is the problem that I addressed in this patch. Since I'm not the one who designed this thing, I prefer small fixes that don't affect the overall architecture which at times is pretty hard to grasp. If you are not happy with this approach, you are quite welcome to fix it "the right way". -Slava _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
