I'm using "--cache_dir /jffs/ddns". This way, every little change doesn't result in forced update.
How does that help not forcing the update? The default is "--cache_dir /tmp/ddns", which points to the folder where ddns also stores the cached IP.
It seems to force an update when I change some settings.
I'm not sure if I missed something, but any changes on the DDNS page on the webgui would just trigger a restart of the inadyn process. The cache_dir option just tells inadyn where to store to cached IP, unless I missed the fact that there are issues with /tmp/ddns within the router's memory.
wpinegar wrote:
crashfly wrote:
That is why this is considered "optional". In quite a few situations, it would work. However, yes, there are quite a few situations were it would also *not* work.
Yes, agreed. It should be relatively easy to add an optional feature to DDNS tab called "Use WAN IP Address" that would force INADYN on DD-WRT to check the WAN IP address stored in NVRAM and use this to update DDNS without the need to perform a round-trip check via an external web server. I've opened a bugtracker on this if anyone would like to comment or follow-up on the request:
It does forced updates for me whenever I change something and click Apply Settings.
You should try to experiment with both settings. The default would also force an update when you click apply on the GUI. You can confirm this by checking "/var/log/messages". inadyn updates or restarts are logged there.
Joined: 07 Jun 2006 Posts: 198 Location: Oregon, US
Posted: Thu Aug 13, 2009 5:34 Post subject:
phuque99 wrote:
Cyberian wrote:
It does forced updates for me whenever I change something and click Apply Settings.
You should try to experiment with both settings. The default would also force an update when you click apply on the GUI. You can confirm this by checking "/var/log/messages". inadyn updates or restarts are logged there.
I think it clears the cache (memory) when Apply Settings is clicked. _________________ Michael
WRT54GS v1.1 with Eko JFFS + OpenVPN
The script assumes the web server will pass on the environment variables in the "HTTP_ENV_VARS" array. If that's not true for your web server, you can check if you can find them in "_ENV" or "_SERVER" array.
Yes, agreed. It should be relatively easy to add an optional feature to DDNS tab called "Use WAN IP Address" that would force INADYN on DD-WRT to check the WAN IP address stored in NVRAM and use this to update DDNS without the need to perform a round-trip check via an external web server. I've opened a bugtracker on this if anyone would like to comment or follow-up on the request:
I'm quite hopeful that this would be added in a future build. Why not?
I assume that you are running PPPoE on your router (as opposed to your modem), and you have your modem running in bridged mode? But the biggest telco ISPs in the U.S. configure their DSL modems to do PPPoE on the modem by default (the main advantage being the ability to easily connect to the modem web interface). And DD-WRT also defaults to "Automatic Configuration - DHCP" on the WAN port, which means that it will never see the ISP-assigned WAN address, but will only receive the default address 192.168.1.64 . So a "Use WAN IP Address" feature may not be that useful to most DD-WRT users...
Thanks for this code. I've never worked with PHP before but was able to take your code and easily modify it for my web site (which I created explicitly to handle WAN address lookups). No more DDNS errors ever again! 8)
P.S. To see exactly how PHP is implemented by my hosting service, I stuck this code in my page:
Code:
phpinfo()
This dumps a listing of the entire PHP hosting environment, including the names and values for the environment array. It turns out that instead of $HTTP_ENV_VARS, my hosting service uses $_SERVER (as you suggested might be the case).
I assume that you are running PPPoE on your router (as opposed to your modem), and you have your modem running in bridged mode? But the biggest telco ISPs in the U.S. configure their DSL modems to do PPPoE on the modem by default (the main advantage being the ability to easily connect to the modem web interface). And DD-WRT also defaults to "Automatic Configuration - DHCP" on the WAN port, which means that it will never see the ISP-assigned WAN address, but will only receive the default address 192.168.1.64 . So a "Use WAN IP Address" feature may not be that useful to most DD-WRT users...
I have cable modem service with a public DHCP address assigned as the WAN IP address on the DD-WRT router. I've been unfortunate enough to use DSL as well and you are not forced to use PPPoE on the ISP's DSL modem. Even though it may be the default configuration you can run the DSL modem in bridged mode and run PPPoE on the router instead.
The main point is: In the instance that the router already has the correct WAN IP address why ask an external web server for something that it already knows?? Just a thought...
The main point is: In the instance that the router already has the correct WAN IP address why ask an external web server for something that it already knows?? Just a thought...
Yeah it would be nice too, along with HTTPS support. I believe the Tomato firmware does exactly what you desire. DD-WRT doesn't want to re-invent the wheel and decided to use the open source tool called inadyn without any modification. Thus we'll have to workaround that tool since dyndns.org IP checker is flaky. Alternatively, just close your eyes and not look at the DDNS.log
I have cable modem service with a public DHCP address assigned as the WAN IP address on the DD-WRT router. I've been unfortunate enough to use DSL as well and you are not forced to use PPPoE on the ISP's DSL modem. Even though it may be the default configuration you can run the DSL modem in bridged mode and run PPPoE on the router instead.
No, you are definitely not forced to use a DSL modem in the default PPPoE configuration. But with the modem in bridged mode, the modem web interface can't be accessed, and you are basically driving without headlights if you can't get DSL line stats. (Yes, I know there may be other ways to connect to a modem in bridged mode, but most are not nearly as practical as simply pointing your browser to the modem.)
Also, it looks like I spoke too soon when I said "No more DDNS errors". Even when pointing to my own private external web page (not indexed by any search engine, and only a single page with phuque99's PHP code), I am still eventually seeing those RC_IP_RECV_ERROR entries in the log. It took nearly 3000 iterations before they finally showed up last night:
Quote:
Sun Aug 16 12:17:42 2009: INADYN: Started 'INADYN Advanced version 1.96-ADV' - dynamic DNS updater.
Sun Aug 16 12:17:42 2009: INADYN: IP read from cache file is '76.238.xxx.xxx'. No update required.
Sun Aug 16 12:21:17 2009: I:INADYN: IP address for alias 'all.dnsomatic.com' needs update to '76.238.xxx.xxx'
Sun Aug 16 12:21:17 2009: I:INADYN: Alias 'all.dnsomatic.com' to IP '76.238.xxx.xxx' updated successfully.
Mon Aug 17 12:33:57 2009: W: DYNDNS: Error 'RC_IP_CONNECT_FAILED' (0x13) when talking to IP server
Mon Aug 17 12:33:57 2009: W:'RC_IP_CONNECT_FAILED' (0x13) updating the IPs. (it 2847)
After rebooting my router they showed up again after less than 200 iterations. In my case I check for an updated IP address every 30 seconds (the minimum inadyn value).
IMO there is a bug in the patched inadyn code that DD-WRT is using, and the changes that eko made several builds ago to fix some issues with the DDNS web page probably surfaced the bug. The inadyn developer has a newer version (1.96.2) that includes a fix to the main loop routine. But plugging this into DD-WRT is probably not trivial. The previous dev who patched inadyn for DD-WRT is no longer working on the project (and I won't go into that history any further...)
DD-WRT doesn't want to re-invent the wheel and decided to use the open source tool called inadyn without any modification.
Actually if you use an SVN browser to check out the DD-WRT inadyn code you can see that it definitely has been modified. Note also that there are switches in the inadyn.conf file used by DD-WRT (e.g. --cache_dir and --exec) that aren't documented at the inadyn site, and are not listed in inadyn_cmd.c in the v1.96 source code from the same site. It seems that these switches were added by the developer of the DD-WRT inadyn patch(es) to accommodate that unique environment.
DD-WRT doesn't want to re-invent the wheel and decided to use the open source tool called inadyn without any modification.
Actually if you use an SVN browser to check out the DD-WRT inadyn code you can see that it definitely has been modified. Note also that there are switches in the inadyn.conf file used by DD-WRT (e.g. --cache_dir and --exec) that aren't documented at the inadyn site, and are not listed in inadyn_cmd.c in the v1.96 source code from the same site. It seems that these switches were added by the developer of the DD-WRT inadyn patch(es) to accommodate that unique environment.
I guess my assumption was wrong. It was more fun for me to workaround the minor issue though. Maybe you can submit an enhancement for the dev to add the desired option of --read-wanip-from-nvram which could be much useful since a lot of people brought it up here
I guess my assumption was wrong. It was more fun for me to workaround the minor issue though. Maybe you can submit an enhancement for the dev to add the desired option of --read-wanip-from-nvram which could be much useful since a lot of people brought it up here
If you are interested in the change request to add an option to INADYN to retrieve the WAN IP address from nvram I have posted the change request on DD-WRT's SVN here:
http://svn.dd-wrt.com:8000/dd-wrt/ticket/1207
