Date   
Re: Node 3288 moribund

larry_n7fm
 

Ramon,

If I were choosing I would go with a Pi3+.
Less power required and runs much cooler than Pi4. Still plenty of Horsepower for IRLP.

Larry -N7FM

On 6/12/20 1:10 AM, Ramon Gandia wrote:
My node 3288 is in a remote Alaskan village. Internet connection is
by way of a satellite dish on VIASAT (formerly EXEDE). I have a
block of IP's from them.
Ping time is now about 2.5 seconds; and connections are often
dropped. The aiming point of the dish is barely above the horizon,
and well beyond the coverage area of VIASAT.
On top of that, looking at the log files in /var/log/syslog shows a breakin attempt on ssh at the rate of 4 attacks PER SECOND.
Finally, the command "last" normally fails, and the wtmp logfile resets every few minutes. This leads me to believe that the computer
has been hacked. Hackers always try to erase all tracks of
themselves.
This is PiRLP node running Wheezy/Raspbian linux 7. 7.6.
My plan is two fold.
1. To move service to the local Cell tower. They now have 4G/LTE.
That service sends out a dynamic IP in the 10.x.y.z range, which is
private. If I run a router on my side, it will be double-NATed.
But I can tie an IRLP node directly to the cell modem, and at least pick up the 10.x.y/z address directly.
There is no hope whatsoever of having the ISP give me a fixed IP.
So, that would leave me using VPN.
I tried my 3289 node on the cell modem, and worked fine on VPN. 3289
is here on my bench, testing before deploying to another village.
2. Will download the raspbian, burn the sd card, and test it all using one of several Pi's I have in stock. Including openvpn.
Once it runs, I'd request the vpn config from Dave.
Should I use a Pi4, or should I go with a Pi3B+? I have several of
each. I think the 3 should be ample.
Next question is: Does the old PiRLP have any modifications to the Pi
board? I believe not, that the only changes are in the IRLP v3 board
on it.
This little Pi is about 3 hours from here by Jeep, and I am trying to
save a trip there until the last minute. Shut down the node up
there, drive, change out the Pi -- or at least the SD card, and touch
up the audio levels.
I think I an run the backup_for_reinstall script from here and download the file.gz. Might take a few tries what with the bad
internet.
Any ideas or suggestions, anyone?
-- Ramon Gandia AL7X 3288 3289 7254
uns much cooler and has enough h

Node 3288 moribund

Ramon Gandia
 

My node 3288 is in a remote Alaskan village. Internet connection is by
way of a satellite dish on VIASAT (formerly EXEDE). I have a block of
IP's from them.

Ping time is now about 2.5 seconds; and connections are often dropped.
The aiming point of the dish is barely above the horizon, and well
beyond the coverage area of VIASAT.

On top of that, looking at the log files in /var/log/syslog shows a
breakin attempt on ssh at the rate of 4 attacks PER SECOND.

Finally, the command "last" normally fails, and the wtmp logfile
resets every few minutes. This leads me to believe that the
computer has been hacked. Hackers always try to erase all tracks
of themselves.

This is PiRLP node running Wheezy/Raspbian linux 7. 7.6.

My plan is two fold.

1. To move service to the local Cell tower. They now have 4G/LTE.

That service sends out a dynamic IP in the 10.x.y.z range, which
is private. If I run a router on my side, it will be double-NATed.

But I can tie an IRLP node directly to the cell modem, and at least
pick up the 10.x.y/z address directly.

There is no hope whatsoever of having the ISP give me a fixed IP.

So, that would leave me using VPN.

I tried my 3289 node on the cell modem, and worked fine on VPN.
3289 is here on my bench, testing before deploying to another
village.

2. Will download the raspbian, burn the sd card, and test it all
using one of several Pi's I have in stock. Including openvpn.

Once it runs, I'd request the vpn config from Dave.

Should I use a Pi4, or should I go with a Pi3B+?
I have several of each. I think the 3 should be ample.

Next question is: Does the old PiRLP have any modifications to
the Pi board? I believe not, that the only changes are in the
IRLP v3 board on it.

This little Pi is about 3 hours from here by Jeep, and I am
trying to save a trip there until the last minute. Shut down
the node up there, drive, change out the Pi -- or at least the
SD card, and touch up the audio levels.

I think I an run the backup_for_reinstall script from here and
download the file.gz. Might take a few tries what with the
bad internet.

Any ideas or suggestions, anyone?

--
Ramon Gandia AL7X 3288 3289 7254

Re: Host Refleector

k9dc
 

Thanks David!

On Jun 11, 2020, at 00:46, David McAnally <David.McAnally@...> wrote:

These two links should help you get started with experimental nodes.
<http://experimental.irlp.net/>
<https://irlp.groups.io/g/IRLP/message/51228>

David M.
WD5M

Re: Host Refleector

David McAnally
 

These two links should help you get started with experimental nodes.

David M.
WD5M



On Wed, Jun 10, 2020 at 10:33 PM Nosey Nick VA3NNW <irlp@...> wrote:

> 1) A stable operating platform (computer and hard drive)
> 2) A stable internet connection with at least 10mbps up/down
> 3) A static IP address that does not change
> 4) The need to run your own versus using another.
1) Check (99.99%uptime for 8yrs), 2) Check (10gigabit), 3) Check (6, and
more if I want 'em), 4) Check ('cos I'm not even wanting it to be a
REFLECTOR as such)
> It also needs its OWN static IP address, IOW it cannot share the same connection as your IRLP node, unless you have multiple public IP addresses.
Check.
> Alternatively you also could set up your own Experimental reflector (in fact that is what I thought you were asking about).

*I* was wanting an Experimental reflector, but mine was the
"Experimental nodes" thread, not this "Host Refleector" thread... which
is fine. The more the merrier!   :-D

I was wanting an Experimental reflector because I'm not wanting to
"reflect" as such. I want to be able to accept an incoming connection,
get a bit of info about WHICH NODE has connected, feed that through a
bunch of other scripts I've written, play some WAVs at them, and
disconnect, but I'm still not entirely sure where to begin on the
IRLP-signalling and GPG bits. I'm NOT wanting to impact operation of my
actual node, which is a different machine on a completely different IP, 
I'm wanting to use the server above.

I'm assuming it would need a different GPG key (right?), presumably SOME
of the IRLP code (mynetd? irlpd? irlp_answer? remote_admin_server?) but
at some point (scripts/control? scripts/on? custom/custom_on?) I jump in
and send audio to imike (which is SpeakFreely? Which went EOL in 2004?
But was reborn on sourceforge honest?) instead of an actual microphone?
Or do sfreflect / thelinkbox replace imike too? And is tbd part of the
picture, or is that only if EchoLink is involved? thelinkbox (tlb) is
based on thebridge (tbd) if I understand right?

I assume need "just enough IRLP" to register in the IRLP
DNS/status.irlp/etc (scripts/ipupdate?), accept connections (mynetd
etc?), do some GPG auth(?), then have something imike-like throw a bunch
of WAVS/RAW/whatever back at the caller, and disconnect cleanly. I think
I want to allow multiple simultaneous inbound connections, but they're
not joined/talkign to each other, in fact inbound audio can be
dropped/ignored, but they need to be receiving *different* collections
of pre-prepared outbound WAVs/RAW/whatever. I don't think I need any of
the irlp_port, dtmf, scripts/decode, none of the IRLP hardware or even a
soundcard, as this is internet-side only, 100% digital, no analogue, no RF?

I'm fluent in Linux, BASH, Perl, C/Python/JAVA if I have to, but still
confused as to where to start. Is there any "developer documentation"
beyond what I've explored in http://irlp.net/owners/ ?

Thanks
Nick VA3NNW

--
"Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209.
use Std::Disclaimer;    sig@...
Start a nasty rumor and see if you recognize it when it comes back to you.





Re: Host Refleector

k9dc
 

Experimental nodes/reflector (same thing) are not really part of the IRLP network per se. We simply offer a number, mapped to a specific public IP address or name. There are no keys issued and no security at all. If you want the connection secured, it is up to you to set it up, otherwise it is open to any IP address on the Internet. All you have to do is set a specific IP address or name for the reflector/node, select a codec you want to use, and duplex mode. Once established, it can never be changed. Only IRLP nodes explicitly optioned will be able to connect.

IRLP.net does not provide any software for them. You can choose whatever product you want, generic sfreflect, linkbox, theBridge, up to you to get it working. Take a look on your node, at the file scripts/exp-x-reference to see what other folks are using.

In order to connect, nodes must be explicitly be set up to allow connections to experimental nodes. export ALLOW_EXPERIMENTAL_NODES=YES

-k9dc

On Jun 10, 2020, at 23:28, Nosey Nick VA3NNW <irlp@...> wrote:


1) A stable operating platform (computer and hard drive)
2) A stable internet connection with at least 10mbps up/down
3) A static IP address that does not change
4) The need to run your own versus using another.
1) Check (99.99%uptime for 8yrs), 2) Check (10gigabit), 3) Check (6, and
more if I want 'em), 4) Check ('cos I'm not even wanting it to be a
REFLECTOR as such)
It also needs its OWN static IP address, IOW it cannot share the same connection as your IRLP node, unless you have multiple public IP addresses.
Check.
Alternatively you also could set up your own Experimental reflector (in fact that is what I thought you were asking about).
*I* was wanting an Experimental reflector, but mine was the
"Experimental nodes" thread, not this "Host Refleector" thread... which
is fine. The more the merrier! :-D

I was wanting an Experimental reflector because I'm not wanting to
"reflect" as such. I want to be able to accept an incoming connection,
get a bit of info about WHICH NODE has connected, feed that through a
bunch of other scripts I've written, play some WAVs at them, and
disconnect, but I'm still not entirely sure where to begin on the
IRLP-signalling and GPG bits. I'm NOT wanting to impact operation of my
actual node, which is a different machine on a completely different IP,
I'm wanting to use the server above.

