Date   
Re: Custom DTMF Dial Path

Nosey Nick VA3NNW
 

VK4DAK wrote:
I am hoping to create a custom script so that when a discrete DTMF code is punched - it allow the connection to 9999
Any ideas? I have tried creating a script that when the discrete code is entered, it will either $SCRIPT/decode 9999 -- but this then ends up in the "exit 1" pile (nothing happens)
Thoughts, comments, suggestions?

Well... You could just give it a DIFFERENT NUMBER, EG:

if [ "${1}" = "9999" ]; then exit 1 ; fi # having done nothing
if [ "${1}" = "ABC123" ]; then $SCRIPT/connect_to_reflector ref9999 ; fi

If, on the other hand, you want to keep it as an "enable/disable" idea, maybe use the presence of a file to say "9999 is allowed now" or alternatively "9999 is blocked now"? You can create a file with "touch FILENAME", remove it with "rm FILENAME", check for it like "if [ -f FILENAME ] then ... fi" or considering you already have the "if" statement, you can combine:

CONDITION1 -a CONDITION2 means "CONDITION1 AND CONDITION2"
CONDITION1 -o CONDITION2 means "CONDITION1 OR CONDITION2"

So my UNTESTED example might be...

if [ "$1" = "A999" ]; then touch /tmp/enable9999; exit 1; fi
if [ "$1" = "D999" ]; then rm /tmp/enable9999; exit 1; fi # disable it again
if [ "$1" = "9999" -a -f /tmp/enable9999 ]; then $SCRIPT/connect_to_reflector ref9999; exit 1; fi

Or it might be nice to play some WAVs so it can provide some feedback, and it looks like you don't even need to record any custom ones - there are some provided ones you can use! ... so ALSO UNTESTED...

if [ "$1" = "A999" ]; then
  touch /tmp/enable9999
  $SCRIPT/wavplay 9 9 9 9 enabled
  exit 1
fi
if [ "$1" = "D999" ]; then
  rm /tmp/enable9999
  $SCRIPT/wavplay 9 9 9 9 disabled
  exit 1
fi
if [ "$1" = "9999" ]; then
 if [ -f /tmp/enable9999 ]; then
   $SCRIPT/connect_to_reflector ref9999
  else
    $SCRIPT/wavplay lockout_local
  fi
  exit 1
fi

Incidentally, BASH's "case" statement can make "custom_decode" MUCH neater, I wonder why IRLP doesn't use it? Allows you to combine a big list of "if [ $1 = blah ]; then blah fi" into...

case "$1" in
  A999) touch   /tmp/enable9999; $SCRIPT/wavplay 9 9 9 9 enabled;  exit 1 ;;
  D999) rm      /tmp/enable9999; $SCRIPT/wavplay 9 9 9 9 disabled; exit 1 ;;
  9999) if [ -f /tmp/enable9999 ]; then $SCRIPT/connect_to_reflector ref9999
                                   else $SCRIPT/wavplay reflector disabled
        fi ; exit 1 ;;
esac

Again, UNTESTED, but could probably slowly debug over email if it doesn't work as expected.

Nick VA3NNW

-- 
"Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209.
use Std::Disclaimer;    sig@...
A bug in the hand is better than one as yet undetected.

Custom DTMF Dial Path

VK4DAK
 

Hi all!

I am hoping you may be able to assist with some scripting .....

I have a problem where some locals think its great to key up REF9999 (Parrot) and leave it connected. The problem is that it causes loopbacks. I have created a custom decode so that when 9999 is detected - it is sent to "exit 1" (nothing happens).

The problem with this is that I have had some users wishing to use the 9999 to test their audio levels .... 

Here in is my problem.... some people can't be trusted which is at the detriment to others who do.

I am hoping to create a custom script so that when a discrete DTMF code is punched - it allow the connection to 9999

Any ideas? I have tried creating a script that when the discrete code is entered, it will either $SCRIPT/decode 9999 -- but this then ends up in the "exit 1" pile (nothing happens)

Thoughts, comments, suggestions?

Re: V3.0 board

Rick Szajkowski
 

What are you asking for it ?

Richard Szajkowski VA3RZS,VA3ZJ,VE3BTE

On Jun 9, 2020, at 8:31 PM, Jeff Kelly via groups.io <jkelly=verizon.net@groups.io> wrote:

I have a 3.0 board, from an older desktop, if anyone needs one.

Jeff
K2SDR
jkelly@...




V3.0 board

Jeff Kelly
 

I have a 3.0 board, from an older desktop, if anyone needs one.

Jeff
K2SDR
jkelly@...

Some changes to the PiRLP4, plus new DC-DC power supply

David Cameron - IRLP
 

Just a few changes to the PiRLP4 to announce:

1) There is a new channel carved into the case to allow viewing of the power and activity lights from the outside. This is just at the bottom right of the DB9.

2) The label now includes all the AUX1/2/3 as well as the PTT, COS, and DTMF identified on the outside

3) New heat sinks are installed on the processor, ram, and usb/ethernet chip. They are not really needed, but just add a layer of additional cooling

4) Additional components have been removed from the USB sound card which makes the install cleaner and able to dissipate heat better.

I also have sourced and torture tested a DC-DC converter option for the PiRLP4. It is a 12-15V input, 5VDC output power supply. Currently I am manually adding the USB-C connector, and I can supply it with an older micro-USB instead - just inform me at the time of the order.

The new pictures of the PiRLP4 and power supply are on the order page:

http://www.irlp.net/order/

David Cameron
VE7LTD

Re: Experimental nodes

Craig - K1BDX - Node 8724
 

Tony, yes, thanks for pointing that out.

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
do that.

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
knowledge.




------ original message --------

On 6/8/20, Tony Langdon <@vk3jed> wrote:

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. :)

Re: ECHOIRLP assistance

Rick Szajkowski
 

We figured this out when he booted the old node and every thing worked

Just waiting on if he found the problem

Most likely the password was on lower case ( I hope )

Richard Szajkowski
VA3 RZS VA3ZJ VE3BTE

On Jun 8, 2020, at 7:40 PM, Tony Langdon <@vk3jed> wrote:

On 06/06/20 06:42, Rick Szajkowski wrote:
That would narrow things down for sure , just make sure the ports are
forwarded to the correct IP address on your lan , if both system have
the same IP make sure that both are not on at the same time , would be
better if the new one was not the same IP for testing ( or the old one )
For everyone's information, any references to port forwarding are a red
herring with regards to the OP's question. Port forwarding issues
causes a totally DIFFERENT error. Specifically:

The original question talked about "The node could not be found". This
means that tlb was not able to log into the Echolink servers for some
reason. Common causes are:

1. Incorrect node name/callsign. It must be a valid registered node
and be a repeater (-R) or link (-L) callsign. User logins will also
cause this error, and using a conference ID will cause tbd to run as an
independent conference, not an EchoIRLP node.

2. Incorrect password - make sure this is correct.

3. MaxConferenceClients MUST be set to 2 (i.e. MaxConferenceClients =
2). No other value will work.

As for port forwarding, if there's issues there, you'll get a different
error ("The call attempt has timed out"). This is why I know the root
cause here is not port forwarding. There _may_ be port forwarding
issues, but they won't be evident until the authentication issue is
fixed first.

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com



Re: ECHOIRLP assistance

 

On 06/06/20 06:42, Rick Szajkowski wrote:
That would narrow things down for sure , just make sure the ports are
forwarded to the correct IP address on your lan , if both system have
the same IP make sure that both are not on at the same time , would be
better if the new one was not the same IP for testing ( or the old one )
For everyone's information, any references to port forwarding are a red
herring with regards to the OP's question.  Port forwarding issues
causes a totally DIFFERENT error.  Specifically:

The original question talked about "The node could not be found".  This
means that tlb was not able to log into the Echolink servers for some
reason.  Common causes are:

1.  Incorrect node name/callsign.  It must be a valid registered node
and be a repeater (-R) or link (-L) callsign.  User logins will also
cause this error, and using a conference ID will cause tbd to run as an
independent conference, not an EchoIRLP node.

2.  Incorrect password - make sure this is correct.

3.  MaxConferenceClients MUST be set to 2 (i.e. MaxConferenceClients =
2).  No other value will work.

As for port forwarding, if there's issues there, you'll get a different
error ("The call attempt has timed out").  This is why I know the root
cause here is not port forwarding.  There _may_ be port forwarding
issues, but they won't be evident until the authentication issue is
fixed first.

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com

Re: ECHOIRLP assistance

 

On 06/06/20 02:51, Rick Bates, NK7I wrote:

Chris,

"PC based node"?  The software being discussed in this group runs under a carefully limited operating system of linux, not Windows (just to be clear).

I think he means "not on a Pi - using PC hardware".
-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com

Re: ECHOIRLP assistance

 

On 06/06/20 02:38, Chris Pitre wrote:
I appreciate the info, I 'm trying to do the install on a PC based node.

The Echolink node is not showing up the echolink user page ..nor does
it let me connect to anything..says the node you are calling does not
exist.

I have opened ports 5198 and 5199 on my router...I think.

