Opened 5 years ago

Closed 4 years ago

#632 closed (duplicate)

DDNS for zoneedit.com not working

Reported by: therecker Owned by: eko
Keywords: Cc:

Description (last modified by therecker)

Sat Aug 2 11:48:46 2008: INADYN: Started 'INADYN Advanced version 1.96-ADV' - dynamic DNS updater.

Sat Aug 2 11:48:46 2008: INADYN: IP read from cache file is '66.2x.xxx.xxx'. No update required.

Sat Aug 2 11:48:46 2008: I:INADYN: IP address for alias 'xxxx.com' needs update to '66.2x.xxx.xxx'

Sat Aug 2 11:48:47 2008: W:INADYN: Error validating DYNDNS svr answer. Check usr,pass,hostname[[BR]]

My Username, Password and Hostname are all correct. I am not the only one experiencing this. Every router I manage uses this feature and after updating them to V24-SP1 they now will not update. The hardware versions I am experiencing this on are as follows: WRT54GL v1, WHR-G54s, WRT54G v3.1 and a WRT54GS v2.

Change History (18)

comment:1 Changed 5 years ago by Eko

  • Resolution set to worksforme
  • Status changed from new to closed

Works for me. As it says: recheck your username, password and check if you registered your domain (hostname)

comment:2 Changed 5 years ago by Eko

Well, tested with 10086 and 10102.

comment:3 Changed 5 years ago by therecker

  • Description modified (diff)
  • Resolution worksforme deleted
  • Status changed from closed to reopened

When I submit a ticket I do so for a reason. ALL 47 of my routers and all 9 of my friends routers and this post http://www.dd-wrt.com/phpBB2/viewtopic.php?t=35773 are experiencing problems using DDNS with zoneedit.com in v24 SP1. I would appreciate it if you wouldn't just blow this off. I checked my username, password and hostname SEVERAL times and they are correct. I even reconfigured from scratch some of these devices and they still won't work so please investigate this a little deeper because there is a problem.

comment:4 Changed 5 years ago by therecker

After further in depth investigation by myself and my colleagues we determined that the router is giving a false update error when it says that no update is required. I found this out by forcing the router to poll a different IP address from the ISP. It worked perfectly like it did prior to v24 SP1. But when it doesn't actually need updated because the zoneedit IP address on record matches the one being sent this is what happens

Sat Aug 2 11:48:46 2008: INADYN: IP read from cache file is '66.2x.xxx.xxx'. No update required.

Sat Aug 2 11:48:46 2008: I:INADYN: IP address for alias 'xxxx.com' needs update to '66.2x.xxx.xxx'

Sat Aug 2 11:48:47 2008: W:INADYN: Error validating DYNDNS svr answer. Check usr,pass,hostname

So something has changed between versions or something has changed in the way zoneedit sends its messages back to the client, but either way something IS wrong and needs fixed.

comment:5 Changed 5 years ago by dc

I can verify this for dyndns.com as well. One simple way to test is to reboot the router .. the error shows up. Then change (for dyndns) the wildcard attribute and press apply which works just fine so it isn't a DNS error. DC

comment:6 Changed 5 years ago by dc

After I posted the above comment, I downloaded eko's latest svn builds (100108) and the dyndns update seems to work correctly. I'll leave the ticket open so therecker can check his router farm and update as appropriate.

DC

comment:7 Changed 5 years ago by Eko

I'm still checking - sometimes it works, sometime it's not....

comment:8 Changed 5 years ago by therecker

So far with build 100108 it is working like a charm. I will leave the ticket open for a few more days just to make sure that there are no further errors. I do not know what caused this problem in SP1, but in the svn build 10108 it has been alleviated.

comment:9 Changed 5 years ago by therecker

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:10 Changed 5 years ago by peelman

I just installed 10328 to try to correct this problem and I'm still having the issue. I think that MY problem is that for some reason since the later v24 builds (even pre-v24-official) You guys started storing the username in all lower case and This doesn't play well with ZoneEdit? which allows Uppercase letters in their user names and is case-sensitive. My username is NPeelman but it gets stored in the router as npeelman. Apparently its been an issue for quite some time according to my logs which i just went into a checked. My IP just hasn't changed in so long as to make the point moot. However I have deployed DD-WRT on various devices to serveral client sites, which is where I first noticed this. Fixing this would be downright fantastic.

Some code jockey got a little carried away with filtering user input it would seem. :)

comment:11 Changed 5 years ago by peelman

  • Resolution fixed deleted
  • Status changed from closed to reopened

Doh, forgot to reopen...

comment:12 Changed 5 years ago by BrainSlayer

believe it or not, but we do not filter the input. we do also not convert the upper to lower case etc. its just plain saved as is

comment:13 Changed 5 years ago by therecker

This is a problem, but it isn't a functional problem. The router still works and updates just for some reason it says this. It does need to be fixed though and it would be nice if the powers that be would do that.

comment:14 Changed 5 years ago by peelman

Forgive me for disagreeing, but there is *something* being filtered. I enter my username as NPeelman, hit save, and it shows back up as npeelman. So its either being formatted before its being stored or being formatted before it gets used, either way I can log in with that account via ZoneEdit?'s webpage but the router fails continuously using the _exact_same_creds_ (copied and pasted.

Oh, and none of the routers under my charge are updating IPs. I get a page full of error messages and no DNS updates :\ Its not a HUGE deal because the IPs really *don't* change that often, it just sucks having to make a phone call anytime they lose power for an extended amount of time, just to get them to give me the IP address so i can manually update it. So yeah, if its not too much of a pain to trace down and fix, it would save me (and others i assume) some headaches :\

comment:15 Changed 5 years ago by therecker

Like I stated in the previous post nothing is technically wrong. If you force your router to pull a new IP address it will update. I have tested this several times. However, the inadyn interface in DD-WRT is displaying that there are errors. It is only doing this because your router does not need updated. You need to test this because this is what is happening. Now don't get me wrong I am on your side that it needs to be fixed, but you need to come at this with the actual problem and not your perception of the problem.

comment:16 Changed 5 years ago by therecker

  • Owner changed from somebody to eko
  • Status changed from reopened to new

comment:17 Changed 5 years ago by peelman

Well...

I'm leaning now towards ZoneEdit? having changed something with their process. My home router was legitimately jacked up, my browser (camino) was filling in (and overwriting) old crusty credentials. I found the config file in /tmp/ddns/ that lead me to that conclusion. Still getting the crappy errors.

However, I just checked a pair of clients that were affected by the fallout from Ike that reached the Midwest last week. They lost power for a while, as well as the phone company, so when everything finally came back up they had new, fresh IPs. Neither was doing ZoneEdit? updates, spouting the user/pass/host error. Triple checking that, and releasing/renewing the IPs (after setting a looping web request so i would get their new IP from my server logs when they came back), they are STILL not updating. I don't know how or why your request went through, but I think it would be worth investigating if ZoneEdit? has made any recent (as in the last 3 months) changes to their stuff that might be causing issues. I can't devote any more time to it right now, but if/when i get back around to it i'll post any updates/feedback I can. I'm open to ideas/suggestions.

comment:18 Changed 4 years ago by therecker

  • Resolution set to duplicate
  • Status changed from new to closed

Works with a workaround. Refer to ticket 720.

Note: See TracTickets for help on using tickets.