- App_rpt-users - lists.keekles.org

AllStarLink apt-get install
by Steve Zingman 18 Nov '17

18 Nov '17

Since the introduction of DIAL, we have had a number of requests for a better method of installing and upgrading AllStarLink. The D in DIAL stands for Debian. The Intel/AMD versions of DIAL are built on a slightly modified version of the NetInstaller from Debian. The Raspberry Pi version of DIAL is built on a modified version of Raspbian which is a modified version of Debian. The Intel/AMD installer builds ASL from the GitHub repository. The Raspbian image uses pre-compiled ASL programs and scripts. A number of people have also wanted to build ASL on their own install install of Debian or a derivative. I have tried to provide install scripts to accommodate this also. None of these are "easy" to upgrade and maintain. One of the biggest stumbling blocks to installing ASL is the requirement for DAHDI. DAHDI is a set of kernel modules that HAS to be built for the running kernel. Every time a user upgraded the kernel, the user had to rebuild DAHDI. To say that is a pain is a understatement. A few months ago I started using a system call Dynamic Kernel Module Support (DKMS). One of the features of DKMS is the ability to install the needed support programs and source to build the needed kernel modules. In simple terms Debian calls on DKMS to rebuild DAHDI. The big advantage to this is when the kernel is upgraded, DKMS tries to rebuild DAHDI. DHADI does not change very often, but it does require some maintenance. DKMS has helped to allow users to upgrade their host OS and continue to run ASL. The other parts of ASL are or should be more fluid. They should be changing as new bugs are found and new features are added. Under the current system, this sometimes requires downloading and building asterisk from the GitHub repository. Not really that hard to do, but it is time consuming and error prone. I don't expect users to be Linux software experts, though some basic understanding of the OS they use to run their repeaters and remote bases would be nice. Due to this complexity, I have held off putting out a update to DIAL. There have been some changes in the installers and some minor tweaks, but nothing of consequence. This will now start to change. Over the year since we have put the ASL source on GitHub, people have contributed changes. These changes have been or will be staged and tested. At some point they will be ready to be included in ASL. We need a mechanism to easily put these changes to use. I do not want to require a user to have to download an new image just to get fixes, upgrades and enhancements. It can be done, but should be limited and rare. I have taken the GitHub main branch(s) and built a Debian repository. What this means is the method to install ASL or upgrade ASL will change. Though the ARM and Intel/AMD images will be available, they will be built using the repository rather then static programs. This also open up the possibility of support for other Debian based distribution. For ARM this means support for Armbian <https://www.armbian.com> Armbian is a very well done distribution supporting a number of ARM based single board computers. Many more boards to choose from! The next release of the images will use the repository. This will take some time. In the long run for images I will follow Debian. With each new revision of Debian I will release a new image. As of today, we are built on Debian 8. The next install image will be built on Debian 9 (Stretch) As we progress, the repository will also contain programs to enhance ASL. Rather then searching for and having how to figure out how to install the program it will become as simple as apt-get install Analog_Bridge. I will work with the developers to include their programs in the repository. OK, so 4 paragraphs to get to the good stuff. How do I use the repositories? How do I upgrade my OS and ASL? Why is the sky blue? (Just waned to make sure you were still awake) For the adventurous among us here we go. In Debian it is quite easy to add a repository. I have built a simple script to add the repository for you. You will start with a off the shelf image, in this example from Raspbian. Intel/AMD users should get the idea. Remember this is a test. Most things will stay the same, some will change as issues are found. You can use either Jessie or Stretch image as a starting point. A couple of warnings are in order. These are stock images. There is NO protection from someone hacking into your machine if you expose it before at least changing to default password. A stock Raspbian image will not even allow you to use SSH to login the machine without 1 change. You must add a file to /boot. The file can be empty but must be named "ssh" I have take a stock Raspbian Jessie image and added the file. That is the ONLY change I have made to the image. It is available for download from <http://dvswitch.org/files/AllStarLink/2017-06-21-raspbian-jessie-lite.tar.gz> Extract the image and burn it to a SD card. The login is pi and the password is raspberry. DO NOT DO THIS ON TOP OF YOUR EXISTING DIAL INSTALL !!!!!!!!!!!!!!!!!!!!!!!! You will need to do a few things to you fresh image to prepare for ASL install. sudo -s so you are root Use raspi-config to change the login password Use the advanced menu from raspi-config to expand the file system to use your whole SD card. On exit from raspi-config you will be asked to reboot After the reboot, log back in and become root. If you are installing on a fresh Intel/AMD or some other Debian derivative, start here. apt-get update apt-get upgrade -y At this point this is nothing but a ready to run Raspbian Jessie machine. cd /tmp wget https://github.com/AllStarLink/DIAL/raw/master/repository/install-repository chmod +x install-repository ./install-repository The ONLY thing the script does is add the new AllStarLink repository. To install ASL: apt-get install allstarlink When the install completes (yes it does take a while since DAHDI still has to be compiled) reboot. You should have a fresh install of ASL ready for you to edit the config files. Over the next few weeks, my time will be somewhat limited. When I have a update ready I'll post on the list. You will then be able to run apt-get upgrade and the changes will be applied to your test machine. Upgrade will NOT overwrite your config files. If you want to test this on a fresh install of Intel/AMD or the Raspbian Stretch, go for it. I have done some quick tests on Raspbian Stretch and it does work. Needs at least one bug fix and a LOT more testing. Last but not least is the support programs that are used to help you configure the node and OS. The existing scripts are a MESS. I have a completely new set of programs I'll be working on and roll out in time. For now, edit the config file and ask questions. -- "The nice thing about DIY is that if you break it, you get to keep both pieces"

