Package: connman
Severity: normal
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
I do apologize if this is routed poorly, but I figure I have to start
somewhere.
* What led up to the situation?
I've had an unstable/sid server system working well for decades - its
configuration has overall been pretty stable.
On 2021-02-23, the unattended-upgrades system installed connman (among others)
on my system. connman was never on my system before. I do not know how/why
unattended-upgrades decided to install the package, and I don't even know
who/where to file that bug. (Suggestions welcome... but not your problem)
But it did expose a problem with the connman package: It doesn't appear to
conflict with other interface configuration systems. Having multiple things
changing the network configuration was deeply confusing and hard to debug.
My system would not boot, and there were many network configuration errors. The
package appears to behave quite poorly with ifupdown:
* Classic /etc/network/interfaces.d/ network configurations were being
configured twice:
* Ifupdown was told to give an interface a static IPv4 address (as
* expected)
* wide-dhcpv6-client was able to initially configure IPv6 for the
address, but then couldn't upon fixing the static ipv4 address.
* For whatever reason connman was trying a DHCP, not getting it, and
re-assigned the interface to the 169.254 automatic private ip
addresses.
* Because of the dual-configuration "race", the system was rendered
unbootable and unusable, as the two configuration systems appeared to be
"fighting" each other.
* I couldn't even login locally as root
* often, the system never even reached a login prompt
* It wasn't easy to diagnose the source of why the system wasn't
booting, but I eventually found it.
* What exactly did you do (or not do) that was effective (or
ineffective)?
* I removed connman, clearing the conflict, so there was only one thing
trying to configure my network interfaces.
* What was the outcome of this action?
* After removing connman, the system started behaving
normally/correctly.
* What outcome did you expect instead?
* Ideally, unattended upgrades should not have installed connman. I
don't have the slightest idea who to ask about that situation,
though. If you could point me in the right direction, I'd be
grateful.
* I imagine a "conflict" in the connman package for other incompatible
interface configuration systems would be good in general. Having
multiple interface configuration systems modifying the same
interfaces seems like a guaranteed race condition.
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages connman depends on:
ii dbus 1.12.20-2
ii init-system-helpers 1.60
ii iptables 1.8.7-1
ii libc6 2.31-9
ii libdbus-1-3 1.12.20-2
ii libglib2.0-0 2.66.7-1
ii libgnutls30 3.7.0-7
ii libreadline8 8.1-1
ii libxtables12 1.8.7-1
ii lsb-base 11.1.0
Versions of packages connman recommends:
ii bluez 5.55-3
pn ofono <none>
ii wpasupplicant 2:2.9.0-20
Versions of packages connman suggests:
pn connman-vpn <none>
