Update to DynDNS module

DHawthorne

Repost from ACE area, which not everyone has access to:

I've updated this module with a few bug fixes:

1) If the master was reset while an IP connection was pending, it would never try to reconnect again. Fixed so that a pending status is cleared on restart.
2) One client that had this installed was having some difficulty with his cable modem so that responses across the Internet were extremely lagged at times, resulting in timeouts on IP checks. This, in turn, resulted in the IP being set as blank, and forced an update to DynDNS. DynDNS took exception to that and shut down the host for "abusive" updates. To prevent this, I've added code that checks IP values to at least verify they are complete and in the proper format, and if not, flags the IP as unknown rather than changed so it will not act unless a check goes through, gets a valid address, and determines the IP really has changed. I also applied the check to the "SET IP=" command while I was at it.

All that is needed is to drop the new TKO file where the old one was in your project, then recompile and load the project. The AXI file has only changed in terms of the documentory comments; you do not need to replace it (and if you do anyway, make sure you edit it for your project appropriately). You can verify the new version was installed by Telnetting your master after the update, turning on diagnostic messages, and using a send_command to the virtual device interface (default is 33020) of "'QUERY=STATUS'". Among the information that is returned should be a version number of 1.0a.

giacomo

problem with DYNDNS module

Hi DAVE,
I tried to use DYNDNS module, I followed the installation notes...but the result is this list of errors:

UNKNOW HOST: checkip.dyndns.org
ClientOpen PanjaInetAddr or hostGetNyName error 0x0
CIpEvent::OnError 0:5:1

It seems that the module isn't able to use the "check ip service" of DYNDNS.

please, can you hel me?

thank you very much
ciao

DHawthorne

Their IP check service goes offline once in a while. Try putting the same URL in your browser, and see if you get a result. If you do, it is probable that the DNS information is not properly set in your NetLinx master (whcih means your NetLinx isn't going to be able to get out on the Internet at all with namespace URL's).

From a Windows machine connected to the same network as the NetLinx, run a command window and type in ipconfig /all . This will tell you the proper DNS settings for your network, which you can then put into the NetLinx. If all else fails, you can use 204.13.250.51 instead of checkip.dyndns.org, but it's not recommended because they may change the IP. Alternately, you can use any IP check service that outputs "Address: <IP number>," including one locally hosted.

giacomo

Hi Dave,

thank you for fast replay.
You are right! I had to set the DNS on my NI-3000.
Unfortunately there is another type of problem:
when I try to force the IP UDATE, this is the reply:

send_command 33020, "'reset=ip'"
>(0001246199) DYNDNS Module COMMAND ECHO --> reset=ip
(0001246201) DYNDNS Module --> Setting IP state to UNKNOWN, forcing IP check
(0001246488) Connected Successfully
(0001246490) CIpEvent::OnLine 0:2:1
(0001246491) DYNDNS Module --> Checking for IP change with service at checkip.dyndns.org
(0001246725) Exiting TCP Read thread - closing this socket for local port 2
(0001246727) CIpEvent::OffLine 0:2:1
(0001246728) DYNDNS Module <-- HTTP/1.0 200 OK
Server: Cherokee/0.4.6
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Conn

Afther this command, I ask for information from the DYNDNS module:

send_command 33020, "'query=status'"
>(0001582550) DYNDNS Module COMMAND ECHO --> query=status
(0001582554) DYNDNS Module --> Version 1.0a
(0001582554) DYNDNS Module --> Current IP =
(0001582555) DYNDNS Module --> IP last checked 10/24/05 at 18:55:57
(0001582555) DYNDNS Module --> Host: ***********
(0001582556) DYNDNS Module --> IP last updated on 10/24/05
(0001582556) DYNDNS Module --> Module Status is: NORMAL
(0001582557) DYNDNS Module --> Connect status = NOT CONNECTED
(0001582557) DYNDNS Module --> Connect mode = IDLE
(0001582558) DYNDNS Module --> IP Status = IP UNKNOWN
(0001582558) DYNDNS Module --> Debug mode is ON

