Thanks for the feedback.
and option to enable force update every 24h with dyndns?
I *could* add this, but it's very much against the TOS. I'm not sure what the limits are set at for DynDNS, so I'm not sure if a forced 24h set would get you on the wrong side... I just think it's a bad idea.
Also, writing the code to handle state seems a bit daunting. [You'd have to keep last update date/time & state across a reboot.]
NAND file read/write support is really pretty sketchy - so I don't fancy writing this code very much.
(And I've not used any date/time comparisons in RoS, but I can't imagine them working very well when so much else really doesn't. )
I guess I just see pretty significant time involvement to rework (& debug) the script to to something that's very explicitly and directly against the TOS at DynDNS. Since following the TOS is one of the prime reasons I re-wrote the script in the first place, I'm not eager to add options to violate it.
Unless someone comes up with some sweetener, I'm not likely to tackle it.
If you decide to do it, and write some good documented code, I might add/merge it though.
4. possible to add multi wan update in one script instead of one script for each wan interface?
This is much more do-able...
I could do this, but I am not sure I see the need. On multi-wan installations, DHCP isn't very common anyway. To have multiple DHCP clients on a multi-wan setup is even more uncommon. [I have multi-WAN connects that have a single DHCP, but none that have more than one.]
The additional work to support multiple DHCP WAN legs is non-trivial. And to do that work to save the very occasional end-user the work of a more-than-one script setup seems like pretty diminishing returns. So, while it is more feasible, I don't think it warrants the investment of time - at least on my part.
Sorry I am not giving the answers you probably want, but that's how it seems to me.