Date   

Re: More Secure Port Forwarding

Jerry Powell
 

I found the issue........In the manual it states to open up 15426 i looked in the sshd_config file and sshd was accepting connections on that port....
Commented that out bounced sshd and all is fine now........22 comes into the Jump Server and then to the PI.....
I still would like to know the addresses of the servers that initiate an inbound connection to IRLP or ECHOLINK Pi node?


On Mon, Oct 5, 2020 at 4:00 AM Jerry Powell via groups.io <jpowell=neeko.us@groups.io> wrote:
Correct i do not have ssh port 22 exposed that is routed to my jumpbox for ssh.....they are attacking the ports the other ports...........
if i shut the Echolink and IRLP port forwards down the attacks stop...........

Oct  5 03:57:50 stn725 sshd[30650]: Received disconnect from 46.101.204.113 port 40648:11: Bye Bye [preauth]
Oct  5 03:57:50 stn725 sshd[30650]: Disconnected from authenticating user root 46.101.204.113 port 40648 [preauth]
Oct  5 03:57:55 stn725 sshd[30644]: Accepted password for root from 192.168.30.252 port 60517 ssh2
Oct  5 03:57:55 stn725 sshd[30644]: pam_unix(sshd:session): session opened for user root by (uid=0)
Oct  5 03:57:55 stn725 systemd-logind[287]: New session c15 of user root.
Oct  5 03:57:55 stn725 systemd: pam_unix(systemd-user:session): session opened for user root by (uid=0)
Oct  5 03:57:55 stn725 sshd[30662]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.90.199.208  user=root
Oct  5 03:57:56 stn725 sshd[30664]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=190.104.148.52  user=root
Oct  5 03:57:57 stn725 sshd[30662]: Failed password for root from 202.90.199.208 port 46550 ssh2
Oct  5 03:57:58 stn725 sshd[30664]: Failed password for root from 190.104.148.52 port 48916 ssh2
Oct  5 03:57:59 stn725 sshd[30662]: Received disconnect from 202.90.199.208 port 46550:11: Bye Bye [preauth]
Oct  5 03:57:59 stn725 sshd[30662]: Disconnected from authenticating user root 202.90.199.208 port 46550 [preauth]
Oct  5 03:57:59 stn725 sshd[30664]: Received disconnect from 190.104.148.52 port 48916:11: Bye Bye [preauth]
Oct  5 03:57:59 stn725 sshd[30664]: Disconnected from authenticating user root 190.104.148.52 port 48916 [preauth]
Oct  5 03:58:09 stn725 sshd[30713]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=165.22.26.140  user=root
Oct  5 03:58:12 stn725 sshd[30713]: Failed password for root from 165.22.26.140 port 55602 ssh2
Oct  5 03:58:13 stn725 sshd[30713]: Received disconnect from 165.22.26.140 port 55602:11: Bye Bye [preauth]
Oct  5 03:58:13 stn725 sshd[30713]: Disconnected from authenticating user root 165.22.26.140 port 55602 [preauth]
Oct  5 03:58:14 stn725 sshd[30721]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=49.233.192.145  user=root
Oct  5 03:58:15 stn725 sshd[30724]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=122.51.142.33  user=root
Oct  5 03:58:16 stn725 sshd[30721]: Failed password for root from 49.233.192.145 port 60592 ssh2
Oct  5 03:58:17 stn725 sshd[30724]: Failed password for root from 122.51.142.33 port 15943 ssh2
Oct  5 03:58:18 stn725 sshd[30721]: Received disconnect from 49.233.192.145 port 60592:11: Bye Bye [preauth]
Oct  5 03:58:18 stn725 sshd[30721]: Disconnected from authenticating user root 49.233.192.145 port 60592 [preauth]
Oct  5 03:58:19 stn725 sshd[30724]: Received disconnect from 122.51.142.33 port 15943:11: Bye Bye [preauth]
Oct  5 03:58:19 stn725 sshd[30724]: Disconnected from authenticating user root 122.51.142.33 port 15943 [preauth]
Oct  5 03:58:31 stn725 sshd[30733]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=152.136.237.47  user=root
Oct  5 03:58:33 stn725 sshd[30733]: Failed password for root from 152.136.237.47 port 44480 ssh2
Oct  5 03:58:35 stn725 sshd[30733]: Received disconnect from 152.136.237.47 port 44480:11: Bye Bye [preauth]
Oct  5 03:58:35 stn725 sshd[30733]: Disconnected from authenticating user root 152.136.237.47 port 44480 [preauth]
Oct  5 03:58:37 stn725 sshd[30738]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=185.120.28.19  user=root
Oct  5 03:58:39 stn725 sshd[30738]: Failed password for root from 185.120.28.19 port 38868 ssh2
Oct  5 03:58:40 stn725 sshd[30742]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.225.36.142  user=root
Oct  5 03:58:40 stn725 sshd[30738]: Received disconnect from 185.120.28.19 port 38868:11: Bye Bye [preauth]
Oct  5 03:58:40 stn725 sshd[30738]: Disconnected from authenticating user root 185.120.28.19 port 38868 [preauth]
Oct  5 03:58:42 stn725 sshd[30742]: Failed password for root from 64.225.36.142 port 33872 ssh2