7 14

IAX registry
by Corey 18 Nov '17

18 Nov '17

Good afternoon all, My nodes no longer register automatically since I moved over to a PI DIAL setup. I have to issue a IAX2 reload command whenever the pi is rebooted or I restart the asterisk service. Any advice on what I need to do to automate the registry is appreciated. Have a great day, Corey

2 1

AllStar Node 46841 on a RPi Zero W
by Will Bashlor 18 Nov '17

18 Nov '17

Good Friday Evening, Node 46841 is a hub node running on a Raspberry Pi Zero W. I am monitoring the CPU, RAM, and other resources, which you can see below. Also see bubble chart below. It’s connected to hub node 46690 which is permanently connected to the Echolink Georgia Conference with many linked repeaters throughout GA. Feel free to connect your personal node to 46841 and listen via the Pi Zero W. You can monitor the CPU, memory, etc by clicking on the link below, for both 46841 and 46648. For comparison 46648 is an RPi 3 with a DMK URI connected to a Yaezu 7800. If it does get loaded down take note of how many nodes are connected. If for some reason it starts affecting 46690 or the conference I’ll disconnect it. I wouldn’t think so, but just so you know. Node 46841 http://stats.allstarlink.org/nodeinfo.cgi?node=46841 I have no idea how many nodes the Zero W can handle but at the moment I have 2 connected and it seems to be handling it fine for now. At 8:00PM EST tonight there will be a tech net that will last over 2 hours, which should be a good test for it. The Pi Zero W will only have power connected and will be connected to the network via wireless, and you can also see the bandwidth usage via the link below. If it runs fine as a hub node I’ll eventually test it with a CM108 URI and an 888. I can probably add another graph to historically graph the number of nodes connected to it, but it would more than likely be too much trouble just for temporary testing. Live resource monitoring for nodes 46841 and 46648 http://home.bashlor.com:81/probenode.htm?id=1 <http://home.bashlor.com:81/probenode.htm?id=1&tabid=1&username=allstar&pass…> &tabid=1&username=allstar&password=AllStar1 73 Will, KE4IAJ <https://www.facebook.com/profile.php?id=196073504193006&ref=br_rs> TARG AEC

2 1

Re: [App_rpt-users] DNS Setup
by Darren Carleton 17 Nov '17

17 Nov '17

My I suggest rather than updating /etc/resolv.conf a static value should be placed in /etc/systemd/resolvconf.conf. This way regardless of network interface it will maintain the value. I have also seen cases where the DNS IP does not get updated correctly after reboot on Pi3 systems when using DHCP. From the best I can tell, it appears the correct values are written to /var/run/resolvconf/interfaces/wlan0 but resolvconfig tries to read it immediately after but it was not written yet (slow flash card). My recommendation to work around it to add $(which resolvconf) -u to /etc/rc.local. This give enough time between the write to the flash card. The result is /etc/resolv.conf has the correct values. Your thoughts? DarrenKJ6KFB

