Buster is a macOS application for ham radio written by Jeremy McDermond, NH6Z. It lets you to connect to the D-STAR network without a radio. Hardware-wise, Buster works with the ThumbDV™ USB dongle on your local computer, or over a network-connected PiDV™ device (formerly DV3000).
Last fall, Buster started to malfunction. Connections to many of the reflectors were failing and it had become a regular topic on the D-STAR Roundtable. Finally at the end of May, a fix was released through the app store.
Functionally, the Buster 1.1 update is working well on Sierra. I can connect, transmit, and receive on most REF, XRF/XLX, and DCS reflectors.
The bad news is that the host data is still inaccurate. It’s more current than before, but a lot of host addresses are still out-of-date. And IP addresses are often used in place of hostnames. Does this all sound familiar? It’s the same old “which host file is authoritative?” issue, but with a new twist…
Github’s issue tracker for Buster shows that the host data is now coming from ar-dns.net, a centralized host file and DNS lookup provider for D-STAR. ar-dns.net is a nice system, but its sources for XRF and XLX addresses are problematic.
Many connections will continue to fail…
As an example, 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 submitted with host names, not bare IP addresses.
So, Buster’s host data, now derived from ar-dns.net, has the 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 XRF010 and XLX010 both work—for now. But, XLX011 recently moved to a different server and its IP address changed. So it’s already broken in Buster. Additionally, the entry for XRF011 has a long-outdated IP that resolves to a host in Germany. This means that XLX011 won’t connect using either XRF011 or XLX011, and for two entirely different reasons. Crazy.
Old problems…
Buster uses an XML-formatted file for the host addresses. That’s good for an Objective C program, but there’s no easy way for you to quickly copy and paste the entire reflector list from a more current data source. So errant reflector addresses must be investigated on a case-by-case basis, and then you have to update the individual addresses by hand in the xml file. You could script a utility that downloads and converts host files to xml, but Buster could change its processes down the road and render that 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 can’t download host updates on demand. So host updates will remain dependent on app store updates.
I don’t mean to complain…
It’s nice that somebody took the time to create a D-STAR client for the Mac. And I don’t mind changing host addresses by hand. I just want to point out issues that could easily trip you up—issues that can be hard to pinpoint with so many moving parts.
And really, these problems have more to do with the ongoing host file issue than with Buster itself. ar-dns.net is encouraging though—it could be the solution to this and other D-STAR problems, assuming that it’s a robust system with redundancy. Even so, the data needs to be sourced better.