On Mon, Oct 5, 2020 at 3:43 AM Tony Langdon <vk3jed@...> wrote:
On 5/10/20 4:08 pm, Jerry Powell wrote:
>
> I have my firewall setup to forward all the ports in the Manual....
>
> The Problem is those ports are getting hammered with script kiddies
> trying to get in with SSH.......
>
> So the question is. what is the server ip and dns name to put in my
> firewall so it accepts the connections from Echo/IRLP and shuns the rest?
>
> I have a SSH Jump Box already setup but having those ports forwarded
> is making that pointless........
>
Just remove the port forwarding for SSH (TCP port 22 by default). 
That's only needed if you or someone else (e.g. IRLP installs team) need
to access your node remotely.  There are ways of getting in without
exposing your SSH port as well, by using VPNs or virtual LANs (e.g.
ZeroTier).  I use ZeroTier for remote SSH access (i.e. across the
virtual LAN ZT creates), because the constant bot attempts were
consuming too many resources on the low end machine, as well as filling
up log files.

IRLP only needs TCP 14525 and UDP 2074 - 2093.  Echolink needs UDP 5198
and 5199 forwarded, as per the docs.

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







Re: More Secure Port Forwarding

Jerry Powell
 

Correct i do not have ssh port 22 exposed that is routed to my jumpbox for ssh.....they are attacking the ports the other ports...........
if i shut the Echolink and IRLP port forwards down the attacks stop...........

Oct  5 03:57:50 stn725 sshd[30650]: Received disconnect from 46.101.204.113 port 40648:11: Bye Bye [preauth]
Oct  5 03:57:50 stn725 sshd[30650]: Disconnected from authenticating user root 46.101.204.113 port 40648 [preauth]
Oct  5 03:57:55 stn725 sshd[30644]: Accepted password for root from 192.168.30.252 port 60517 ssh2
Oct  5 03:57:55 stn725 sshd[30644]: pam_unix(sshd:session): session opened for user root by (uid=0)
Oct  5 03:57:55 stn725 systemd-logind[287]: New session c15 of user root.
Oct  5 03:57:55 stn725 systemd: pam_unix(systemd-user:session): session opened for user root by (uid=0)
Oct  5 03:57:55 stn725 sshd[30662]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.90.199.208  user=root
Oct  5 03:57:56 stn725 sshd[30664]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=190.104.148.52  user=root
Oct  5 03:57:57 stn725 sshd[30662]: Failed password for root from 202.90.199.208 port 46550 ssh2
Oct  5 03:57:58 stn725 sshd[30664]: Failed password for root from 190.104.148.52 port 48916 ssh2
Oct  5 03:57:59 stn725 sshd[30662]: Received disconnect from 202.90.199.208 port 46550:11: Bye Bye [preauth]
Oct  5 03:57:59 stn725 sshd[30662]: Disconnected from authenticating user root 202.90.199.208 port 46550 [preauth]
Oct  5 03:57:59 stn725 sshd[30664]: Received disconnect from 190.104.148.52 port 48916:11: Bye Bye [preauth]
Oct  5 03:57:59 stn725 sshd[30664]: Disconnected from authenticating user root 190.104.148.52 port 48916 [preauth]
Oct  5 03:58:09 stn725 sshd[30713]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=165.22.26.140  user=root
Oct  5 03:58:12 stn725 sshd[30713]: Failed password for root from 165.22.26.140 port 55602 ssh2
Oct  5 03:58:13 stn725 sshd[30713]: Received disconnect from 165.22.26.140 port 55602:11: Bye Bye [preauth]
Oct  5 03:58:13 stn725 sshd[30713]: Disconnected from authenticating user root 165.22.26.140 port 55602 [preauth]
Oct  5 03:58:14 stn725 sshd[30721]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=49.233.192.145  user=root
Oct  5 03:58:15 stn725 sshd[30724]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=122.51.142.33  user=root
Oct  5 03:58:16 stn725 sshd[30721]: Failed password for root from 49.233.192.145 port 60592 ssh2
Oct  5 03:58:17 stn725 sshd[30724]: Failed password for root from 122.51.142.33 port 15943 ssh2
Oct  5 03:58:18 stn725 sshd[30721]: Received disconnect from 49.233.192.145 port 60592:11: Bye Bye [preauth]
Oct  5 03:58:18 stn725 sshd[30721]: Disconnected from authenticating user root 49.233.192.145 port 60592 [preauth]
Oct  5 03:58:19 stn725 sshd[30724]: Received disconnect from 122.51.142.33 port 15943:11: Bye Bye [preauth]
Oct  5 03:58:19 stn725 sshd[30724]: Disconnected from authenticating user root 122.51.142.33 port 15943 [preauth]
Oct  5 03:58:31 stn725 sshd[30733]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=152.136.237.47  user=root
Oct  5 03:58:33 stn725 sshd[30733]: Failed password for root from 152.136.237.47 port 44480 ssh2
Oct  5 03:58:35 stn725 sshd[30733]: Received disconnect from 152.136.237.47 port 44480:11: Bye Bye [preauth]
Oct  5 03:58:35 stn725 sshd[30733]: Disconnected from authenticating user root 152.136.237.47 port 44480 [preauth]
Oct  5 03:58:37 stn725 sshd[30738]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=185.120.28.19  user=root
Oct  5 03:58:39 stn725 sshd[30738]: Failed password for root from 185.120.28.19 port 38868 ssh2
Oct  5 03:58:40 stn725 sshd[30742]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.225.36.142  user=root
Oct  5 03:58:40 stn725 sshd[30738]: Received disconnect from 185.120.28.19 port 38868:11: Bye Bye [preauth]
Oct  5 03:58:40 stn725 sshd[30738]: Disconnected from authenticating user root 185.120.28.19 port 38868 [preauth]
Oct  5 03:58:42 stn725 sshd[30742]: Failed password for root from 64.225.36.142 port 33872 ssh2

