Lack of GUI validation in DDNS page causes repeated forced updates

[SNR]

Bug noted in builds 12220 thru 12262. Possibly present in earlier releases as well:

Background:

The "Force Update Interval" field in the DDNS page expects an entry of n Days but actually accepts any arbitrary string. Input is saved as-is in the "ddns_force" variable in NVRAM. DD-WRT then converts the stored entry to a valid integer, converts the integer to seconds, and uses the value for the "--forced_update_period" option in inadyn.conf. If the update interval entered by the user evaluates to zero then DD-WRT writes "--forced_update_period 0" to inadyn.conf.

With "--forced_update_period 0", inadyn instead uses the period specified by "--update_period_sec" to determine the forced update period.

This behavior can be observed by entering some arbitrary non-numeric (or empty) string into the field (followed by Save and Apply). After doing this note that the DDNS log shows a forced update approximately once every six minutes, which corresponds to the "--update_period_sec 360" option string present by default in inadyn.conf. Unfortunately some Dynamic DNS providers might interpret this pattern of unnecessary forced updates as abuse and flag the user's account accordingly.

To prevent this problem, DD-WRT needs to validate the input in the "Force Update Interval" field. inadyn itself defaults to 30 days (in seconds) for this value. Any positive integer from 1 to 30 (days) should be acceptable for this purpose. If an actual entry of zero is allowed, then DD-WRT should interpret this as "don't specify any setting" and it should not write any "--forced_update_period" option string to inadyn.conf (in which case the inadyn default of 30 days would be enforced).

[Eko]

fixed in r12266 and r12268

[SNR]

Eko,

Thanks for fixing this. FYI, there's a minor issue with the error dialog if the "Force Update Interval" is out of range:

"undefined value is out of range [1 - 60]."

Shouldn't this error identify the label for the entry field, or at least the variable name?

[Eko]

fixed in r12283