Linux install of /etc/udev/rules.d/52-airspyhf.rules maybe could add group and mode

[mahtin]

In order to remove the need to run everything accessing the AirspyHF+ via sudo; I'm wondering if the following is acceptable as a change to the s/w? (If so, I'll PR it). It does work.

The distributed 52-airspyhf.rules file does not specify the group id or mode for the created device file /dev/airspyhf-*. I've added GROUP="dialout", MODE="0660", to the file and now I can use the AirspyHF+ without sudo. My file is as follows:

$ cat /etc/udev/rules.d/52-airspyhf.rules 
ATTR{idVendor}=="03eb", ATTR{idProduct}=="800c", SYMLINK+="airspyhf-%k", GROUP="dialout", MODE="0660", TAG+="uaccess"
$

I picked dialout as the group as I was already a member. I don't know if there's a better choice (maybe gpio or netdev? - neither is great!)

Thoughts. As I said, I'm happy to PR this.

[jketterl]

I'll just chime in here since I just noticed that the udev rules have been reduced to uaccess tagging in this repository. I don't know where this movement started, I think I do understand the idea behind it, but I can tell that it is insufficient to cover all use cases.

From what I can tell, the idea is that the uaccess tag will handle the permissions of the devices "automagically" through ACLs when a user logs in. From what I can tell, this is probably working for SDR applications running in userspace. The problem with the uaccess tagging is that it leaves a big hole for anything that does not run in a systemd user session, for example any application running as a systemd service unit will not be able to access the devices (unless it is run as root, which is probably not a good choice in general).

I have brought this to the attention of the Debian maintainers of the libairspy packages (yes, i know that's a different library, but they introduced the same change a while back and it cause the same issues) and they have now brought back the group assignment for "plugdev" in the most recent version.

See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033121

I don't know if there's another solution to this in the systemd universe. If you know how to solve this differently, please let me know. For me, it seems there has to be at least some "classical" permissions in place for this to work correctly, so I'd recommend combining the best of both worlds, that is: having both a group assignment and uaccess tagging.

[mahtin]

The key takeaway from that reference is:

 * use group plugdev along with uaccess to allow for systemd services

Which makes sense.

Plus, plugdev is a better choice and works well for me.

$ grep plugdev /etc/group
plugdev:x:46:martin
$
$ cat /etc/udev/rules.d/52-airspyhf.rules 
ATTR{idVendor}=="03eb", ATTR{idProduct}=="800c", SYMLINK+="airspyhf-%k", GROUP="plugdev", MODE="0660", TAG+="uaccess"
$

With 0660 mode and group "plugdev" this will be a step forward. Those still running as root (ie. Everyone following the instructions) won't be affected. Those following newer versions of instructions will benefit. (Or their system will benefit - more correctly).

I'll PR it and see how this goes.

[mahtin]

Ok. There's history here. @aeroevan needs to chime in because of this edit. https://github.com/airspy/airspyhf/commit/6d4469d80d4788bae24b8d5cb8558770f868ae2d

A year ago the group and mode was removed and replaced uaccess. Why not both as I'd like to recommend?

[AsciiWolf]

It would be ideal if the udev rules (for both airspy and airspyhf) were submitted into upstream udevd (systemd), just like other devices do. It would prevent similar issues and make airspy work out-of-box on all modern Linux distributions (including containerized environments like Flatpak, Snap or AppImage).

[mahtin]

Yes that would be idea (and I believe needs a different issue opened - along with an advocate to do that work); however, that doesn't detract from this issue and its (present day) need.

[aeroevan]

On fedora there isn't a plugdev group, and removing that reference was needed to get running on my fedora-iot hosts. There probably is a better way to handle cross-distro support though, I'm not really an expert in udev rules and would be willing to test on a fedora install. I probably should have tested on the debian side too, but I don't currently run any debian based systems

[jj1bdx]

The same modification was needed to run libairspyhf on Raspberry Pi OS 64bit. See this comment: https://github.com/jj1bdx/airspy-fmradion/issues/77#issuecomment-2011091931

[jj1bdx]

The same modification was also needed to run libairspyhf on Ubuntu 22.04.4 LTS.

[bigalnz]

+1 on this issue - I just spent an hour trying to workout why airspyhf_info will only run as sudo. Still a little unclear on steps from here? Add my user to plugdev and modify the udev rule?

[vielmetti]

I happened upon this issue when getting OpenWebRX+ to run on my AirSPY HF+. As distributed, the v1.2.61 version udev rules generate this exception:

owrx.source.airspy - ERROR - Exception during postStart()
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/owrx/source/__init__.py", line 427, in start
    self.postStart()
  File "/usr/lib/python3/dist-packages/owrx/source/connector.py", line 62, in postStart
self.controlSocket.connect(("localhost", self.controlPort))
ConnectionRefusedError: [Errno 111] Connection refused

see also discussion at https://groups.io/g/openwebrx/topic/103545886

[touil]

Unrelated to this repos.