On Mon, Oct 5, 2020 at 3:43 AM Tony Langdon <vk3jed@...> wrote:
On 5/10/20 4:08 pm, Jerry Powell wrote:
>
> I have my firewall setup to forward all the ports in the Manual....
>
> The Problem is those ports are getting hammered with script kiddies
> trying to get in with SSH.......
>
> So the question is. what is the server ip and dns name to put in my
> firewall so it accepts the connections from Echo/IRLP and shuns the rest?
>
> I have a SSH Jump Box already setup but having those ports forwarded
> is making that pointless........
>
Just remove the port forwarding for SSH (TCP port 22 by default). 
That's only needed if you or someone else (e.g. IRLP installs team) need
to access your node remotely.  There are ways of getting in without
exposing your SSH port as well, by using VPNs or virtual LANs (e.g.
ZeroTier).  I use ZeroTier for remote SSH access (i.e. across the
virtual LAN ZT creates), because the constant bot attempts were
consuming too many resources on the low end machine, as well as filling
up log files.

IRLP only needs TCP 14525 and UDP 2074 - 2093.  Echolink needs UDP 5198
and 5199 forwarded, as per the docs.

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







Re: More Secure Port Forwarding

 

On 5/10/20 4:08 pm, Jerry Powell wrote:

I have my firewall setup to forward all the ports in the Manual....

The Problem is those ports are getting hammered with script kiddies
trying to get in with SSH.......

So the question is. what is the server ip and dns name to put in my
firewall so it accepts the connections from Echo/IRLP and shuns the rest?

I have a SSH Jump Box already setup but having those ports forwarded
is making that pointless........
Just remove the port forwarding for SSH (TCP port 22 by default). 
That's only needed if you or someone else (e.g. IRLP installs team) need
to access your node remotely.  There are ways of getting in without
exposing your SSH port as well, by using VPNs or virtual LANs (e.g.
ZeroTier).  I use ZeroTier for remote SSH access (i.e. across the
virtual LAN ZT creates), because the constant bot attempts were
consuming too many resources on the low end machine, as well as filling
up log files.

IRLP only needs TCP 14525 and UDP 2074 - 2093.  Echolink needs UDP 5198
and 5199 forwarded, as per the docs.

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


More Secure Port Forwarding

Jerry Powell
 

I have my firewall setup to forward all the ports in the Manual....

The Problem is those ports are getting hammered with script kiddies trying to get in with SSH.......

So the question is. what is the server ip and dns name to put in my firewall so it accepts the connections from Echo/IRLP and shuns the rest?

I have a SSH Jump Box already setup but having those ports forwarded is making that pointless........ 

Snip 

Oct  5 01:01:39 stn725 sshd[21187]: Received disconnect from 49.234.30.113 port 57418:11: Bye Bye [preauth]

Oct  5 01:01:39 stn725 sshd[21187]: Disconnected from authenticating user root 49.234.30.113 port 57418 [preauth]

Oct  5 01:01:40 stn725 sshd[21188]: Received disconnect from 103.39.212.96 port 39176:11: Bye Bye [preauth]

Oct  5 01:01:40 stn725 sshd[21188]: Disconnected from authenticating user root 103.39.212.96 port 39176 [preauth]

