Nosey Nick VA3NNW
Craig - K1BDX - Node 8724 wrote:
So, if any of you were using ipxcore for a vpn or an experimentalForgive me for somewhat changing the subject, but it sounds like you'd
know... If someone wants to create a new special-purpose experimental
reflector from scratch, where is a good place to begin?
I'm very familiar with Linux, scripting, coding, and I do cloud
computing stuff for my day job. I have a PiRLP node, and know my way
around most of it. I have written a weather-bot script for my node which
reads out a short local weather report approx every hour in a very
polite voice (approx Alexa-like). I was considering extending it to
offer it to others in the form of an experimental node. Theory is they
could cron a "$SCRIPT/connect_to_reflector BLAH", my reflector would
check a cache / do a quick lookup of their node's LatLon, feed it into
the weather API I'm already using, and prepare and read back THEIR
weather instead of just mine.
... so where would I start?
"Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209.
use Std::Disclaimer; sig@...
Stalinism begins at home. -- Tom Neff
David Cameron - IRLP
As this is one way communications, there is no reason why you could not just run this from the PiRLP node, or another computer behind its same router. A TCP dump watcher could catch the connection and IP, and then a process could use imike to just stream the file to the end user.toggle quoted messageShow quoted text
For the DNS name, just use
stn1234.ip.irlp.net (replace 1234 with your node number)
This would not even affect your node in operation in any way, as the ispeaker process is filtered to the IP it is connected to....
It would be easier to use a separate IP, but it could be done without.
On 2020-06-04 4:59 p.m., Nosey Nick VA3NNW wrote:
Craig - K1BDX - Node 8724 wrote:So, if any of you were using ipxcore for a vpn or an experimentalForgive me for somewhat changing the subject, but it sounds like you'd
Craig - K1BDX - Node 8724
Craig - K1BDX - Node 8724 wrote:Hello, Nick.So, if any of you were using ipxcore for a vpn or an experimental
An experimental reflector has to be run from a public IP address not
shared by any IRLP nodes. This usually rules out anyone putting a
reflector on their home internet unless multiple IPs are offered which
is not very common. So what we have been doing is renting a virtual
computer for $12.50 a year (a buck a month) which comes with its own
unique public IP address. There are two major parts to our
experimental reflectors, voice and activity lists. To simply
reflect voice packets you run a tiny little program called "sfreflect"
and you are done. If you also want a list of who is keying up the
reflector and another list showing who is listening to the reflector,
I wrote some scripts to handle that. You can see an example at these
So far we have built 9 experimental reflectors and you see a list of
them and others at this link
If you want to have a reflector of your own, the easiest thing to do
is rent a virtual computer at virmach.com and select Debian 9 as the
operating system and they will email you a confirmation with the IP
address and the temporary root password. If you forward the IP and
the password to me, I will log in and load it up with a reflector for
you. If you just want to talk on your reflector then you are done.
However, if you are like me and you want to mess around with the
software then just keep a few copies of the original software and then
play around to your heart's content. If you mess anything up then you
simply rebuild the virtual debian 9 operating system with the push of
a button which wipes away any previous software and then upload your
copy of your reflector software and you are back in business.
On 05/06/20 10:56, Craig - K1BDX - Node 8724 wrote:
Hello, Nick.There's actually multiple ways to run experimental reflectors. I don't
use sfreflect at all. Mine (exp0018) runs thelinkbox, which I
configured in transcoding mode. That allows people to play with any of
the supported codecs, and as a side effect, it also works full duplex!
My experimental reflector ended up being the prototype that allowed me
to incorporate transcoding and full duplex into regular IRLP
reflectors. Reflector channel 9555 is setup this way, but is reachable
by a standard node. However, to connect full duplex (other than needing
a node actually capable of running full duplex), you will need to write
a custom_decode entry to make the connection in full duplex.
My point being simply that there are many ways to create an experimental
reflector, depending on what you want to achieve. :)
Yes, a virtual private server is the easiest route. You will need a
public IP for each experimental reflector. My system now has over 200
IPs available (though the bulk are for public Echolink proxies).
Getting so many IPs is possible for ham use under certain conditions,
but that's beyond the scope of this message. :)
73 de Tony VK3JED/VK3IRL
Craig - K1BDX - Node 8724
Tony, yes, thanks for pointing that out.toggle quoted messageShow quoted text
Where can we get some introductory tutelage on how to set up and
operate a "linkbox" reflector? I have always wanted to learn how to
And anyone else who has information to share about building reflectors
of any kind that are compatible with IRLP pleas jump in and share your
------ original message --------
On 6/8/20, Tony Langdon <@vk3jed> wrote:
There's actually multiple ways to run experimental reflectors. I don't
On 09/06/20 09:58, Craig - K1BDX - Node 8724 wrote:
Tony, yes, thanks for pointing that out.I'm happy to help. As a first installment, there's a few things to get
you started. To use tlb or tbd as a reflector, the first thing you need
to do is enable the Speak Freely protocol. This is the protocol that
IRLP audio uses. You do this with:
SF_Enable = 1
In addition, I would also set these to the following values:
SF_Port = 2074
SF_ReplyPort = 2074
If your server has multiple IP addresses, you should set
SFBind2IP = <IP of experimental reflector>
If the latter is not set, and the reflector is running on an alias IP,
it may reply using the main IP of the interface, which will cause the
security mechanisms on the IRLP node to reject the packets. Binding the
specific IP ensures that the replies are sent with the correct IP.
If you're planning on setting up a conventional style of reflector, you
need to tell tbd/tlb what codec the reflector will use, which is done
with the CompressionType directive. Here are the possible values
CompressionType = 0 #UNCOMP
CompressionType = 3 #GSM
CompressionType = 5 #ADPCM
However, for transcoding, full duplexx reflectors, you have to use tlb,
and things are done very differently. You actually disable the standard
conference facilities with
ConfEnable = 0
And you don't need to bother with CompressionType, because the packet
conference is disabled anyway. Instead, the conferencing is handled
using the port linking facilities - the same features used to link radio
ports. This requires an EventScript that looks for stations that have
connected, then connects the new station to all existing ports using the
"link" command. On the integrated reflectors, this is done using a pair
of scripts. The first is called "linkports" and has the following code.
if ! [ "$PORT" = "" ]; then ARGS="-p$PORT" ; fi
"$TBDCMD" $ARGS ..port | xargs -r -l1 "$SCRIPT"/addlink
The other script is called "addlink"
if [ "$1" = "0" ];then exit 0 ; fi
if [ "$1" = "tbdcmd" ];then exit 0 ; fi
if [ "$1" = "Available" ];then exit 0 ; fi
if [ "$1" = "$NEWCALL" ];then exit 0 ; fi
#echo "linking $NEWCALL to $1" >> ./link.log
$TBDCMD $ARGS ..link $NEWCALL $1
These scripts were written to run in a specific environment, but the
explanation of the extra variables is as follows:
$SCRIPT is where you keep your scripts to run the system.
$TBDCMD is the path to tlbcmd, usually /usr/local/bin/tlbcmd
$PORT is the CmdPort from the configuration file. For most purposes, it
can be statically defined if it's not the default (5198). I use a
variable, because the scripts can be run on one of 10 configuration
files, and the correct value is read from the relevant config file then
saved in the $PORT variable locally.
$NEWCALL is the callsign of the station that just connected. It is set
and exported by the EventScript when it runs on a "connected" event.
Here's a sample part of an EventScript that should work. This one can
work with both transcoding and non transcoding by looking for the
if [ "$1" = "connected" ]; then
# Check for a transcoding conference (presence of ./linkports symlink
if [ -f ./linkports ]; then
Another consideration is security. IRLP's experimental reflectors
feature, by default, provides no security (see the sample tlb.conf to
find out how to disable audio packet passwords). However, if you do
want to implement your own security mechanisms, look up the allow
commands (allow add, allow delete, etc), which will allow you to enforce
a degree of security, similar to how the reflectors do it. But the
mechanisms of authentication and issuing the allow commands is for you
to work out. :)
Anyway, that should get you started. You need to read the README and
SCRIPTING files in the tlb archive, they will give you a LOT of useful
information, along with the sample tlb.conf.sample and other sample
73 de Tony VK3JED/VK3IRL