I’ve been having an issue with one of my repeater systems, running Allstar on a Pi. The Pi runs fine and the repeaters run fine for a few days and then, I find the heartbeat LEDs (on two fobs) blinking either slowly or really fast. The repeaters are unusable at this point.
I can still SSH into the Pi - CPU usage, ‘disk’ space availability, memory usage / free space all looks good. If I reboot the Pi, everything resets and is good for another few days and then the same thing. Thinking that this may be a power supply issue, I have tried half a dozen power supplies now (5V, 3A).
In desparation, I did an apt-update / upgrade earlier today… and of course, now Asterisk will not even start (no surprise there ;).
Here are the last few lines when I try to run asterisk from the command line:
[Jan 6 23:14:53] WARNING[1384]: chan_dahdi.c:928 dahdi_open: Unable to open ‘/dev/dahdi/pseudo’: No such file or directory
[Jan 6 23:14:53] ERROR[1384]: chan_dahdi.c:7906 chandup: Unable to dup channel: No such file or directory
rpt:Sorry unable to obtain pseudo channel
== Set device 1-1.1.3:1.0 to usb_27919
[Jan 6 23:14:53] WARNING[1385]: chan_usbradio.c:1760 hidthread: Loaded parameters from usbradio_tune_usb_27919.conf for device usb_27919 .
== Set device 1-1.1.2:1.0 to usb_28762
[Jan 6 23:14:53] WARNING[1385]: chan_usbradio.c:2308 setformat: Unable to re-open DSP device 0 (usb_27919): No such file or directory
[Jan 6 23:14:53] WARNING[1386]: chan_usbradio.c:1760 hidthread: Loaded parameters from usbradio_tune_usb_28762.conf for device usb_28762 .
[Jan 6 23:14:53] WARNING[1386]: chan_usbradio.c:2308 setformat: Unable to re-open DSP device 1 (usb_28762): No such file or directory
[Jan 6 23:14:55] ERROR[1327]: app_rpt.c:22223 rpt_master: Continual RPT thread restarts, killing Asterisk
I do have everything backed up… so I could blow the SD card away and start over - but the Pi image is dated 2018, so thought I’d ask here to see if I can recover from here.
Hi Ramesh!
Long time since we talked toghter. the DVRPTR time!
If you can access the raspberry pi physicaly, I would back up all the /etc/asterisk/ directory first then redo the image and do as stated in the image readme.
Login: repeater
Passsword: allstarlink
SSH port: 22
User repeater has sudo privileges (sudo -s)
There may have been updates to the operating system and AllStarLink since this image was built.
Run the following commands after the first time you boot.
The system that I was having issues with was built a few years ago… I really can’t remember whether I put a hold on the kernel headers from being updated. That said, since I had a backup of my configs and just re-tuned both repeaters (calibrated audio) last week, it was fairly quick for me to flash a new SD card with the ASL image. I was sure to put a hold on the kernel headers from being updated before I did an update!
I will monitor for the next few days to see if the original problem manifests itself again.
Just in case, review your authentication logs and see if you are getting hack attempts. For some reason, I find the PI’s to get weird issues, freezing up, audio issues etc when ssh port is open to the world. Even with a custom port, the hackers get busy doing what they do. I would have to reboot every few days. My fix was to firewall them and only allow my few static IP’s to have access to the ssh port. If I need to access a node when I’m not home or on a static IP, I just VPN to my house (which is on the white list) and get in that way. Webmin is the east way to install the utilities needed to perform this form of mitigation. There is also another one out there that might be helpful call fail to ban. I had trouble setting that up so I’m not the expert with that approach.
Lu
KA4EPS
What Lu says is pretty good advice.
You should be sure to both change your default ssh port to something else and be sure to install fail2ban.
However incomplete working it is for asterisk internet worms, it will serve you well in ssh and other areas.
Once these hacks find a open port that they know what it is, they hammer it well. And there are plenty of scripted hacks out there.
Well folks - even after flashing a new SD card, with the ASL image, applying the updates, installing fail2ban, etc… wham - same thing happened after 2 days - the LED’s on the 2 fobs are flashing super fast and the repeaters are non-responsive.
I can still SSH into the Pi, ‘lsusb’ still shows the 2 fobs. With the Pi still powered, I unplugged one of the fobs and plugged it back in, same thing (LED flashes about 2x the normal rate).
So having tried about 6 power supplies (with the previous SD card), I doubt this is a power supply issue - the only thing left is the Pi itself…???
Hey Ramesh – I emailed you earlier about your node. Based on this and the traffic we’re seeing, I’m going to go with the Pi being faulty. A replacement is likely necessary. Let us know how it goes.
Got your email - that was regarding node 2200. I looked at that - Asterisk was consuming 100% CPU cycles on that box. I restarted asterisk and all seems to be fine - that is a server, no fobs involved.
The issue I am having, as discussed here, is on a Pi (Nodes 27919 and 28762).
I’m going to order another couple of Sandisk Ultra SD cards (I have always used the Sandisk Ultra cards on all of my systems) - will see if I can solve this with another / brand-new card before deciding to try another Pi.