Ah, looking through the debug output from launching connmand in the foreground, I see that it was trying to access /usr/local/var/lib/connman rather than /var/lib/connman. Once I created the /usr/local/var/lib path, then it populated the directory with details about the wifi connection.
Unfortunately even with this change, it still failed to reconnect upon reboot— or at least, it fails most of the time. I get a successful connection probably 1 out of 5 startups (either via reboot or by manually launching the daemon). Is there some way to make connman more persistent in trying to achieve a connection? My perception is that it basically tries once, fails, and then gives up for good. In any case, is /usr/local the default for a source installation? If so, this should definitely be clearly documented, especially when users are encouraged to install connman from source! Mike On 5 September 2014 09:29, Mike Purvis <mpur...@clearpathrobotics.com> wrote: > Hmm. My exact command sequence from startup is: > > $ connmanctl > connmanctl> agent on > Agent registered > connmanctl> enable wifi > Error wifi: Already enabled > connmanctl> scan wifi > Scan completed for wifi > connmanctl> connect wifi_xxxxxxxx_managed_psk > Passphrase? xxxxx > Connected wifi_xxxxxxxx_managed_psk > connmanctl> config wifi_xxxxxxxx_managed_psk --autoconnect yes > connmanctl> > > I now have full internet connectivity, confirmed by ifconfig, iwconfig, > ping, wget. So yes, it does seem to help to run the config command > immediately following the scan. > > However, when I now (in a different terminal) do > > $ ls /var/lib/connman > > I see only wired_xxxxx directories. Note that this is definitely the 1.25 > daemon: > > $ connmand --version > 1.25 > > And I've also confirmed that I'm using the version of connmanctl from the > 1.25 tarball. > > Note that the above behaviour is 100% consistent whether connmand is run > by upstart, or launched in the foreground with > > $ sudo connmand -d -n > > What are the reasons that the /var/lib/connman directory might not get > written? Is there something particular I should look for in the debug > output regarding this? As it is, the debug output is mostly overrun with > NEWROUTE and DELROUTE messages from rtnl.c; seems to be several of them > every few seconds. > > > > > On 5 September 2014 06:07, Patrik Flykt <patrik.fl...@linux.intel.com> > wrote: > >> >> Hi, >> >> On Thu, 2014-09-04 at 17:02 -0400, Mike Purvis wrote: >> > - When I connect to my wifi, it no longer creates a directory for it >> under >> > /var/lib/connman. Did this behaviour change? I'm assuming this is >> related >> > to the not-reconnecting behaviour. >> >> This means it did not get connected. >> >> > - Running "config wifi_xxxxxxxx_managed_psk --autoconnect yes" tells me >> > "invalid service" >> >> The service wifi_xxxxxxxx_managed_psk does not exist as connmanctl >> cannot send a D-Bus method call to it. The cause is that the scan has >> not been done recently enough and the WiFi network has therefore timed >> out (in wpa_supplicant to be exact). >> >> > - connmand is being executed by upstart. The invocation is "connmand >> > --nobacktrace". >> > >> > Is there a way for the daemon to tell me what its config is and where it >> > came from? Would be really helpful for debugging to know if it's using >> the >> > /var/lib/connman directory at all. >> >> No. But if there expected directory is not in /var/lib/connman, it means >> the network is not connected. >> >> 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
