Date   

Re: ECHOIRLP assistance

 

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

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

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

2.  Incorrect password - make sure this is correct.

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

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

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


Re: ECHOIRLP assistance

 

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

Chris,

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

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


Re: ECHOIRLP assistance

 

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

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

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

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

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

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


Re: ECHOIRLP assistance

 

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

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

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


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


Re: Experimental nodes

 

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

Hello, Nick.

An experimental reflector has to be run from a public IP address not
shared by any IRLP nodes. This usually rules out anyone putting a
reflector on their home internet unless multiple IPs are offered which
is not very common. So what we have been doing is renting a virtual
computer for $12.50 a year (a buck a month) which comes with its own
unique public IP address. There are two major parts to our
experimental reflectors, voice and activity lists. To simply
reflect voice packets you run a tiny little program called "sfreflect"
and you are done. If you also want a list of who is keying up the
reflector and another list showing who is listening to the reflector,
I wrote some scripts to handle that. You can see an example at these
links:
There's actually multiple ways to run experimental reflectors.  I don't
use sfreflect at all.  Mine (exp0018) runs thelinkbox, which I
configured in transcoding mode.  That allows people to play with any of
the supported codecs, and as a side effect, it also works full duplex! 
My experimental reflector ended up being the prototype that allowed me
to incorporate transcoding and full duplex into regular IRLP
reflectors.  Reflector channel 9555 is setup this way, but is reachable
by a standard node.  However, to connect full duplex (other than needing
a node actually capable of running full duplex), you will need to write
a custom_decode entry to make the connection in full duplex.

My point being simply that there are many ways to create an experimental
reflector, depending on what you want to achieve. :)

If you want to have a reflector of your own, the easiest thing to do
is rent a virtual computer at virmach.com and select Debian 9 as the
operating system and they will email you a confirmation with the IP
Yes, a virtual private server is the easiest route.  You will need a
public IP for each experimental reflector.  My system now has over 200
IPs available (though the bulk are for public Echolink proxies). 
Getting so many IPs is possible for ham use under certain conditions,
but that's beyond the scope of this message. :)

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


Re: ipupdate script

Nosey Nick VA3NNW
 

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

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

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

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

Nick VA3NNW

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


Re: ipupdate script

Dave K9DC
 

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

'man dhclient.conf’ for more information.

-k9dc

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

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


Re: ipupdate script

Dave K9DC
 

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

As user repeater:
mkdir noupdate
mkdir noupdate/scripts

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

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

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

ipupdate force

-k9dc

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

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

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

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

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

Ramon AL7X 3288 3289 7254


Re: ipupdate script

Fred
 

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

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


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

David M.
WD5M

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

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

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

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

Ramon AL7X 3288 3289 7254



Re: ipupdate script

David McAnally
 

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

David M.
WD5M

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

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

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

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

Ramon AL7X 3288 3289 7254



Re: ipupdate script

Ramon Gandia
 

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

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

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

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

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

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

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

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




Re: ipupdate script

Tony
 

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

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

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

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

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


Re: Fatal Error Code 40 NODE 2803

larry_n7fm
 

Chris,

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

Larry - N7FM

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


ipupdate script

Ramon Gandia
 

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

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

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

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

Ramon AL7X 3288 3289 7254


Re: ECHOIRLP assistance

David Cameron - IRLP
 

Couple of things about EchoIRLP
1) The password needs to be uppercase IN ALL CAPS in the tbd.conf file
2) Sometimes you need to wait a few minutes after its connected and installed before it starts to work.

You will get a lot of info by typing:

killall tbd

then:

tbd -ddd

The problem is EchoIRLP is no longer maintained. It was not written by IRLP, but we do what we can to help you get it running. As Debian moves forward, some scripts need changes in order to work. Those will need to be copied and supported by others and involve the use of SOX with deprecated arguments. This was discussed a few months ago.

Dave Cameron

On 2020-06-05 9:51 a.m., Rick Bates, NK7I wrote:
Chris,
"PC based node"?  The software being discussed in this group runs under a carefully limited operating system of linux, not Windows (just to be clear).
Not being logged into the echolink network is often the incorrect user and password OR not being registered within the network; check your config file(s) carefully, each must be EXACT.
Node not exists is a symptom of not being logged into the network OR it may be an incorrect command; does the command use a 'prefix', commonly an * (star)?
The (lack of) port opening (routing) may be another issue, but for the moment assume that they're open until the above is completed.
EchoIRLP works well, but to stop the constant random connects, no users speaking, I've limited my node to accepting only a few nodes from the echolink network.
[In the future, please add your call and node number to your signature when writing this group, so local specific help can be offered.  It's 'netiquette'.]
73,
Rick NK7I
7962
N ID
On 6/5/2020 9:38 AM, Chris Pitre wrote:
I appreciate the info, I 'm trying to do the install on a PC based node.

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

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

This may be an easy process and perhaps im just overlooking the finest detail.


Re: ECHOIRLP assistance

Chris Pitre
 

Something is different between the new and the old box.

on the old box VE3TOM is on the echolink repeater list, on the new box it is not

The APRS script works

and the IRLP works.

and I hear audio

so that tells me that  something in the setup of the new box is not good.

The same ver 3 board is being used just moved from box to box.

Chris
VE3ZO

NODE 2803 


Re: ECHOIRLP assistance

Rick Szajkowski
 

That would narrow things down for sure , just make sure the ports are forwarded to the correct IP address on your lan , if both system have the same IP make sure that both are not on at the same time , would be better if the new one was not the same IP for testing ( or the old one ) 

I had a problem with Cogeco before I am now with eastlink with out problems 

Richard Szajkowski 
VA3 RZS VA3ZJ VE3BTE

On Jun 5, 2020, at 4:31 PM, Chris Pitre <ve3ctp@...> wrote:

Since I have the old computer still available I can plug it in and check to see if it works here, when the old computer was at the location it did in fact work.

IRLP
APRS Script 
and ECHOIRLP were fully functional


Re: ECHOIRLP assistance

Chris Pitre
 

Since I have the old computer still available I can plug it in and check to see if it works here, when the old computer was at the location it did in fact work.

IRLP
APRS Script 
and ECHOIRLP were fully functional


Re: ECHOIRLP assistance

Rick Szajkowski
 

Did it ever work ?? 

I would check with your ISP to see if anything changed , 

Good luck  

Richard Szajkowski 
VA3 RZS VA3ZJ VE3BTE

On Jun 5, 2020, at 4:01 PM, Chris Pitre <ve3ctp@...> wrote:

I live in Canada...my Inet provider is Cogeco, using an ARRIS router from them


Re: ECHOIRLP assistance

Chris Pitre
 

I live in Canada...my Inet provider is Cogeco, using an ARRIS router from them

941 - 960 of 78244