I'm assuming it would need a different GPG key (right?), presumably SOME
of the IRLP code (mynetd? irlpd? irlp_answer? remote_admin_server?) but
at some point (scripts/control? scripts/on? custom/custom_on?) I jump in
and send audio to imike (which is SpeakFreely? Which went EOL in 2004?
But was reborn on sourceforge honest?) instead of an actual microphone?
Or do sfreflect / thelinkbox replace imike too? And is tbd part of the
picture, or is that only if EchoLink is involved? thelinkbox (tlb) is
based on thebridge (tbd) if I understand right?

I assume need "just enough IRLP" to register in the IRLP
DNS/status.irlp/etc (scripts/ipupdate?), accept connections (mynetd
etc?), do some GPG auth(?), then have something imike-like throw a bunch
of WAVS/RAW/whatever back at the caller, and disconnect cleanly. I think
I want to allow multiple simultaneous inbound connections, but they're
not joined/talkign to each other, in fact inbound audio can be
dropped/ignored, but they need to be receiving *different* collections
of pre-prepared outbound WAVs/RAW/whatever. I don't think I need any of
the irlp_port, dtmf, scripts/decode, none of the IRLP hardware or even a
soundcard, as this is internet-side only, 100% digital, no analogue, no RF?

I'm fluent in Linux, BASH, Perl, C/Python/JAVA if I have to, but still
confused as to where to start. Is there any "developer documentation"
beyond what I've explored in http://irlp.net/owners/ ?

Thanks
Nick VA3NNW

Re: Host Refleector

Nosey Nick VA3NNW
 

1) A stable operating platform (computer and hard drive)
2) A stable internet connection with at least 10mbps up/down
3) A static IP address that does not change
4) The need to run your own versus using another.
1) Check (99.99%uptime for 8yrs), 2) Check (10gigabit), 3) Check (6, and
more if I want 'em), 4) Check ('cos I'm not even wanting it to be a
REFLECTOR as such)
It also needs its OWN static IP address, IOW it cannot share the same connection as your IRLP node, unless you have multiple public IP addresses.
Check.
Alternatively you also could set up your own Experimental reflector (in fact that is what I thought you were asking about).
*I* was wanting an Experimental reflector, but mine was the
"Experimental nodes" thread, not this "Host Refleector" thread... which
is fine. The more the merrier!   :-D

I was wanting an Experimental reflector because I'm not wanting to
"reflect" as such. I want to be able to accept an incoming connection,
get a bit of info about WHICH NODE has connected, feed that through a
bunch of other scripts I've written, play some WAVs at them, and
disconnect, but I'm still not entirely sure where to begin on the
IRLP-signalling and GPG bits. I'm NOT wanting to impact operation of my
actual node, which is a different machine on a completely different IP, 
I'm wanting to use the server above.

I'm assuming it would need a different GPG key (right?), presumably SOME
of the IRLP code (mynetd? irlpd? irlp_answer? remote_admin_server?) but
at some point (scripts/control? scripts/on? custom/custom_on?) I jump in
and send audio to imike (which is SpeakFreely? Which went EOL in 2004?
But was reborn on sourceforge honest?) instead of an actual microphone?
Or do sfreflect / thelinkbox replace imike too? And is tbd part of the
picture, or is that only if EchoLink is involved? thelinkbox (tlb) is
based on thebridge (tbd) if I understand right?

I assume need "just enough IRLP" to register in the IRLP
DNS/status.irlp/etc (scripts/ipupdate?), accept connections (mynetd
etc?), do some GPG auth(?), then have something imike-like throw a bunch
of WAVS/RAW/whatever back at the caller, and disconnect cleanly. I think
I want to allow multiple simultaneous inbound connections, but they're
not joined/talkign to each other, in fact inbound audio can be
dropped/ignored, but they need to be receiving *different* collections
of pre-prepared outbound WAVs/RAW/whatever. I don't think I need any of
the irlp_port, dtmf, scripts/decode, none of the IRLP hardware or even a
soundcard, as this is internet-side only, 100% digital, no analogue, no RF?

I'm fluent in Linux, BASH, Perl, C/Python/JAVA if I have to, but still
confused as to where to start. Is there any "developer documentation"
beyond what I've explored in http://irlp.net/owners/ ?

Thanks
Nick VA3NNW

--
"Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209.
use Std::Disclaimer; sig@...
Start a nasty rumor and see if you recognize it when it comes back to you.

Re: Custom DTMF Dial Path

VK4DAK
 

Thanks all for your input. I have learnt a bit from reading this - Including using parts of existing scripts to solve the problem.

Looks like I have managed to resolve my problems - thanks to all for the input!

Re: Custom DTMF Dial Path

David Cameron - IRLP
 

Case is good, but it is also easier to make syntax errors in (in my opinion). If/then is also easier to understand for someone not familiar with logic programming.

Also, when talking about processor load and if/then versus case statements - keep in mind this is maybe run at most a few times an hour, and the processors in any of these nodes is capable of running through tens of thousands of if/then lines using bash variables per second....

We are out of the ARPAnet days where your paid your provider by how many processor cycles you use :)

