|SE QLD Linked Repeater Net
|The Knobby Ipswich
|Brisbane QLD QG62nk
|Redlands Coast, Qld
|Booral, Fraser Coast [Svx]
|Craignish Fraser coast
This page provides for extensive searches of Echolink Nodes. It also provides an export facility to Google Maps.
EchoLink Link Status
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:
|Date Registered (UTC)
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.
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
Address type IPv4 ASN 47610 - RWTH-AS ISP Achses Organization RWTH Aachen University
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.
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
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: