troglobit/inadyn

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

avakhitov-gmg opened this issue · 7 comments

avakhitov-gmg commented

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 commented

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 commented

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 commented

@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!

  • 👍1
fdcastel commented

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.

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?

  • 👍1
troglobit commented

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

Please continue down the rabbit hole

  • 😄1
fdcastel commented

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

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.

  • 👍2