Oct  5 01:01:52 stn725 sshd[21202]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=124.127.42.42  user=root

 


Re: When I use RA or Vcon several times the node locks up have to reboot node

kd1yh
 

Just have to find out how disable vcon
 

From: David Cameron - IRLP
Sent: Sunday, October 04, 2020 2:19 PM
To: IRLP@irlp.groups.io
Subject: Re: [IRLP] When I use RA or Vcon several times the node locks up have to reboot node
 

IRLP RA will not do it, as long as IRLPvCON is disabled or not installed. The problem is when IRLPvCON or IRLPvMON is running, the parallel port is polled continually.

IRLP Remote Admin does not actually access the parallel port like IRLPvCON does. The problem is the polling that IRLPvCON does of the parallel port somehow creates a race condition with the same polling being done by the DTMF process.

Dave Cameron

On 2020-10-03 6:32 p.m., Tom E H Gruis wrote:
Thanks for the heads up.
 
On Sat, Oct 3, 2020, 19:39 kd1yh <kd1yh@...> wrote:
it does the same with RA.
Paul KD1YH node 8581


-----Original Message-----
From: David Cameron - IRLP
Sent: Friday, October 02, 2020 9:51 AM
To: IRLP@irlp.groups.io
Subject: Re: [IRLP] When I use RA or Vcon several times the node locks up
have to reboot node

Try not using Vcon and see if it still happens. There is a bug in Vcon
that was never found or fixed that can cause the parallel port to stop
responding. This in turn hangs the dtmf process and the node gets dumb
until you kill off the dtmf process.

It is something to do with irlpvcon_get (or similar). Without support
from the developer, there is nothing that can be done about it.

Funny enough, it works fine on the raspberry pi version.

Dave Cameron

On 02/10/2020 3:20 a.m., kd1yh wrote:
> When I use RA  or Vcon several times the node locks up have to reboot
> node.
> It seems not clear reset back to idle.
> home /IRlp
> Locks up can control z to get to root and reboot/ halt and restart  node.
> Paul KD1YH node 8581
>











Re: When I use RA or Vcon several times the node locks up have to reboot node

David Cameron - IRLP
 

IRLP RA will not do it, as long as IRLPvCON is disabled or not installed. The problem is when IRLPvCON or IRLPvMON is running, the parallel port is polled continually.

IRLP Remote Admin does not actually access the parallel port like IRLPvCON does. The problem is the polling that IRLPvCON does of the parallel port somehow creates a race condition with the same polling being done by the DTMF process.

Dave Cameron

On 2020-10-03 6:32 p.m., Tom E H Gruis wrote:
Thanks for the heads up.

On Sat, Oct 3, 2020, 19:39 kd1yh <kd1yh@...> wrote:
it does the same with RA.
Paul KD1YH node 8581


-----Original Message-----
From: David Cameron - IRLP
Sent: Friday, October 02, 2020 9:51 AM
To: IRLP@irlp.groups.io
Subject: Re: [IRLP] When I use RA or Vcon several times the node locks up
have to reboot node

Try not using Vcon and see if it still happens. There is a bug in Vcon
that was never found or fixed that can cause the parallel port to stop
responding. This in turn hangs the dtmf process and the node gets dumb
until you kill off the dtmf process.

It is something to do with irlpvcon_get (or similar). Without support
from the developer, there is nothing that can be done about it.

Funny enough, it works fine on the raspberry pi version.

Dave Cameron

On 02/10/2020 3:20 a.m., kd1yh wrote:
> When I use RA  or Vcon several times the node locks up have to reboot
> node.
> It seems not clear reset back to idle.
> home /IRlp
> Locks up can control z to get to root and reboot/ halt and restart  node.
> Paul KD1YH node 8581
>











Re: When I use RA or Vcon several times the node locks up have to reboot node

Tom E H Gruis
 

Thanks for the heads up.


On Sat, Oct 3, 2020, 19:39 kd1yh <kd1yh@...> wrote:
it does the same with RA.
Paul KD1YH node 8581


-----Original Message-----
From: David Cameron - IRLP
Sent: Friday, October 02, 2020 9:51 AM
To: IRLP@irlp.groups.io
Subject: Re: [IRLP] When I use RA or Vcon several times the node locks up
have to reboot node

Try not using Vcon and see if it still happens. There is a bug in Vcon
that was never found or fixed that can cause the parallel port to stop
responding. This in turn hangs the dtmf process and the node gets dumb
until you kill off the dtmf process.

It is something to do with irlpvcon_get (or similar). Without support
from the developer, there is nothing that can be done about it.

Funny enough, it works fine on the raspberry pi version.

Dave Cameron

On 02/10/2020 3:20 a.m., kd1yh wrote:
> When I use RA  or Vcon several times the node locks up have to reboot
> node.
> It seems not clear reset back to idle.
> home /IRlp
> Locks up can control z to get to root and reboot/ halt and restart  node.
> Paul KD1YH node 8581
>











