nd1l
New Member
Posts: 17 
|
Post by nd1l on Jan 17, 2017 13:47:28 GMT -7
I've been running DStar Commander for quite a while, upgrading as new versions become available here. I'm running v2.01 with both DVAP's and dvMega's. I generally love the program; it's all I've used for a long time. Here are a couple of problems I've encountered recently; maybe someone has some suggestions. - I used to try to automatically link to Reflector 69C at startup. The link is successful only around half the time. The other half of the time the system come up saying "NOT LINKED". When that happens it will not link to DPlus reflectors or DCS reflectors, but it WILL link to X Reflectors. Trying to link to other reflector families returns, "NOT LINKED". To reach a DPlus or DCF Reflector I must power down the Pi and restart the program.
- I changed to not linking automatically to Ref 69C. So now when I enter "*69C" using my keypad I get the "NOT LINKED" message around half the time. When that happens, I cannot link to anything as mentioned above, so I must power down the Pi and restart the system to be able to link to DPlus or DCS Reflector families.
Any ideas? I'm perplexed. This is happening with two Pi3 + dvMega systems (single-band).
Jess ND1L
|
|
nd1l
New Member
Posts: 17
|
Post by nd1l on Jan 31, 2017 10:23:09 GMT -7
Has no one else had this issue? I'm surprised no one commented in the 2 weeks since I posted about this issue.
|
|
|
|
Post by W6KD on Feb 11, 2017 11:33:32 GMT -7
"Not Linked" (as opposed to "Linking to"...) indicates there is no valid host data for the reflector. If it's intermittent, it's likely an issue with a very slow DHCP response coming from your router, which causes the host name resolutions to fail. A look at the log should tell more of the story.
If you're using wifi, you might try a wired ethernet connection to see if the behavior stops. Also, sometimes a reboot of the router can help improve DHCP response time.
Regards
|
|
nd1l
New Member
Posts: 17
|
Post by nd1l on Feb 11, 2017 12:25:23 GMT -7
"Not Linked" (as opposed to "Linking to"...) indicates there is no valid host data for the reflector. If it's intermittent, it's likely an issue with a very slow DHCP response coming from your router, which causes the host name resolutions to fail. A look at the log should tell more of the story. If you're using wifi, you might try a wired ethernet connection to see if the behavior stops. Also, sometimes a reboot of the router can help improve DHCP response time. Regards Interesting! This happens ONLY in my car, which is a 2015 GMC Yukon. There is no option for a wired Ethernet connection. Recent GMC vehicles have built-in WiFi. Aside from finally learning that their cellular carrier is AT&T there's little else we can glean about how the in-car router functions. But I can say that this is a persistent issue. Very close to 50% of the time I power up the Raspberry Pi I get the "Not Linked" response. The really weird part is that when I get that message I CAN link to X-Reflectors, but not to DPlus nor to DCS Reflectors. My solution has been simply to power down the Raspberry Pi and power it back up 10 seconds later. In most cases that gets me a connection to my preferred DPlus Reflector. It doesn't seem to matter whether I send the SHUTDOWN command or not prior to power-cycling the Pi. I did update the Host files using the RF command hoping that would fix it, but no luck. Based on your comments I must surmise that this is an issue related to the way GMC's WiFi system functions. It happens with two Raspberry Pi 3's, both running the latest DStar Commander software. Thanks for your thought. The GMC WiFi system works quite well in every other way. The cell system antenna is out on top of the vehicle, so it far outperforms using an iPhone inside the car. I'll simply continue re-starting it when I get that message. 73 Jess SaveSave |
|
|
|
Post by W6KD on Feb 12, 2017 13:39:47 GMT -7
The reason you're able to get to (some) XRFs and not REF/DCS is most likely because many of the XRFs are defined in the hosts file as IP addresses and don't require a host name to IP address resolution to work. All of the REF/DCS reflectors use a DNS redirect...addresses for REFs, for example, are in the form REFxxx.dstargateway.org, and so to access them the hotspot has to resolve that address via the DNS system at startup, and if there's no internet connectivity until late, that may not happen.
A workaround would be to determine what the IP addresses for your favorite reflectors are (e.g. using tracert in a Windows command window) and place those in a DPlus_Hosts.txt file in your /root directory, which together with a "L" at the end of the line, will override the regular hosts file entry.
As an example, if I run "tracert ref030.dstargateway.org" in a command window on my PC, I see that the IP address for REF030 is 64.16.212.14. So I can go to the /root directory on my pi and create a new DPlus_Hosts.txt via the commands:
sudo su
cd /root
nano DPlus_Hosts.txt
and in nano I enter the line:
REF030 64.16.212.14 L
Write the changes and close the window with ctrl-x and "Y"
Now I reboot the Pi, and REF030 will no longer need to be resolved to work...the IP address I entered and locked in the root level hosts file overrides whatever is in the regular file. All REF and XRF entries need to be in the DPlus_Hosts.txt file, and if you want to use DCS, there needs to be a separate DCS_Hosts.txt file in the root directory with the pre-resolved DCS entries, for example:
DCS006 107.3.98.11 L
The beauty of this is that you can run a hosts file update in DStar Commander and not disturb the root level override. The potential gotcha is that if, at any time, the IP address for any of the overridden reflectors changes, then you will be unable to link to it until you change or remove the overriding entry in the root level file.
Regards
|
|
ka2y
New Member
Posts: 8
|
Post by ka2y on Feb 25, 2017 12:13:15 GMT -7
I have been noticeing this and now if I get a "not linked" I send a "HOSTUPDT" rf command and wait a minute and all is resolved. I have even had it come back and say connected to REF0303C (where I usually go). I am using a Version Elippse hotspot in the car.
|
|
