Trouble porting wifi-ap snap to core18 base

snap
1

Following some discussion around base snaps here, I’m trying to make sure all the snaps I’m using are core-18 based. The only outlier here is the official wifi-ap snap, which is based on core.

I figured that just forking that snap and adding base: core18 to snapcraft.yaml would probably be about it, but so far I’ve been proven wildly wrong. Before giving up, I wanted to put my situation out there in case anyone has any suggestions.

What I did to get it (kind of) working

The following are the changes I made with respect to the original wifi-ap (https://code.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/wifi-ap) snapcraft.yaml. My version is at https://github.com/ammpio/ammp-wifi-ap/blob/master/snapcraft.yaml

  • Added base: core18
  • Made sure the original repo (with the right tag for the stable version of the wifi-ap snap) is used for all required code
  • In order to get the service part to build, added a build-snaps: [go/1.9/stable] line - and removed the deprecated go part. Specifying the Go version appeared to be necessary to get the build to go through. Happily, it works and seems to pass all tests
  • Excplicitly added a few libraries under stage-packages, in order to squash “This part is missing libraries that cannot be satisfied with any available stage-packages known to snapcraft:” messages during build
  • I also kept the configure hook in place

The build now works fine on build.snapcraft.io, with an example log under https://launchpad.net/~build.snapcraft.io/+snap/89d6fa2f052b3d8da13a987ad11f7e2b/+build/831415

What’s working and what’s not

After installation of my core18-based snap, ammp-wifi-ap, I observe the following behavior:

  1. If the official wifi-ap snap is also installed, everything in the ammp-wifi-ap snap works normally.
  2. If the official wifi-ap snap is not installed, then the ammp-wifi-ap snap doesn’t work.

Removing or installing wifi-ap reliably toggles between the two states above.

In case #2, the specific thing that’s not working is the $SNAP/bin/service binary (mapped to ammp-wifi-ap.management-service), which is compiled from the Go code. By “does not work” I mean:

  1. The process has no output whatsoever - regardless of whether it’s run as a daemon or if I manually execute the binary from within the snap environment.
  2. It does not create the $SNAP_DATA/sockets/control socket file, which serves as an API endpoint for controlling the access point
  3. Needless to say, the access point itself is not brought up

In an act of desperation I added adapter: full to the daemon definition in snapcraft.yaml, but that doesn’t appear to have made any difference.

The only way to get $SNAP/bin/service to run properly (and create the control socket) is to install the official wifi-ap snap. Note that the wifi-ap services don’t need to be running, but the snap just needs to be installed.

That is obviously very weird behavior, given that the two snaps should exist more or less separately. Any ideas?

Some guesses

I don’t know enough about the snapd universe to tell what’s really going on here (or even to embark on proper diagnostics), but I wonder if this is something to do with libraries. In this regard I did notice two slightly odd things in the build log, though I’m not sure either is the key to the issue here:

  • The following message comes up:
Priming network-utils 
This part is missing libraries that cannot be satisfied with any available stage-packages known to snapcraft:
- libiw.so.30

Even though libiw30 is explicitly listed under stage-packages for that part, and I can see it is installed by snapcraft.

  • When building for armhf I guess the message:
Priming service 
Unable to determine library dependencies for '/build/ammp-wifi-ap/prime/bin/service'

This does not appear for the amd64 build. (both builds exhibit the symptoms above)

snap version is as follows:

snap    2.43.2
snapd   2.43.2
series  16
ubuntu  18.04
kernel  4.15.0-72-generic
2

did you consider just dropping wifi-ap and simply creating a snap that utilizes the network-manager interface instead to set up an AP ? something like below should just work:

nmcli con add type wifi ifname wlan0 mode ap con-name WIFI_AP ssid MY_AP
nmcli con modify WIFI_AP 802-11-wireless-security.key-mgmt wpa-psk
nmcli con modify WIFI_AP 802-11-wireless-security.psk 11223344
nmcli con modify WIFI_AP ipv4.method shared
nmcli con up WIFI_AP
1 Like
3

Are you sure you have connected all interfaces? Those are not automatically connected when sideloading. You can check with snap connections wifi-ap

But, I second @ogra’s suggestion of using NM if enough for your needs. However, make sure that you are following the 1.10 track:

$ snap {install,refresh} --channel=1.10  network-manager

Also, setting up an AP can be a single command :slight_smile::

nmcli d wifi hotspot ifname wlp4s0 ssid <SSID> password "<password>"
2 Likes
4

Yup, the interfaces are connected. Same set as wifi-ap: network-control, network-manager, firewall-control. I didn’t mention it, but if I drop into my snap’s shell environment, I can just run $SNAP/bin/ap.sh and bring up the access point successfully. So the fundamentals are there - it’s just the bin/service binary that’s misbehaving.

I did actually initially intend to just roll my own simple AP snap from scratch, but then discovered Canonical’s wifi-ap and figured I’d go with that rather than reinvent the wheel. So at the moment I’ve sort of bought into it - and have another snap binds to the REST API that the wifi-ap snap provides (for settings and control). Obviously I’d rather not have to also refactor that interface.

I guess a part of me also fears that it’s one of those things that seems trivial in principle, but ends up throwing up problems once you actually try and do it. Like my little core18 porting adventure here :smile:

5

Ok, mystery solved - I think.

The Go code for wifi-ap’s management service binary has a hardcoded path reference to /var/snap/wifi-ap/common. And that code doesn’t do anything (or say anything) until a .setup_done file appears at that hardcoded path. Which…only happens when a snap named wifi-ap is actually installed!

Will patch that code and give it another try.

UPDATE: Yes, that was it. Now working fine.

1 Like