Buster is a macOS application for ham radio written by Jeremy McDermond, NH6Z, that allows Mac users to connect to the D-STAR network without a radio. It works with the ThumbDV™ USB dongle on the local machine or a network connected PiDV™ device (formerly DV3000).
Last fall, I noticed that Buster started to work erratically and wouldn’t connect to many reflectors. The good folks on the D-STAR Roundtable net indicated they were experiencing the same thing, and for many months the application was basically unusable. Finally at the end of May, the Buster 1.1 update was released through the app store.
The good news is that, functionally, Buster 1.1 appears to be working well on Sierra. I don’t remember all the specific problems with it, but I successfully tested connecting, transmitting, and receiving on REF, XRF/XLX, and DCS reflectors. I’m unable to test using a networked PiDV, so this just applies to a ThumbDV connected locally.
The bad news is that the host file still has problems. It’s more up to date than it was, but at least some of the addresses are (very) stale, and there are a lot of IP addresses being used instead of hostnames, which begs for bad links. This is the old “which hosts file is authoritative?” issue, but with a twist…
A look at the issue tracker for Buster on github reveals that the host file data is coming from ar-dns.net, a service intended to be a centralized host file and DNS lookup provider for all things D-STAR that, in turn, gets its data from various unmentioned sources. It’s a project by K7VE, the designer of STARnet. It looks like a nice system and cool project, but the source of the XRF and XLX addresses is problematic.
This means there will be some problems connecting from Buster. There already are.
Case in point: I host XRF010 and XRF011, both of which are XLX reflectors. Both have been up and listed in the Kings of Digital host file, on xrefl.net, and the automatic XLX Reflectorlist since late last year. They were submitted with hostnames and never bare IP addresses.
Buster’s hosts file, now derived from ar-dns.net, has both of these x reflectors listed twice – once as XLX and once as XRF – which is great. However, all four entries use IP addresses instead of hostnames. The IP address for XLX010 has never needed to change, so the XRF010 and XLX010 entries both work in Buster for now. But, XLX011 moved to a different server over a month ago and had to change its IP address, 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.
What’s not new is that Buster uses an XML-formatted host file. This is probably the right thing to do in Objective C, but it means there’s no easy way to do a quick copy/paste of the entire reflector list from a more current data source. So reflectors that won’t connect require investigation by the user on a case-by-case basis, and the individual addresses then need to be updated directly in the xml file. Somebody could easily script a little utility that pulls down the KD host file and converts it to xml for Buster, but the fix really should be with ar-dns.net’s data — ar-dns.net could be the solution to this and many other related D-STAR problems (provided it is a robust system with redundancy), but the data needs to be sourced better, as mentioned above.
Even if the ar-dns.net data gets straightened out, Buster doesn’t have the ability to download host file updates on demand, a la DStar Commander, so host file updates will continue to be dependent on Buster’s author pushing app updates through the app store.
Hopefully this doesn’t sound like I’m complaining. I’m very happy that somebody took their own time to create a solid macOS D-STAR client, and I don’t personally have a problem changing host addresses when needed – it works well for me. I’m just pointing out some issues that could easily trip some users up, and they have more to do with the ongoing host file issue than with Buster itself.