David Cameron
VE7LTD

On 2020-06-10 4:19 p.m., Steve Jones wrote:
Nick,
  Good point about using ‘case’ instead of a bucket load of  if-then-fi statements.  I have been using the case statement in my custom_decode since building my node on CentOS-4…  It runs quicker and less CPU intensive and allows reg-exp selections, like
000|9|9[0-5])  $CUSTOM/tx_info $1       # Play node information recordings
           exit 1 ;;
which responds to 000,9,and 90-95 , all in the same line.  I too wondered why it was not used from the start..
Steve  VK2YLD
   Node 6732
*From:*IRLP@irlp.groups.io [mailto:IRLP@irlp.groups.io] *On Behalf Of *Nosey Nick VA3NNW
*Sent:* Wednesday, 10 June 2020 11:26 PM
*To:* IRLP@irlp.groups.io
*Subject:* Re: [IRLP] Custom DTMF Dial Path
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@... <mailto:sig@...>
A bug in the hand is better than one as yet undetected.

Re: Custom DTMF Dial Path

Steve Jones
 

Nick,

  Good point about using ‘case’ instead of a bucket load of  if-then-fi statements.  I have been using the case statement in my custom_decode since building my node on CentOS-4…  It runs quicker and less CPU intensive and allows reg-exp selections, like

 

000|9|9[0-5])  $CUSTOM/tx_info $1       # Play node information recordings

           exit 1 ;;

 

which responds to 000,9,and 90-95 , all in the same line.  I too wondered why it was not used from the start..

 

Steve  VK2YLD

   Node 6732

 

From: IRLP@irlp.groups.io [mailto:IRLP@irlp.groups.io] On Behalf Of Nosey Nick VA3NNW
Sent: Wednesday, 10 June 2020 11:26 PM
To: IRLP@irlp.groups.io
Subject: Re: [IRLP] Custom DTMF Dial Path

 

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.

Re: Host Refleector

k9dc
 

It also needs its OWN static IP address, IOW it cannot share the same connection as your IRLP node, unless you have multiple public IP addresses.

Alternatively you also could set up your own Experimental reflector (in fact that is what I thought you were asking about). There are a few folks around here that can help you do that.

FWIW the 9600 reflector generally has no one on it at all. It is in Australia, but it really works very well regardless of where you are located.

-k9dc

On Jun 10, 2020, at 17:51, David Cameron - IRLP <dcameron@...> wrote:

Hosting a reflector involves four important things:
1) A stable operating platform (computer and hard drive)
2) A stable internet connection with at least 10mbps up/down
3) A static IP address that does not change
4) The need to run your own versus using another.

As pointed out, there are lots that have little use, and no need to add another unless you are bringing up a network of 20+ repeaters full time and want it to be available to others.

Dave Cameron
VE7LTD

Re: Networking failing using openvpn

David McAnally
 

These changes are now applied to my github repository <https://github.com/wd5m/echoirlp> for new installs. Thank you Dave Cameron! I should have done this long ago.

David M.
WD5M


On Wed, Jun 10, 2020 at 1:07 PM David Cameron - IRLP <dcameron@...> wrote:
Klaus,

Someone needs to fix the EchoIRLP scripts in the download repository
and/or update the install script. I spent a lot of time to fix the
broken scripts and it went nowhere. You will see my comments in the scripts.

The problem is the use of SoX (command is sox) and how it handles
arguments. IRLP fixed this in 2015. There are also reasons to use aoss
and aplay versus other programs and play in many cases. It happens in 5
scripts in the EchoIRLP/scripts directory:

echo_common
echo_on
echo_wavgen
echo_wavplay
wavprep

I have put a copy of all of these scripts here:

ftp://ftp.irlp.net/pub/bugfixes/Deb_EchoIRLP_scriptfix.tgz

On your node, change to the EchoIRLP scripts directory, and run:

wget  ftp://ftp.irlp.net/pub/bugfixes/Deb_EchoIRLP_scriptfix.tgz
tar  -zxvf  Deb_EchoIRLP_scriptfix.tgz
chown  repeater.repeater  *
chmod  750  *

I can not help you fix it if it breaks anything.

We can not choose to run outdated software to keep hold of things that
are not maintained. The solution is simple. Someone near and dear to
EchoIRLP needs to take this on and fix the scripts that the installs use.

Dave Cameron
VE7LTD

