Auto-connect interfaces on wifi-connect

store
1

Hi wifi-connect [1] snap uses some interfaces that I’d like to be auto-connected. Can snap declaration be created to enable this?

network, network-control, network-bind, network-manager, control

Thanks,
kyleN

2

Any initial feedback on this request from the snapd team?

3

Hello

I believe that out of the given set only network-manager-control needs an assertion. I don’t know who precisely can issue such assertions (this is a store side thing) but I believe that @jdstrand can at least point you the right way (or even make an assertion)

Good luck!

4

Here are the relevant parts of the snap.yaml:

apps:
  daemon:
    command: command-daemon.wrapper
    daemon: simple
    plugs:
    - network-manager
    - control
    - network-bind
  wifi-connect:
    command: command-wifi-connect.wrapper
    plugs:
    - network
    - network-control
    - network-bind
    - network-manager
    - control
...
plugs:
  control:
    content: socket-directory
    default-provider: wifi-ap
    interface: content
    target: $SNAP_COMMON/sockets

Of these, network-manager, network-control and content (ie, ‘control’ to access wifi-ap’s socket directory) could all be made to auto-connect. It seems you are referring to https://dashboard.snapcraft.io/dev/snaps/7327/ in the store, which has the publisher ‘rmescandon’, not you. I’m wondering if this snap should be from the ‘canonical’ publisher, in which case ‘control’ would be auto-connected. If it should continue to be ‘rmescandon’, can @rmescandon comment on why and/or otherwise state the case for auto-connection?

In addition to that, can you give details on why network-control and network-manager are needed? I would’ve expected that wifi-connect would simply use the APIs exposed by wifi-ap’s sockets and have wifi-ap do all the heavy lifting.

5

Thanks for handling this, Jamie. Couple of related points:

Why would having canonical as the publisher auto-connect network-control? It doesn’t sound right that we have interfaces that auto-connect based solely on the publisher and ignoring the snap being evaluated.

Then, as an aside, I think we should accept third-parties proxying for the publisher when requesting auto-connections, as long as they’re able to explain the rationale for the auto-connection. There’s really no downside in this case (unlike, say, aliases).

6

‘control’ in my response was for the content interface that is (confusingly) named ‘control’ in the wifi-connect snap.yaml, not ‘network-control’. I was stating that if from the same publisher (eg, ‘canonical’), then the content interface would be auto-connected.

Perhaps… I hadn’t thought all the way through this but I suspected that wifi-connect actually should be from ‘canonical’ in this particular case (since all the parties involved (the requester, wifi-connect publisher and wifi-ap publisher) are all from Canonical), so wanted to understand what was happening here and guide towards what people actually want.

1 Like
7

Canonical should always have been the publisher on this snap though. I am not sure how to accomplish this: tips?

Regarding the interfaces, network-manager is needed because we are using network-manager dbus extensively: See https://github.com/CanonicalLtd/UCWifiConnect/blob/master/netman/dbus.go

network-control may not be needed. I am checking now and will report back.

8

Regarding the interface, makes sense.

Regarding the publisher, we’re probably aligned about this, but just to be extra clear, the simple fact people work at Canonical isn’t enough to justify having the snap being published by Canonical. Many of us publish snaps because thankfully this is a really convenient mechanism to manage software :slight_smile:, and often we’ll publish snaps even for working purposes that are not actually being properly maintained as a product needs to be. Just like any other company, something that is published in its name implies commitment. We need to make sure that commitment is in place for those cases.

9

Absolutely. wifi-connect is a project of the solutions-engineering team under: Ara/AlexN. We can take this part up offline as needed.

10

Yes, we are certainly aligned on this point. I just had a sneaking suspicion for this particular snap, it should be ‘canonical’ so wanted to check on that. It seems I was right based on Kyle’s comments.

11

We should generally ask for a clear statement of maintenance commitment by the team before this is taken as a company published snap. The fact the snap is part of a team’s duties is not a clear commitment of continued maintenance.

12

So:

  • network-control is not needed: apologies
  • network-manager is needed for netman dbus

It works as expected with:

knitzsche@pi3test:~$ snap interfaces | grep wifi-connect
:network                  wifi-ap,wifi-connect
:network-bind             wifi-ap,wifi-connect
network-manager:service   network-manager:nmcli,wifi-ap:network-manager,wifi-connect:network-manager
wifi-ap:control           wifi-connect
13

Let’s hold off on auto connection via snap declaration.

Current thinking is that pre-installation in image is the target use case, so gadget snap can connect the interfaces.

14

Based on KyleN’s last comment, I’m closing this task.