This may be one of those "we know and it's fixed in the next release..." things but if it's not known or some other poor soul is running the *current* stable `Pi-Star:3.4.17` has this issue, i've got a bit of a fix.
The **problem**:
When i was running the update command, things would get "stuck" on the `Updating hosts files...`. After a bit of digging, i found the `curl` call that was blocking the script. It appears that when the rPi host is on an IPv6 capable network, `curl` will attempt to connect to the hosts via their IPv6 address... even if the rPi does NOT have an ipv6 address. When i took the command out of the script to run in a console, i get results that look like this:
```
pi-star@my-host(rw):~$ curl -vvv --fail -o /usr/local/etc/APRSHosts.txt -s http://www.pistar.uk/downloads/APRS_Hosts.txt
* Hostname was NOT found in DNS cache
* Trying 104.27.184.136...
* Trying 2606:4700
:681b:b888...* Immediate connect fail for 2606:4700
:681b:b888: Cannot assign requested address* Trying 2606:4700
:681b:b988...* Immediate connect fail for 2606:4700
:681b:b988: Cannot assign requested address* Trying 2606:4700
:681b:b888...< this will repeat until the command is manually killed>
```
This would repeat forever... holding up the host update process in the script.
The "fix" is to add a `-4` flag to the `curl` calls in `/usr/local/sbin/HostFilesUpdate.sh` to **explicitly** tell `curl` not to use IPv6 when performing the fetch.
My system info:
```
Pi-Star:3.4.17 / Dashboard:20190119
```
```
pi-star@my-host(rw):~$ ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:132 errors:0 dropped:0 overruns:0 frame:0
TX packets:132 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:10568 (10.3 KiB) TX bytes:10568 (10.3 KiB)
wlan0 Link encap:Ethernet HWaddr b8:27:eb:5f:a4:d5
inet addr:myHost.ipv4.addy.here Bcast:<snip> Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7257 errors:0 dropped:0 overruns:0 frame:0
TX packets:5224 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2872803 (2.7 MiB) TX bytes:1754175 (1.6 MiB)
```
**TL;DR:**
rPi is on an IPv6 capable network (yay!), but is not bothering to get an IPv6 address for itself (boo!). `curl` is doing a good job and trying to use IPv6 when the network can resolve AAAA responses, but can't connect to an IPv6 host when the rPi has no IPv6 address... resulting an a looping forever error condition that blocks the update script. The fix is to manually tell curl to use only IPv4 addresses (boo!).
Can somebody please tell me that the next release of pi-start *will* support IPv6 capable networks!