Buster 1.1 for D-STAR on macOS

BusterBuster is a macOS application for ham radio written by Jeremy McDermond, NH6Z. It allows you to connect to the D-STAR network without a radio. Buster works with the ThumbDV™ USB dongle on your local computer, or over a network-connected PiDV™ device (formerly DV3000).

Last fall, Buster started producing some new glitches. Most notably, connections to many of the reflectors were failing. Hams on the D-STAR Roundtable net were starting complaining about the same thing, and for many months after, it was basically unusable. Finally, at the end of May, the 1.1 update was released through the app store.

The good news is that, functionally, Buster 1.1 is working well on Sierra. I successfully tested connecting, transmitting, and receiving on REF, XRF/XLX, and DCS reflectors. I don’t have a networked PiDV to try, so this just applies to a ThumbDV connected on the local computer.

The bad news is that the host data is still flakey. It’s more up to date than it was, but some of the addresses are still very stale. And a lot of IP addresses are being used instead of hostnames, which begs for bad links. Does this all seem familiar? Why yes, it’s the same old “which hosts file is authoritative?” issue, but with a new twist.

Github’s issue tracker for Buster shows that the host data is coming from ar-dns.net now, a centralized hostfile and DNS lookup provider for D-STAR. ar-dns.net is a nice system and a cool project, but its sources for XRF and XLX addresses are problematic.

This means that problems connecting to many reflectors from Buster will continue…

Case in point: I host two XLX reflectors, XRF010 and XRF011. They’ve been working properly and listed in the Kings of Digital host file, on the xrefl.net site, and in the automatic XLX Reflector list since late last year. And they were always submitted with hostnames. Never bare IP addresses.

Buster’s host data, now derived from ar-dns.net, has both of these x reflectors listed twice—once as XLX and once as XRF. And that’s great. However, all four entries use IP addresses instead of hostnames. The IP address for XLX010 has never changed, so the entries for XRF010 and XLX010 both work—for now. But, XLX011 moved to a different server last month and the IP address had to change. So it’s already broken in Buster. Additionally, the entry for XRF011 is a long-outdated IP that resolves to a host in Germany. So XLX011 won’t connect using either XRF011 or XLX011, and for two entirely different host file related reasons. Crazy.

Old problems…

Buster uses an XML-formatted file to store the host file addresses. No argument that it’s the right thing for an Objective C program to do, but there’s no easy way for you to quickly copy and paste the entire reflector list from a more current data source. So reflectors that can’t connect require you to investigate them on a case-by-case basis. Then you have to update the individual addresses by hand directly in the xml file. I suppose you could script a little utility that pulls down the KD host file and converts it to xml, but Buster could easily change how it does things down the road and render your work useless. No, the fix should be with ar-dns.net’s data sources.

Even if the ar-dns.net data gets straightened out, Buster doesn’t have the ability to download host file updates on demand. So host file updates will continue to be dependent on Buster’s author pushing app updates through the app store.

I don’t mean to complain. I’m happy that somebody took the time to create a solid macOS D-STAR client, and I don’t mind changing host addresses by hand at all. I just want to point out some issues that could easily trip you up—issues that are often hard to pinpoint among so many moving parts.

And really, these problems have more to do with the ongoing host file issue than with Buster itself. The host file dilemma continues to be a challenge for open source D-STAR developers and it drives me crazy that it lingers on. Certainly ar-dns.net could be the solution to this and many other similar D-STAR problems, assuming that it’s a robust system with redundancy. Even so, the data needs to be sourced better. Somehow.