This may be an easy process and perhaps im just overlooking the finest
detail.
Looks like your node isn't logging into the Echolink servers.

Check that your Echolink node name (must be a -L or -R) and password are
in uppercase in tbd.conf.  Also, you must make sure that
MaxConferenceClients is set to 2 - no other value will work!

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com

Re: ECHOIRLP assistance

 

On 05/06/20 23:41, Chris Pitre wrote:
is there anyone that can assist with an ECHOIRLP installation for
Debian 10 off list.

I don't think the group supports that software being installed on IRLP
computers.

IF it will not work with Debian, perhaps I can get assistance
installing CentOS, there is a message during the install process that
it will not get past.
There is a Debian installation script.  It certainly works on Debian 9,
but I can't 100% confirm on Debian 10.


--
73 de Tony VK3JED/VK3IRL
http://vkradio.com

Re: Experimental nodes

 

On 05/06/20 10:56, Craig - K1BDX - Node 8724 wrote:

Hello, Nick.

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
links:
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. :)

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
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
http://vkradio.com

Re: ipupdate script

Nosey Nick VA3NNW
 

That command should rarely take more than 2 seconds
I'll be honest, I'm slightly surprised someone has a network that CAN'T
get an answer out of dyndns.org in 2sec but CAN operate IRLP with
acceptable lag/jitter. I struggle to make the curl take longer than 0.4
seconds, and that's on the tiniest pi I had, with all DNS caches flushed
in advance. I'm curious what ISP?... so I can avoid them  ;-)

$ cat ipupdate | sed 's/timeout=2/timeout=10/g' > temp
$ mv temp ipupdate
Simpler, use sed's "in-place" mode, and no need for "/g" if there's only
going to be max 1 per line:

sed -i~ 's/timeout=2/timeout=10/' ipupdate

... yeah or the better supported noupdate/scripts approach

Nick VA3NNW

--
"Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209.
use Std::Disclaimer; sig@...
You sound reasonable...Time to up my medication.

Re: ipupdate script

k9dc
 

A better way is to edit /etc/dhcp/dhclient.conf and turn off the request domain-name-servers. DHCP must be told what to request, the default is to request nearly everything, but it doesn’t have to.

'man dhclient.conf’ for more information.

-k9dc

On Jun 7, 2020, at 15:16, Fred via groups.io <w5mgm=aol.com@groups.io> wrote:

To add to what David McAnally said once you set your DNS in /etc/resolv.conf run this command chattr +i /etc/resolv.conf This will lock the /etc/resolv.conf file down so the dns doesn’t change on you.

Re: ipupdate script

k9dc
 

The supported way to do this is to create the directory structure inside /home/irlp/ noupdate/scripts/ and then place the modified file you want inside noupdate/scripts/

As user repeater:
mkdir noupdate
mkdir noupdate/scripts

Basically when the update script runs, one of last things it does, is check for files in noupdate/scripts/ and copies it back to the regular scripts directory.

But as WD5M offered, this should never happen unless something is very wrong with your network. 2 seconds to look up an IP, is an eternity.

There is also the use of the force flag which forces a full authenticated update of your IP. ipupdate by itself only updates if it detects a change of your IP address. It can sometimes fail.

ipupdate force

-k9dc

On Jun 6, 2020, at 23:44, Ramon Gandia <rfg8yg@...> wrote:

In the ~/scripts/ipupdate script there is a troublesome line:

NEWIPADDRESS=`${WGET} -q --timeout=2 -O- http://checkip.dyndns.org:8245 2>/dev/null \
| cut -d":" -f2 | cut -d" " -f2 | cut -d"<" -f1`

The problem is the --timeout=2 instance. With only 2 seconds grace period, the log gets
full of all sort of error messages. I changed it to 10 seconds, and that took care of it.

But of course, the script will soon be overwritten ... any way to gracefully get around this?

Ramon AL7X 3288 3289 7254

Re: ipupdate script

Fred
 

To add to what David McAnally said once you set your DNS in /etc/resolv.conf run this command  chattr +i  /etc/resolv.conf    This will lock the /etc/resolv.conf  file down so the dns doesn’t change on you. 

On Jun 7, 2020, at 1:55 PM, David McAnally <David.McAnally@...> wrote:


That command should rarely take more than 2 seconds. I suggest checking your DNS or network performance. Use a fast DNS resolver, such as google (8.8.8.8) or quad9 (9.9.9.9). See /etc/resolv.conf

David M.
WD5M

On Sat, Jun 6, 2020 at 10:44 PM Ramon Gandia <rfg8yg@...> wrote:
In the ~/scripts/ipupdate script there is a troublesome line:

NEWIPADDRESS=`${WGET} -q --timeout=2 -O- http://checkip.dyndns.org:8245 2>/dev/null \
 | cut -d":" -f2 | cut -d" " -f2 | cut -d"<" -f1`

The problem is the --timeout=2 instance.  With only 2 seconds grace period, the log gets
full of all sort of error messages.  I changed it to 10 seconds, and that took care of it.

But of course, the script will soon be overwritten ...  any way to gracefully get around this?

Ramon AL7X 3288 3289 7254


Re: ipupdate script

David McAnally
 

That command should rarely take more than 2 seconds. I suggest checking your DNS or network performance. Use a fast DNS resolver, such as google (8.8.8.8) or quad9 (9.9.9.9). See /etc/resolv.conf

David M.
WD5M

On Sat, Jun 6, 2020 at 10:44 PM Ramon Gandia <rfg8yg@...> wrote:
In the ~/scripts/ipupdate script there is a troublesome line:

NEWIPADDRESS=`${WGET} -q --timeout=2 -O- http://checkip.dyndns.org:8245 2>/dev/null \
 | cut -d":" -f2 | cut -d" " -f2 | cut -d"<" -f1`

The problem is the --timeout=2 instance.  With only 2 seconds grace period, the log gets
full of all sort of error messages.  I changed it to 10 seconds, and that took care of it.

But of course, the script will soon be overwritten ...  any way to gracefully get around this?

Ramon AL7X 3288 3289 7254


Re: ipupdate script

Ramon Gandia
 

In answer to my own question, I have had a brilliant idea. Like this.
I run a script that takes the ipupdate file, changes "timeout=2" to
"timeout=10", and writes it back.

I can run this script on cron, everytime the update runs. It is
harmless if it is already at "10".

Like this:
$ cat ipupdate | sed 's/timeout=2/timeout=10/g' > temp
$ mv temp ipupdate

On 6/7/20 10:35 AM, Tony via groups.io wrote:
On 6/6/20 8:44 PM, Ramon Gandia wrote:
In the ~/scripts/ipupdate script there is a troublesome line:

NEWIPADDRESS=`${WGET} -q --timeout=2 -O-
http://checkip.dyndns.org:8245 2>/dev/null \
  | cut -d":" -f2 | cut -d" " -f2 | cut -d"<" -f1`

The problem is the --timeout=2 instance.  With only 2 seconds grace
period, the log gets
full of all sort of error messages.  I changed it to 10 seconds, and
that took care of it.

But of course, the script will soon be overwritten ...  any way to
gracefully get around this?
One would certainly want to make a note of it in the system logbook in
case the file needs to be edited in the future, but changing the file's
attributes to "immutable" would certainly accomplish the task. First
examine the existing attributes, make the change and then verify:

$ lsattr ~/scripts/ipupdate
--------------e---- ~/scripts/ipupdate
$ chattr +i ~/scripts/ipupdate
$ lsattr ~/scripts/ipupdate
----i---------e---- ~/scripts/ipupdate



Re: ipupdate script

Tony
 

On 6/6/20 8:44 PM, Ramon Gandia wrote:
In the ~/scripts/ipupdate script there is a troublesome line:

NEWIPADDRESS=`${WGET} -q --timeout=2 -O- http://checkip.dyndns.org:8245 2>/dev/null \
| cut -d":" -f2 | cut -d" " -f2 | cut -d"<" -f1`

The problem is the --timeout=2 instance. With only 2 seconds grace period, the log gets
full of all sort of error messages. I changed it to 10 seconds, and that took care of it.

But of course, the script will soon be overwritten ... any way to gracefully get around this?
One would certainly want to make a note of it in the system logbook in case the file needs to be edited in the future, but changing the file's attributes to "immutable" would certainly accomplish the task. First examine the existing attributes, make the change and then verify:

$ lsattr ~/scripts/ipupdate
--------------e---- ~/scripts/ipupdate
$ chattr +i ~/scripts/ipupdate
$ lsattr ~/scripts/ipupdate
----i---------e---- ~/scripts/ipupdate

Re: Fatal Error Code 40 NODE 2803

larry_n7fm
 

Chris,

One comment... When installing on new hardware a person needs to remember that all port forwarding will more than likely break as the New PC will be given a new IP lease differing from the old. Unless you pre- configure the new hardware to utilize the same static IP address as the prior node utilized. Broken port forwarding alone will create issues with connection and audio routing.

Larry - N7FM

On 6/3/20 9:08 PM, Chris Pitre wrote:
Almost convinced that this isn't for beginners..
Nothing else seems to be working now..the APRS script, is still not functioning,  I have no audio coming back from the test server.