1 0

To All wireless lan (WiFi) users of RaspberryPi 3 boards w/DIAL distribution
by Darren Carleton 17 Nov '17

17 Nov '17

I have experienced simular issues with my Pi3 connecting to nodes, keeping time, updating Echolink online hosts all while using the onboard WiFi. What I found is that the DNS Name service IP was not being correctly applied to /etc/resolv.conf. See if you replicate the issues by following these steps: Execute: cat /var/run/resolvconf/interfaces/wlan0Result (yours will be different but should look simular):domain hsd1.ca.comcast.net.nameserver 192.168.240.1 Execute: cat /etc/resolv.confResult:# This file is managed by systemd-resolved(8). Do not edit.## Third party programs must not access this file directly, but# only through the symlink at /etc/resolv.conf. To manage# resolv.conf(5) in a different way, replace the symlink by a# static file or a different symlink. Execute: cat /etc/systemd/resolved.confResult:# This file is part of systemd.## systemd is free software; you can redistribute it and/or modify it# under the terms of the GNU Lesser General Public License as published by# the Free Software Foundation; either version 2.1 of the License, or# (at your option) any later version.## See resolved.conf(5) for details [Resolve]#DNS= Execute: ping www.google.comResult:ping: unknown host www.google.com If the above matches your case, I suggest doing the following:Execute: resolvconf -u(No result displayed) Execute: ping www.google.comResult:PING www.google.com (74.125.135.103) 56(84) bytes of data.64 bytes from pl-in-f103.1e100.net (74.125.135.103): icmp_seq=1 ttl=44 time=42.0 ms^C--- www.google.com ping statistics ---1 packets transmitted, 1 received, 0% packet loss, time 0msrtt min/avg/max/mdev = 42.074/42.074/42.074/0.000 ms Execute: cat /etc/resolv.confResult: # Generated by resolvconfdomain hsd1.ca.comcast.net.nameserver 192.168.240.1 Now you can see that the nameserver is defined and DNS name resolution functions correctly. Suggested perminent fix:Add the following lines to /etc/rc.local just under the existing comments:# Update DNS Resolution$(which resolvconf) -u Execute: shutdown -r now After the reboot is complete, login and verify DNS resolves. A simple ping is enough to verify. Please reply if this solves your issue.

3 2

Re: [App_rpt-users] hub crash help
by ars.w5omr＠gmail.com 17 Nov '17

17 Nov '17

