Buster 1.1 on macOS Sierra
Jun 11, 2017 0:48:39 GMT -8
Post by n8qq on Jun 11, 2017 0:48:39 GMT -8
I haven't been able to listen to the net directly lately and I'm just catching up on the podcasts this evening. It sounds like there haven't been any responses to the Buster queries on the net for two weeks running, so I assume the topic is still open. This is probably way too long winded for the shoutbox, so I'll post here.
The good news is that, functionally, Buster 1.1 appears to be working well on Sierra. It's been so long since being able to really use Buster that I don't remember all the specific problems now, but I successfully tested connecting and tx/rx-ing on REF, XRF/XLX, and DCS reflectors. I'm unable to test using a networked dv3000, so this just applies to a USB ThumbDV connected locally.
The bad news is that the host file 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 lots of breakage. It's the old "which hosts file is authoritative?" issue, but with a twist...
A look at the issue tracker for Buster on github reveals the host data source: github.com/mcdermj/buster/issues/47
It's coming from ar-dns.net, 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 - a project by K7VE, the designer of STARnet. Maybe you all already knew about this system, but it's news to me. It's a nice system and cool project, but where and/or how he's sourcing the XRF and XLX addresses is problematic, imo.
This means there will be some problems connecting from Buster.
Case in point: I host XRF010 and XRF011, both of which are XLX reflectors. Both have been up and listed in the KD host file, on xrefl.net, and the automatic XLX Reflectorlist since late last year. They were submitted with hostnames, never bare IP addresses.
Buster's dextra 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 changed, so the XRF010 and XLX010 entries both work in Buster. But XLX011 moved to a different server over a month ago and changed IP addresses - so now it's already broken in this Buster update. Additionally, the entry for XRF011 is an 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.
It's not new that Buster uses an XML formatted hosts file, which is probably the right thing to do in Objective C, so there's no way to do a quick copy/paste update of the entire reflector list using a more current data source. Addresses of non-connecting reflectors require investigation by the user on a case-by-case basis, and individual addresses need to be updated directly in the xml file by users who are comfortable editing an xml file in the Buster application directory. Somebody could easily script a little utility that pulls down the KD host file and converts it to xml for Buster, but the fix here really should be with ar-dns.net's data sourcing.
Even when or 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 updates will still be dependent on Buster's author pushing app updates through the app store, as always.
Hopefully it doesn't sound like I'm complaining. I'm very happy that somebody took the time to create a nice macOS D-STAR client, and I don't personally have a problem changing host addresses when needed - it works well for me. Just wanting to point out the current issues, which have more to do with the ongoing host file issue than with Buster itself.
Thanks!
Brad N8QQ
The good news is that, functionally, Buster 1.1 appears to be working well on Sierra. It's been so long since being able to really use Buster that I don't remember all the specific problems now, but I successfully tested connecting and tx/rx-ing on REF, XRF/XLX, and DCS reflectors. I'm unable to test using a networked dv3000, so this just applies to a USB ThumbDV connected locally.
The bad news is that the host file 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 lots of breakage. It's the old "which hosts file is authoritative?" issue, but with a twist...
A look at the issue tracker for Buster on github reveals the host data source: github.com/mcdermj/buster/issues/47
It's coming from ar-dns.net, 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 - a project by K7VE, the designer of STARnet. Maybe you all already knew about this system, but it's news to me. It's a nice system and cool project, but where and/or how he's sourcing the XRF and XLX addresses is problematic, imo.
This means there will be some problems connecting from Buster.
Case in point: I host XRF010 and XRF011, both of which are XLX reflectors. Both have been up and listed in the KD host file, on xrefl.net, and the automatic XLX Reflectorlist since late last year. They were submitted with hostnames, never bare IP addresses.
Buster's dextra 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 changed, so the XRF010 and XLX010 entries both work in Buster. But XLX011 moved to a different server over a month ago and changed IP addresses - so now it's already broken in this Buster update. Additionally, the entry for XRF011 is an 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.
It's not new that Buster uses an XML formatted hosts file, which is probably the right thing to do in Objective C, so there's no way to do a quick copy/paste update of the entire reflector list using a more current data source. Addresses of non-connecting reflectors require investigation by the user on a case-by-case basis, and individual addresses need to be updated directly in the xml file by users who are comfortable editing an xml file in the Buster application directory. Somebody could easily script a little utility that pulls down the KD host file and converts it to xml for Buster, but the fix here really should be with ar-dns.net's data sourcing.
Even when or 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 updates will still be dependent on Buster's author pushing app updates through the app store, as always.
Hopefully it doesn't sound like I'm complaining. I'm very happy that somebody took the time to create a nice macOS D-STAR client, and I don't personally have a problem changing host addresses when needed - it works well for me. Just wanting to point out the current issues, which have more to do with the ongoing host file issue than with Buster itself.
Thanks!
Brad N8QQ