Host Name Resolution

dchristo

Has anyone had any trouble with Studio being able to resolve host names? I had some problems yesterday trying to update a remote system. Here's the scenario (this setup has worked before with no problems):

1. I use Dyndns.org for the dynamic name resolution service. The proper ports are open on the firewall at the remote site.

2. I am able to browse to the master, FTP, and telnet with no problems using the mynetlinx.dyndns.org (not the actual address, but you get the idea). I was able to FTP the Java web pages just fine from TPD3.

3. Studio would not connect to the master on 1319.

4. Using the command prompt, I pinged the master and got the actual IP address of the remote site. Using Ethereal, I noticed that studio was directing it's traffic to a different IP address. When watching telnet traffic to the master, the Destination ip was the host name (mynetlinx.dyndns.org), but Studio traffic showed an actual IP address (which was wrong).

5. Entering the actual IP address in Studio cleared up the issue.

Does Studio cache DNS information? It doesn't seem like Studio was correctly resolving the IP, but other applications were. Like I said before, I have used this connection several times in the past with no issues.

Any thoughts?

Thanks,

--D

HARMAN_icraigie

I have been having a lot of trouble connecting over the ICSNet port (1319), into a couple of projects since the last release - never an issue through telnet or web. Using the IP vs the URL makes no difference.

DHawthorne

I would suspect the local network. I have had lots of issues with a local router no longer providing DNS information to NetLinx masters and panels, it's one of the reason I now exclusively use static IP's in my projects. Even if the DNS server drops out of communications, the actual IP will work. I hesitate to blame this on the AMX NIC's, it seems to be more of a router issue to me.

Thomas Hayes

Depending if there was a power issue then I was told that depending on the router that the Nelinx system would boot faster than it would and it would be possible for the router to missing the info. I think you had to insure the router was on fast arc?

dchristo

That's an interesting thought, although I don't think it's a router issue because I can still connect to the master by FTP, Telnet, and a web browser by using the host name. It's only Studio on 1319 that's the issue.

--D

DHawthorne

dchristo wrote:

That's an interesting thought, although I don't think it's a router issue because I can still connect to the master by FTP, Telnet, and a web browser by using the host name. It's only Studio on 1319 that's the issue.

--D

Stupid question maybe, but is the router forwarding 1319 to something else? Also, you can change the master's program port, make sure it didn't get switched to something besides 1319. I would reset the router before doing anything else though.

[Deleted User]

Is Ping the Master checked?

In the IP communications setup for a master, there is a check box to ping the master. I always deselect this option for a remote network connection. See if this helps.

For more info reference AMX tech note 565.

http://www.amx.com/techsupport/PDNTechNote.asp?id=565

dchristo

I have tried communicating with the "Ping Master" option checked and unchecked with no difference.

Also, the data I collected from an Ethereal session seems to confirm that Studio is not resolving the host name correctly. It is relsolving to an incorrect IP address. That's why I don't think it's a router problem... Studio isn't even trying to connect to the proper IP address. Also, I've tried communciation with the actual IP address of the remote site, and it worked fine (which means the router is properly configured to forward 1319).

--D

[Deleted User]

Sounds like a different issue.

Dave,

Have you submitted this problem to AMX tech support?

Brian

Chip Moody

Have you tried telnetting from a DOS prompt to port 1319 using the domain name? I'm wondering if DynDNS.org is possibly not regestering the IP address correctly with association to that port. If you were able to telnet using the domain name to 1319 (telnetting normally to port 23 doesn't count) that would eliminate the possibility that the DNS servers are supplying bad info.

- Chip

dchristo

I just tried to telnet to 1319 with the host name and it connected just fine.

Brian, no, I haven't talked to tech support yet. I wanted to see if anyone else had experienced this as well. I'll give them a call on Thursday.

Thanks,

--D

DHawthorne

I wonder if this is similar to a problem I had a while back. I set up a master in the office for remote connection, manually entering a static IP and all the network information specific to the jobsite. Once installed, it was not remotable. On site, I could connect to everything using the local IP's, but not remotely; neither would the master itself communicate over the Internet with i!-TimeManager, etc. So I changed the network settings to dynamic on site, rebooted it, and let it get everything from the DHCP server. Then, I went back and re-entered all the IP information exactly as it was before. After that, everything worked fine. I am convinced there is a setting or flag that will only set properly with a DHCP server connection, and there is no way to access it manually. I can't imagine what it may be, but I make it a point now to set up every master with DHCP first before switching over to my final static settings.

dchristo

Update:

Further testing has revealed that Studio is failing to perform any kind of DNS query. I have reported it to tech support and I'll update again when I hear back from them.

--D

ldeblank@jnv.nl

Had some kind of the same problem on a Windows 2003/XP local network. Check if you're local(if you have one) DHCP server had switched on dynamic DNS. If not there is a change that the ip adress the DHCP server gives you don't matches the dns name. I my case I had two computers with diffent names and different ip's. Using configsys /all shows that the IPadresses and DNS names has swapted.
Good luck