[App_rpt-users] app_rpt updates, upgrades etc.

[Stacy]

Steve,
Thanks.

I agree that loading everything under the sun is a bad idea.

While it may have a small attack surface, the support for IPv6 is 
something that we could benefit from.  There are other things in 1.8 
that may not be useful yet, but still useful.  Plus, there are other 
things in the 1.4.x version Asterisk that aren't in 1.8.32.3 (the 
version I ported things to) that are listed in Digium's security 
advisories.  If I remember correctly, some were given some patching, but 
others haven't.  These alone warrant looking at upgrading to a newer 
version of Asterisk.

I've got all but chan_beagle, chan_rptdir, chan_tlb, and chan_usrp 
ported over and loading into the 1.8 system without causing a panic.

chan_echolink (with issues), chan_simpleusb, chan_usbradio, and 
chan_voter were ported over.  The only one I was able to test was 
chan_echolink and noted in the issues on the github repository that it 
is deaf to DTMF tones at the moment.

I will say that I appreciate your efforts on rolling out a version of 
Asterisk from Jim's SVN repository that runs on modern hardware.  That 
alone is a step forward that many would not have been able to make (I've 
peaked at the Debian docs for custom installers, it is not for the faint 
of heart).

As for the app_rpt code, I haven't added comments to it, but there is a 
ton of stuff that I did to follow the program flow for debugging while I 
was working on getting in running on 1.8. You can turn this on and off 
with a simple define in the app_rpt.c in the repository.  Once the code 
is stable, this can be edited out fairly easily.

I really think that we would benefit for trying to get this moved up to 
a newer version with all the bugs ironed out.  Since Digium et all have 
made changes to the code base for Asterisk that break app_rpt without 
mods, we will likely never be able to get things back into the base 
repository without re-writing parts of app_rpt to work with the newer 
framework.  This means we will always be stuck on a fork of Asterisk for 
our own needs. 13 would be great, but I believe we first we need to get 
to 1.8 and go from there.

-Stacy
KG7QIN

On 09/14/2016 08:53 AM, Steve Zingman wrote:
> I've been watching the back and forth concerning updating app_rpt to 
> run on "a more current version" of Asterisk in hopes of a number if 
> improvements. Some of these improvements do have value, others not so 
> much.
>
> A little history is in order here. I have been using and supporting 
> AllStar for the past 10 years. Like most, I used ACID to get up and 
> running. Centos is not my preferred Linux distribution. I prefer 
> Debian and pretty quickly built what I needed to run AllStar on Debian 
> for myself. Debian is not "bleeding edge" It's not meant to be. It's 
> rock solid stable.
>
> About 1.5 years ago I started seeing a increasing number of people 
> reporting issues with installing ACID on newer hardware. No network 
> drivers etc. Since I did not have those issues running current Debian, 
> I decided to see if I could do something about the problem.
>
> I took the current Debian netinst image and using the ability to 
> "preseed" the answers required for a base install of Debian. From 
> there it was a simple task to automate the download of the most 
> current source from the "official" SVN compile and install it. 
> Building the kernel modules for DAHDI had to be done also. With that, 
> we had AllStar running on a distribution with up to date drivers and a 
> fairly current kernel. With the apt system of Debian a user could 
> update the OS easily. Pulling updates from the SVN for Asterisk can be 
> done manually or via a pretty simple script. I now had what I called 
> "Bare Metal Install"
>
> Could AllStar be turned into installable Debian programs? Yes a 
> repository could be built. Scripts could be built to automate the 
> package creation. To be honest I don't think AllStar changed that 
> often to make this worthwhile. Someone could take this on.
>
> A couple of the things bothered me about ACID. First was that Asterisk 
> loaded every conceivable module at startup. No matter if you needed 
> the module or not. This worked and the user usually did not care. It 
> put a lot of bogus errors in the log and to some extent, ate memory 
> that was not needed. I tried to build every module, even if it was not 
> needed but did not enable the module in modules.conf. The other thing 
> that bothered me was that the sample rpt.conf and other config files 
> were not complete. Most everything was there, but some thing were 
> missing and I felt it was better to try to include all options AND add 
> comments detailing all possible values. Nothing is ever perfect, but I 
> tried and continue to add things I missed.
>
> Jim approached me and asked if I was willing to turn BMI into the 
> official AllStar x86 distribution. I agreed and added the scripts to 
> support the web portal for creation and backup of configs. Jim came up 
> with a name DIAL.
>
> At the same time, Jim had heard I built a image for the Raspberry Pi 
> using Debian Jessie. He asked if we could also us it as official PIi 
> version. I agreed added the scripts and DIAL for the RPi was born. 
> This image does not build on the fly as did BMI but the update path 
> was the same.
>
> DIAL relies on the official Asterisk source for the SVN. No more no 
> less. I do not believe in fluff being part of a official distribution. 
> Sure, it can be added. I just don't want people to have to remove 
> things. There are quite a few great add on features and programs 
> available for AllStar. I'll continue to make sure they work, but I 
> don't think they should be part of the distribution. All of my work 
> for building DIAL and scripts to support more platforms is kept in a 
> GIT repository along with links to the "release candidate" for amd64, 
> i386
> and the RPi. <https://github.com/N4IRS/AllStar>
>
> The reason for this romp down memory lane is just to point out that 
> DIAL is independent of the official source. I don't care is it is in a 
> SVN or GIT repository. As long as I can get to the current source, 
> DIAL is good.
>
> For me, I could care less if appt_rpt is ported to a more current 
> version of Asterisk. To me the current version is fine as a repeater 
> controller, remote base and voter. I think the current attack surface 
> is small and still be reduced within the host OS. If I want a PBK I'll 
> spin up the current Asterisk and connect the 2.
>
> The time available for people that can work on app_rpt is limited. I 
> think that time at least at first should be spent on app_rpt.c and the 
> channel drivers. There is a LOT of code there and if more people 
> understood it, the more people could maintain and enhance it. First 
> that means comments! A push to comment the existing code would go a 
> long way. Who knows what might be found while commenting the existing 
> code.
>
> There are some parts of app_rpt that have a very limited audience. The 
> support for the Uchameleon comes to mind. I'm not saying kill it. I'm 
> saying break it out as a module and allow the user to load it if the 
> user has one and wants to use it. Other areas that can get the same 
> treatment could be the remote base. I know others have done work with 
> Hamlib. It should be leveraged. I think it could be more of a module, 
> not a set of scripts that need to be pasted together. Integrate it and 
> let the user decide to enable it.
>
> The channel drivers could use some attention. Right now we have the 
> PCI quad card and USB sound. Other devices are due in the future. 
> Break out the "digital IO" from the channel driver. Move the PTT, COS 
> and CTCSS and other digital IO away from the dependence on the CM1xx. 
> I'm not saying remove it. Make it more modular. If I want the GPIO on 
> the CM1xx great. If I want to use the GPIO of the RPi fine. If I want 
> to use the parallel port on the PC, fine. This way only the Digital IO 
> module needs to be modified, not the whole channel driver. Combine the 
> simpleUSB and USBradio channel drivers. I know of at least one fork 
> that did this with success. and future channel drivers are doing this 
> soon. One less channel driver to maintain.
>
> Expand the capability of chan_usrp. We use this channel driver for the 
> DMRGateway project with great success. Being able to pass more data 
> between app_rpt and the outside world (and back) would enhance the 
> abilities of both. Think of passing a MDC ID through to DMRGateway or 
> D-StarGateway.
>
> I could go on and on. There are a ton of feature and enhancements 
> people have asked for. All of this requires the "buy in" of Jim. 
> Without it, it's just another fork.
>
> Just one off the top of my head.
>
> 73, Steve N4IRS
>
>