Running multiple ASL nodes on a single machine instance (all defined in a single rpt.conf) is something that works quite well, but running multiple EchoLink nodes on a single instance has never worked – until now. Before I outline the work-around, it should be noted that this is a bug in how chan_echolink.so handles EL registration. I’m hoping someone can fix it with understanding what the actual problem is. I should note that this does not change the EL requirement of a separate external public IP for each EL node.
Problem: EchoLink requires a separate IP for each node since it will only communicate on UDP ports 5198-5199. When a station registers on the EL server, the server sets your host IP by the source IP you used to establish the connection to the EL server. In the ASL echolink.conf file, you can define multiple IP’s for multiple EL nodes ([el0], [el1], etc.) and chan_echolink will create listeners on each IP you define. The bug here is that chan_echolink makes the outbound registration request to the EL servers for each EL node defined ONLY on your first/primary internal IP address. This causes outside EL connections to only be able to communicate with your first EL node defined. Instead, chan_echolink SHOULD be binding to each separate local IP before making the registration call so your router can use the source IP to do the outbound NAT to the proper external IP.
Below is my sample configuration and how to work around this:
• Single instance of ASL running on PC (all 4 nodes in single rpt.conf, both EL nodes in echolink.conf)
• Two internal IP’s bound to Ethernet interface
• Four nodes configured with two on each IP address (not necessary for AllStar nodes, but necessary for EchoLink since it will ONLY talk on 5198/5199 UDP).
• Internal IP’s (70/72) are routed to respective external IP’s (01/02) for outbound communications.
• Ubiquiti EdgeRouter used for incoming AND outgoing NAT (a router that can perform outbound NAT is required)
The trick to getting this to work is to be able to have your router steer the outbound connection to the proper external IP so that the EL servers see each of your nodes at a different source IP. At first, I didn’t think this could be done since both EL nodes were originating from the same internal IP (the bug) and going out to the same EL destination. However, I came up with a way to tell which node was going outbound and have the router steer the outbound connection to the proper external IP. I was able to do this by configuring all 3 EchoLink DNS servers for [el0] (the first EchoLink node) to server3.echolink.org and all 3 DNS servers for [el1] (the second EchoLink node) set to server1.echolink.org. Even though both registration requests originate from the same internal IP (70), they are now trying to register at different external servers, so I was able to use that destination address to create a router rule that said to use outbound external IP 02 for any traffic to server1.echolink.org. SUCCESS!!
Long term solution is to have it fixed in the code for chan_echolink to use the proper IP binding for the outbound registration.