To make the review of your request easier, please use the following template to provide all the required details and also include any other information that may be relevant.
name: foxflss
description: This snap packages the FoxFlss tools for modem management. Normally it’s used for DELL DW5932e and DW5934e
snapcraft: contents as below since there is no public URL
name: foxflss
base: core22
version: ‘1.0.16’
summary: Foxconn unlock and write RF files dynamically
description: |
This snap packages the FoxFlss tools for modem management.
This project was designed for Dell customized Ubuntu OS(22.04 and 24.04). And this customization was handled by Canonical (some one like Kai-Chuan Hsieh )
ModemManager requires a FCC unlock script for WWAN device.
The supported path shall be /usr/lib/systemd/system/ModemManager.service.d/ or /etc/systemd/system/ModemManager.service.d. Currently the snap secure path can’t be detected by ModemManager.
To avoid intermediary releases（Foxconn->Canonical->Dell end user） during a release launches, we need to connect directly with end users (Foxconn->Dell end user). Once we have a support in snap store, end user could do a update directly.”
I understand that strict confinement is generally preferred over classic.
I’ve tried the existing interfaces to make the snap to work under strict confinement.
Can you tell us how this app is exactly used as a debug tool like i.e. valgrind, gdb or strace (who are allowed as classic to be able to operate against other running applications for debugging and tracking purposes)
Looking at the GitHub website it seems the only reason for you to ask for classic confinement is to be able to write to one of the ModemManager service.d directories, that can be easily achieved through a system-files interface entry without the need to run the app under classic. Did you try this route before asking for classic? Did you hit any obstacles that you could not overcome with this approach that we could perhaps help you with?
EDIT: also note that classically confined snaps can not be installed on UbuntuCore systems which is the typical OS used on IoT and industrial devices/gateways.
Given that WWAN modems are a very common type of hardware in such environments you would block your application to be usable in these setups.
Thanks for your prompt response to this request.
Actually this tool will write the RF files dynamically according to different platform. This progress may be considered as a debug tool(This is just my personal opinion, and it may be wrong). If there are more suitable categories here, please let me know.
Yes, your analysis is correct. We did attempt to create a snap package following the standard procedure, but we ultimately got stuck on the requirement to place files in the ModemManager service.d system directory. Additionally, our experience with snaps is quite limited, which has made us unfamiliar with some of the rules and restrictions involved in snap package creation. We really appreciate your suggestion, and we haven’t tried that approach yet. We will start working on a new plan based on your advice. Thank you very much!
Thanks for the response and for confirming @ogra ‘s read of the situation. Before commenting I looked at the fii_linux repository and at the modemmanager packages currently in 22.04 and 24.04. so let me lay it out, what I found
First, on the classic request itself: -1. The debug tools category covers tools which need to operate on other running processes, which this is not and your actual requirement (placing files in system directories) is a file access question that classic confinement is explicitly not granted for.
Now the technical findings. Your install-data-hook places three distinct things on the system.
FCC unlock scripts for 105b:e0f5, 105b:e0f9 and 105b:e11d. I checked the modemmanager binaries shipped in Ubuntu: both 1.20.0 (22.04) and 1.23.4 (24.04) have exactly two compiled-in search paths for unlock scripts, /etc/ModemManager/fcc-unlock.d and /usr/lib/x86_64-linux-gnu/ModemManager/fcc-unlock.d and there is no configuration option to extend that list. Your Makefile installs the DW593Xe script and its vid:pid symlinks under /opt/foxconn/fcc-unlock.d, which stock ModemManager will never look at. So even with a system-files grant, installing to the paths in your current layout would not make ModemManager pick the script up. Separately, both Ubuntu releases already ship Foxconn unlock scripts in /usr/share/ModemManager/fcc-unlock.available.d for 105b:e0ab and 105b:e0c3 but not for your three new device IDs, so there is a real enablement gap for the DW5932e and DW5934e. The sustainable fix for that gap is not a snap. I would recommend you to please submit it upstream to ModemManager’s fcc-unlock.available.d and work with your Canonical contact on landing it in the Ubuntu package. That fixes it for every Ubuntu user permanently, survives ModemManager updates and needs no store grant at all.
The ModemManager.service.d drop-in. I have to be direct about this one. Your mm-suspend-resume-options.conf clears ExecStart and replaces it with /opt/foxconn/suspend/mm-options.sh, a wrapper that re-derives ModemManager’s command line from its unit file and appends --test-quick-suspend-resume or --test-low-power-suspend-resume depending on the installed version. Replacing the ExecStart of a root system daemon with a vendor script is not something the store can grant to a snap under any confinement model, classic or strict with system-files. It is also fragile since it re-parses the unit file on every start and relies on ModemManager test options. Suspend and resume tuning for specific Dell platforms is an OEM image customization and should go through the enablement channel for these platforms.
The RF SSKU provisioning itself (FoxFlss -f Check_RF_SSKU as a oneshot after ModemManager). This is the one piece that looks genuinely snap shaped. Your own FoxFlss.service declares CAP_NET_ADMIN and RestrictAddressFamilies including AF_QIPCRTR, meaning the binary talks to the modem directly over Qualcomm IPC Router rather than through ModemManager’s D-Bus API. snapd has a qualcomm-ipc-router interface for that socket family, so a strictly confined snap daemon plugging it (plus network-control and hardware-observe if you need netlink and device enumeration) is the route I would suggest prototyping..
Also the repository ships bin/FoxFlss as a prebuilt binary committed to git rather than built from source and it runs as root against WWAN hardware. Proprietary snaps are permitted in the store, but for privileged hardware enablement from a new publisher account, publisher vetting will be a prerequisite for any grant and it would help a lot to have Canonical contact confirm the Foxconn and Dell relationship on this thread. Also, as @ogra noted, classic snaps cannot be installed on Ubuntu Core, so if any target deployment is Core based the strict route is the only one that works there anyway.
Feel free to correct me if I am missing something or my understanding is not correct. Thanks
Thank you for your analysis from your perspective or that of the Snap community.
Based on your analysis, there are indeed several issues and limitations with my tool stored on Snap. I will continue to stay in touch with DELL and Canonical to keep updated on the latest developments.
Regarding the FCC unlock issue you mentioned, this feature is currently activated. The script links the vendor’s unlock script to the legitimate path of ModemManager using the command “sudo ln -sft /usr/lib/x86_64-linux-gnu/ModemManager/fcc-unlock.d/ /opt/foxconn/fcc-unlock.d/*” so that ModemManager can call the script for unlocking. As for why the FCC unlock algorithm cannot be open-sourced, this relates to legal compliance and DELL’s requirements (currently, all open-source unlock algorithms are hacks and not voluntarily submitted by WWAN vendors).
Regarding the suspend-resume optimization measures you mentioned, they are currently implemented through OEM image customization. I did overlook the impact of this package on ModemManager. I assumed that those installing the foxflss snap would be DELL computer users, and that the outcome of installing the snap package would be consistent with the results of using the OEM customized image.
Assuming the above issues are excluded, is it possible to configure the snap package to be bundled and associated only within the OEM customized image (typically for updates), while general Ubuntu users would not download or be able to access this package?
Thanks, this clarifies the remaining questions and I think it also settles the request.
On the symlink: understood, that explains how the /opt layout functions on your current installs. It is worth spelling out what the equivalent would mean for a snap though. A strictly confined snap would need a system-files write grant on /usr/lib/x86_64-linux-gnu/ModemManager/fcc-unlock.d to create that symlink and the link would point at a script inside the snap that ModemManager then executes as root, outside any confinement, with the target changing on every snap revision. That is a root code execution grant into the host in all but name and it is not something we would approve for a general store snap, especially one shipping a prebuilt proprietary binary.
You mentioned the suspend-resume tuning is already delivered through OEM image customization. That means the snap as proposed would also be competing with the OEM image for ownership of the same ModemManager drop-in, which is a further reason not to ship it this way.
On restricting a store snap to OEM image users only: the global Snap Store has no mechanism for that. The mechanism that matches what you describe is a dedicated store, which is a commercial arrangement with Canonical rather than something the review team can set up here. But note that once the goal is “only Dell OEM machines receive this component, with updates”, you have described the Dell OEM archive you are already using for the suspend-resume piece. If the concern driving this request is update latency through the Foxconn to Canonical to Dell pipeline, I would raise that directly with your Canonical OEM contact, because changing the distribution channel does not remove the need for the vetting and review that pipeline provides, it only removes the review.
As this request is no longer needed, will remove it from reviewers’ queue. Feel free to ask any further questions you have on the same thread.
