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

Doug Crompton wa3dsp at gmail.com
Fri Feb 22 02:30:45 EST 2019 

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
>

More information about the ARM-allstar mailing list