Re: When I use RA or Vcon several times the node locks up have to reboot node

kd1yh
 

it does the same with RA.
Paul KD1YH node 8581

-----Original Message-----
From: David Cameron - IRLP
Sent: Friday, October 02, 2020 9:51 AM
To: IRLP@irlp.groups.io
Subject: Re: [IRLP] When I use RA or Vcon several times the node locks up have to reboot node

Try not using Vcon and see if it still happens. There is a bug in Vcon
that was never found or fixed that can cause the parallel port to stop
responding. This in turn hangs the dtmf process and the node gets dumb
until you kill off the dtmf process.

It is something to do with irlpvcon_get (or similar). Without support
from the developer, there is nothing that can be done about it.

Funny enough, it works fine on the raspberry pi version.

Dave Cameron

On 02/10/2020 3:20 a.m., kd1yh wrote:
When I use RA or Vcon several times the node locks up have to reboot node.
It seems not clear reset back to idle.
home /IRlp
Locks up can control z to get to root and reboot/ halt and restart node.
Paul KD1YH node 8581


Re: Node 6372

 

I was about to say "check your port forwarding", but you beat me to it. ;)

On 2/10/20 9:40 pm, VK3AJ wrote:

Hi All,

 

Please disregard the below.

 

I found the problem.

 

After sitting untouched for I can’t remember how long, the router had lost all it’s port forwarding.

Very strange since I’m the only one that has access.

 

Restored the router from a backup (good reason to keep backups), and everything came to life.

 

Regards,

 

Peter Chaplin

peter@...

VK3AJ

Scout Radio & Electronics Service Unit

Repeater Coordinator

0418 328 882

 

No trees were harmed in the posting of this message...however an extraordinarily large number of electrons were horribly inconvenienced.

 

From: IRLP@irlp.groups.io <IRLP@irlp.groups.io> On Behalf Of VK3AJ
Sent: Friday, 2 October 2020 21:17
To: IRLP@irlp.groups.io
Subject: [IRLP] Node 6372

 

Hi All,

 

I manage Node 6372 for Scouts Victoria, Australia.

This node runs EchoIRLP as VK3RAJ-R.

A little while back, I setup an instance of theBridge conference server as *SCOUTS-VK* and have added StartupCmd = connect VK3RAJ-R to the tbd.conf file.

 

This effectively connects the *SCOUTS-VK* conference to VK3RAJ-R permanently.

 

Apart from some times of 3rd party failures (power, internet, etc), the *SCOUTS-VK* conference server has connected to VK3RAJ-R without failure.

This appears to have changed sometime in the last 24Hrs when the conference server disconnected from VK3RAJ-R and now wont reconnect.

I’ve tested connection to the Echolink system by adding StartupCmd = connect VK3AJ, my callsign, to the tbd.conf file and it connects successfully.

The *SCOUTS-VK* conference appears in EchoLink and I can connect to it from EchoLink on any of my devices (PC, iPad, iPhone, etc)

From this, my conclusions are;

That the conference server will connect to the EchoLink servers OK.

That the conference server is not connecting to the EchoIRLP on node 6372.

 

Node 6372 is a DC supplied Raspberry Pi 3B.

 

I know that this forum doesn’t support EchoIRLP or theBridge, but I was wondering if there has been any changes pushed out to IRLP nodes in the last few days that may have unintentionally resulted in theBridge not connecting to EchoIRLP.

Obviously with JOTA not far off, I’m keen to get this back up and stable before then.

I only have basic Linux skills, so would appreciate detailed advice on how to fault find if anyone is able to assist.

Thanks in advance for any assistance anyone can provide.

 

Regards,

 

Peter Chaplin

peter@...

VK3AJ

Scout Radio & Electronics Service Unit

Repeater Coordinator

0418 328 882

 

No trees were harmed in the posting of this message...however an extraordinarily large number of electrons were horribly inconvenienced.

 


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


Re: When I use RA or Vcon several times the node locks up have to reboot node

David Cameron - IRLP
 

Try not using Vcon and see if it still happens. There is a bug in Vcon that was never found or fixed that can cause the parallel port to stop responding. This in turn hangs the dtmf process and the node gets dumb until you kill off the dtmf process.

It is something to do with irlpvcon_get (or similar). Without support from the developer, there is nothing that can be done about it.

Funny enough, it works fine on the raspberry pi version.

Dave Cameron

On 02/10/2020 3:20 a.m., kd1yh wrote:
When I use RA  or Vcon several times the node locks up have to reboot node.
It seems not clear reset back to idle.
home /IRlp
Locks up can control z to get to root and reboot/ halt and restart  node.
Paul KD1YH node 8581


Re: Node 6372

VK3AJ
 

