10 thoughts on - app_rpt

  • Paul,

    thanks for the info. I’m the maintainer od the Asterisk extension in
    Tiny Core Linux and received a request to have Asterisk with app_rpt
    module in the repository. I haven’t seen it before and didn’t find it
    listed in confure’s help as a configuration option. I will try to
    rebuild actual 1.8 with DAHDI and see the result.

    Regards… Bela

    2012.03.09. 13:06 keltezéssel, Paul Belanger írta:

  • 2012/3/9 Paul Belanger

    Here are details on 1.4 I have not done 1.8.

    “Unfortunately, things are in somewhat of a mess.

    There are major logistical hurdles with getting app_rpt code back into
    the main Digium source tree. In addition, the latest versions of
    asterisk have broken some of the code which app_rpt.c depends on, The
    best thing to do at this point in time is to download the files.tar.gz
    patched version of Asterisk from http://dl.allstarlink.org/installcd
    and unpack it in /usr/src. Configure and compile zaptel, libpri, and
    asterisk just like you would be downloading the sources from asterisk.org.

    Once you have this version running, you can download the latest
    app_rpt.c from:

    http://svn.digium.com/view/asterisk/team/jdixon/chan_usbradio-1.4/apps

    and install it in /usr/src/asterisk/apps and recompile asterisk.”

  • On Fri, Mar 9, 2012 at 8:52 AM, Steve Totaro
    wrote:

    There may be a working version of app_rpt.c for 1.8 in Jim Dixon’s repo but
    I doubt it. Worth a look, I guess.

    Not sure why you need 1.8 for a radio/repeater controller.

    Thanks,
    Steve T

  • Steve,

    thanks for yout help.

    I thought to start with 1.8 as the current long term supported release
    but of course will go back if it is requered to get it up and running.

    Regards… Béla

    2012.03.09. 15:00 keltezéssel, Steve Totaro írta:

  • I’m really trying to avoid fanning the flames here, but if that code is
    *really* based on 1.4.23, and hasn’t been kept up to date with the
    Asterisk 1.4 releases, then that means it contains a number of security
    vulnerabilities that users should be aware of. Some of them are user
    enumeration vulnerabilities, but others (like AST-2011-010,
    AST-2011-005, AST-2011-001, and maybe more) are more serious.

  • Kevin,

    You are not fanning any flames, that is a good point and anyone that
    deploys this technology should have to read a disclaimer as
    to vulnerabilities. I am well aware that there have been some serious
    security issues in those earlier versions.

    As for an Asterisk Box, or probably better described by what It is used
    for, a Repeater or Base Station Controller Boxen, I have them locked down
    in IPTables and in Asterisk. There are usually not more then a dozen or so
    RoIP conncted repeaters.

    In my case, I only open one port for OpenVPN and I define the other
    repeaters by host=IP. As far as “Soft Radios and Autopatch” that function
    is taken care of by a “real” Asterisk server that is more of a PBX and
    faces the world, not the “Repeater Controller”, again, one entry defined by
    IP over OpenVPN. Bridged or routed, they non-routeable IPs. The RoIP VPN
    is only accessible through that tunnel, which is dedicated for that purpose.

    I am very mindful of security, especially dealing with DoD, but pretty much
    apply the same kind of security on any implementation.

    Obviously, these security issues should be patched, but I feel that in my
    implementations, things are very secure.

    Thanks,
    Steve T

  • I don’t use Debian, but since this is a fork, the patches may break app_rpt
    again like DAHDI did.

    I may fire up a Debian Lenny VM and see if the fork with the patches match
    up and work, and then if app_rpt and app_radio compile or throw an error.

    The latest all in one ISO uses CentOS 5.7.

    Thanks,
    Steve Totaro