Over the last few weeks, you may have noticed that Echolink connections for W8WKY 147.39 MHz, N8XPK 53.17 MHz, and N8XPK 444.2 MHz have not been working correctly. When someone tried to connect to one of those systems, they would periodically receive a strange “UNAUTHORIZED” message. This was not you or your client! At some point, something changed with the Echolink servers or something in between our services such that it was not working properly with the Megalink ham network that connects all the systems. After a significant amount of network-level troubleshooting, a work-around was identified and put in place on Friday, January 29th.
If you’re keenly interested in the details of the problem…. Each piece of data the crosses the Internet is called a packet. Each packet is, for historical reason, no larger than 1500 bytes. After the various metadata in a packet such as the source and destination addresses, there is 1480 bytes maximum for the actual data of the packet. Sounds simple right? Not really… due to all the various ways the Internet is connected, 1480 is a rule of thumb but a lot of connections use smaller payloads because of additional overhead such as tunnels, VPN, and all sorts of other things. The maximum size of a packet on any given connection is called the Maximum Transmission Unit or, usually, “MTU”. There is a technology called Path MTU Discovery that helps two systems figure out what the largest practical size they can use it. However not all systems can and do use it. Something changed between Megalink and the Echolink servers such that the MTU size either got smaller or Path MTU Discovery stopped working (either is as equally possible). This required changing some parameters on the Raspberry Pis that run the Echolink service to hardcode a smaller MTU so the communications can get through. If you’re really curious, the size was determined to be an MTU of 1380. Thanks for reading if you got this far.