Moreso, Tim, what I find most upsetting is that all Allstar users can't get on the same page. I'm not interested in resparking the ages old debate - that horse is long dead and even the maggots have moved on. I -do- wish however, there was simply more respect for one another in this world. Good job on identifying problem areas in the code. Perhaps an in-depth review of those specific modules by someone who knows the language (that ain't me!) is in order. 73 Geoff/W5OMR 29655/56/57 On Nov 15, 2017 5:54 PM, Tim Sawyer <tisawyer(a)gmail.com> wrote: > > I have long complained about the uptime of App_Rpt. I've identified two repeatable problems. > > First one is if a node is connected more than about 650 hours or so there is a buffer overflow. I notice this most prominently with my RTCMs that are all on the same server connected to a hub on the same server. Allmon will show an negative number of connected hours followed shortly by a crash. Apparently this not just an RTCM problem, it just shows up there more readily because the nodes on the same server and aren't disconnecting due to network issues. > > The second problem can be recreated in two ways. Set up a bunch of nodes to repeatedly connect and disconnect to a hub with some simple bash scripting. After a random time there will be a crash. The second way is to crank in simulated packet loss with the IAX2 test command. It takes more time and patients for it to crash under this test. I believe both these tests demonstrate the same problem. There is something flaky in the area of IAX links within App_Rpt or Asterisk > > The Ham VoIP guys say they have really improved the uptime of their distro. I think that's great but I find it terribly upsetting that the DIAL folks don't get these fixes. >

2 1

Re: [App_rpt-users] Trouble with RTCM and Garmin GPS (18x LVC)
by Lee Woldanski 17 Nov '17

17 Nov '17

Have you looked at: http://wiki.allstarlink.org/wiki/RTCM_Client#GPS Specifically, does this Garmin use 5V or 3.3V logic? I believe the RTCM uses 5V logic only (the VOTER) will do either. If your Garmin is 3.3V, it may have issues. Also, make sure the baud rate is correct, and it is configured to send the required NMEA sentences. Lee On Nov 16, 2017 12:40 AM, "Doug Kingston" <dpk(a)randomnotes.org> wrote: I can't get the RTCM to recognize the attached GPS unit. Reference: http://static.garmincdn.com/pumac/GPS_18x_Tech_Specs.pdf I have determined that pin6 on the DB15 of the RTCM is transmit data to the GPS (using an oscilloscope) and that's hooked to the RxData line of the Garmin (green). Will the Garmin respond if it does not have lock? RTCM diagnostics complain: Running Diagnostics... Warning!! VF Diode NOT calibrated!!! Testing PTT/External CTCSS Error - Failed to read PTT/CTCSS in asserted state Testing GPS UART Error - Failed to read data from GPS UART Any hints? or ways to get more diagnostics? -Doug- _______________________________________________ App_rpt-users mailing list App_rpt-users(a)lists.allstarlink.org http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://lists.allstarlink.org/ cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.

3 3

chan_usbradio.c error
by Bob 16 Nov '17

16 Nov '17

I periodically experience the following error on the RPi3 with DIAL (/var/log/asterisk/messages). Any clues? The repeater uses a URIx, and the Linux address for the USB is the same as devstr= in usbradio_tune_usb.conf ERROR[537] chan_usbradio.c: HID process has died or something!! [Nov 12 13:17:07] NOTICE[538] chan_usbradio.c: Assigned USB device 1-1.2:1.0 to usbradio channel usb [Nov 12 13:17:07] WARNING[538] chan_usbradio.c: Loaded parameters from usbradio_tune_usb.conf for device usb . [Nov 12 13:17:07] WARNING[537] chan_usbradio.c: Possibly stuck USB read channel. [usb] [Nov 12 13:17:07] WARNING[537] chan_usbradio.c: Nope, USB read channel [usb] wasn't stuck after all. [Nov 12 13:38:16] ERROR[537] chan_usbradio.c: HID process has died or something!! [Nov 12 13:38:16] WARNING[520] app_rpt.c: rpt_thread restarted on node <# redacted> The 21 min delay from the prior message is typical. After the error, it restarts asterisk, and the startup macro reconnects the repeater. Thanks, Bob k6ecm

4 5

Trouble with RTCM and Garmin GPS (18x LVC)
by Doug Kingston 16 Nov '17

16 Nov '17

I can't get the RTCM to recognize the attached GPS unit. Reference: http://static.garmincdn.com/pumac/GPS_18x_Tech_Specs.pdf I have determined that pin6 on the DB15 of the RTCM is transmit data to the GPS (using an oscilloscope) and that's hooked to the RxData line of the Garmin (green). Will the Garmin respond if it does not have lock? RTCM diagnostics complain: Running Diagnostics... Warning!! VF Diode NOT calibrated!!! Testing PTT/External CTCSS Error - Failed to read PTT/CTCSS in asserted state Testing GPS UART Error - Failed to read data from GPS UART Any hints? or ways to get more diagnostics? -Doug-

2 2

Re: [App_rpt-users] (no subject)
by John Griffith 16 Nov '17

16 Nov '17

Hi everyone. I’ve had my Allstar ACID system up for years and for the most part it’s working fine. If the repeater has had no local use for an extended period of time, then someone local transmits into it, The first 10 seconds of audio is “mororboat” choppy, with rapid rhythmical packet loss into the remote nodes (not the local transmitter though), then after 10 seconds or so it’s fine again and There’s no way to get it to do that again except to wait another 2 hours or so. Anyone experienced this? I’m on CenturyLink ISP with the proper ports configured. I don’t find that opening ports makes much difference anyway, the packets seem to find their way.

4 3