I cannot see my IP (it's blank!) and when I PING the my site www.*******.net I receive the message "host is not on line".

Thank you for your suggestions
ciao

giacomo

DHawthorne

I think I have introduced a bug in my last update, it doesn't seem to like updating the initial IP. You can use the "SET IP=xxx.xxx.xxx.xxx'" to initialize the module; use the same IP number you get when point a browser at the checkip address. The bug only shows upwhen there is no IP data at all in the system, and I use a persistent variable, so it is never a problem after the first update. It will work correctly after that. I just haven't got around to fixing this, I've been aware of it for some time I'm sorry to admit...

CT-Dallas

I do not think it is recording the IP. Here is my status:


>(0000380657) DYNDNS Module COMMAND ECHO --> QUERY=STATUS
(0000380659) DYNDNS Module --> Version 1.0a
(0000380659) DYNDNS Module --> Current IP =
(0000380659) DYNDNS Module --> IP last checked 12/20/07 at 14:40:53
(0000380659) DYNDNS Module --> Host: xxxxxxxxx.xxxxxx.com
(0000380660) DYNDNS Module --> IP last updated on 12/20/07
(0000380660) DYNDNS Module --> Module Status is: NORMAL
(0000380660) DYNDNS Module --> Connect status = NOT CONNECTED
(0000380661) DYNDNS Module --> Connect mode = IDLE
(0000380661) DYNDNS Module --> IP Status = IP UNKNOWN
(0000380662) DYNDNS Module --> Debug mode is ON

so I force the reset of the IP and query again


>SEND_COMMAND 33020, "'RESET=IP'"
>(0000503077) DYNDNS Module COMMAND ECHO --> RESET=IP
(0000503078) DYNDNS Module --> Setting IP state to UNKNOWN, forcing IP check
(0000503163) Connected Successfully
(0000503164) CIpEvent::OnLine 0:15:3
(0000503165) DYNDNS Module --> Checking for IP change with service at checkip.dyndns.org
(0000503207) Exiting TCP Read thread - closing this socket for local port 15
(0000503208) CIpEvent::OffLine 0:15:3
(0000503209) SendString 0:0:0 too long 278 truncated to 274
(0000503209) DYNDNS Module <-- HTTP/1.1 200 OK
Content-Type: text/html
Server: DynDNS-CheckIP/1.0
Connection: close
Cache-Control: no-cache
>SEND_COMMAND 33020, "'QUERY=STATUS'"
>(0000582291) DYNDNS Module COMMAND ECHO --> QUERY=STATUS
(0000582292) DYNDNS Module --> Version 1.0a
(0000582293) DYNDNS Module --> Current IP =
(0000582293) DYNDNS Module --> IP last checked 12/20/07 at 14:47:28
(0000582294) DYNDNS Module --> Host: xxxxxxxx.xxxxxxxxx.com
(0000582294) DYNDNS Module --> IP last updated on 12/20/07
(0000582295) DYNDNS Module --> Module Status is: NORMAL
(0000582295) DYNDNS Module --> Connect status = NOT CONNECTED
(0000582295) DYNDNS Module --> Connect mode = IDLE
(0000582295) DYNDNS Module --> IP Status = IP UNKNOWN
(0000582296) DYNDNS Module --> Debug mode is ON

Can you see where and if something is going wrong?

Thanks,
Chris

DHawthorne

There were several bugs in the module, most of which were of the category "not broken enough to worry about," but Chris ran across a real one that quite broke the module - the IP validation routine flagged some good IP addresses as bad, and so wouldn't update. I've fixed that, as well as the blank IP on initial use problem, so on a new installation, sending the command RESET=IP will now properly initialize the module and set the IP with DynDNS.com. Just a reminder though, you should set up your host with DynDNS first, but not put the correct IP in if you are going to do this; unless it's a pay account, it will see that as an "abusive" update because there was no change. Alternately, you can put the proper IP in your axi file and go ahead and set it up when you create the host. It then will not update until it actually changes, or the 30 days for a forced update pass.

There are a few other minor bug fixes, and are detailed in the installation text file.

DHawthorne

I have yet another update - and I thought I was quite done with this module .

Someone raised the concern that the login information is stored in plain text in the AXI file, and anyone with access to it could conceivably mess with your DynDNS account. Though I couldn't imagine why someone would do such a thing, it is a valid concern. So, I have removed the login information from the AXI file, and you now have to set it using a send command of the form "'SET LOGIN=username: password'" (no space after the colon, I added that to prevent the forum turnng it into a smiley). This new version will disable itself immediately if this is not done. When you issue the command, it is encrypted and stored in the module memory, and written in its encrypted form to a file on the master so it will survive code updates.

The encryption is not very strong; but it is the same encryption that DynDNS accepts when using the update service. Since anyone so inclined could intercept a packet sent during an update, and conceivably crack that encryption, I didn't figure it was necessary to store it in a stronger form (though I have seen a module using Blowfish for this, it seemed to me like putting five padlocks and a deadbolt on the front door, but leaving just a hook latch on the back ... my way only has two hook latches, but it's still better than leaving it wide open). As far as I can tell, the only better security DynDNS offers is using an SSL connection, but I wasn't about to go that far for such a simple module.

I also made a minor change so that if you issue a "'RESET=IP'" command on an established system, it will check the IP immediately instead of waiting for the next scheduled IP check.

*** WARNING ***

This update **WILL** break any older versions if you are not storing separate copies in every project folder. As soon as the module starts up, if it cannot find the password file on the master, it will disable itself. Setting the login information will reset it, and all should be well after that. I recommend you turn on debugging when doing so to make sure everything goes a s expected. Also, don't forget to update your AXI files so the login data is no longer there, or the encryption addition will be utterly wasted .

ryanww

