|
|
Post by kf5zbl on Mar 12, 2015 17:43:09 GMT -7
I am not having any luck connecting to DCS reflectors. I have the config enabled and the Hosts files are good. Where am I going wrong?
Thanks
Bill
KF5ZBL
|
|
|
|
Post by W6KD on Mar 12, 2015 18:49:33 GMT -7
The DCS reflectors are enabled by default in DStar Commander. I'm listening to a QSO on DCS006B using DSC 1.11 as I write this.
Did you try more than one DCS reflector? Sometimes they go down. A problem with the callsign server at xreflector.net could also cause problems accessing the DCS reflectors.
Regards
|
|
|
|
Post by kf5zbl on Mar 13, 2015 8:46:03 GMT -7
I guess I just needed to restart the PI or something. It is working now for some reason.
Thanks
Bill
KF5ZBL
|
|
|
|
Post by W6KD on Mar 13, 2015 10:48:35 GMT -7
More than likely the callsign server at xreflector.net was down. All the DCS reflectors are defined via a redirect thru xreflector.net in the hosts file, so when the server goes down or is otherwise unreachable, the gateway can't resolve "DCS006.xreflector.net" to a good IP address.
Regards
|
|
nd1l
New Member
Posts: 17 
|
Post by nd1l on Apr 5, 2015 19:51:37 GMT -7
Bob:
When I try linking to DSC006B, I get "DCS006B is unknown; ignoring link request" on the ircDDB Gateway display. This happens around 95% of the time, then once in a blue moon it links.
Any ideas? I'm using the latest version of DStar Commander with a Pi2 and a dvMega. The version of ircDDB Gateway is 20140326 and the version of DStar Gateway is 20140521.
I thought this issue was confined to use in my car using GMC's WiFi hotspot but it's happening in my home using an Ethernet connection to my LAN.
I do have the necessary DCS_Hosts.txt file in usr/local/etc by the way. All the listings in that file have the "L" (locked) suffix. The file date is March 2015. Does it need to be updated perhaps?
73
Jess
|
|
|
|
Post by W6KD on Apr 5, 2015 22:00:14 GMT -7
Well, first make sure you really aren't trying to link to "DSC006B" -- there's no such thing. It's DCS006B
If the problem isn't a typo in the command, then try creating the file /root/DCS_Hosts.txt and put this one line into it:
DCS006 66.30.81.236 L
Reboot the gateway, and see if that works. If it does, then it's most likely the callsign server behind the trouble.
Regards
|
|
nd1l
New Member
Posts: 17
|
Post by nd1l on Apr 6, 2015 8:56:30 GMT -7
Hi Bob:
Thanks!
My typo was confined to my note to you. I typically connect by entering the DTMF string "D6B".
I added the one-line DCS_Hosts.txt file in /root. I was able to connect to DCS006B as soon as I rebooted the Pi.
I'll check in the car to make sure the success was not something particular about my office LAN routing.
Since that evidently worked, how about the other DCS reflectors? I suppose I ought to add their IP addresses as well... ?
Jess
p.s. - I just checked... the system does connect to DCS006B while mobile. I connected and disconnected several times without an issue. So as I mention above, the question is how to connect to other DCS reflector...
jg
|
|
|
|
Post by W6KD on Apr 7, 2015 10:08:18 GMT -7
It looks to me that you have a DNS or firewall issue on the internet connection you're using. If using the IP works, but attempting to use the default host address (in the form dcsXXX.xreflector.net) does not, then the host name is most likely either not being resolved or is being blocked by the policies in effect on your firewall.
You can build a list of the IP addresses for the other DCS reflectors, whose IP addresses can be determined by running tracert dcsXXX.xreflector.net in a command prompt window in Windows. But be aware that the IP addresses could change over time, so if it stops working you'll need to see if the hostname still points to the same IP address.
Regards
|
|
nd1l
New Member
Posts: 17
|
Post by nd1l on Apr 9, 2015 8:30:52 GMT -7
It appears that in your image for the dvMEega, the file /etc/resolv.conf didn't have much in it. In the images I downloaded in past form Western DStar that file contains the lines as follow:
nameserver 8.8.8.8
nameserver 8.8.4.4
which are for Google's public DNS servers.
So I brought my Pi2/dvMega into my office where I could look at that file and I've added those two lines.
I'm going to put the box back in my car at lunchtime; we'll see how it does with DCS reflectors.
Oh, BTW I discovered that GMC uses AT&T as its carrier for its in-vehicle WiFi.
Finally, I built a list of the (current!) numeric IP addresses for all the DCS reflectors but using the "dig" command... that command doesn't work in your image but it works on our office Linux server which runs CentOS. If you happen to know what package contains that command I'd like to add it to my Pi2. It's a useful little tool. Still, as mentioned by a couple of friends (W1FJM & K1WIZ), it seems wiser to fix the DNS resolution problem since that precludes any issues if a reflector IP address changes.
73
Jess ND1L
REF069C (mostly)
|
|
|
|
Post by W6KD on Apr 9, 2015 11:40:03 GMT -7
Normally resolv.conf is written out by the system service resolvconf using data obtained from the DHCP server.
So that leaves me wondering if there's something nonstandard about the DHCP server in your office LAN. You can try putting a known working set of DNS nameserver entries into the resolv.conf file and then write-protect it (sudo chattr +i /etc/resolv.conf) to prevent the resolvconf service from changing it, but be aware that many corporate firewalls have common DNS sites blocked as a security measure to preclude unauthorized redirection.
Regards
|
|
nd1l
New Member
Posts: 17
|
Post by nd1l on Apr 9, 2015 12:34:17 GMT -7
Well, not to worry, my "fix" which was to modify resolv.conf did not work out in the car. I still can't connect to DCS reflectors other than DCS006 for which I had already created the single-line file as you suggested in your 4/6 message. You had written:
>If the problem isn't a typo in the command, then try creating the file /root/DCS_Hosts.txt and put this one line into it:
>DCS006 66.30.81.236 L
Well, I can now easily drop a fully-populated DCS_Hosts.txt file into /root as mentioned. I'm going to try that next.
Again, this occurs ONLY in my car where my frames are going through the GMC WiFi hotspot out to the AT&T cell network. I have no problems at my office or at my home. In those places my routers have been told to use the Google public DNS name servers, so in view of what you mention that's why those listings appear in resolv.conf when I look at the file in either my office or home. At least that part I can understand.
I still can't understand, however, why AT&T's name server can't resolve the dcsXXX.xreflector.net fully-qualified symbolic addresses, but if one looks at the other two host files (for DPlus & X Reflectors) one finds mostly numeric IP addresses so DNS lookups are not necessary. So maybe AT&T is simply not supporting DNS lookups like that... but anyone with, say, an iPad would need that service to just browse the web, wouldn't they? I don't get it...
73
Jess
|
|
|
|
Post by W6KD on Apr 9, 2015 18:29:00 GMT -7
OK, for some reason thought the office was the problem.
I'd still try setting a primary and secondary nameserver value (to google or opendns) manually in the resolv.conf file and locking it as described above and see if that works. If you don't lock (write-protect) the file, it's going to be overwritten by the service with whatever it gets from the DHCP server in the car's hotspot.
Regards
|
|
nd1l
New Member
Posts: 17
|
Post by nd1l on Apr 10, 2015 11:03:20 GMT -7
Okay, I'll try that when I get a chance. I would prefer to solve the problem that way, of course, but... in the meantime, yesterday I loaded my version of DCS_Hosts.txt (with their current IP addresses) on the Pi2. As soon as I fired it up in the car I was able to connect to all the DCS reflectors. It's a small file (less than 1K), so in case anyone else has this issue with a mobile installation as I have I'd be happy to make it available.
73
Jess ND1L
|
|
