Our snap is private and will only be installed on our devices.
Our device connects to an NVR which uses multicast WS-Discovery, the issue with this is that the host operating system has rp-filters which block all multicast packets from ever reaching user-space. So this snap has to temporarily disable the filter (by doing “echo 0 > /proc/sys/net/ipv4/conf//rp_filter”) so that the packets are not dropped and the device can self-assign an IP address in the correct network, to then re-enable the rp_filter for security (by doing “echo 1 > /proc/sys/net/ipv4/conf//rp_filter”).
Another part of this snap uses VAAPI for hardware-accelerated video compression, we have been having problems to use this functionality in strict mode.
Note: I know it’s better to not name the snaps with “-snap” but this was the name of our project before thinking it would become a snapcraft snap.
Have you tried using the firewall-control interface? It should allow access to /proc/sys/net/ipv4/conf/*/rp_filter. As for self-assigning an IP address, can you accomplish this with network-control or network-setup-control or possibly talking to NetworkManager via the D-Bus interface and using the network-manager interface?
What kind of problems? Do you have specific denials when these problems happen?
Thanks for the quick reply.
Yes, we do network configuration with network-manager and had it working with the interface on strict confinement. I am trying to use now firewall-control but there is now another issue: as we need to self-assign an IP address, we need to do an arp discovery to check if the IP is not taken. The python code socket.socket(socket.AF_PACKET, socket.SOCK_RAW, socket.htons(type)) from the scapy module fails with permission denied. I’ve tried using avahi-control but this does not work.
Regarding this:
I figured out the error was because libva couldn’t find the vaapi drivers, because on priming they are placed in ${SNAP}/usr/lib/x86_64-linux-gnu/dri. Fortunately, this can be worked around by setting LIBVA_DRIVERS_PATH=${SNAP}/usr/lib/x86_64-linux-gnu/dri in the environment.
We also use the gi.repository module in python and had a similar problem with the typelib files, which we solved by setting GI_TYPELIB_PATH=${SNAP}/usr/lib/x86_64-linux-gnu/girepository-1.0. I mention this because it might be useful to other users.
You may also need network-observe or network-control. What are the policy violations at the time of the denial in journalctl? (Note, you may be interested in the snappy-debug snap which will make recommendations for you. Eg: sudo snap install snappy-debug ; snappy-debug).
The error in the logs was an Errno 13 Permission denied (probably to do with the fact that raw sockets need root), fortunately the network-control interface worked. Our snap is now working on strict confinement, and I am pushing to the store now. I will give snappy-debug a try later. I think the information you gave me here would have been impossible to get from docs (which I believe could do with a more comprehensive description). Many thanks for the input 
1 Like
