Date   
Host Refleector

honda5603@...
 

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
 

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: Networking failing using openvpn

k9dc
 

On Jun 10, 2020, at 13:25, wa1nvc <wa1nvc@...> wrote:
BTW, Debian 9 so far appears to be more stable with the VPN client than Debian 7.
Roger
WA1NVC
That is correct. I actually would have preferred to make IRLP VPN only work only with the newer versions BECAUSE they are more reliable. But all of the Nanonodes in the network are running Debian 7, and since Micronode International is now out of business, it is unlikely they will ever be upgraded. Probably a third of the VPNs assigned are on Nanonodes.

-k9dc

Re: Networking failing using openvpn

Klaus Rung
 

Ok thanks for that. I will give that a try as the node has been loosing connectivity daily sometimes and then it will go for a couple of days no problem.

Klaus
ve3kr

On Wednesday, June 10, 2020, 1:25:08 p.m. EDT, wa1nvc <wa1nvc@...> wrote:


I had the same problem.  Change the DNS server (resolv.conf) to be your
router so the VPN client can find the VPN server when the network bounces.

I had the problem intermittently; I think the problem was whether the
cache was stale.  Setting resolv.conf to 192.168.1.1 (your
router/gateway) fixed the problem.

BTW, Debian 9 so far appears to be more stable with the VPN client than
Debian 7.

Roger
WA1NVC

--
Sent from my MS Surface



Re: Custom DTMF Dial Path

David Cameron - IRLP
 

I would suggest a separate script that is called that just records and plays back the audio. Using the echo reflector for this is not the best way. The script "audio_level_test" contains all the needed pieces, just needs to be told to play back the audio file instead of the statistics.

For the fun of it, I made one called rx_parrot and put it in the scripts directory to sync to all nodes.

It is not perfect, but will be adjusted over time I am sure. To use it, add this line to custom_decode (replacing A3 with the code you want):

if [ "${1}" = "A3" ]; then $SCRIPT/rx_parrot ; fi

David Cameron
VE7LTD

On 2020-06-10 6:25 a.m., Nosey Nick VA3NNW wrote:
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: Networking failing using openvpn

wa1nvc
 

I had the same problem. Change the DNS server (resolv.conf) to be your router so the VPN client can find the VPN server when the network bounces.

I had the problem intermittently; I think the problem was whether the cache was stale. Setting resolv.conf to 192.168.1.1 (your router/gateway) fixed the problem.

BTW, Debian 9 so far appears to be more stable with the VPN client than Debian 7.

Roger
WA1NVC

--
Sent from my MS Surface

Re: Networking failing using openvpn

Klaus Rung
 

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@...> 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@...>>
>  >> Date: 6/10/20 7:27 AM (GMT-08:00)
>  >> To: 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>> 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: Networking failing using openvpn

Klaus Rung
 

Ok thanks for the info below. I will experiment for now and see if I can get it to stop failing and if not will have to go the route you suggest.


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


To me it is a bit of a "hang"... The VPN drops, but the gateway is not
returned to the local LAN. It gets stuck on the VPN, but can not reconnect.

I think the only solution is to have an external script that tries to
ping the private IP of the VPN server you are connected to, and if fails
a few times in a row, then restart the VPN.

It appears to be a bug in the older openvpn, as it does not seem to
recover from certain situations. You should be able to adjust some of
the keepalive parameters, etc.

Dave Cameron

On 2020-06-10 9:53 a.m., 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
>
>
> On Wednesday, June 10, 2020, 10:27:41 a.m. EDT, k9dc <dave@...> wrote:
>
>
>
> 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>> 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: Networking failing using openvpn

David Cameron - IRLP
 

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@...> 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@...>>
>> Date: 6/10/20 7:27 AM (GMT-08:00)
>> To: 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>> 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: Networking failing using openvpn

David Cameron - IRLP
 

To me it is a bit of a "hang"... The VPN drops, but the gateway is not returned to the local LAN. It gets stuck on the VPN, but can not reconnect.

I think the only solution is to have an external script that tries to ping the private IP of the VPN server you are connected to, and if fails a few times in a row, then restart the VPN.

It appears to be a bug in the older openvpn, as it does not seem to recover from certain situations. You should be able to adjust some of the keepalive parameters, etc.

Dave Cameron

