@ogra I have been developing a snap which monitors the firmware runtime health of a particular usb device. If a firmware lockup occurs, we have found that cycling the device power using the built-in hub on our device is enough to bring it out of a hard hang situation. My snap has registered connections to usb-raw and ordinary commands such as “lsusb” which I built as part of our embedded snap are working fine, but “uhubctl” is being held back by the extra kernel write restrictions which are in place for the hub port writes, which either require root access of a higher level than the snap innards are running at (if I call my code using sudo snap-name.method, it works, but I cannot do this for the timer mode this task is running in) or an explicit MODE=“0666” on the specific leg of the udev usb entry for the hub itself.
Is it possible to request some special connection for uhubctl to allow this access? Our particular device was set up by Canonical.
I’m not sure what uhubctl is or does exactly, i have a tool snapped that controls power on usb hubs just fine, i wonder where the differences are between the two tools.
@ogra Thank you for getting back to me. Nice app! However, it requires the same “sudo” to invoke it that uhubctl requires, which I cannot grant to my simple daemon (or can I? is there a way?) or defining the idVendor for the specific hub in udev as writable for my app. It’s easy to forget about the sudo. I overlooked it as I was writing the script for my daemon, then ended up here on the forum after it failed to access the hub because I couldn’t step up the privilege level. Right now, I’m hacking udev in Core, but I’m hoping for a more officially-sanctioned way, because there’s no way to do it inside the snap ecosystem.
