Echolink

1. Echolink Nodes in Queensland
2. EchoLink Link Status
3. Echolink Callsign Registration and Validation
4. History of EchoLink
5. TCP/IP Ports and Firewall Considerations
6. CQiNet
7. Echolink Proxy Protocol
8. How Ecolink implements UDP Connections
9. Real-Time Transport Protocol (RTP)
10. svxLink Overview
11. FireWall Port Forwarding
12. EcholinkPlus
13. References
14. pfsense

Echolink Nodes in Queensland

EchoLink Link Status

This page provides for extensive searches of Echolink Nodes. It also provides an export facility to Google Maps.

EchoLink Link Status

[Top][Home]

Echolink Callsign Registration and Validation

All access to the Echolink "network" is controlled by a validation database. You are required to provide proof of license. Several way are offered to validate.

The following screen allows for amateur radio operators to validate their callsigns: https://secure.echolink.org/validation

Results of my searches:

Callsign suffix meaning. Note this is only a conventions and not a fixed rule. Some clubs that have two Echolink Nod/es will use "-L" for one and "-R" for the other.

• -R indicates that you have connected EchoLink to a rig tuned to the frequency pair of a local repeater
  (or connected directly to a repeater)
• -L indicates it is tuned to a simplex frequency. Commonly used as a private node.

History of EchoLink

Real-Time Transport Protocol (RTP) Parameters:
https://vkradio.com/linkcomp.html

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

[Top][Home]

TCP/IP Ports and Firewall Considerations

• Listening means that the port isn't protected by a firewall or the firewall allows inbound traffic
  to there and that there is a service listening on that port
• Filtered means that there may be or may not be a service listening to that port but the firewall
  is denying inbound traffic
• Closed means that the port isn't protected by the firewall and but there is no service/application
  listening on that port
• Open means it is available to the outside with a service application is listening.
  If it isn't, it will show as "closed" on nmap scans.

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

CQiNet

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.

Source
https://secure.echolink.org/firewall-friendly.htm



[Top][Home]

Real-Time Transport Protocol (RTP)

svxLink Overview

FireWall Port Forwarding

Port forwarding for Echolink does not work with: iptables -A PREROUTING -t nat -i eth0 -p udp --match multiport --dport 5198,5199 -j DNAT --to 192.168.8.101

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

Port based routing in Linux:
https://www.sparksupport.com/blog/2010/10/02/application-based-routing-in-linux_port-based-routing/

TCP 3-Way Handshake (SYN, SYN-ACK,ACK):
https://www.guru99.com/tcp-3-way-handshake.html

[Top][Home]

EcholinkPlus

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

EcholinkPlus:
http://www.alximedia.de/df2nu/inhalt4a.htm



[Top][Home]

References

pfsense

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.