On 2020-06-10 9:53 a.m., 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
On Wednesday, June 10, 2020, 10:27:41 a.m. EDT, k9dc <dave@...> wrote:
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>> 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: Networking failing using openvpn

Klaus Rung
 

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@...> 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@...>
>> Date: 6/10/20 7:27 AM (GMT-08:00)
>> To: 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> 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: Networking failing using openvpn

Klaus Rung
 

Ok thanks for the dns info to use the router dns and see if that fixes the problem.

Klaus


On Wednesday, June 10, 2020, 10:27:41 a.m. EDT, k9dc <dave@...> wrote:



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> 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: Networking failing using openvpn

David Cameron - IRLP
 

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@...>
Date: 6/10/20 7:27 AM (GMT-08:00)
To: 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> 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: V3.0 board

Jeff Kelly
 

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
 

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@...>
Date: 6/10/20 7:27 AM (GMT-08:00)
To: 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> 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: Networking failing using openvpn

David Cameron - IRLP
 

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@...>
Date: 6/10/20 7:27 AM (GMT-08:00)
To: 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@...> 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: Networking failing using openvpn

k9dc
 

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

Networking failing using openvpn

Klaus Rung
 

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: Custom DTMF Dial Path

k9dc
 

Goops. Forgot
de k9dc

On Jun 10, 2020, at 09:26, k9dc <Dave@...> wrote:


On Jun 10, 2020, at 07:44, VK4DAK <vk4dak@...> wrote:
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 ….
There are a couple of ways to handle this.

First is to create and use the lockout_list file. If the file exists, it contains a list of nodes and reflectors you do not want to connect, both outgoing and incoming calls are blocked.

If custom/lockout_list looks like this

ref9605
ref9607
stn4733
stn7530
ref9999
ref9998
ref9990

This nodes cannot be dialed, and incoming calls (from listed nodes) are also blocked. Users will hear the lockout_local recording when dialing “Your node operator does not allow calls to this node” If an incoming call is received (from 4733 or 7530) the calling station hears the lockout_remote recording "The node you are calling does not allow calls from your node"

Simply include ref9999 ref9990 and others you want to block, but leave at least one open that works (I leave 9997 working on my machines).

Second method involves editing custom_decode and mixing up the the dial requirements. Two entries required for each. First, trap out the pattern you want to disallow. Then set up an alternate pattern that works.

if [ "$1" = “9999" ] ; then "$SCRIPT"/wavplay lockout_local ; exit 1 ; fi
if [ "$1" = “12345" ] ; then "$SCRIPT"/connect_to_reflector ref9999 ; exit 1 ; fi

This plays the lockout_local recording when 9999 is dialed (sounds the same a using the lockout_list file above). But if 12345 is dialed it connects to 9999.

custom/custom_decode entries can also be used if you want to use some of the options like “notimeout” on specific destinations.

Re: Custom DTMF Dial Path

k9dc
 

On Jun 10, 2020, at 07:44, VK4DAK <vk4dak@...> wrote:
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 ….
There are a couple of ways to handle this.

First is to create and use the lockout_list file. If the file exists, it contains a list of nodes and reflectors you do not want to connect, both outgoing and incoming calls are blocked.

If custom/lockout_list looks like this

ref9605
ref9607
stn4733
stn7530
ref9999
ref9998
ref9990

This nodes cannot be dialed, and incoming calls (from listed nodes) are also blocked. Users will hear the lockout_local recording when dialing “Your node operator does not allow calls to this node” If an incoming call is received (from 4733 or 7530) the calling station hears the lockout_remote recording "The node you are calling does not allow calls from your node"

Simply include ref9999 ref9990 and others you want to block, but leave at least one open that works (I leave 9997 working on my machines).

Second method involves editing custom_decode and mixing up the the dial requirements. Two entries required for each. First, trap out the pattern you want to disallow. Then set up an alternate pattern that works.

if [ "$1" = “9999" ] ; then "$SCRIPT"/wavplay lockout_local ; exit 1 ; fi
if [ "$1" = “12345" ] ; then "$SCRIPT"/connect_to_reflector ref9999 ; exit 1 ; fi

This plays the lockout_local recording when 9999 is dialed (sounds the same a using the lockout_list file above). But if 12345 is dialed it connects to 9999.

custom/custom_decode entries can also be used if you want to use some of the options like “notimeout” on specific destinations.