Disables Wi-Fi just because
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
connman (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
Steps to reproduce:
- Install an unrelated package, such as lxqt
Expected behavior:
- Nothing in particular happens until I choose to launch lxqt
Actual behavior:
- Wi-Fi is suddenly down
- nmcli conn up says “Error: Connection activation failed: No suitable device found for this connection (device wlan0 not available because device is not available).”
- ip link set wlan0 up says “RTNETLINK answers: Operation not possible due to RF-kill”
- rfkill does not say anything because it does not happen to be installed
Apparently the following happened:
- lxqt has an (optional!) dependency on a widget that controls the network, none of which were installed previously, and APT chose cmst (perhaps because it’s the first alphabetically in the list of alternatives)
- as dependency of cmst, connman got installed, started itself, saw a Wi-Fi device, and obviously, when a network management daemon starts on a system already managed by a different daemon, the correct course of action is to assert dominance by rfkilling the Wi-Fi device.
Thankfully, connman’s post-init script took ages to run and it was still visible in the terminal where I ran APT, so I was able to associate the connection loss with it and look up (on a different machine!) the solution of `connmanctl enable wifi`.
Now imagine a user that is unable to make the connection in all senses of the expression, how are they to solve the problem?
Suggested resolution:
- the fight to the death between network managers should happen in some symbolic way without rfkilling spectators.
- packages that can rfkill interfaces should depend on the rfkill package so the user can, upon seeing the RF-kill message, resurrect the interface manually.