<div dir="ltr">Thanks for the trip down memory lane Steve.  Quite a few things I wasn't aware of.  <div><br></div><div>If I hadn't said so lately, a Tremendous thanks to Jim Duuuude, Steve, Steve and the team who made this project possible!  You guys provided a way for me to link repeaters in a new way.  Sure there were other methods of doing so over IP but app_rpt allowed us to do it on a private IP backbone if we wanted to.  Now we have 2 large systems in the state using app_rpt as the linking system...bye bye UHF analog links!  There is Allmon courtesy of Tim which is another invaluable tool! Then there's voted receivers and the list goes on and on!<div><br></div><div><br></div><div>Thanks guys!!!!</div><div><br></div><div>de K0JSC</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 14, 2016 at 10:00 AM,  <span dir="ltr"><<a href="mailto:app_rpt-users-request@ohnosec.org" target="_blank">app_rpt-users-request@ohnosec.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send App_rpt-users mailing list submissions to<br>
        <a href="mailto:app_rpt-users@ohnosec.org">app_rpt-users@ohnosec.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users" rel="noreferrer" target="_blank">http://ohnosec.org/cgi-bin/<wbr>mailman/listinfo/app_rpt-users</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:app_rpt-users-request@ohnosec.org">app_rpt-users-request@ohnosec.<wbr>org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:app_rpt-users-owner@ohnosec.org">app_rpt-users-owner@ohnosec.<wbr>org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of App_rpt-users digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. app_rpt updates, upgrades etc. (Steve Zingman)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Wed, 14 Sep 2016 11:53:50 -0400<br>
