Hi Tormen, On Tue, Mar 26, 2019 at 08:09:26PM +0100, tormen(a)mail.ch wrote: No worries. I know that feeling. iwd is far easier to use from ConnMan's perspective. The only problem is that I haven't updated the plugin for a while. I see that ConnMan detects the iwd service on D-Bus. But that's about it. There is no interaction. I suppose that is a API issue. The plugin needs to be updated to a recent version of iwd. And the scan feature needs to be added as well. I'll update the plugin if no one else is stepping up. But don't expect me to be done with it in few days :) Thanks, Daniel

Hi, On 3/27/19 6:41 PM, tormen(a)mail.ch wrote: Not sure what you mean with agent in this. We have two WiFi 'drivers', one is wpa_supplicant and the other is iwd. Don't know. But are you sure you are use latest ConnMan? Again don't know. But likely. This is something different. An agent in ConnMan terminology is the a D-Bus client which will be called by ConnMan. It's a kind of RPC. They have their own UI and are using wpa_supplicant from what I know. But you can check this. All open source :) Thanks, Daniel

Hi again, please note the below was tested on an archlinux machine using: aur/connman-git 1.36.r164.gb7ddedc4-1 (+13 0.53%) (Installed) core/wpa_supplicant 2:2.6-2 (914.5 KiB 4.1 MiB) (Installed) Well, it /seems/ that the wpa_supplicant has the same problems than the community/iwd 0.14-1 (333.5 KiB 1.1 MiB) (Installed) I had tested and ran tests before, when starting this thread. Here is what I did: I deactivated and masked iwd.service, I activated and started wpa_supplicant.service. I then set a journalctl cursor --> see journalctl.log --> http://sprunge.us/pXxKPU I then started: CONNMAN_SUPPLICANT_DEBUG=1 connmand -n -d see 2019-03-27_connmand_-n_-d___wit_wpa_supplicant.log --> http://sprunge.us/IoSfR5 And issued a bunch of connmanctl commands, see cli.txt --> http://sprunge.us/hJbZV3 Please let me know if I missed anything or if the above seems correct. And if there is anything I can do to assist further. Thanks again for *any* hint to help me get past this. Tormen -- On Wed, 27 Mar 2019 21:00:20 +0100 <tormen(a)mail.ch&gt; wrote:

Hi, On Thu, 28 Mar 2019 08:35:09 +0100 Daniel Wagner <wagi(a)monom.org&gt; wrote: ... the list was EMPTY :((( really sorry about that!!! As my laptop does not have a wlan hardware switch, I am removing the wlan kernel module to save energy. I was always wondering if this is the best way to achieve that. I think I asked the intel guys once and they had confirmed that this works... but I can't clearly remember anymore... So the wlan-modules where not loaded ;) Funnily the "technologies" command still said: /net/connman/technology/wifi Name = WiFi Type = wifi Powered = True Which is why I did not notice / think about it... because I thought Powered means, well there is a wifi device and it's not rfkilled ... Would be nice if the technologies command could list the number of devices in each category that where found, no ? Anyways: I am REAYLLY sorry!! And promise to try to make sure that this won't happen again (iw list is easy enough to type ;))!! So, here is what I did: * ran a 'my-set wlan-on' (my command to disable / enable wifi) ((really simply handles rfkill + kernel modules you'll see the commands ran below)) * checked with 'ip link', 'iw list': all good * stopped wpa_supplicant, connman.service, connman-vpn.service. * exited cmst * set the journalctl cursor and recordered all of the following. Here is the resulting journalctl.log: http://sprunge.us/QIenau * started the wpa_supplicant.service * ran: CONNMAN_SUPPLICANT_DEBUG=1 connmand -n -d &>/root/connmand_-n_-d___wit_wpa_supplicant.log --> http://sprunge.us/PfwklC * started cmst: Rescan button grayed out * entered connmanctl, ran some commands, added a iw list and rfkill --> http://sprunge.us/vLh7Ve It went further, but did not work! - see the log: wifi scan gave a "no carrier" ? * then I killed the connmand * exited cmst * systemctl restart connman.service * started cmst and /now/ cmst had a "Rescan" button and showed wireless networks * ran my-set wlan-off --> the rescan button grayed out in the still running cmst * ran my-set wlan-on --> the rescan button STAYED grayed out :( * exited cmst * restarted cmst --> the rescan button was STILL grayed out !! :(( * systemctl restart connman.service * started cmst --> the rescan button was not grayed out anymore So it seems to me that connman.service might not handle well the fact that I remove and then add wlan kernel modules?? So I ran one more test to collect the connmand log for you while I unload reload the wifi kernel modules. It turns out that connman needs an extra push (manually) by issuing connmanctl disable wifi, connmanctl enable wifi after reloading the kernel modules, before connmanctl scan wifi works. Even though connmanctl showed in "technologies" that wifi was Powered off (when kernel modules unloaded) and showed it as Powered on after kernel modules were reloaded! Which seems to me to be a bug in connmand. - But see for yourself, here is what I did: * wlan is ON, iw list shows, rfkill: shows unblocked * I kept cmst running (it showed the "Rescan" button + wlan networks) this time to see if he handles well the restart of connmand and it actually did :) * systemctl stop connman.service * systemctl stop wpa_supplicant.service * set a journalctl cursor (as a marker in journalctl) recorded all of the following --> http://sprunge.us/0HWp0j * systemctl start wpa_supplicant.service * CONNMAN_SUPPLICANT_DEBUG=1 connmand -n -d --> http://sprunge.us/jrXoWQ * checked in cmst: it showed still "Rescan" and wlan-networks * issued a bunch of connmanctl commands: --> http://sprunge.us/2OdDqz Ok, I stop here :) Tormen