Echolink Setup

Echolink requires 5200/tcp, 5198/udp, and 5199/udp ports to be open.
The application test shows that they fail but this appears to be a false report
as the application works well despite the reported errors. This maybe a result of
running the application in wine emulation on Ubuntu Linux.

Uncomplicated Firewall (ufw): - A good tutorial on UFW

The terms to describe a ports state are confusing. Here is a summary of their meanings:
The "netstat -atnp" command does not show 5200, 5298, 5199 ports as open.

The nmap command shows the ports as closed.

The command "nc -l port-no" will run a "service" on the port and as there is now a
service "listening" on the port an nmap scan should show the port as open.

Opening the ports required for Echolink to operate is one issue, but a far bigger issue appears
to be obtaining a reliabale proxy server.

Echolink worked fine this morning, 9th April 2018, on both the Laptop and the Android phone.
Now, four hours later neither will connect! Still using the Optus Hauwei E5186s-61a wireless modem.
The log on the Laptop shows "2018-04-09 12:51:23 ConnectAttemptFailed VK4RBS-R Timed out."

A browser search of reveals the following:

Address type	IPv4   
ASN	47610 - RWTH-AS
ISP	Achses
Organization	RWTH Aachen University

Maybe this proxy server was not responding.


Qtel- A Native Linux Echolink Client

Qtel v1.2.4 - Qt EchoLink client.
Copyright (C) 2011 Tobias Blomberg / SM0SVX

Qtel, the Qt EchoLink client, is a graphical application used to access the EchoLink network and is available from:
It can be installed on Ubuntu with the linux "apt" utility by typing the following command at the terminal. At the same time make sure alsa sound driver is installed.

For testing the *ECHOTEST* node can be found under the "Conferences" heading.


History of EchoLink

Real-Time Transport Protocol (RTP) Parameters:

I have reproduced this section on Echolink:

iLINK was born in May 2001, when Graeme Barnes, M0CSH, released the first version of his Windows based Internet linking system, to provide a Windows based alternative to IRLP, with the added feature of direct connections from the Internet. iLINK was the predecessor to EchoLink.

In mid 2002, a new client program, EchoLink. written by K1RFD, arrived on the scene. Written to be compatible with iLINK, it offered several features which the original iLINK software didn't have, and EchoLink rapidly became popular. EchoLink also offered a simple means to interface a radio to the software, using a home brew interface similar to those used for PSK-31, SSTV and other computer generated modes, making gateway operation more attractive.

Some weeks after EchoLink's arrival, the iLINK and EchoLink server networks were split. While this split was intended to give people choice in whether they wanted to interace with some of the extra EchoLink features, the net result was that the iLINK users moved to EchoLink, and iLINK has very little activity. As of October 2002, iLINK appears to have gone to a closed commercial model of distribution.

In recent times, several amateurs have started work with the EchoLink protocols and have written some open source implementations of EchoLink conference server and client software. The conference server, called thebridge, though very new has proved to be extremely robust. It runs on almost any Unix like system, as well as Windows.

EchoLink has a couple of things in common with IRLP. Firstly, it allows radio connected nodes to be controlled by DTMF commands. Secondly, it uses a dedicated hardware interface board between the radio and the computer. However, at this time, the hardware control is one one way (PTT only). The received audio is still sampled by a VOX routine in the EchoLink software. Unlike the original iLINK sysop software, EchoLink also supports hardware COS detection (like IRLP) and simple PSK-31 style radio interfaces. More recently, a Linux client, EchoLinux, has been written, making EchoLink the first cross platform linking system.

EchoLink also supports both point to point and conference connections. There are access control settings which allow the user to control whether repeaters, links, PC based users or conferences are allowed to be connected to their system, or any combination of the above. EchoLink also supports access control by callsign prefix or user defined allow and deny lists. Within limits imposed by access control settings at each end, computer based users can call other computer based users, or they can call RF links and get out on air. Similarly, RF users can key in a computer user's index number and call them from the mobile. The computer interface is, for the most part, simple and well laid out, and offers very good audio quality.

On the security front, when a new user registers on the EchoLink network for the first time, they are denied access until their callsign is verified as being legitimate. Once verification is successful, then the user is issued an index number, and can log into their account from other PCs using their index number and password. There has been debate in the amateur community about the degree of authentication deemed necessary (and whether the above is sufficient) for computer access to linked systems. There have been a number of improvements to the underlying security mechanism, during the life of EchoLink.

EchoLink's computer access is a mixed blessing. On one hand, it allows one to experience Internet linking without having to setup a gateway in their local area. However, I also find it annoying being called by other computer based users and getting interrupted. When I was using iLINK, I used to only run it to make a call. Now, I run an EchoLink (actually EchoIRLP) gateway, so callers can try their luck on the radio here.