On 2020-06-10 10:08 a.m., Klaus Rung via groups.io wrote:
> If I update to the deb 9 will the audio announcements stop working on
> echolink and the other old scripts that are in the node like time etc? I
> would hate to break things worse than they are now. The reason for using
> the vpn service on these nodes is because of their internet connection
> being non routable.
>
> On Wednesday, June 10, 2020, 1:04:26 p.m. EDT, David Cameron - IRLP
> <dcameron@...> wrote:
>
>
> No, the update will have no effect on your problem. All it will do is
> change the IP address reported in your error.
>
> You should update these nodes to Debian 9 at least, and then try it with
> the update openvpn.
>
> Updating a Debian node in place is not overly complicated. Debian 7 is
> no longer supported though, so the first step is not simple. There are
> lots of sites online that describe the update process. Just google
> "update debian 7 to 9" (or 7 to 8, then 8 to 9 etc.)
>
> David Cameron
>
> On 2020-06-10 9:56 a.m., Klaus Rung via groups.io wrote:
>  > So are you saying I should wait until the update to see if things stay
>  > working?
>  >
>  >
>  >
>  > On Wednesday, June 10, 2020, 12:53:38 p.m. EDT, David Cameron - IRLP
>  > <dcameron@... <mailto:dcameron@...>> wrote:
>  >
>  >
>  > Its in a comment in ipupdate, and I recently fixed the script for the
>  > find_best_server. It will be in the next update.
>  >
>  > I also updated the web DYNDNS timeout to 5 seconds. It is not a time
>  > critical piece, but adds delay into anything calling ipupdate if there
>  > is a DNS problem.
>  >
>  > Those errors will still exist, but it will show a different IP (which is
>  > valid).
>  >
>  > When the node has no internet, it will keep trying to connect, and throw
>  > errors when it doesn't connect.
>  >
>  > David Cameron
>  >
>  > On 2020-06-10 8:57 a.m., Ramon Gandia wrote:
>  >  > On my node 3288, that IP address is hard coded into
>  >  > ~/scripts/ipupdate
>  >  > ~/scripts/bind_best_server
>  >  >
>  >  > It seems that if there is poor connectivity, it defaults
>  >  > to that IP address.  With good connectivity, its not an
>  >  > issue.
>  >  >
>  >  > Was one of the reason I wanted to lengthen the timeout
>  >  > value in an earlier post.  However, doing so, just
>  >  > covers up the problem.
>  >  >
>  >  > --
>  >  > Ramon AL7X 3288 3289 7254
>  >  >
>  >  > On 6/10/20 6:52 AM, David Cameron - IRLP wrote:
>  >  >> A big problem is that the server you are showing doesn't exist
> any more
>  >  >> (142.103.194.4). We need to figure out why that is also. Somewhere,
>  >  >> that ip is hard coded.
>  >  >>
>  >  >> Sounds like openvpn is losing the gateway, and not able to recover.
>  >  >>
>  >  >> Dave Cameron
>  >  >>
>  >  >>
>  >  >>
>  >  >> -------- Original message --------
>  >  >> From: k9dc <Dave@... <mailto:Dave@...> <mailto:Dave@...
> <mailto:Dave@...>>>
>  >  >> Date: 6/10/20 7:27 AM (GMT-08:00)
>  >  >> To: IRLP@irlp.groups.io <mailto:IRLP@irlp.groups.io>
> <mailto:IRLP@irlp.groups.io <mailto:IRLP@irlp.groups.io>>
>  >  >> Subject: Re: [IRLP] Networking failing using openvpn
>  >  >>
>  >  >>
>  >  >> This is probably because your DNS 1.1.1.1 is not accessible after the
>  >  >> tunnel drops. With DNS dead, your node will not be able to lookup
>  >  >> vpn01.irlp.net.  I would suggest using your local router for DNS (not
>  >  >> 1.1.1.1 or other outside nameserver).  The reason is that your local
>  >  >> router will always work regardless of the VPN being there or not.
>  >  >>
>  >  >> I would also recommend upgrading to Debian 9 Stretch.  The version of
>  >  >> OpenVPN that comes with 9, is much more robust than Debian 7.
>  >  >>
>  >  >> -k9dc
>  >  >>
>  >  >>  > On Jun 10, 2020, at 10:14, Klaus Rung via groups.io
>  >  >> <k_rung=yahoo.com@groups.io <mailto:yahoo.com@groups.io>
> <mailto:yahoo.com@groups.io <mailto:yahoo.com@groups.io>>> wrote:
>  >  >>  >
>  >  >>  > I have a deb 7 jessie node that has the openvpn installed. The
>  >  >> openvpn work fine when booted and gets the 44. ip and works
> normally for
>  >  >> a day or so. When the provider releases the wan ip it appears
> that the
>  >  >> node cannot reconnect to get the 44 ip and the message in the log is
>  >  >>  >
>  >  >>  > Jun 09 2020 12:07:47 -0400 ipupdate: WARNING - Comms error to
> server
>  >  >> 142.103.194.4. Cant obtain current IP.
>  >  >>  > Jun 09 2020 12:15:31 -0400 ipupdate: WARNING - Comms error to
> server
>  >  >> 142.103.194.4. Cant obtain current IP.
>  >  >>  > Jun 09 2020 12:41:36 -0400 ipupdate: WARNING - Comms error to
> server
>  >  >> 142.103.194.4. Cant obtain current IP.
>  >  >>  > Jun 09 2020 12:43:46 -0400 WARNING - DNS is not setup correctly
>  >  >>  > Jun 09 2020 12:47:57 -0400 ipupdate: WARNING - Comms error to
> server
>  >  >> 142.103.194.4. Cant obtain current IP.
>  >  >>  >
>  >  >>  > The resolv.conf is set up to use 1.1.1.1, the same is set up
> in the
>  >  >> networking file.
>  >  >>  >
>  >  >>  > Once you reboot the pc all is good again. Is there anything I
> should
>  >  >> check or is there a solution to this. It only happens when using the
>  > vpn.
>  >  >>  >
>  >  >>  > Klaus
>  >  >>  > ve3kr
>  >  >>  > node 7371
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  >  >
>  >  >
>  >  >
>  >
>  >
>  >
>
>
>