Hi All,

 

Please disregard the below.

 

I found the problem.

 

After sitting untouched for I can’t remember how long, the router had lost all it’s port forwarding.

Very strange since I’m the only one that has access.

 

Restored the router from a backup (good reason to keep backups), and everything came to life.

 

Regards,

 

Peter Chaplin

peter@...

VK3AJ

Scout Radio & Electronics Service Unit

Repeater Coordinator

0418 328 882

 

No trees were harmed in the posting of this message...however an extraordinarily large number of electrons were horribly inconvenienced.

 

From: IRLP@irlp.groups.io <IRLP@irlp.groups.io> On Behalf Of VK3AJ
Sent: Friday, 2 October 2020 21:17
To: IRLP@irlp.groups.io
Subject: [IRLP] Node 6372

 

Hi All,

 

I manage Node 6372 for Scouts Victoria, Australia.

This node runs EchoIRLP as VK3RAJ-R.

A little while back, I setup an instance of theBridge conference server as *SCOUTS-VK* and have added StartupCmd = connect VK3RAJ-R to the tbd.conf file.

 

This effectively connects the *SCOUTS-VK* conference to VK3RAJ-R permanently.

 

Apart from some times of 3rd party failures (power, internet, etc), the *SCOUTS-VK* conference server has connected to VK3RAJ-R without failure.

This appears to have changed sometime in the last 24Hrs when the conference server disconnected from VK3RAJ-R and now wont reconnect.

I’ve tested connection to the Echolink system by adding StartupCmd = connect VK3AJ, my callsign, to the tbd.conf file and it connects successfully.

The *SCOUTS-VK* conference appears in EchoLink and I can connect to it from EchoLink on any of my devices (PC, iPad, iPhone, etc)

From this, my conclusions are;

That the conference server will connect to the EchoLink servers OK.

That the conference server is not connecting to the EchoIRLP on node 6372.

 

Node 6372 is a DC supplied Raspberry Pi 3B.

 

I know that this forum doesn’t support EchoIRLP or theBridge, but I was wondering if there has been any changes pushed out to IRLP nodes in the last few days that may have unintentionally resulted in theBridge not connecting to EchoIRLP.

Obviously with JOTA not far off, I’m keen to get this back up and stable before then.

I only have basic Linux skills, so would appreciate detailed advice on how to fault find if anyone is able to assist.

Thanks in advance for any assistance anyone can provide.

 

Regards,

 

Peter Chaplin

peter@...

VK3AJ

Scout Radio & Electronics Service Unit

Repeater Coordinator

0418 328 882

 

No trees were harmed in the posting of this message...however an extraordinarily large number of electrons were horribly inconvenienced.

 


Node 6372

VK3AJ
 

Hi All,

 

I manage Node 6372 for Scouts Victoria, Australia.

This node runs EchoIRLP as VK3RAJ-R.

A little while back, I setup an instance of theBridge conference server as *SCOUTS-VK* and have added StartupCmd = connect VK3RAJ-R to the tbd.conf file.

 

This effectively connects the *SCOUTS-VK* conference to VK3RAJ-R permanently.

 

Apart from some times of 3rd party failures (power, internet, etc), the *SCOUTS-VK* conference server has connected to VK3RAJ-R without failure.

This appears to have changed sometime in the last 24Hrs when the conference server disconnected from VK3RAJ-R and now wont reconnect.

I’ve tested connection to the Echolink system by adding StartupCmd = connect VK3AJ, my callsign, to the tbd.conf file and it connects successfully.

The *SCOUTS-VK* conference appears in EchoLink and I can connect to it from EchoLink on any of my devices (PC, iPad, iPhone, etc)

From this, my conclusions are;

That the conference server will connect to the EchoLink servers OK.

That the conference server is not connecting to the EchoIRLP on node 6372.

 

Node 6372 is a DC supplied Raspberry Pi 3B.

 

I know that this forum doesn’t support EchoIRLP or theBridge, but I was wondering if there has been any changes pushed out to IRLP nodes in the last few days that may have unintentionally resulted in theBridge not connecting to EchoIRLP.

Obviously with JOTA not far off, I’m keen to get this back up and stable before then.

I only have basic Linux skills, so would appreciate detailed advice on how to fault find if anyone is able to assist.

Thanks in advance for any assistance anyone can provide.

 

Regards,

 

Peter Chaplin

peter@...

VK3AJ

Scout Radio & Electronics Service Unit

Repeater Coordinator

0418 328 882

 

No trees were harmed in the posting of this message...however an extraordinarily large number of electrons were horribly inconvenienced.

 


When I use RA or Vcon several times the node locks up have to reboot node

kd1yh
 

When I use RA  or Vcon several times the node locks up have to reboot node.
 
It seems not clear reset back to idle.
home /IRlp 
Locks up can control z to get to root and reboot/ halt and restart  node.
 
 
 