From: Steve Zingman <<a href="mailto:szingman@msgstor.com">szingman@msgstor.com</a>><br>
To: 'Allstar app_rpt-users Group' <<a href="mailto:app_rpt-users@ohnosec.org">app_rpt-users@ohnosec.org</a>><br>
Subject: [App_rpt-users] app_rpt updates, upgrades etc.<br>
Message-ID: <<a href="mailto:f088fcb9-fa59-fb52-9eef-b8e0dac72df8@msgstor.com">f088fcb9-fa59-fb52-9eef-<wbr>b8e0dac72df8@msgstor.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
I've been watching the back and forth concerning updating app_rpt to run<br>
on "a more current version" of Asterisk in hopes of a number if<br>
improvements. Some of these improvements do have value, others not so much.<br>
<br>
A little history is in order here. I have been using and supporting<br>
AllStar for the past 10 years. Like most, I used ACID to get up and<br>
running. Centos is not my preferred Linux distribution. I prefer Debian<br>
and pretty quickly built what I needed to run AllStar on Debian for<br>
myself. Debian is not "bleeding edge" It's not meant to be. It's rock<br>
solid stable.<br>
<br>
About 1.5 years ago I started seeing a increasing number of people<br>
reporting issues with installing ACID on newer hardware. No network<br>
drivers etc. Since I did not have those issues running current Debian, I<br>
decided to see if I could do something about the problem.<br>
<br>
I took the current Debian netinst image and using the ability to<br>
"preseed" the answers required for a base install of Debian. From there<br>
it was a simple task to automate the download of the most current source<br>
from the "official" SVN compile and install it. Building the kernel<br>
modules for DAHDI had to be done also. With that, we had AllStar running<br>
on a distribution with up to date drivers and a fairly current kernel.<br>
With the apt system of Debian a user could update the OS easily. Pulling<br>
updates from the SVN for Asterisk can be done manually or via a pretty<br>
simple script. I now had what I called "Bare Metal Install"<br>
<br>
Could AllStar be turned into installable Debian programs? Yes a<br>
repository could be built. Scripts could be built to automate the<br>
package creation. To be honest I don't think AllStar changed that often<br>
to make this worthwhile. Someone could take this on.<br>
<br>
A couple of the things bothered me about ACID. First was that Asterisk<br>
loaded every conceivable module at startup. No matter if you needed the<br>
module or not. This worked and the user usually did not care. It put a<br>
lot of bogus errors in the log and to some extent, ate memory that was<br>
not needed. I tried to build every module, even if it was not needed but<br>
did not enable the module in modules.conf. The other thing that bothered<br>
me was that the sample rpt.conf and other config files were not<br>
complete. Most everything was there, but some thing were missing and I<br>
felt it was better to try to include all options AND add comments<br>
detailing all possible values. Nothing is ever perfect, but I tried and<br>
continue to add things I missed.<br>
<br>
Jim approached me and asked if I was willing to turn BMI into the<br>
official AllStar x86 distribution. I agreed and added the scripts to<br>
support the web portal for creation and backup of configs. Jim came up<br>
with a name DIAL.<br>
<br>
At the same time, Jim had heard I built a image for the Raspberry Pi<br>
using Debian Jessie. He asked if we could also us it as official PIi<br>
version. I agreed added the scripts and DIAL for the RPi was born. This<br>
image does not build on the fly as did BMI but the update path was the<br>
same.<br>
<br>
DIAL relies on the official Asterisk source for the SVN. No more no<br>
less. I do not believe in fluff being part of a official distribution.<br>
Sure, it can be added. I just don't want people to have to remove<br>
things. There are quite a few great add on features and programs<br>
available for AllStar. I'll continue to make sure they work, but I don't<br>
think they should be part of the distribution. All of my work for<br>
building DIAL and scripts to support more platforms is kept in a GIT<br>
repository along with links to the "release candidate" for amd64, i386<br>
and the RPi. <<a href="https://github.com/N4IRS/AllStar" rel="noreferrer" target="_blank">https://github.com/N4IRS/<wbr>AllStar</a>><br>
<br>
The reason for this romp down memory lane is just to point out that DIAL<br>
is independent of the official source. I don't care is it is in a SVN or<br>
GIT repository. As long as I can get to the current source, DIAL is good.<br>
<br>
For me, I could care less if appt_rpt is ported to a more current<br>
version of Asterisk. To me the current version is fine as a repeater<br>
controller, remote base and voter. I think the current attack surface is<br>
small and still be reduced within the host OS. If I want a PBK I'll spin<br>
up the current Asterisk and connect the 2.<br>
<br>
The time available for people that can work on app_rpt is limited. I<br>
think that time at least at first should be spent on app_rpt.c and the<br>
channel drivers. There is a LOT of code there and if more people<br>
understood it, the more people could maintain and enhance it. First that<br>
means comments! A push to comment the existing code would go a long way.<br>
Who knows what might be found while commenting the existing code.<br>
<br>
There are some parts of app_rpt that have a very limited audience. The<br>
support for the Uchameleon comes to mind. I'm not saying kill it. I'm<br>
saying break it out as a module and allow the user to load it if the<br>
user has one and wants to use it. Other areas that can get the same<br>
treatment could be the remote base. I know others have done work with<br>
Hamlib. It should be leveraged. I think it could be more of a module,<br>
not a set of scripts that need to be pasted together. Integrate it and<br>
let the user decide to enable it.<br>
<br>
The channel drivers could use some attention. Right now we have the PCI<br>
quad card and USB sound. Other devices are due in the future. Break out<br>
the "digital IO" from the channel driver. Move the PTT, COS and CTCSS<br>
and other digital IO away from the dependence on the CM1xx. I'm not<br>
saying remove it. Make it more modular. If I want the GPIO on the CM1xx<br>
great. If I want to use the GPIO of the RPi fine. If I want to use the<br>
parallel port on the PC, fine. This way only the Digital IO module needs<br>
to be modified, not the whole channel driver. Combine the simpleUSB and<br>
USBradio channel drivers. I know of at least one fork that did this with<br>
success. and future channel drivers are doing this soon. One less<br>
channel driver to maintain.<br>
<br>
Expand the capability of chan_usrp. We use this channel driver for the<br>
DMRGateway project with great success. Being able to pass more data<br>
between app_rpt and the outside world (and back) would enhance the<br>
abilities of both. Think of passing a MDC ID through to DMRGateway or<br>
D-StarGateway.<br>
<br>
I could go on and on. There are a ton of feature and enhancements people<br>
have asked for. All of this requires the "buy in" of Jim. Without it,<br>
it's just another fork.<br>
<br>
Just one off the top of my head.<br>
<br>
73, Steve N4IRS<br>
<br>
<br>
--<br>
"No, INAD is not JUST I need a drink"<br>
<br>
<br>
------------------------------<br>
<br>
______________________________<wbr>_________________<br>
App_rpt-users mailing list<br>
<a href="mailto:App_rpt-users@ohnosec.org">App_rpt-users@ohnosec.org</a><br>
<a href="http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users" rel="noreferrer" target="_blank">http://ohnosec.org/cgi-bin/<wbr>mailman/listinfo/app_rpt-users</a><br>
<br>
<br>
End of App_rpt-users Digest, Vol 91, Issue 29<br>
******************************<wbr>***************<br>
</blockquote></div><br></div>