Re: Host Refleector

David Cameron - IRLP
 

Hosting a reflector involves four important things:
1) A stable operating platform (computer and hard drive)
2) A stable internet connection with at least 10mbps up/down
3) A static IP address that does not change
4) The need to run your own versus using another.

As pointed out, there are lots that have little use, and no need to add another unless you are bringing up a network of 20+ repeaters full time and want it to be available to others.

Dave Cameron
VE7LTD

On 10/06/2020 12:34 p.m., Kevin Halton wrote:
If you want a channel or two on 9870 let me know. Sitting idle with little traffic 0 and 1 are already assigned.


On Jun 10, 2020, at 3:25 PM, honda5603@... wrote:

I currently have a simplex node for IRLP, but would like to see if I can setup a Reflector for all to use?

Re: Networking failing using openvpn

David Cameron - IRLP
 

Caution with a blanket statement to use the router as the DNS. Not ALL routers have DNS forwarders, and they might not be active.

You can set multiple DNS servers in the /etc/resolv.conf file. I suggest using your router and one of 1.1.1.1, 1.0.0.1, 4.4.2.2, 8.8.8.8. Each one on a new line

nameserver 192.168.1.1
nameserver 1.0.0.1
nameserver 4.4.2.2

I know that some "paygates" on wifi hotspots used to use 1.1.1.1 as a local address. It causes a number of problems.

Dave Cameron

On 2020-06-10 1:48 p.m., k9dc wrote:
Yes, it is a routing issue, in that 1.1.1.1 needs the VPN to work. But so does 8.8.8.8 or any other address not on your network. The local router will always be accessible, even if the VPN dies.
-k9dc

On Jun 10, 2020, at 15:41, Ramon Gandia <rfg8io@...> wrote:

Some ISPS do not handle the 1.x.x.x DNS correctly. Historically,
AT&T used the 1.x.x.x network for themselves even if IANA had
not assigned it to them.

That was fixed not too long ago, but some ISPs have wrong routing
table.

The gooble DNS's 8.8.8.8 seem to always work. Try that, if the
problem goes away, then its a routing issue with the 1.x.x.x
network.

--
Ramon AL7X 3288 3289 7254
On 6/10/20 8:53 AM, Klaus Rung via groups.io wrote:
Ok thanks for the dns info to use the router dns and see if that fixes the problem.
Klaus

Re: Networking failing using openvpn

Klaus Rung
 

I set it to use the local router and will watch it over the next few days..

On Wednesday, June 10, 2020, 4:49:10 p.m. EDT, k9dc <dave@...> wrote:



Yes, it is a routing issue, in that 1.1.1.1 needs the VPN to work. But so does 8.8.8.8 or any other address not on your network. The local router will always be accessible, even if the VPN dies.

-k9dc


> On Jun 10, 2020, at 15:41, Ramon Gandia <rfg8io@...> wrote:
>
> Some ISPS do not handle the 1.x.x.x DNS correctly.  Historically,
> AT&T used the 1.x.x.x network for themselves even if IANA had
> not assigned it to them.
>
> That was fixed not too long ago, but some ISPs have wrong routing
> table.
>
> The gooble DNS's 8.8.8.8 seem to always work.  Try that, if the
> problem goes away, then its a routing issue with the 1.x.x.x
> network.
>
> --
> Ramon AL7X 3288 3289 7254
> On 6/10/20 8:53 AM, Klaus Rung via groups.io wrote:
>> Ok thanks for the dns info to use the router dns and see if that fixes the problem.
>> Klaus




Re: Networking failing using openvpn

Klaus Rung
 

Thanks for that hint, and another thing I can try.


On Wednesday, June 10, 2020, 3:42:20 p.m. EDT, Ramon Gandia <rfg8io@...> wrote:


Some ISPS do not handle the 1.x.x.x DNS correctly.  Historically,
AT&T used the 1.x.x.x network for themselves even if IANA had
not assigned it to them.

That was fixed not too long ago, but some ISPs have wrong routing
table.

The gooble DNS's 8.8.8.8 seem to always work.  Try that, if the
problem goes away, then its a routing issue with the 1.x.x.x
network.

--
Ramon AL7X 3288 3289 7254
On 6/10/20 8:53 AM, Klaus Rung via groups.io wrote:
> Ok thanks for the dns info to use the router dns and see if that fixes
> the problem.
>
> Klaus




Re: Networking failing using openvpn

k9dc
 

Yes, it is a routing issue, in that 1.1.1.1 needs the VPN to work. But so does 8.8.8.8 or any other address not on your network. The local router will always be accessible, even if the VPN dies.

