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

Larry larry at thunderbolt.net
Fri Feb 22 03:50:42 EST 2019 

I see your point Doug.

My tunnel vision stemmed from the word "macro". Always learning 
something new from You, Dave and the Group.
When I first setup a node all the instructions I read said Macro begin 
with a *5. That setting example never made sense to me either.

I had not realized until you pointed out "startup_macro" could be other 
commands and not just programmed *5x Macro.
Never found it written anywhere until you just explained it. WELL DONE!

Allstar seem to have many hidden abilities that aren't documented.
Thanks to You and the Group on here, The various quirks are slowly being 
revealed.

Larry - N7FM


On 2/21/19 11:30 PM, "Doug Crompton via ARM-allstar" wrote:
> Your right BUT it could be *7 or *829 or *52.  It does not have to be a
> macro as I pointed out. The real misconception is the name of the command.
> It should probably be  startup_command  not  startup_macro.  These names
> and many of the examples were assigned early on in the Allstar history and
> long before HAMVOIP existed. We have talked about changing a lot of this
> but it is hard to make changes when a command or method has been around for
> so long. The other confusing thing is the timers being in milliseconds.
> Why? Most all would be fine with a one second resolution. wouldn't it be
> easier and much more understandable to say tx_timeout=180 but how do you
> change this now?  I suppose putting an s after it would distinguish seconds
> and make both compatible.
>
>
> *73 Doug*
>
> *WA3DSP*
>
> *http://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*
>
>
> On Fri, Feb 22, 2019 at 2:18 AM "Larry via ARM-allstar" <
> arm-allstar at hamvoip.org> wrote:
>
>> 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
>>>
>> _______________________________________________
>>
>> 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
>

More information about the ARM-allstar mailing list