NM fails with 'config-failed' despite successful MM connection

[Bjørn Mork]

Dan Williams <dcbw at redhat.com> writes:

> Any idea what suspend/resume support your NM is built with?

debian/rules has this:

override_dh_auto_configure:
        dh_auto_configure -- \
                --libexecdir=/usr/lib/NetworkManager \
                --with-pppd-plugin-dir=$(PPPD_PLUGIN_DIR) \
                --with-pppd=/usr/sbin/pppd \
                --with-resolvconf=/sbin/resolvconf \
                --with-dhclient=/sbin/dhclient \
                --with-iptables=/sbin/iptables \
                --with-dnsmasq=/usr/sbin/dnsmasq \
                --with-dnssec-trigger=/usr/lib/dnssec-trigger/dnssec-trigger-script \
                --with-systemdsystemunitdir=/lib/systemd/system \
                --with-udev-dir=/lib/udev \
                --with-crypto=gnutls \
                --with-session-tracking=systemd \
                --with-suspend-resume=systemd \
                --with-modem-manager-1 \
                --with-nmtui \
                --with-nmcli \
                --disable-more-warnings \
                --disable-modify-system \
                --enable-polkit \
                --enable-polkit-agent \
                --enable-ppp \
                --enable-ifupdown \
                --enable-config-plugin-ibft \
                --enable-introspection \
                --enable-gtk-doc \
                --enable-concheck \
                --enable-teamdctl \
                --enable-bluez5-dun \
                --with-selinux=yes \
                --with-libaudit=yes

so I guess the answer is 'systemd'.

And I am actually running systemd on this laptop, even if I am old and
grumpy enough to whine about how it changes everything I'm familiar
with.

> Do you see NM log lines about "suspending" and "waking up"?

"journalctl --unit=NetworkManager|egrep -i 'suspend|resume'" got me this:

Jan 05 20:46:05 miraculix NetworkManager[8315]: <info>  [1483645565.8375] manager: logging: level 'TRACE' domains 'PLATFORM,RFKILL,ETHER,WIFI,BT,MB,DHCP4,DHCP6,PPP,IP4,IP6,AUTOIP4,DNS,VPN,SHARING,SUPPLICANT,AGENTS,SETTINGS,SUSPEND,CORE,DEVICE,OLPC,INFINIBAND,FIREWALL,ADSL,BOND,VLAN,BRIDGE,TEAM,CONCHECK,DCB,DISPATCH,AUDIT,SYSTEMD'
Jan 05 20:46:22 miraculix NetworkManager[8315]: <debug> [1483645582.2054] sleep-monitor-sd: received RESUME signal
Jan 05 20:57:31 miraculix NetworkManager[8315]: <debug> [1483646251.1373] sleep-monitor-sd: received RESUME signal
Jan 05 22:03:36 miraculix NetworkManager[8315]: <debug> [1483650216.0202] sleep-monitor-sd: received RESUME signal


Nothing mentioned about any suspend.  But they have happened, as you can
deduce from the RESUMEs.  Similarily, I can only see udev 'add' events
and no 'remove' event:

Jan 05 20:46:22 miraculix NetworkManager[8315]: <debug> [1483645582.1992] udev rfkill event: action 'remove' device 'rfkill23'
Jan 05 20:46:23 miraculix NetworkManager[8315]: <debug> [1483645583.0331] udev rfkill event: action 'add' device 'rfkill24'
Jan 05 20:57:31 miraculix NetworkManager[8315]: <debug> [1483646251.1312] udev rfkill event: action 'remove' device 'rfkill24'
Jan 05 20:57:31 miraculix NetworkManager[8315]: <debug> [1483646251.9189] udev rfkill event: action 'add' device 'rfkill25'
Jan 05 20:57:40 miraculix NetworkManager[8315]: <debug> [1483646260.9599] platform-linux: UDEV event: action 'add' subsys 'net' device 'wwan0' (39); seqnum=4314
Jan 05 20:57:40 miraculix NetworkManager[8315]: <trace> [1483646260.9599] platform-linux: udev-add[wwan0,39]: device added
Jan 05 22:03:36 miraculix NetworkManager[8315]: <debug> [1483650216.0069] udev rfkill event: action 'remove' device 'rfkill25'
Jan 05 22:03:36 miraculix NetworkManager[8315]: <debug> [1483650216.7912] udev rfkill event: action 'add' device 'rfkill26'
Jan 05 22:03:44 miraculix NetworkManager[8315]: <debug> [1483650224.9700] platform-linux: UDEV event: action 'add' subsys 'net' device 'wwan0' (40); seqnum=4412
Jan 05 22:03:44 miraculix NetworkManager[8315]: <trace> [1483650224.9701] platform-linux: udev-add[wwan0,40]: device added


Is this the reason it fails?  A cached entry is not expired because we
miss the udev 'remove' event and/or suspend?


Bjørn