Usage

Reason: Only Wired and Wi-Fi plugins are described. (Discuss in Talk:ConnMan#)

ConnMan comes with the connmanctl command-line interface, see connmanctl(1).
If you do not provide any commands connmanctl starts as an interactive shell.

ConnMan automatically handles wired connections.

Wi-Fi

Enabling and disabling wifi

To check if wifi is enabled you can run connmanctl technologies and check for the line that says Powered: True/False.
To power the wifi on you can run connmanctl enable wifi or if you need to disable it you can run connmanctl disable wifi.
Other ways to enable wifi could include using the Fn keys on the laptop to turn it on or running ip link set <interface> up.

Connecting to an open access point

To scan the network connmanctl accepts simple names called technologies. To scan for nearby Wi-Fi networks:

$ connmanctl scan wifi

To list the available networks found after a scan run (example output):

The agent will then ask you to provide any information the daemon needs to complete the connection. The
information requested will vary depending on the type of network you are connecting to. The agent
will also print additional data about the information it needs as shown in the example below.

Provide the information requested, in this example the passphrase, and then type:

connmanctl> quit

If the information you provided is correct you should now be connected to the protected access point.

Using iwd instead of wpa_supplicant

ConnMan can use iwd to connect to wireless networks. The package which is available in community already supports using iwd for connecting to wireless networks. It is recommended to uninstall wpa_supplicant (see below).

Currently the -i-option of iwd seems to cause that the WiFi-interface gets hidden from connman.

Create the following two service files which should cause that connman uses iwd to connect to wireless networks, regardless if wpa_supplicant is installed (as connman will start wpa_supplicant when it finds it, it's probably still better to uninstall it).

Advantage of using iwd instead of wpa_supplicant is, that the ping times seem to be much more consistent and the connection seems to be more reliable.

Settings

Settings and profiles are automatically created for networks the user connects to often. They contain fields for the passphrase, essid and other information. Profile settings are stored in directories under /var/lib/connman/ by their service name. To view all network profiles run this command from root shell:

# cat /var/lib/connman/*/settings

Note: VPN settings can be found in /var/lib/connman-vpn/.

Technologies

Various hardware interfaces are referred to as Technologies by ConnMan.

To list available technologies run:

$ connmanctl technologies

To get just the types by their name one can use this one liner:

$ connmanctl technologies | awk '/Type/ { print $NF }'

Note: The field Type = tech_name provides the technology type used with connmanctl commands

To interact with them one must refer to the technology by type. Technologies can be toggled on/off with:

$ connmanctl enable technology_type

and:

$ connmanctl disable technology_type

For example to toggle off wifi:

$ connmanctl disable wifi

Warning: connman grabs rfkill events. It is most likely impossible to use rfkill or bluetoothctl to (un)block devices, yet hardware keys may still work.[2] Always use connmanctl enable|disable

Tips and tricks

Avoid changing the hostname

By default, ConnMan changes the transient hostname (see hostnamectl(1)) on a per network basis. This can create problems with X authority: If ConnMan changes your hostname to something else than the one used to generate the xauth magic cookie, then it will become impossible to create new windows. Symptoms are error messages like "No protocol specified" and "Can't open display: :0.0". Manually resetting the host name fixes this, but a permanent solution is to prevent ConnMan from changing your host name in the first place. This can be accomplished by adding the following to /etc/connman/main.conf:

For testing purposes it is recommended to watch the journal and plug the network cable a few times to see the action.

Prefer ethernet to wireless

By default ConnMan does not prefer ethernet over wireless, which can lead to it deciding to stick with a slow wireless network even when ethernet is available. You can tell connman to prefer ethernet adding the following to /etc/connman/main.conf:

[General]
PreferredTechnologies=ethernet,wifi

Exclusive connection

ConnMan allows you to be connected to both ethernet and wireless at the same time. This can be useful as it allows programs that established a connection over wifi to stay connected even after you connect to ethernet. But some people prefer to have only a single unambiguous connection active at a time. That behavior can be activated by adding the following to /etc/connman/main.conf:

[General]
SingleConnectedTechnology=true

Connecting to eduroam (802.1X)

WPA2 Enterprise networks such as eduroam require a separate configuration file before connecting to the network. For example, create /var/lib/connman/eduroam.config:

Avoiding conflicts with local DNS server

If you are running a local DNS server, it will likely have problems binding to port 53 (TCP and/or UDP) after installing Connman. This is because Connman includes its own DNS proxy which also tries to bind to those ports. If you see log messages from BIND or dnsmasq like

"named[529]: could not listen on UDP socket: address in use"

this could be the problem. To verify which application is listening on the ports, you can execute ss -tulpn as root.

To fix this connmand can be started with the options -r or --nodnsproxy by overriding the systemd service file. Create the folder /etc/systemd/system/connman.service.d/ and add the file disable_dns_proxy.conf:

/etc/systemd/system/connman.service.d/disable_dns_proxy.conf

[Service]
ExecStart=
ExecStart=/usr/bin/connmand -n --nodnsproxy

Make sure to reload the systemd daemon and restart the connman.service, and your DNS proxy, after adding this file.

Blacklist interfaces

If something like Docker is creating virtual interfaces Connman may attempt to connect to one of these instead of your physical adapter if the connection drops. A simple way of avoiding this is to blacklist the interfaces you do not want to use. Connman will by default blacklist interfaces starting with vmnet, vboxnet, virbr and ifb, so those need to be included in the new blacklist as well.

Blacklisting interface names is also useful to avoid a race condition where connman may access eth# or wlan# before systemd/udev can change it to use a Predictable Network Interface Names like enp4s0. Blacklisting the conventional (and unpredictable) interface prefixes makes connman wait until they are renamed.

Once connman.service has been restarted this will also hide all the veth####### interfaces from GUI tools like Econnman.

Troubleshooting

Error /net/connman/technology/wifi: Not supported

Currently, connman doesn't support scanning for WiFi networks with iwd, at the moment this functionality is available with wpa_supplicant only (see [4]). In order to have Wifi Scanning support from within connman, install wpa_supplicant and then restartconnman.service after you stop iwd.service.

Error /net/connman/technology/wifi: No carrier

You have enabled your wifi with:

$ connmanctl enable wifi

If wireless scanning leads to above error, this may be due to an unresolved bug.[5]
If it does not resolve even though wireless preconditions are met, try again after disabling competing network managers and rebooting.

This may also simply be caused by the wireless interface being blocked by rfkill, which can occur after restarting wpa_supplicant. Use rfkill list to check.

It likely is Connman performing a connectivity check to the ipv4.connman.net host (which resolves to the IP address 82.165.8.211 at current).[6] See the Connman README for more information on why and what - apart from the connecting IP - it transmits.
This behaviour can be prevented by adding the following to /etc/connman/main.conf:

[General]
EnableOnlineCheck=false

This setting will cause that the default device will not switch to ONLINE, but stay in READY state.[7] However, the connection will still be functional.

The connection itself is also functional (unless behind a captive portal) if the check is blocked by a firewall rule: