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

Hi Steve, Thank you for your message, and for your overall work for the community. I fully agree with all what you said. But, if I have to retain the most important thing for me, that would be : Le 14/09/2016 à 17:53, Steve Zingman a écrit :

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!

I'm not a C programmer. I never enjoyed it, and probably will never enjoy it ;-) But I'm an experienced programmer in other languages. With a fully documented C source code, I can find a specific function, and improve / add some little features. But with the current code, that's merely impossible for me. I've been using app-rpt for a few months only, with just two repeters deployed for now. So, I'm still a newbie ;-) But I really appreciate it. I think Linux and Open Source are the two essential keys for the future of ham radio digital communications. Asterisk is the perfect tool for aggregating various VoIP flows, from various manufacturers/protocols. We'll use Asterisk / app_rpt as the central element of our multi-protocol VoIP network in Corsica. And, of course, I'll be happy to contribute in the future. 73 de TK1BI