Ok! For you and others - I am still not sure the new version is bugfree. I made some more changes and the latest version is now on the site with date Mar 24 at 17:28 UTC so you probably already have that. But I am still on the lookout for possible issues caused by the rewrite. Never touch the code when it is working :-) There is a proxy N9MUF-FENDER that I assume is running as a test but it fails to work from here in a way that is worrying and that I cannot reproduce on my own servers or a Pi that a fellow amateur installed. Hopefully I can work out with him what is going wrong. But your proxies do not show that same problem... Should you or others notice any problem please mail me at rob@pe1chl.nl

Rob

On 3/24/21 10:24 PM, Dan Keizer via 44Net wrote:

Hi Rob - thanks for the update. I used that to restart our servers at our new data center. Already serving up proxies and relays.

73 Dan, ve4drk

Hi Toussaint,

I will explain things here on the list as there may be other people wondering about this...

The package you can download at https://pe1chl.nl/Softw/elproxy.tar.gz includes a README file and a configuration example.  You can also look on the original Echolink.org site for the Java proxy and its documentation, this proxy has nearly the same configuration and of course the same usage scenario.  See https://secure.echolink.org/proxy.htm

An echolink proxy server is a connection between a TCP session at the user side and a pair of UDP ports at the proxy.  This has been invented because Echolink requires 2 UDP ports to be open to the public (5198 and 5199) to be able to receive incoming connections from other users.  As users often are behind firewalls or NAT that they do not manage, the proxy server is used to move the UDP ports outside the own network and use only a single outgoing TCP connection which normally passes through NAT and firewalls without issue.

Each proxy server can be used only by a single user at a time, and it requires its own static IP address on the internet, without NAT.  So you can usually cut some space out of a 44.190 allocation (or just any allocation) and run several proxy servers.  We run 230 proxy servers on 44.137.75.x, and several other networks already offer proxy servers in the 44.190 space. See http://echolink.org/proxylist.jsp for a list of currently active proxies and their busy status. A proxy server, when configured and running, automatically registers itself in that list.

A relay server is a kind of "proxy server light" that was invented for use by the echolink app on mobile devices.  It has some restrictions:

- users of a relay can only make outbound connections, you cannot connect someone behind a relay

- only one of all users of the same relay can connect to the same destination

As a big benefit, a relay can have multiple users so a single relay, occupying a single external IP address, can serve many of those mobile users.  We are running 10 relay server instances which typically have 40-50 users each.  But they consume only 10 IP addresses instead of 500. The echolink software detects conflicts when you want to connect someone who is already connected by another user of the same relay, and hops over to another relay.  That is the reason it still is useful to run e.g. 10 relays on a single site, e.g. when several users want to connect to a popular repeater.

A relay server requires manual registration at Echolink.  There is a geo-aware DNS service for the domain name relay.echolink.org and it returns a number of IP adresses of available relay servers, depending on the approximate location from where the request was made. (unless you use a VPN to the other side of the world or a DNS resolver somewhere else, of course) The mobile app picks a number of these addresses, sends a ping to each of them, and then connects to the relay that responds the quickest.

Normally you would first gain some experience with proxy servers, maybe setup the relays and use a trick to let relay.echolink.org resolve to your own relay servers locally on your network, and when it all works and you still want to do this you can contact the admin to suggest adding your relay servers to the pool. (our 10 relays consume about 150GB/month of data traffic so make sure that is no problem)

For all of this, software released by Echolink already exists.  But it is written in Java and each instance of the program can only serve 1 proxy.  My software is different in that it is written in C and a single instance of the program can serve hundreds of proxies and many relays, provided that the machine where it runs has many IP addresses on its network device (I use a separate dummy0 interface where I add all the IP addresses in a startup script).  The total resource consumption (memory and CPU) of our 230proxy+10relay service is much less than even a single instance of the Java software :-) (about 3MB memory and 3-5% of a single core of a Xeon CPU E5-2667 v3 @ 3.20GHz)

I have been running these proxies for about 5 years and often the process has run for well over a year.  In the 1.2.4c version I have had some stability problems but it looks like they now are under control.   I have not changed the software version number to track each change, as originally all proxies had the version 1.2.3 (of the Java version) and I changed that to 1.2.3c for my C version.  Now there is version 1.2.4c but it would actually have been better to increment the version at each change.  I did not do that because I was unsure if there would been issues with that in the network (I know that there are issues when the version number of the clients is changed, because the server changes behavior depending on client version number...).  However, the Echolink admin has recently confirmed there is no such issue with the proxy/relay version, so I will likely just increment it in the future.   The file date of the .c file is now Apr 6, 2021.  When you have an older version, please re-download it.

I also have been trying to add it to the GIT repository recently discussed, but I have encountered difficulty when trying to synchronize the entire history instead of only the most recent version. (due to my lack of knowledge of GitLab)

I don't think there is a dedicated mailing list, I am in direct contact with the Echolink author/admin when I have questions.  But to run relays that is not required, you can just install the program, configure it, and provide the proxies which will automatically be used.

Rob

On 4/15/21 3:31 PM, Toussaint OTTAVI via 44Net wrote:

Le 24/03/2021 à 09:15, Rob PE1CHL via 44Net a écrit :

...

I have released a new version 1.2.4c of my Echolink proxy/relay software, which is now available on my websitehttps://pe1chl.nl/%C2%A0 ashttps://pe1chl.nl/Softw/elproxy.tar.gz

Hi Rob,

I have quite no experience with Echolink. But as far as users seem to enjoy this mode, I'd like to install a local relay and/or proxy on our 44.190 IP range. Do you have some documentation about how to setup a relay / proxy ? Do I need both ? Can the same software do both ? Do I need several instances of each ?

I know it may be a little bit off-topic here. Is there a dedicated mailing-list about Echolink sysop / server administration ?

Thank you in advance.

73 de TK1BI

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

On 4/16/21 7:58 AM, Toussaint OTTAVI via 44Net wrote:

Le 15/04/2021 à 18:15, Rob PE1CHL via 44Net a écrit :

...

I will explain things here on the list as there may be other people wondering about this...

Wow ! What can I say more than : "Thank you very much" :-) You provided in one message all the answers I didn't find in the Echolink documentation, HI :-)

In fact, I never managed to get my personal callsign registered at Echolink, and that's one of the reasons reason why I don't really enjoy "closed source" and "closed networks" :-) But it's just a personal opinion, HI :-) As far as some of our users do enjoy Echolink, my job is to provide network access :-)

Well I deliberately did not touch on that sensitive subject...  it is unfortunate that the system is rather closed, but it is how it is. The protocols are kind of standard (RTMP/RTCMP) and it has been reverse engineered, e.g. by SM0SVX who made the SVXlink repeater controller which has Echolink support, and also the Qtel echolink client. But they are not really the same thing, e.g. the directory server fetches by the original software are compressed and take less traffic than the SVX implementation.  I think this is determined also by the version number (the server recognizes if the client can do compression by comparing the version number).

Yesterday, when trying to troubleshoot a problem with our Asterisk / app_rpt / chan_echolink, I noticed that, when selecting "auto proxy" on the client, I was redirected to 44.190.8.180 (VK3JED), with a ping of 256ms (Hello Tony, are your proxies using "long path", HI ?)

What made me think about installing some local proxy :-)

Yes that is a bit funny, it appears the geolocation service sometimes fails dramatically.   I also have many users from all over the world on our system. The client fetches the proxy list (echolink.org/proxylist.jsp) and picks a "Ready" proxy at some small random offset near the top. Normally you should see local proxies at the top of the list.  Here I do.  But apparently this does not always work.

Anyway, reading your clear explanation, I think it would be a waste of public IPs. AFAIK, I can install some "local proxies" and point my users specifically to them. But it's not possible to make "local relays" and restrict them to my local users. And I don't have network resources for providing WW relays. Then, as far as our BGP gateway for 44.190 addresses is in Paris, and most French public ISP traffic (even from our island of Corsica) goes through Paris, it seems clever to use existing proxies/relays in Europe, and in the Netherlands (which is very near from Paris in terms of ping).

Well, in my opinion the use of a couple hundred or a few thousand of our public IP addresses for this purpose, which although it is a closed system is really an amateur radio related application, is not too bad.  Of course when you have a 44.190/24 network and you use it for other things as well it may be that way, but we use 256 out of our 65536 addresses in 44.137.0.0/16 and I think that is fine.  Even in 44.190 I think you could apply for another /24 when you would desire to do that. However, there already are quite some proxies these days (it was quite different before I made this software, there were not many of those sites with 200 proxies because that required a ridiculous amount of resources, still there are some who apparently are not aware of the alternative). Running "local relays" is only possible when you can run a DNS for them, which usually is impractical on internet and while it is possible to do that on net-44 it is not very useful because there your users can work without NAT when they desire and thus require no relay or proxy.

Then, the remaining question is : When using Echolink Android client, and selecting "Auto proxy" settings, why does it select VK3JED and not PE1CHL ?

See above.  I think it is a failure of the geolocation.  That can be either because you or VK3JED are not "correctly" registered in Maxmind or because it was updated recently and Echolink has not loaded that update yet (one needs to download a database at some interval, it is not a dynamically queried system). When I started routing 44.137.0.0/16 on internet, I filled in some form at Maxmind and some weeks later the location was correctly registered in their system.  But that was over 5 years ago and by now that location has propagated everywhere.

Rob

On 16/4/21 6:44 pm, Rob PE1CHL via 44Net wrote:

On 4/16/21 7:58 AM, Toussaint OTTAVI via 44Net wrote:

...

Le 15/04/2021 à 18:15, Rob PE1CHL via 44Net a écrit :

...

I will explain things here on the list as there may be other people wondering about this...

Wow ! What can I say more than : "Thank you very much" :-) You provided in one message all the answers I didn't find in the Echolink documentation, HI :-)

In fact, I never managed to get my personal callsign registered at Echolink, and that's one of the reasons reason why I don't really enjoy "closed source" and "closed networks" :-) But it's just a personal opinion, HI :-) As far as some of our users do enjoy Echolink, my job is to provide network access :-)

