Hi Daniel, On 2/4/20, Daniel Wagner <wagi@xxxxxxxxx> wrote: > The 'Invalid Sched_scan parameters' indicates, wpa_supplicant is > providing the wrong parameters. Best thing is to monitor between > wpa_supplicant and kernel the netlink messages. iwmon is an excellent > tool for this. Thanks for the tip, I did not realize that connman is actually heavily relied on wpa_supplicant, if I restarted wpa_supplicant, most of time it popped up mwifiex_sdio messages, then the WiFi could be up: $ systemctl restart wpa_supplicant [ 371.617417] mwifiex_sdio mmc0:0001:1: info: 2 [ 371.647545] mwifiex_sdio mmc0:0001:1: info: associated to bssid 34:08:04:12:y [ 371.726667] IPv6: ADDRCONF(NETDEV_CHANGE): mlan0: link becomes ready [ 371.772758] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x23f error, result=0x2 But sometime when I restated wpa_supplicant, that message did not come, the WiFi network was still down. How is mwifiex_sdio related to wpa_supplicant? Why it is nondeterministic, sometime restart wpa_supplicant could bring mwifiex_sdio and WiFi up, something it couldn't? I think mwifiex_sdio is the lowest layer to interact to WiFi modem, in which circumstance it could bring WiFi modem up and in which circumstance it couldn't? That is far too unstable, I always thought I could rely on connman for WiFi connection stability, but it seems that beyond connman capacity, so what I can do when the WiFi is not up when restart wpa_supplicant could not fix it? Thank you very much Daniel. Kind regards, - jh