-k9dc

On Jun 10, 2020, at 15:41, Ramon Gandia <rfg8io@...> wrote:

Some ISPS do not handle the 1.x.x.x DNS correctly. Historically,
AT&T used the 1.x.x.x network for themselves even if IANA had
not assigned it to them.

That was fixed not too long ago, but some ISPs have wrong routing
table.

The gooble DNS's 8.8.8.8 seem to always work. Try that, if the
problem goes away, then its a routing issue with the 1.x.x.x
network.

--
Ramon AL7X 3288 3289 7254
On 6/10/20 8:53 AM, Klaus Rung via groups.io wrote:
Ok thanks for the dns info to use the router dns and see if that fixes the problem.
Klaus

Re: V3.0 board

Victor Zarich
 

Thank you for responding.
73’s de Vic K6VIZ

On Jun 10, 2020, at 9:04 AM, Jeff Kelly via groups.io <jkelly=verizon.net@groups.io> wrote:

Thank you.

I was able to give the board to the first emailer.

Jeff
K2SDR




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






Re: Networking failing using openvpn

Ramon Gandia
 

Some ISPS do not handle the 1.x.x.x DNS correctly. Historically,
AT&T used the 1.x.x.x network for themselves even if IANA had
not assigned it to them.

That was fixed not too long ago, but some ISPs have wrong routing
table.

The gooble DNS's 8.8.8.8 seem to always work. Try that, if the
problem goes away, then its a routing issue with the 1.x.x.x
network.

--
Ramon AL7X 3288 3289 7254

On 6/10/20 8:53 AM, Klaus Rung via groups.io wrote:
Ok thanks for the dns info to use the router dns and see if that fixes the problem.
Klaus

Re: Host Refleector

Kevin Halton
 

If you want a channel or two on 9870 let me know. Sitting idle with little traffic 0 and 1 are already assigned. 


On Jun 10, 2020, at 3:25 PM, honda5603@... wrote:

I currently have a simplex node for IRLP, but would like to see if I can setup a Reflector for all to use?

Re: Networking failing using openvpn

Klaus Rung
 

Thanks for this help Dave with your fixes. I am sorry to see that nobody is taking up the upkeep of the EchoIRLP scripts as it was very handy to have both systems available on the same pc and the echolink side gets the reliability of irlp and the same standards the irlp side had. It is very handy to be able to call into the home repeater using the echolink app on your phone when you cannot use a radio but have internet like during a trip or no node available in the area.

On Wednesday, June 10, 2020, 2:08:10 p.m. EDT, David Cameron - IRLP <dcameron@...> wrote:


Klaus,

Someone needs to fix the EchoIRLP scripts in the download repository
and/or update the install script. I spent a lot of time to fix the
broken scripts and it went nowhere. You will see my comments in the scripts.

The problem is the use of SoX (command is sox) and how it handles
arguments. IRLP fixed this in 2015. There are also reasons to use aoss
and aplay versus other programs and play in many cases. It happens in 5
scripts in the EchoIRLP/scripts directory:

echo_common
echo_on
echo_wavgen
echo_wavplay
wavprep

I have put a copy of all of these scripts here:

ftp://ftp.irlp.net/pub/bugfixes/Deb_EchoIRLP_scriptfix.tgz

On your node, change to the EchoIRLP scripts directory, and run:

wget  ftp://ftp.irlp.net/pub/bugfixes/Deb_EchoIRLP_scriptfix.tgz
tar  -zxvf  Deb_EchoIRLP_scriptfix.tgz
chown  repeater.repeater  *
chmod  750  *

I can not help you fix it if it breaks anything.

We can not choose to run outdated software to keep hold of things that
are not maintained. The solution is simple. Someone near and dear to
EchoIRLP needs to take this on and fix the scripts that the installs use.

Dave Cameron
VE7LTD

