Forced Update Improvement about inadyn HOT 7 CLOSED

Any ideas which random IP should be generated?

from inadyn.

Is that a trick question? =P If I told you WHICH IP, it wouldn't be random.

Seriously though, the random IP doesn't matter because it should be IMMEDIATELY changed to the actual IP after. The only purpose is to trick the DDNS server into thinking the IP changed when in fact, it didn't.

Does this make sense?

Cheers

On May 17, 2012, at 1:03 AM, Timur [email protected] wrote:

Any ideas which random IP should be generated?

---

Reply to this email directly or view it on GitHub:
#15 (comment)

from inadyn.

Hi,

Thursday 17 May 2012 20:18, Cameron Boulton:

Is that a trick question? =P If I told you WHICH IP, it wouldn't be random.

Sorry, my English is not very well.
I meant which kind of IP should be generated - private/public?

Seriously though, the random IP doesn't matter because it should be
IMMEDIATELY changed to the actual IP after. The only purpose is to trick
the DDNS server into thinking the IP changed when in fact, it didn't.

Does this make sense?

I guess.

Timur

from inadyn.

Interesting idea! We've had a few issues with customers not getting their records updated properly. This workaround could actually prove useful.

from inadyn.

Glad to hear. I recommend only performing this on a FORCED event, not every usual check for an IP change. DDNS providers could start banning users who abuse this feature. Another reason a "random" IP is important compared to 0.0.0.0

On May 20, 2012, at 3:13 PM, Joachim [email protected] wrote:

Interesting idea! We've had a few issues with customers not getting their records updated properly. This workaround could actually prove useful.

---

Reply to this email directly or view it on GitHub:
#15 (comment)

from inadyn.

I shall see what I can do, but it is likely I will not have time to work on this until the fall.

As usual, patches are most welcome! :)

from inadyn.

This issue has been stuck a bit too long for my comfort. I've both been out of time and also out of clue on the random IP# as well as unclear on what DDNS service providers would appreciate a client that accesses too fast.

What about this?

1. Triggered by external event, SIGUSR1 and new config option: --fake-address-change
2. Send update to (all) DDNS provider(s) in .conf using random address from 203.0.113.0/24, RFC5737
3. Wait random number of seconds (1-10)
4. Send new update with actual IP address to (all) DDNS prover(s) in .conf

from inadyn.