Talk:ConnMan
Resume connection after suspend
On my laptop (Thinkpad X61) connman doesn't restore the wifi connection after resuming from suspend. To have it working again I have to un/set the physical wifi switch. I've found a workaround, but it's crude and the issue may be hardware-related (though wicd works just fine, maybe because it has resume scripts) so I'm leaving it here for review.
/etc/systemd/system/connman-resume.service
[Unit] Description=Connman resume actions After=suspend.target [Service] Type=simple ExecStart=/usr/bin/systemctl restart connman.service ExecStart=/usr/bin/sh -c 'sleep 1; /usr/bin/rfkill unblock 0 1' [Install] WantedBy=suspend.target
# systemctl enable connman-resume
edit: There's a setting in connman.conf
, PersistentTetheringMode
, but it doesn't seem to work. I'll bring this up to the connman mailing list. -- Alad (talk) 18:23, 3 February 2015 (UTC)
-- Alad (talk) 09:42, 12 January 2015 (UTC)
Much of this wiki really old
I just struggled to get this working properly on my laptops and RPIs and there are a couple of details which are important and are not in this wiki.
- the 'using iwd' portion of the wiki is way out of date. No longer required to use the
--wifi=iwd_agent
. IMO best is to disable wpa_supplicant withsystemctl disable wpa_supplicant
if you cannot uninstall it (i.e if you don't want to or cannot uninstall NetworkManager). If you can uninstall it, it is best to do so. In most cases the default iwd and connman services are fine, IMO.
# If you want connman to reconnect when the SSID drops and reappears, you must add a line to the /etc/connman/main.conf: This is wrong according to the connman list, this setting is only for wpa_supplicant and not for iwd. They are working on rescan.
BackgroundScanning = true
. If this is not added, connman will never tell iwd to re-scan to see if/when the SSID returns and will, therefore, never reconnect.
- the Arch package has no tmpfile, for some reason so the connman cannot create /run/connman/resolv.conf. One option is to add a line to the connman.service file:
ExecStartPre=/bin/mkdir -p /run/connman
, but this is frowned upon in the systemd group and the 'right way', apparently, is to add a file /etc/tmpfiles.d/connman_resolvconf.conf which has the contents:
d /run/connman - - - - L /etc/resolv.conf - - - - /run/connman/resolv.conf
this way connman can create its resolv.conf and not complain in the journal that the folder does not exist and can nod do DNS lookups.
- As someone who has repeatedly tried to use connman together with iwd using the this wiki page and has failed again and again, I think that the information is indeed outdated. I would appreciate if someone with more knowledge took the time write a working
iwd
section. Wlhlm (talk) 17:26, 3 November 2020 (UTC)
DNS and ntp information
There is information on setting up custom DNS for NetworkManager and I think the same could be provided for connman. Also, connman is menioned in System_time#Time_synchronization section. So, a section for configuring ntp servers for connman would also be nice. --RaZorr (talk) 10:00, 17 January 2022 (UTC)
connman + iwd as backend
It seems that the simplest way to use iwd
as the backend (instead of wpa_supplicant
) is to follow this procedure:
- Uninstall
wpa_supplicant
- If you cannot uninstall
wpa_supplicant
, stop, disable and/or optionally mask itsystemctl mask [unit name]
- Make sure
iwd
is installed. Do not enable theiwd.service
unit.
Add iwd.service
as a requirement to the default connman.service
unit file with a drop-in snippet:
systemctl edit connman.service
Insert the following as the snippet:
[Unit] Requires=iwd.service
reload and restart connman.service
.
That is ALL that is required. This is the simplest method which allows you to keep updating connman and its service unit file (whenever it changes upstream) AND provide a stable connection + re-connection after suspending/hibernating.
Method 2.1.4 in the main page does not create a smooth re-connection after suspending/hibernating.
Original idea from here. (Although the method described in that page no longer works verbatim.)
Stef 204 (talk) 00:19, 14 May 2024 (UTC)