I decided to try this today, and am having some issues with this. I am putting it on an older ME260.

When I send the command RESET=IP to manually get the current ip address, it replies:

SEND COMMAND 33030,"'RESET=IP'"
>(0000636362) DYNDNS Module COMMAND ECHO --> RESET=IP
(0000636366) Ref Error ^LIPCHECKTIME Index 0 Line=628
(0000636368) CIpLibrary::Timeline_Set - Error
(0000636369) DYNDNS Module --> Setting IP state to UNKNOWN, forcing IP check
(0000786360) UNKNOWN HOST: checkip.dyndns.org
(0000786362) ClientOpen PanjaInetAddr or hostGetNyName error 0x0
(0000786363) CIpEvent::OnError 0:30:2
SEND_COMMAND 33030,"'QUERY=STATUS'"
>(0000883042) DYNDNS Module COMMAND ECHO --> QUERY=STATUS
(0000883046) DYNDNS Module --> Version 1.03.1
(0000883047) DYNDNS Module --> Current IP = 1.1.1.1
(0000883048) DYNDNS Module --> IP not yet checked with IP service
(0000883049) DYNDNS Module --> Host: wms.dynalias.com
(0000883050) DYNDNS Module --> IP last updated on 02/25/09
(0000883051) DYNDNS Module --> Module Status is: NORMAL
(0000883052) DYNDNS Module --> Connect status = NOT CONNECTED
(0000883054) DYNDNS Module --> Connect mode = IDLE
(0000883055) DYNDNS Module --> IP Status = IP UNKNOWN
(0000883056) DYNDNS Module --> Debug mode is ON

DHawthorne

Your master is not connecting to the DynDNS web site ... can't even find the name from the DNS server. That's why the UNKNOWN HOST error when it goes out to get the current IP.

There are two possibilities here:

1) DynDNS.com had a temporary service outage. If that's the case, it will more than likely be resolved within an hour.
2) More likely: your network is not properly set up on the master. Pay particular attention to the DNS server entries. If you are using a static IP in your master (recommended highly), your best bet is to set it up for DHCP first, let it get all the pertinent info from the DHCP server, then go back and set it for static and change only the actual IP number. I've also found it is usually sufficient to set the first DNS server IP to the IP of your router, in case your provider changes DNS locations on you.

ryanww

Yep that worked! I forgot to set that when I set it up a while back. Thanks!!

felixmoldovan

Dave...
Trying to use this module with no much joy. Can you look at the reply from checkip.dyndns.org and, perhaps, spot my mistake.

DHawthorne

I really can't imagine ... it's the simplest of HTML exchanges. All that get's sent to the server on an IP check is a GET command ... that's it, no headers, no parameters, nothing but the word GET. How that could possibly generate a server error I couldn't tell you. The only guess I can even make is that something is corrupting the packet on it's way out to the server, or as it leaves your local network. Firewall blocking your master, or appending something maybe?

LCubed@snet.net

Try downloading WireShark and use it to take a look at the outgoing message.

DHawthorne

I can confirm it's still working on my jobs, so it's not a matter of DYNDNS changing their server's header requirements.

LCubed@snet.net

I can confirm it's still working on my jobs, so it's not a matter of DYNDNS changing their server's header requirements.

I agree. I've got about eight projects using this, and although sometimes it may lockup on one project or another, they all still do work. It would be nice if there were a flag one could set to tell the module to do an automatic reset if it is in trouble mode for more than two months.

felixmoldovan

Thanks Gents.
I am sure the module is fine... It works just fine in onother application. It might be something site specific or just my bad luck.

DHawthorne

LCubed@snet.net wrote: »

I agree. I've got about eight projects using this, and although sometimes it may lockup on one project or another, they all still do work. It would be nice if there were a flag one could set to tell the module to do an automatic reset if it is in trouble mode for more than two months.

Hey, I provided the source, go for it . Though actually, I deliberately didn't do it that way to force the account to be corrected rather than annoy DynDNS with repeated bad attempts. What I do is check my account page regularly to see which systems haven't been reporting. Nine times out of ten, it's because something changed at the house and they have no connectivity at all on the NetLinx anymore. I had a customer recently change his router and reconfigure his home network to a different subnet just so he could VPN in from the office. When the entire AV network blew up because all the IP's were static (and now not only on the wrong subnet, but also not having the necessary ports forwarded), he casually calls me up and says I need to "fix the AMX, it doesn't work anymore." People forget it's a network device, and if they change the network, it needs to be updated as well.

LCubed@snet.net

Cool, I'll do that. Yeah, I check my account page as well, but if all that happens is the module needs to be reset and the WAN address changed, it means a site visit. If there is a problem with the local network and the module can't get out to check its IP, then a reset after two months of failure won't hurt.

DHawthorne

DHawthorne wrote: »

Hey, I provided the source, go for it .

Um, well, I thought I provided the source ... guess I didn't. Here's just the source axs.