Well I deliberately did not touch on that sensitive subject...  it is unfortunate that the system is rather closed, but it is how it is. The protocols are kind of standard (RTMP/RTCMP) and it has been reverse engineered, e.g. by SM0SVX who made the SVXlink repeater controller which has Echolink support, and also the Qtel echolink client. But they are not really the same thing, e.g. the directory server fetches by the original software are compressed and take less traffic than the SVX implementation.  I think this is determined also by the version number (the server recognizes if the client can do compression by comparing the version number).

...

Yesterday, when trying to troubleshoot a problem with our Asterisk / app_rpt / chan_echolink, I noticed that, when selecting "auto proxy" on the client, I was redirected to 44.190.8.180 (VK3JED), with a ping of 256ms (Hello Tony, are your proxies using "long path", HI ?)

What made me think about installing some local proxy :-)

Yes that is a bit funny, it appears the geolocation service sometimes fails dramatically.   I also have many users from all over the world on our system. The client fetches the proxy list (echolink.org/proxylist.jsp) and picks a "Ready" proxy at some small random offset near the top. Normally you should see local proxies at the top of the list.  Here I do.  But apparently this does not always work.

...

Anyway, reading your clear explanation, I think it would be a waste of public IPs. AFAIK, I can install some "local proxies" and point my users specifically to them. But it's not possible to make "local relays" and restrict them to my local users. And I don't have network resources for providing WW relays. Then, as far as our BGP gateway for 44.190 addresses is in Paris, and most French public ISP traffic (even from our island of Corsica) goes through Paris, it seems clever to use existing proxies/relays in Europe, and in the Netherlands (which is very near from Paris in terms of ping).

Well, in my opinion the use of a couple hundred or a few thousand of our public IP addresses for this purpose, which although it is a closed system is really an amateur radio related application, is not too bad.  Of course when you have a 44.190/24 network and you use it for other things as well it may be that way, but we use 256 out of our 65536 addresses in 44.137.0.0/16 and I think that is fine.  Even in 44.190 I think you could apply for another /24 when you would desire to do that. However, there already are quite some proxies these days (it was quite different before I made this software, there were not many of those sites with 200 proxies because that required a ridiculous amount of resources, still there are some who apparently are not aware of the alternative). Running "local relays" is only possible when you can run a DNS for them, which usually is impractical on internet and while it is possible to do that on net-44 it is not very useful because there your users can work without NAT when they desire and thus require no relay or proxy.

...

Then, the remaining question is : When using Echolink Android client, and selecting "Auto proxy" settings, why does it select VK3JED and not PE1CHL ?

See above.  I think it is a failure of the geolocation.  That can be either because you or VK3JED are not "correctly" registered in Maxmind or because it was updated recently and Echolink has not loaded that update yet (one needs to download a database at some interval, it is not a dynamically queried system). When I started routing 44.137.0.0/16 on internet, I filled in some form at Maxmind and some weeks later the location was correctly registered in their system.  But that was over 5 years ago and by now that location has propagated everywhere.

I filled out the relevant forms at several geolocation services, but while the services themselves updated fairly quickly (for the most part), Echolink seemed to take a lot longer for some reason.  Mine's going through VK4 ATM.  Will try restarting my proxy server.

Nope, still VK4, but my private proxy is working properly. :)

On 17/4/21 1:11 am, Rob PE1CHL via 44Net wrote:

The issue with using Maxmind is that they generate a database I think every two weeks and then the user has to download those to their server and use it e.g. in this case for sorting the proxylist appropriately.  Maybe the downloaded copy is out of date, I can ask about it.  How long ago did you update that location info?

Umm, a few years ago now.

Restarting the proxy does not change that, it is determined by the server at Echolink.

The restart was in case it actually wasn't working. :)

That should be different for the relay service, I think the geolocation of that is done by AWS using some standard "geo-aware DNS service" that echolink uses.  Thus the updating of the location database is done by AWS.

Well, Echolink on my phone doesn't seem to want to use my proxies, even though they should be the closest (both geographically and topologically).

On 4/16/21 10:15 AM, Tony Langdon via 44Net wrote:

Your software is great, though sometimes, individual proxies seem to die for no apparent reason (even after waiting for any dropped connection to time out).

There has been a bug like that, but it was fixed Jun 27, 2018 thanks to a patch by Jann DG8NGN.  After that, I have not seen it anymore. I admit it is confusing that there have been updates without changing the version number, so they went on unnoticed.

The new 1.2.4c version had some bug that lead to crashing but after several fixes it now has run for 10 days without issue.  Of course that never means it is bugfree now... I did a major overhaul to change the use of select() to epoll() which should be more efficient when a large number of sockets is open (many proxies). But inevitably there are some oversights when making such a drastic change.

Rob

On 4/16/21 1:28 PM, Tony Langdon via 44Net wrote:

Guess I'll have to upgrade at some stage.  Where's your repo?

The repo is not done yet (I do not understand that GitLab thing, I tried to import my git repo but it won't do it). But the latest version can be downloaded from my website: https://pe1chl.nl/Softw/elproxy.tar.gz

Rob