Paul KD1YH node 8581
 


Re: Irlp ownership

Dave K9DC
 

The PGP key is assigned only to a Node Number. It is not assigned to a person or callsign.

My public key (below) appears in everyone’s node in the network (actually a compressed binary version of it), along with the public key for all other nodes, reflectors and servers. As keys are added to the network, they are sync’d to all nodes, usually within a few hours (servers and reflectors get them near immediately). Ownership of the key is determined by possession of the corresponding Secret Key, which only ever exists on your node. Basically, having my public key on your node, allows your node to access mine, essentially “unlocking” my node.

The tie in to callsigns or people, is maintained by the status page database. The status page database creates a logical connection from a node number, to a callsign, name, location, and an email address, all of which can be updated by the owner, from an authenticated public IP address. In fact that is the only way the status page can be updated.

So if node ownership changes, the number and PGP remain intact. But the responsible person, callsign, location and email address can be changed. Whoever has physical access to it, can update the records. In fact that is the ONLY way it can be updated. If someone needs to recover their number from a crash or whatever, we will only perform that recovery if the email address of the request, exactly matches the email in the database, since that information was entered by the owner him/herself. IOW, the email address becomes secondary authentication for your node. This is why keeping your information up to date in the status page is very important.

It doesn’t matter to us who “owns” any number at any particular time. The system is completely self-maintained by each node owner. We are not even notified of any changes.

-k9dc

Type Bits/KeyID Date User ID
pub 512/F86AEDDD 2003/06/20 stn4732

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia

mQBNAz7yWN0AAAECALvnXvbd5xhlKBc5C4IltBtbZaSjVVbja0Sd2I8wMl7BkC+5
5G9ZkciMbDBlYFvEFeiW5Xn3qPCS39RCIfhq7d0ABRO0B3N0bjQ3MzKJAFUDBRA+
8ljd39RCIfhq7d0BAVSBAf9eU1w3C7/hJTBcCQQK2H7Jn1BLPIPnCUDv4sHip0yO
WG9c96BzN4Ztw+dK6QaEfS3RNOAx7hICTFIcg1MwBzzK
=KBkP
-----END PGP PUBLIC KEY BLOCK-----

On Oct 1, 2020, at 15:13, k9dc <dave@dcg.us> wrote:


You can change everything in the database, callsign, name, city. lat/lon and most importantly the email address associated with the node. You would never need to change the PGP key. The PGP key is tied only to the node number which would not change.

-k9dc

On Oct 1, 2020, at 14:34, Ray - KF6OJE <rtorella@email.com> wrote:

The Update DB info is for your existing IRLP information only, not to change node ownership. You can change your callsign, lattitude longitude, City Name, etc. Not for changing the IRLP key assigned to original purchaser.


Re: Irlp ownership

Dave K9DC
 

You can change everything in the database, callsign, name, city. lat/lon and most importantly the email address associated with the node. You would never need to change the PGP key. The PGP key is tied only to the node number which would not change.

-k9dc

On Oct 1, 2020, at 14:34, Ray - KF6OJE <rtorella@email.com> wrote:

The Update DB info is for your existing IRLP information only, not to change node ownership. You can change your callsign, lattitude longitude, City Name, etc. Not for changing the IRLP key assigned to original purchaser.


Re: Irlp ownership

Dave K9DC
 


On Oct 1, 2020, at 12:35, Ray - KF6OJE <rtorella@email.com> wrote:

Thats ok Dave. Just let me know if John pulls the plug. I have my own IRLP node assigned and could transfer it to your Nano
73
Ray Torella KF6OJE
I assume you meant this message for me? I am confused. We would have no idea if John “pulls the plug.” No one in IRLP is ever aware any of ownership changes. All you have to do is update the status page database. The instructions to do that are at http://irlp.net/owners/dbupdates.html and is posted throughout the web site and the documentation. This can be done by anyone that has physical possession of the hardware, That could be the seller or the buyer. We (Installs team) cannot do this for you, even if we wanted to, since we do not have your hardware. No one is even aware the change has occurred. Totally self service.

Simply connect the node to the Internet, the node authenticates itself to IRLP using the installed PGP key. Once the node is authenticated, the status page can be updated from any browser on that same public IP address. This includes the built-in Linux text based web browser “lynx”

If your node is using a VPN (IRLP VPN or any other vendor) to get on the Internet, you may have to temporarily drop the VPN to authenticate from your local public address, long enough to update the database. Turn the VPN back on to return to normal operation.

The main data element used for ownership is the owner’s email address. We suggest you use an address you use for routine correspondence and not an alias or forwarding address (like arrl.net or other club address). This will speed up requests for security related support, such as node number recovery, or IRLP VPN requests.

