Connman and wifi - no connection so far

1st Official Post

    I can not find a way to connect to the wifi network either using WPA supplicant or Connman. I've tried in 3 different ways (see below) none of these worked:

    • with WPA supplicant on /etc/
    • with Connman using various commands targeting /storage/.cache/connman/
    • on the Kodi UI

    WPA supplicant attempts

    When trying to configure the wifi settings via SSH with commands it seems most of the file system is read-only (i.e. I can not write on /etc/).

    These commands:

    Code
    mkdir -p /etc/wpa_supplicant/
wpa_passphrase {{wifi_ssid}} {{wifi_psw}} > /etc/wpa_supplicant/wpa_supplicant.conf

    Give this output:

    Code
    mkdir: can't create directory '/etc/wpa_supplicant/': Read-only file system
can't create /etc/wpa_supplicant/wpa_supplicant.conf: nonexistent directory

    However I am able to enable/restart the SyestemD daemon with:

    Code
    systemctl enable wpa_supplicant
systemctl restart wpa_supplicant
systemctl status wpa_supplicant

    Also: from the Kodi UI I can see a list of wifi networks (although I can not find commonly available commands like wpa_cli or iwlist).

    Connman attempts

    I later realised I had to use Connman. I can see there is a conf file: /storage/.cache/connman/settings

    containing:

    Code
    [WiFi]
Enable=true
Tethering=false
    • I enabled the wifi thing with the command: connmanctl enable wifi.
    • I found the wifi network unique ID with the command: connmanctl scan wifi && connmanctl services. It should be something like: wifi_<some_unique_id>_<some_other_unique_id>_managed_psk
    • I created this settings file at: /storage/.cache/connman/wifi_<some_unique_id>_<some_other_unique_id>_managed_psk/settings with the content:
    Code
    [wifi_<some_unique_id>_<some_other_unique_id>_managed_psk]
Name={{ my_wifi_ssid }}
AutoConnect=true
Type=wifi
Security=wpa2
Passphrase={{ my_wifi_password }}

    where {{ my_wifi_ssid }} is the usual name of the wifi network you would see from anywhere e.g. from your phone.

    • I restarted the SystemD service for Connman with: systemctl restart connman.
    • I checked the status with systemctl status connman and the logs with journalctl -u connman but I did not see anything suspicious like error messages or warnings. The only strange thing I've seen is a message saying wlan0 {newlink} index 3 operstate 5 <DORMANT>, but that’s the network interface and it’s been up and enabled because I can see it from the output of ifconfig. Also I can see it’s enabled from the output of: /storage/.cache/connman/settings.

    Connecting via the UI

    The first time I tried this, when choosing the wifi network on the Kodi menus from the list, after typing the password, I've seen the system trying to connect because there was a label that changed from idle to connect (or connecting don’t remember). After a few seconds I've briefly seen it becoming failed, then going back to idle.

    Checking the logs at /storage/.kodi/temp/kodi.log I've seen the following Connman error message:

    Code
    connman::dbus_error_handler
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken

    The second time I tried this (after a few reboots, the day after) I first enabled some DBUS logs as when searching for the previous error message I found people saying that would have helped to get more information, so I've done this:

    Code
    # dbus-launch
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-QqCdchGh2c,guid=da98deee70458042f51c70ee5de3a89d
DBUS_SESSION_BUS_PID=3139
# export $(dbus-launch)
# dbus-monitor
signal time=1575201002.773722 sender=org.freedesktop.DBus -> destination=:1.0 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
string ":1.0"
signal time=1575201002.773953 sender=org.freedesktop.DBus -> destination=:1.0 serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost
string ":1.0"

    However when later I tried manually from the UI to connect, then I did not see log statements in here (not sure why as I am not familiar with these tools). I could see some extra logs on the Kodi logs, I could see this message:

    Code
    connman::dbus_error_handler 
Already connected

    But when checking the wifi interface with ifconfig I can not see an IP address assigned to it, so it's not "already connected".

    • How can I connect to the wifi?
    • What's the relationship between WPA supplicant and Connman? Do I have to configure both?
    • Is there a way to automate this configuration process via some commands that could be included in a bash script via SSH?
    • Official Post

    Anything under /etc is not writeable in LE (as it's part of a read-only squashfs file) but you don't need to touch wpa_supplicant anyway as this is driven by connman which has an easy to use console configuration tool (connmanctl) which writes the service/settings files. Manual configuration to those files will fail unless connman is stopped as connman will overwrite them at any time.

    Code
    connmanctl
agent on
scan wifi
services
connect wpa_your_network_psk
<enter password>

    ^ if you insist on configuring from the console that sequence of commands will work. connmanctl is also scriptable but configuration from the GUI is also available. I can't explain why you saw an error, but the GUI is the normal and recommneded way to configure network things.

    Thanks for that ^

    I am trying to automate the configuration of the system using Ansible i.e. downloading some zip files for plugins from Github, setting up some aliases on .profile / .bashrc (using bash instead of sh), putting some configuration files e.g. for remote controllers in the right places.

    That's why I am trying to encapsulate the Connman thing in a script that I could automate by providing SSID and password as environment variables for the Ansible script.

    Regarding the Connman / WPA Supplicant relationship: I remember in the beginning the WPA supplicant service was stopped (or maybe disabled), I now see that constantly up (along with the Connman service) via these commands systemctl status wpa_supplicant and systemctl status connman. This happens even after rebooting.

    Is there a way to "reset" LE to the original "factory state" for these services? E.g. the WPA supplicant service should probably be disabled/stopped by default and (I am assuming) being enabled/started by the Connman service (or something like that), but I don't know what was the original state of the system so perhaps there is a command to revert these changes to the original factory state.