On 2020-06-10 10:08 a.m., Klaus Rung via groups.io wrote:
> If I update to the deb 9 will the audio announcements stop working on
> echolink and the other old scripts that are in the node like time etc? I
> would hate to break things worse than they are now. The reason for using
> the vpn service on these nodes is because of their internet connection
> being non routable.
>
> On Wednesday, June 10, 2020, 1:04:26 p.m. EDT, David Cameron - IRLP
> <dcameron@...> wrote:
>
>
> No, the update will have no effect on your problem. All it will do is
> change the IP address reported in your error.
>
> You should update these nodes to Debian 9 at least, and then try it with
> the update openvpn.
>
> Updating a Debian node in place is not overly complicated. Debian 7 is
> no longer supported though, so the first step is not simple. There are
> lots of sites online that describe the update process. Just google
> "update debian 7 to 9" (or 7 to 8, then 8 to 9 etc.)
>
> David Cameron
>
> On 2020-06-10 9:56 a.m., Klaus Rung via groups.io wrote:
>  > So are you saying I should wait until the update to see if things stay
>  > working?
>  >
>  >
>  >
>  > On Wednesday, June 10, 2020, 12:53:38 p.m. EDT, David Cameron - IRLP
>  > <dcameron@... <mailto:dcameron@...>> wrote:
>  >
>  >
>  > Its in a comment in ipupdate, and I recently fixed the script for the
>  > find_best_server. It will be in the next update.
>  >
>  > I also updated the web DYNDNS timeout to 5 seconds. It is not a time
>  > critical piece, but adds delay into anything calling ipupdate if there
>  > is a DNS problem.
>  >
>  > Those errors will still exist, but it will show a different IP (which is
>  > valid).
>  >
>  > When the node has no internet, it will keep trying to connect, and throw
>  > errors when it doesn't connect.
>  >
>  > David Cameron
>  >
>  > On 2020-06-10 8:57 a.m., Ramon Gandia wrote:
>  >  > On my node 3288, that IP address is hard coded into
>  >  > ~/scripts/ipupdate
>  >  > ~/scripts/bind_best_server
>  >  >
>  >  > It seems that if there is poor connectivity, it defaults
>  >  > to that IP address.  With good connectivity, its not an
>  >  > issue.
>  >  >
>  >  > Was one of the reason I wanted to lengthen the timeout
>  >  > value in an earlier post.  However, doing so, just
>  >  > covers up the problem.
>  >  >
>  >  > --
>  >  > Ramon AL7X 3288 3289 7254
>  >  >
>  >  > On 6/10/20 6:52 AM, David Cameron - IRLP wrote:
>  >  >> A big problem is that the server you are showing doesn't exist
> any more
>  >  >> (142.103.194.4). We need to figure out why that is also. Somewhere,
>  >  >> that ip is hard coded.
>  >  >>
>  >  >> Sounds like openvpn is losing the gateway, and not able to recover.
>  >  >>
>  >  >> Dave Cameron
>  >  >>
>  >  >>
>  >  >>
>  >  >> -------- Original message --------
>  >  >> From: k9dc <Dave@... <mailto:Dave@...> <mailto:Dave@...
> <mailto:Dave@...>>>
>  >  >> Date: 6/10/20 7:27 AM (GMT-08:00)
>  >  >> To: IRLP@irlp.groups.io <mailto:IRLP@irlp.groups.io>
> <mailto:IRLP@irlp.groups.io <mailto:IRLP@irlp.groups.io>>
>  >  >> Subject: Re: [IRLP] Networking failing using openvpn
>  >  >>
>  >  >>
>  >  >> This is probably because your DNS 1.1.1.1 is not accessible after the
>  >  >> tunnel drops. With DNS dead, your node will not be able to lookup
>  >  >> vpn01.irlp.net.  I would suggest using your local router for DNS (not
>  >  >> 1.1.1.1 or other outside nameserver).  The reason is that your local
>  >  >> router will always work regardless of the VPN being there or not.
>  >  >>
>  >  >> I would also recommend upgrading to Debian 9 Stretch.  The version of
>  >  >> OpenVPN that comes with 9, is much more robust than Debian 7.
>  >  >>
>  >  >> -k9dc
>  >  >>
>  >  >>  > On Jun 10, 2020, at 10:14, Klaus Rung via groups.io
>  >  >> <k_rung=yahoo.com@groups.io <mailto:yahoo.com@groups.io>
> <mailto:yahoo.com@groups.io <mailto:yahoo.com@groups.io>>> wrote:
>  >  >>  >
>  >  >>  > I have a deb 7 jessie node that has the openvpn installed. The
>  >  >> openvpn work fine when booted and gets the 44. ip and works
> normally for
>  >  >> a day or so. When the provider releases the wan ip it appears
> that the
>  >  >> node cannot reconnect to get the 44 ip and the message in the log is
>  >  >>  >
>  >  >>  > Jun 09 2020 12:07:47 -0400 ipupdate: WARNING - Comms error to
> server
>  >  >> 142.103.194.4. Cant obtain current IP.
>  >  >>  > Jun 09 2020 12:15:31 -0400 ipupdate: WARNING - Comms error to
> server
>  >  >> 142.103.194.4. Cant obtain current IP.
>  >  >>  > Jun 09 2020 12:41:36 -0400 ipupdate: WARNING - Comms error to
> server
>  >  >> 142.103.194.4. Cant obtain current IP.
>  >  >>  > Jun 09 2020 12:43:46 -0400 WARNING - DNS is not setup correctly
>  >  >>  > Jun 09 2020 12:47:57 -0400 ipupdate: WARNING - Comms error to
> server
>  >  >> 142.103.194.4. Cant obtain current IP.
>  >  >>  >
>  >  >>  > The resolv.conf is set up to use 1.1.1.1, the same is set up
> in the
>  >  >> networking file.
>  >  >>  >
>  >  >>  > Once you reboot the pc all is good again. Is there anything I
> should
>  >  >> check or is there a solution to this. It only happens when using the
>  > vpn.
>  >  >>  >
>  >  >>  > Klaus
>  >  >>  > ve3kr
>  >  >>  > node 7371
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  >  >
>  >  >
>  >  >
>  >
>  >
>  >
>
>
>