search

wb2osz / direwolf

Dire Wolf is a software "soundcard" AX.25 packet modem/TNC and APRS encoder/decoder. It can be used stand-alone to observe APRS traffic, as a tracker, digipeater, APRStt gateway, or Internet Gateway (IGate). For more information, look at the bottom 1/4 of this page and in https://github.com/wb2osz/direwolf/blob/dev/doc/README.md
GNU General Public License v2.0
1.6k stars 306 forks source link

GPIO permission denied, udev racing #341

Open craigerl opened 3 years ago

craigerl commented 3 years ago

I'm "reopening" this bug since it's still observed in direwolf 1.6. In this case it's a Raspberry Pi ZeroW. The additional 250ms wait time is likely insufficient on this cpu. Increase to a full second giving udev a chance to update permissions?

pi@gtown:~ $ tail -f /run/direwolf.log 
Line 8: Invalid port number for IGate server. Using default 14580.
Audio device for both receive and transmit: plughw:0,0  (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
You don't have the necessary permission to access GPIO.
There are three different solutions: 
 1. Run as root. (not recommended)
 2. If operating system has 'gpio' group, add your user id to it.
 3. Configure your user id for sudo without a password.
dranch commented 3 years ago

A Raspberry Pi Zero W has more than enough CPU power to run Direwolf at it's maximum performance and there isn't any need for extended TXDELAY for a Zero that's not not too overloaded (high CPU load). As to your UDEV issue, are you sure the login name that's running the Direwolf process is in the "udev" Unix group and you've logged out and logged back in to get those permissions? I don't believe there is a real issue here so please move your support question to the direwolf@groups.io email list as Github's "issue" tracker is only for bugs and new feature enhancements.

craigerl commented 3 years ago

The pi user is in the gpio group, there isn't a udev group(?). The issue is observed, rarely, immediately after a reboot, with significant cpu load on account of the boot proces and systemd. Ultimately the issues still exists, even if we don't want to call it a bug. I upped the value to 500ms, to see if that helps. I'll also put defensive code around the direwolf command since it's still non-deterministic, though, imho, the fix should be a retry inside direwolf upon gpio permission error. I'll followup with the mailing list, thanks.

dranch commented 3 years ago

Ultimately it's WB2OSZ's call here but I believe your issue is happening at the UDEV level and not Direwolf. If Udev is malfunctioning, no number of Direwolf retries will be helpful here.