EchoLink doesn't support SWLs (except on scanners within range of a gateway), but a number of node and conference owners have setup streaming audio feeds for SWLs to enjoy.

EchoLink, like IRLP, supports sysop installed scripts, which allow the functionality of EchoLink to be extended in any way. The limitation is usually the imagination of the EchoLink community. There are a large number of scripts available for sysops to install.

In summary, EchoLink offers a relatively simple way to setup an Internet link, with support for direct connections, as well as DTMF controlled RF links. I have been running EchoLink as an RF gateway for some time. It is a well behaved and stable system with good audio quality, and a good interface for both PC based and RF users. EchoLink is also under active development by both the original author and open source developers, and is the first system to support multiple platforms (currently, Windows, Macintosh, Linux and Java). EchoLink can also be supported by IRLP nodes, using the EchoIRLP add-on scripts for IRLP. The new conference server software gives EchoLink the same scalability as IRLP reflectors, enabling large nets (limited only by available bandwidth) to take place on the system.

Source: Tony Langdon, VK3JED



Echolink Proxy Protocol



How Ecolink implements UDP Connections

A: There are two parts to it. The first is simple; Echolink uses the same ports (5198 and 5199) for both source and destination when it sends UDP packets. In the early days, it used dynamically-assigned source port numbers. Most types of NAT routers will establish a "flow" when they see a request and a corresponding response with precisely reversed addresses (including port number), allowing other unsolicited packets to be received over the same "flow" within a certain time period. Using fixed source ports ensures that the source and destination addresses are exactly swapped in a response packet. This also avoids false triggering of denial-of-service protections built into some firewalls, which had been a problem in the past.

The second part is a way to accommodate a firewall on incoming connections. When a node initiates a connection, it sends an additional packet to its addressing server indicating that it wishes to connect to the other node. The addressing server relays this request to the receiving node, which responds by sending a pair of packets back to the initiating node to establish the "flow" described above. (Nodes maintain a UDP "flow" with the addressing server to prepare to receive these requests by sending packets to it periodically.) This works even if the two nodes are on different addressing servers, because these connection-request packets are relayed internally amongst the addressing servers as well.



Real-Time Transport Protocol (RTP)

Real-Time Transport Protocol (RTP) Parameters:


svxLink Overview


FireWall Port Forwarding

Port forwarding for Echolink does not work with:

The problem is, that the Echolink protocol expects the original sender IP and not the VPN server IP.

Port based routing in Linux:

TCP 3-Way Handshake (SYN, SYN-ACK,ACK):



This has been SVXLink but there is some interesting material on this site. The developers state:

The EchoLink standard software has certain disadvantages when operated on link stations or repeaters. For this reason, a team of authors led by R├╝diger, (DC4FS , Sysop from DB0XW) and Hermann ( DK6XH , Syop from DB0UA) has written additional software "EchoLinkPlus" based on Visual Basic scripts, which takes into account the special needs of repeaters and link stations





Based on the Icom Model: IC-F420 Mobile Radio

York Radio Club - Echolink Node Bob Lund: WB9HYB May - 2018:



Why is David Zientara talking about port 6000 in the X11 area?

We can also create rules for applications not covered by pfSense's traffic shaper wizard. For example, we may want to create a rule to prioritize traffic from EchoLink, a VoIP application that allows radio amateurs to communicate with each other. EchoLink uses ports 5198 to 6000, and uses UDP on ports 5198 and 5199, and TCP on port 6000. As a result, we will have to create two rules for EchoLink, but the process is still fairly simple:

  1. From the Floating tab on the Rules page, click on one of the Add buttons at the bottom of the page.
  2. In the Action drop-down box, select Match.
  3. In the Interface listbox, select WAN.
  4. Leave Direction set to any, so that the rule will be a bidirectional rule.
  5. Change Protocol to UDP.
  6. Set Destination port range to 5198 to 5199. You may also enter a brief description (for example, Prioritize EchoLink UDPrule).
  7. Click on the Show Advanced button and scroll down to Ackqueue/Queue.
  8. Set Queue to qOthersHigh.
  9. Click on the Save button. This will take you back to the main Floating rules page.
  10. To save time, we'll copy this rule and make a rule for port 6000.
    Click on the Copy icon on the newly created rule to make a newrule based on this rule.
  11. In the new rule, change Protocol to TCP.
  12. Change Destination port range to 6000. You may also enter a brief description (for example, Prioritize EchoLink TCPrule).
  13. Click on the Save button. On the Floating rules page, click on the Apply Changes button.

You'll probably want to check the firewall rules to make sure no existing rules conflict with the newly created ones. But as this exampledemonstrates, generating your own rules without the wizards is not necessarily difficult.

Source: Mastering pfSense by David Zientara

Glenn Lyons VK4PK
Ver:gnl2020mmdd - pre published v0.9