Disappointingly there is no support for the Micro-node Nanonode products. The company has gone out of business and support for their products is sketchy at best. The Nano runs the long obsolete Debian Wheezy, with no upgrades possible. But the status page database update process is the same as any other node, except that you may not be able to log in to the Nanonode to run lynx. Micro-node rarely provided customers with the password to their machines.

One other recommendation for nano owners; If your node is still working, open it up, pull the SD flash out of the Raspberry Pi and make a bootable copy of it. That SD is THE ONLY SD that will ever boot up your node. The Nanonode node boot sequence includes a hard check against the hardware mac address of the ethernet port. If the check does not pass, the boot is stopped. I have no idea why Micronode made their support vector impossible to get around.

I have tried to help a local friend with one, but making a very long story short, it is not possible to boot up a nanonode with an SD from any other node. Since their hardware (board) is proprietary it is also not possible to perform a standard installation on it and have it work. Basically Nano owners are pretty screwed without factory support.

-k9dc


Re: Irlp ownership

Ray - KF6OJE
 

The Update DB info is for your existing IRLP information only, not to change node ownership. You can change your callsign, lattitude longitude, City Name, etc. Not for changing the IRLP key assigned to original purchaser.

 
 
Sent: Thursday, October 01, 2020 at 11:08 AM
From: "Gary - AG0N" <mcduffie@...>
To: IRLP@irlp.groups.io
Subject: Re: [IRLP] Irlp ownership


> On Oct 1, 2020, at 04:45, k9dc <Dave@...> wrote:
>
> The link I posted was taken directly from the home page “Update DB info.”

Interesting. Those of us who don’t frequent the pages might not associate “Update DB info” to changing ownership. At least I wouldn’t. Obviously, that is the place to put the info, but a more descriptive explanation would help.

Some of us are dense to begin with, and some of us are both OLD and DENSE!

;-)

For that matter, I’m not sure my page covered it either. If I can ever get access to it again, I’ll check and add. It’s getting pretty obsolete anyway.

Gary - AG0N



 


Re: Irlp ownership

Gary - AG0N
 

On Oct 1, 2020, at 04:45, k9dc <Dave@dcg.us> wrote:

The link I posted was taken directly from the home page “Update DB info.”
Interesting. Those of us who don’t frequent the pages might not associate “Update DB info” to changing ownership. At least I wouldn’t. Obviously, that is the place to put the info, but a more descriptive explanation would help.

Some of us are dense to begin with, and some of us are both OLD and DENSE!

;-)

For that matter, I’m not sure my page covered it either. If I can ever get access to it again, I’ll check and add. It’s getting pretty obsolete anyway.

Gary - AG0N


Re: Irlp ownership

Ray - KF6OJE
 

Thats ok Dave. Just let me know if John pulls the plug. I have my own IRLP node assigned and could transfer it to your Nano
 
73
 
Ray Torella KF6OJE

 
 
Sent: Thursday, October 01, 2020 at 4:33 AM
From: "k9dc" <Dave@...>
To: IRLP@irlp.groups.io
Subject: Re: [IRLP] Irlp ownership

I don’t know what to say. I am sorry you didn’t get it.

-k9dc


> On Oct 1, 2020, at 07:07, John <gielisj@...> wrote:
>
> Thanks Dave, but I must disagree..
> I have just clicked on the link you provided.
> There is no explicit mention of any instructions for a irlp node being transferred from one ham to another on that page, unless it's hidden in small print!
>
> I'm pulling the curtain down tonight.
> 73 John
>
> On 1/10/2020 8:45 pm, k9dc wrote:
>> The link I posted was taken directly from the home page “Update DB info.” It is also the very first item in the owners FAQ. It should be pretty obvious. Sorry you guys missed it.
>> -k9dc
>>> On Oct 1, 2020, at 06:38, Brian Smith <k9bps@...> wrote:
>>>
>>> I don’t disagree. I looked both pages over twice before I asked
>>>
>>> Brian Smith
>>>








 


Re: Irlp ownership

Dave K9DC
 

I don’t know what to say. I am sorry you didn’t get it.

-k9dc

On Oct 1, 2020, at 07:07, John <gielisj@westnet.com.au> wrote:

Thanks Dave, but I must disagree..
I have just clicked on the link you provided.
There is no explicit mention of any instructions for a irlp node being transferred from one ham to another on that page, unless it's hidden in small print!

I'm pulling the curtain down tonight.
73 John

On 1/10/2020 8:45 pm, k9dc wrote:
The link I posted was taken directly from the home page “Update DB info.” It is also the very first item in the owners FAQ. It should be pretty obvious. Sorry you guys missed it.
-k9dc
On Oct 1, 2020, at 06:38, Brian Smith <k9bps@mail.com> wrote:

I don’t disagree. I looked both pages over twice before I asked

Brian Smith

921 - 940 of 78750