(Optionally) disable fallback to http://ifconfig.me

[avakhitov-gmg]

Currently inadyn automatically (and unconditionally) falls back to default checkip-server if custom configuration fails to retrieve ip address. I'd like to deactivate fallback because if may lead to unintended actions. Please introduce configuration option to disable the fallback.
Problem in detail: I'm retrieving IPv6 address to use for update with a custom script that builds desired IPv6 address from dynamic prefix assigned by ISP and static token (suffix derived from MAC) of a network device (wifi cam or similar). inadyn updates AAAA DNS record as expected. Script may fail if IPv6 prefix is temporarily unavailable (ISP issues). In this case no update should happen (no address available). The fallback performed by inadyn identifies global IPv4 address of the router where idanyn runs and updates A record with it. The behaviour is completely counterproductive because the IPv4 address is actually inaccessable from internet (CGNAT).

[troglobit]

Ah, good point!

Hopefully someone else can chip in here with a PR to address this since I'm unfortunately quite busy with other projects at the moment. I'll be happy to review, merge and release, of course.

[fdcastel]

Related: #306.

@troglobit @avakhitov-gmg Should we really add another option for this?

Or simply not invoke checkip-server if a custom-script was used?

I'm a firm believer of the second option. When using a custom script the user is clearly saying that he/she doesn't want anything from checkip-server.

[troglobit]

@fdcastel you make a good argument, I'm usually against adding extra options (I'd much rather remove ...). The custom options should really be the ones triggering the "you clearly know what you're doing, I'll leave you alone" :-)

Seconded!

[fdcastel]

I was checking the code and making some tests. Please correct me if I'm wrong.

Currently there are 3 distinct ways to configure how to get the IP address:

1. iface
2. checkip-command
3. checkip-server / checkip-path / checkip-ssl

The above also seems to be the "priority order". I.e.:

• If iface exists, it will be used;
  • I don't know what will happen if this fails.
• Otherwise, if checkip-command exists it will be used;
  • In case of error it will go to next step;
• Lastly, checkip-server will be used.
  • If not specified, use the default service (http://ifconfig.me/ip)

It seems to me that each one are very different from another. There should never be any crossing between them.

In other words: If I ask for an iface update it should never use any other form. It should work or throw an error. Same with checkip-command.

Opinions?

[troglobit]

Agreed. You are not wrong. "Don't cross the streams", basically.

Please continue down the rabbit hole

[fdcastel]

Ok. The root of this problem is caused by the error handling of these 3 functions:

• get_address_cmd()
• get_address_iface()
• get_address_remote()

These 3 functions are called only from get_address_backend() and have the following return behavior:

• !0 if there is no config for it or an error has occurred; or
• 0 if everything is fine

The problem lies in the bold statement above. There is no way to to differentiate between a I DON'T WANT THIS and a I WANT THIS BUT IT RETURNED AN ERROR.

Working on a PR now.

[pelzvieh]

Do I understand correctly that the pull request would not cure the problem, that the built-in default checkip-server would be queried (which is IPv4) if the configured check-ip service has a problem? This implies that there's still no support yet for an IPv6-only setup when using a checkip-server, right?