Network-manager broken for desktop Ubuntu

it has in fact been tested on classic systems and non-Dell hardware

You noticed that the reviews on the store are 11 1-star and a few 2 and 3-star, right? And there’s a bunch of comments saying it doesn’t work. Granted, it’s not clear these people tried very hard or used the CLI tool. But it doesn’t seem to be working for most people in the wild? Have you tried?

@abeato when I tried the non-snap deb version 1.10.6, I didn’t see any setting the way I could see a setting for wake-on-lan (ethernet, described at https://wiki.archlinux.org/index.php/Wake-on-LAN#NetworkManager).

I tried the 1.10.6 snap version as suggested and it’s still broken. I didn’t see any dmesg errors in this case, but I couldn’t connect - either to the CLI or the internet. The dmesg logs you see here are from when I was trying the 1.2.2 version, as you can see from the difference in time logs - 13:10 versus 13.20 for active.

@jcrben,

  1. Check that all interfaces are connected with snap connections --all
  2. Try with sudo

Finally, note that this snap was designed and tested essentially for Ubuntu Core. There is actually little reason to use it on desktop in general. Said this, WoWLAN from suspend should work.

Regular applications and services can still be expected to interact with Network Manager over DBus.
I think the network manager snap should be unpublished from the main store and just published to the Dell gateway store. It is not ready for consumption on a desktop system.

This snap is not only used by Dell, but also in many Ubuntu Core systems. The store is not only for Desktop. We cannot, and we shouldn’t, unpublish it.

2 Likes

@abeato it didn’t work with sudo; I’m not sure what I would be be looking for in the snap connections --all; in any case, the internet doesn’t work regardless of nmcli.

Said this, WoWLAN from suspend should work.

Is there any reason it shouldn’t work with the default deb version? There’s no setting that I can set to “magic”. I’ve been using the regular ethernet wake-on-lan without problems, but that has a setting that I can set to magic. Is the only way to set the setting with the snap hook https://docs.ubuntu.com/core/en/stacks/network/network-manager/docs/reference/snap-configuration/wowlan? In which case it would require the snap, which doesn’t work for me. NOTE: I did run iw phy0 wowlan enable magic-packet; iw phy0 wowlan show confirms enabled

It only takes a few minutes to try out the snap - if someone could try it on desktop and it actually worked, I might be more inclined to experiment. I can’t even clone down the git repository to tweak it to classic.

A store which has apps which work only for one of two different platforms with no indication of which platform it works on doesn’t sound too useful - hopefully there’s a feature request logged to show the platform that an app works for. There’s clearly a bunch of frustrated users who have unsuccessfully tried to get the networkmanager snap working on desktop linux, regardless of whether they should. I’m more concerned by the publication of broken apps than I am about this specific feature.

Would it be best to log this as a bug in Launchpad so someone can investigate eventually? I know the backlog is long and there are higher-priority items.

@abeato it didn’t work with sudo; I’m not sure what I would be be looking for in the snap connections --all; in any case, the internet doesn’t work regardless of nmcli.

We’ve tried to explain that this snap was created, tested, and published to the Snap Store for use on Ubuntu Core. Yes, it can be made to work on a Desktop system, but it’s not for the faint of heart. Note this is specifically called out on the installation page for the snap:

The NetworkManager snap is currently available from the Ubuntu Store. It can be installed on any system that supports snaps but is only recommended on Ubuntu Core at the moment.

Is there any reason it shouldn’t work with the default deb version? There’s no setting that I can set to “magic”. I’ve been using the regular ethernet wake-on-lan without problems, but that has a setting that I can set to magic.

It doesn’t work with the default deb version in bionic because that version of NetworkManager was released before the WoWLAN code was written. It’s since been merged into upstream NetworkManager, but is only present in versions 1.14 or greater, which means you’d have to at minimum use the disco release of Ubuntu (ie. 19.04) which provides network-manager 1.16.0-0ubuntu2.

But even if you did that, it’s likely that it still won’t work as WoWLAN is highly dependent on the WiFi driver and physical hardware having been designed to support WoWLAN. Are you absolutely sure both fully support WoWLAN?

My suggestion to you would be to use WoLAN instead and just continue to use the deb from the archive, or update to a newer version of Ubuntu and try to get it WoWLAN working there first.

1 Like

Thank you, that’s quite detailed. When it’s not running off the flash drive the laptop runs NixOS so I’ll try that, but NixOS tends to be finicky on its own. Or I’ll work up another flash drive running some other distro. Most likely there is a hardware/firmware problem with my laptop, but I am willing to experiment.

As I mentioned in my last post, “I’m more concerned by the publication of broken apps than I am about this specific feature”. I appreciate that there’s something warning users on a webpage, but the actual store page itself (which mirrors https://snapcraft.io/network-manager) says nothing about Ubuntu Core and every review of it expresses frustration. I’d rather that my fellow Linux users do not have to experience this frustration, and I’d like to avoid accidentally installing Ubuntu Core apps on the store myself. Do you have any sense of where I should log this issue for eventual resolution? Or should I just post Launchpad bugs in various places that seem reasonable?

@jcrben :

$ sudo systemctl stop NetworkManager
$ snap install --channel=1.10 network-manager
network-manager (1.10/stable) 1.10.6-1-20190619+916e95e2 from Canonical✓ installed
$ systemctl status snap.network-manager.networkmanager.service 
● snap.network-manager.networkmanager.service - Service for snap application network-manager.networkmanager
   Loaded: loaded (/etc/systemd/system/snap.network-manager.networkmanager.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-07-30 10:31:08 CEST; 1min 37s ago
 Main PID: 14799 (NetworkManager)
    Tasks: 4 (limit: 4915)
   CGroup: /system.slice/snap.network-manager.networkmanager.service
           └─14799 /snap/network-manager/412/usr/sbin/NetworkManager --config-dir=/var/snap/network-manager/412/conf.d/ --config=/snap/network-manager/412/etc/NetworkManager/NetworkManager.conf --log-leve
$ snap connections --all 
Interface              Plug                                   Slot                            Notes
...
network-manager        network-manager:nmcli                  -                               -
...
$ snap connect network-manager:nmcli
$ network-manager.nmcli d
DEVICE           TYPE      STATE         CONNECTION         
enx000ec6e241bf  ethernet  connected     Wired connection 1 
lxdbr0           bridge    connected     lxdbr0             
lxcbr0           bridge    connected     lxcbr0             
mpqemubr0        bridge    connected     mpqemubr0          
virbr0           bridge    connected     virbr0             
veth03RMIL       ethernet  connected     veth03RMIL         
wlp3s0           wifi      disconnected  --                 
maasbr0          bridge    unmanaged     --                 
mpqemubr0-dummy  dummy     unmanaged     --                 
lo               loopback  unmanaged     --                 
virbr0-nic       tun       unmanaged     --                 
$ network-manager.nmcli c
NAME                UUID                                  TYPE      DEVICE          
Wired connection 1  ed72f419-a070-3d3c-9683-a3d4f33d327d  ethernet  enx000ec6e241bf 
lxcbr0              d619a208-3d1b-466b-86f4-51725949cbcd  bridge    lxcbr0          
lxdbr0              fc664f1f-3538-4f7c-8d11-56057307f44a  bridge    lxdbr0          
mpqemubr0           ac07f65c-4827-4ab2-8b05-94825705bfda  bridge    mpqemubr0       
veth03RMIL          5d84ee6f-c691-43b9-a182-b0b8742faeaa  ethernet  veth03RMIL      
virbr0              f5ccaead-23ab-4259-aae7-67f4ab7f1dc8  bridge    virbr0          
Wired connection 2  b4a1ff89-2b85-37db-82ba-b651f7d5a275  ethernet  --      

The critical step you were missing was taking a look at the interfaces and connect the nmcli one, that is why I suggested to look at snap connections --all output. Not all interfaces are auto-connected on installation, for security reasons. Said this, it is a bit strange that that interface is auto-connected on UC systems but not on Desktop. @ijohnson maybe you know why could this be happening?

Nonetheless, you will still see apparmor denials that come from subscriptions of gnome-shell to NM’s dBus signals. The integration of the snap on Desktop is not ideal because, as explained, it is not the main target for the snap, but you should be able to use nmcli and configure the connections as desired.

Finally, I recommend that you remove the network-manager snap and then install the one from the 1.10 track. The reason is that the 1.2 snap does not try to manage ethernet by default, see https://docs.ubuntu.com/core/en/stacks/network/network-manager/docs/enable-ethernet-support for details (you need to set the ethernet.enable property).

1 Like

Re: WoWLAN, once you have the snap running, follow https://docs.ubuntu.com/core/en/stacks/network/network-manager/docs/reference/snap-configuration/wowlan to configure it. First thing to check though is the support you have for WoWLAN in your HW/wifi driver:

$ sudo iw phy

and take a look at what you see under WoWLAN support section.

It’s not clear to me why it auto-connects on UC systems but not on classic… maybe @jdstrand or @pedronis can comment, they know more about the snap declaration machinery than I do :slight_smile: (I think they’re both sprinting this week though so it might be a while for a response)

Thank you! I set it up, and confirmed that the wake-on-wlan setting was on and that the interface had it enabled. No wake up. Looks like my Thinkpad T460s hardware isn’t compatible. :slight_smile:

Sorry to circle back around to this, but how about updating that store description to save future users some trouble? Do you know if these are in a repo somewhere where I can make a PR? I’m also asking this in the ubuntu channel on freenode. Eventually made my way to https://bazaar.launchpad.net/~ubuntu-core-dev/app-install-data-ubuntu/ubuntu/view/head:/menu-data/network-manager-gnome:nm-applet.desktop which seems like it might be related.

better try the #snappy channel when trying to change some snap related bits :wink:

(#ubuntu is more focused on enduser support than on development …)

Sorry to circle back around to this, but how about updating that store description to save future users some trouble? Do you know if these are in a repo somewhere where I can make a PR? I’m also asking this in the ubuntu channel on freenode. Eventually made my way to https://bazaar.launchpad.net/~ubuntu-core-dev/app-install-data-ubuntu/ubuntu/view/head:/menu-data/network-manager-gnome:nm-applet.desktop which seems like it might be related.

The store description must be edited from the store dashboard. But nw, I have changed it now.

@abeato and @awe, network-manager has significant policykit functionality but snapd does not have a policykit backend to properly integrate the snap into the system. It is possible that the snap might work if the deb network-manager was disabled and the policykit files remained on disk if the network-manager snap happened to match whatever had been enabled, but it likely won’t work as expected on other distros or when distro network-manager is uninstalled. Does the network-manager snap always require root when installed? Does it fail open and allow everything when the deb/rpm is purged?

Unless the snapped NetworkManager can actually talk to org.freedesktop.PolicyKit1 on the system bus, it doesn’t really matter if the .policy files from the deb packaged version are available. It won’t be able to perform the access checks.

1 Like

The store description must be edited from the store dashboard. But nw, I have changed it now.

I guess it’s in a database then. Over at the snappy channel on freenode, @ogra pointed me to https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/network-manager/tree/snapcraft.yaml for the text but that seems to be not quite right. Thanks for your help!

snaps behave a bit weird in that regard, by default they always use the text from snapcraft.yaml … but once you edited through the web gui you have to keep doing it from there, changes in the file are then ignored.

If you have already edited the description in the store page, for changes in the file to take effect, you need to push the metadata up to the store explicitly with snapcraft push-metadata (separate from the normal snapcraft push)

3 Likes

The snap declaration for the network-manager snap is such that the slot side allows connection to anyone, allows installation if type snap, and denies auto-connection. The plugs side of the snap declaration allows auto-connecting the network-manager interface (ie, nmcli is auto-connected).

Please note that if you are doing an unasserted install (ie, with --dangerous), there is no snap declaration to apply and you’ll get the defaults from the base declaration. If you are seeing something different, please file a bug with precise steps on how to reproduce.

@jdstrand the issue here is that the connection for the network-manager interface from the network-manager:nmcli plug is not auto-connected to the network-manager:service slot in the network-manager snap on classic.

However, on core, the same interface is auto-connected. This sounds like a bug then, no?

After installing the network-manager snap on classic in a multipass VM:

multipass@organic-kudu:~$ snap connections network-manager
Interface              Plug                                   Slot                     Notes
dbus                   network-manager:wpa                    -                        -
firewall-control       network-manager:firewall-control       :firewall-control        -
modem-manager          network-manager:modem-manager          :modem-manager           -
network                network-manager:network                :network                 -
network-manager        -                                      network-manager:service  -
network-manager        network-manager:nmcli                  -                        -
network-setup-observe  network-manager:network-setup-observe  :network-setup-observe   -
ppp                    network-manager:ppp                    :ppp                     -

after installing in a UC16 VM:

multipass@revered-goby:~$ snap connections network-manager
Interface              Plug                                   Slot                     Notes
dbus                   network-manager:wpa                    -                        -
firewall-control       network-manager:firewall-control       :firewall-control        -
modem-manager          network-manager:modem-manager          -                        -
network                network-manager:network                :network                 -
network-manager        network-manager:nmcli                  network-manager:service  -
network-setup-observe  network-manager:network-setup-observe  :network-setup-observe   -
ppp                    network-manager:ppp                    :ppp                     -

The assertion in the bionic classic VM:

type: snap-declaration
format: 2
authority-id: canonical
revision: 25
series: 16
snap-id: RmBXKl6HO6YOC2DE4G2q1JzWImC04EUy
aliases:
  -
    name: nmcli
    target: nmcli
auto-aliases:
  - nmcli
plugs:
  dbus:
    allow-auto-connection:
      -
        plug-attributes:
          name: $SLOT(name)
        slot-attributes:
          name: fi.epitest.hostap.WPASupplicant
      -
        plug-attributes:
          name: $SLOT(name)
        slot-attributes:
          name: fi.w1.wpa_supplicant1
  firewall-control:
    allow-auto-connection: true
  hardware-observe:
    allow-auto-connection: true
  modem-manager:
    allow-auto-connection: true
  network-manager:
    allow-auto-connection: true
  network-setup-control:
    allow-auto-connection: true
  network-setup-observe:
    allow-auto-connection: true
  ppp:
    allow-auto-connection: true
publisher-id: canonical
slots:
  network-manager:
    allow-connection: true
    allow-installation:
      slot-snap-type:
        - app
    deny-auto-connection: true
snap-name: network-manager
timestamp: 2019-07-01T21:47:45.571440Z
sign-key-sha3-384: BWDEoaqyr25nF5SNCvEv2v7QnM9QsfCc0PBMYD_i2NGSQ32EF2d4D0hqUel3m8ul

The assertion in UC16 is the same as the one in bionic classic:

type: snap-declaration
format: 2
authority-id: canonical
revision: 25
series: 16
snap-id: RmBXKl6HO6YOC2DE4G2q1JzWImC04EUy
aliases:
  -
    name: nmcli
    target: nmcli
auto-aliases:
  - nmcli
plugs:
  dbus:
    allow-auto-connection:
      -
        plug-attributes:
          name: $SLOT(name)
        slot-attributes:
          name: fi.epitest.hostap.WPASupplicant
      -
        plug-attributes:
          name: $SLOT(name)
        slot-attributes:
          name: fi.w1.wpa_supplicant1
  firewall-control:
    allow-auto-connection: true
  hardware-observe:
    allow-auto-connection: true
  modem-manager:
    allow-auto-connection: true
  network-manager:
    allow-auto-connection: true
  network-setup-control:
    allow-auto-connection: true
  network-setup-observe:
    allow-auto-connection: true
  ppp:
    allow-auto-connection: true
publisher-id: canonical
slots:
  network-manager:
    allow-connection: true
    allow-installation:
      slot-snap-type:
        - app
    deny-auto-connection: true
snap-name: network-manager
timestamp: 2019-07-01T21:47:45.571440Z
sign-key-sha3-384: BWDEoaqyr25nF5SNCvEv2v7QnM9QsfCc0PBMYD_i2NGSQ32EF2d4D0hqUel3m8ul
1 Like

Yes, it does sound like a bug.