[arm-allstar] Internal AllStar Node Configuration with External Facing Node

Fri Feb 22 01:44:44 EST 2019

Doug,

I think he is asking what many question... If Macros are a *5 series why 
is the example for ;startup_macro= shown as a *7?
Very confusing to new users to understand why the *7 is listed when 
macro's are a *5x series. Would would be a lot less confusing if it read 
;startup_macro=*5x

Larry - N7FM

On 2/21/19 7:43 PM, "Doug Crompton via ARM-allstar" wrote:
> Kyle,
>
>   Yes certainly.  We use the startup_macro command often. The
> startup_macro=  command can be pointed towards a macro defined in the
> macros stanza of rpt.conf thus doing just about anything you could do
> manually in Allstar. This is done on a node basis so if you had two active
> nodes on a server you could have two different startup macros each doing
> something based on that node number. Here is an example assuming my first
> node number is [40000]  The startup_macro command is already in rpt.conf
> for each node but commented out so remove the semicolon before it to
> activate.
>
> [40000]
> ...
> ...
> ...
> startup_macro=*52
> ;startup_macro_delay=5  default 5 second delay
>
> [macros]    or   [macrosXXXXX]  where XXXXX is your first node number
> ;Macro number = command string (each command separated by space) -end with
> HASH
> 1=*81 *80#    ; play time and voice ID
> 2=*7340001#
>
> Here we show a startup_macro directing us to macro number 2.  *5 is the
> lead in for a macro and the number after it is the macro number. Then in
> the macro stanza where there is already an active example macro of 1 to say
> the time and your ID  we make a second one called 2. This macro does a
> permanent connect to node 40001 at boot. Macro definitions start with a *
> and end with a #. There can be as many space separated commands as you
> want. Thus:
>
> 2=*7340001 *7340002 *7340003#
>
> Would connect to all three of those nodes at boot.  There is also a
> startup_macro_delay command which by default is 5 seconds but can be added
> to delay the execution of the command after boot if necessary. With DNS
> lookup you will find it connects immediately at boot but in some case a
> longer delay like 15-20 seconds might be warranted.
>
> A couple of other things to point out. The startup_macro command can point
> at any function instead of a macro. So if you had  startup_macro=*D900  and
> you had a function defined as D900 then it would be performed at boot. In
> this case you could also DTMF D900 to perform the same function. The
> function can be a command so it could call a script that could do about
> anything in Allstar or Linux.
>
> Also functions can be any alpha!  So  you could have a function called
> E900 that the Macro called and it would work BUT of course DTMF would not,
> there is no E in DTMF. But you could do it through the client or a remote
> command. Thus if you want to obscure a function but still have remote
> control over it you could use an alpha DTMF would not decode.
>
>
> *73 Doug*
>
> *WA3DSP*
>
> *http://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*
>
>
>
>
>
>
>
>
> In any node stanza
>
> On Thu, Feb 21, 2019 at 8:57 PM "Kyle Krieg via ARM-allstar" <
> arm-allstar at hamvoip.org> wrote:
>
>> Hey Doug,
>>
>> Thanks for the info.  One more question about the macros.  I see in my
>> rpt.conf file I have startup macro = *7 that is commented out.  In your
>> example you had *5.  I'm assuming the number after the * matters.  Can you
>> explain a little bit more on this?
>>
>>   Thanks
>>
>> Kyle
>>
>>
>> On Tue, Feb 19, 2019 at 9:21 PM "Doug Crompton via ARM-allstar" <
>> arm-allstar at hamvoip.org> wrote:
>>
>>> Kyle,
>>>
>>> Right now in a private node system like you propose every node that needs
>>> to connect to another node in the network needs the IP address and IAX
>> port
>>> for the node it needs to connect to. So if you had nodes
>>> 1200,1201,1202,1203 and they all need to have the capability to connect
>> to
>>> each other ALL of THEM would need routing information for all the others.
>>> Of course you would not be connecting them all together simultaneously
>> but
>>> for redundancy having the routing information there is a good idea. In
>>> reality you would probably pick one as the hub with all the other private
>>> nodes connected to it and that one would have a public node facing the
>>> Internet.  The NONE is a placeholder and just needs to be there.
>>>
>>> It is also a good idea to always place the port in the routing also so a
>>> line would look like this:
>>>
>>> 1097 = radio at 192.168.0.88:4569/1097,NONE
>>> <http://radio@192.168.0.88/1097,NONE>
>>>
>>> assuming that servers port was 4569. Each server should be on a different
>>> port - 4569,4570,4571, etc.
>>>
>>> The remote stuff is being removed from Allstar and in new installations
>>> those lines are no longer in rpt.conf. Remote control of a radio, if
>>> necessary, should be done through hamlib and DTMF scripts. hamlib is part
>>> of the hamvoip code.
>>>
>>> Permanent connects are *73<node>       *7340000     to permanently
>> connect
>>> to node 40000
>>> You should determine how you want the nodes to connect then from either
>> one
>>> end or the other establish a startup macro.  In rpt.conf in the node
>> stanza
>>> you want to connect from add
>>>
>>> startup_macro=*52
>>>
>>> In the macro section add
>>>
>>> 2=*73<node>#
>>>
>>> So if you wanted node node 1085 to boot and connect permanently to node
>>> 40105 you would put this in the macro stanza at node 1085
>>>
>>> 2=*7340105#
>>>
>>> with the  startup_marco=*52   - up in the [1085] stanza. The command is
>>> already there commented out as an example. Search for it.
>>>
>>> Also keep in mind that Allstar in itself is a repeater controller which
>> in
>>> most cases would replace an expensive commercial controller.
>>>
>>>
>>> *73 Doug*
>>>
>>> *WA3DSP*
>>>
>>> *http://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*
>>>
>>>
>>>
>>> On Tue, Feb 19, 2019 at 10:00 PM "Kyle Krieg via ARM-allstar" <
>>> arm-allstar at hamvoip.org> wrote:
>>>
>>>> We are about ready to start our testing with a new CAT800 controller
>> and
>>>> AllStar nodes.  Exciting!!!!
>>>>
>>>> The club has decided to use private internal nodes to link our
>> repeaters
>>>> around town together (via a private mesh network) and then connect one
>> of
>>>> the private nodes to an external facing public node.  This way there is
>>>> only "1 way into" the private nodes, kinda like a firewall into a
>>> network.
>>>> I'm looking through the documentation and if we have three private
>> nodes
>>>> and one public node, we define them in the rpt.conf stanza just like
>> any
>>>> other node.  We then need to define the other private nodes in
>> rpt.conf,
>>>> and likewise in the other private nodes within the network.
>>>>
>>>> Ex : if we have three private nodes (1085, 1091, 1097) and one public
>>> node
>>>> (40105) our [nodes] stanza would look like this (looking from the 1085
>>> node
>>>> for the example)
>>>>
>>>> 1085 = radio at 127.0.0.1/1085,NONE
>>>> 1097 = radio at 192.168.0.88/1097,NONE
>>>> 1091 = radio at 192.168.0.101/1091,NONE
>>>> 40105 = radio at 192.168.0.125/40105,NONE
>>>>
>>>> Question : I don't understand what the NONE at the end of a node
>>> definition
>>>> line in the [node] stanza is for.
>>>>
>>>> 1085 = radio at 192.168.0.45/1085,NONE
>>>>
>>>> Question : What is a memory for a remote base?  I see they are all
>>>> commented out.
>>>>
>>>> ;00 = 146.580,100.0,m
>>>> ;01 = 147.030,103.5,m+t
>>>> ;02 = 147.240,103.5,m+t
>>>> ;03 = 147.765,79.7,m-t
>>>> ;04 = 146.460,100.0,m
>>>> ;05 = 146.550,100.0,m
>>>>
>>>> Question : What if I wanted to connect node 40105 permanently to local
>>> node
>>>> 1085, so if the 40105 node reboots it automatically connects or
>>>> automatically connects if it drops off some how.  Do I need to write a
>>>> script and call it in cron to check for connection, or will the
>>>> "permanently" checkbox do that in Supermon?
>>>>
>>>> Sorry for all the questions, just trying to get my configs correctly so
>>>> testing goes well.  FYI..we are planning on using duplex = 0 and
>>> linktolink
>>>> = yes because we are interfacing with a multiport controller (CAT 800
>> on
>>>> port 3).  Fusion repeater is connected to port 1.  CAT800 is handling
>> all
>>>> the courtesy tones.
>>>>
>>>> Thanks
>>>> Kyle
>>>> AA0Z
>>>> Allstar Node #48370 + Echolink AA0Z-L
>>>> _______________________________________________
>>>>
>>>> ARM-allstar mailing list
>>>> ARM-allstar at hamvoip.org
>>>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>>>>
>>>> Visit the BBB and RPi2/3 web page - http://hamvoip.org
>>>>
>>> _______________________________________________
>>>
>>> ARM-allstar mailing list
>>> ARM-allstar at hamvoip.org
>>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>>>
>>> Visit the BBB and RPi2/3 web page - http://hamvoip.org
>>>
>> _______________________________________________
>>
>> ARM-allstar mailing list
>> ARM-allstar at hamvoip.org
>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>>
>> Visit the BBB and RPi2/3 web page - http://hamvoip.org
>>
> _______________________________________________
>
> ARM-allstar mailing list
> ARM-allstar at hamvoip.org
> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>
> Visit the BBB and RPi2/3 web page - http://hamvoip.org
>