Management of DDNS when using both Asus & No-IP on RT-AC68U / Merlin 386.3_2

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

learning_curve

Occasional Visitor
Okay - A Full Re-Edit / Updated version of this now:

The setup that I was using was as follows:

Asus DDNS **.asuscomm.com is configured via the GUI page: **/Advanced_ASUSDDNS_Content.asp

No-IP DDNS **.ddns.net is configured via CLI in a new file here: /jffs/configs/inadyn.conf.add

When the DDNS client / service was restarted, the two were correctly combined within this file: /etc/inadyn.conf and the dual source DDNS is fully operational. The Let's Encrypt SSL Certificate was easily issued / re-issued etc and things were looking good at that point.

However... an IPv6 DDNS service can only be provided by the No-IP DDNS service as the ASUS DDNS service apparently is still IPv4 only at present. Erroneously, I had included this line: allow-ipv6 = true within the /jffs/configs/inadyn.conf.add file, which with hindsight, was unnecessary.

That line meant that when /etc/inadyn.conf ran, the No-IP DDNS worked perfectly on both IPv4 and IPv6, but the Asus DDNS (predictably) logged the following errors:
inadyn[16229]: Failed resolving hostname **.asuscomm.com: Name or service not known
Oct 5 20:15:15 inadyn[16229]: IPv6 address fe80::** is not a valid Internet address.
Oct 5 20:15:15 inadyn[16229]: IPv6 address fe80::** is not a valid Internet address.
Oct 5 20:15:18 inadyn[16229]: ppp0 ipv6 address=<2001:**>
Oct 5 20:15:18 inadyn[16229]: alias address=<2001:**>

dig AAAA **.ddns.net and dig A **.ddns.net return the correct and expected IPv4 and IPv6 values
dig AAAA **.asuscomm.com and dig A **.asuscomm.com BOTH return the IPv6 value only... which I was surprised about as I thought it would just be A - Yes / AAAA - No!

So... I went back to reading this: https://github.com/RMerl/asuswrt-merlin.ng/wiki/DDNS-services Plus this: http://www.snbforums.com/threads/inadyn-configuration-files.72130/post-684701 Plus this https://github.com/troglobit/inadyn#configuration and even this: https://fossies.org/linux/inadyn/man/inadyn.conf.5 for good measure.

Although there's three different options available, I chose to create an original inadyn.conf file, store it in /jffs/configs/ which then, as all of the guidance above says clearly, completely replaces the config file generated by the firmware, which it does indeed and, it works perfectly, so all is good.

It seems that the ONLY remaining issue (not one that causes any actual problems other than faro much logging, but it is still an unnecessary issue) is one that's been here for a while now, which is; the regular re-start of the DDNS service, because of the involvement with IPv6.

This older thread touches on this: https://www.snbforums.com/threads/r...n-when-then-ddns-client-is-not-enabled.69988/ with the last three paragraphs in the final thread post, being a suggested 'fix'

See the next post in this thread for more final thoughts after this re-edit.
 
Last edited:

learning_curve

Occasional Visitor
~~~~~

This older thread touches on this: https://www.snbforums.com/threads/r...n-when-then-ddns-client-is-not-enabled.69988/ with the last three paragraphs in the final thread post, being a suggested 'fix'

See the next post in this thread for more final thoughts after this re-edit.
In a nut shell, it's illustrated right here & commencing really, at line 1252 and then again at line 1369.

@RMerlin You made this post previously, thank you, which made perfect sense back then, but is it still NOT possible to 'fix' this issue? Say as per the quoted text suggestion above?

@dave14305 You added this post to that old thread too, thank you, which is what led to the final post ^ looking for a "fix" for those effected

Example: If you have a DHCP IPv6 address like @archiel did in that older post, then you will have periodic DDNS restarts that are relevant to your DHCP lease time, not ideal but it is what it is. However... if you have a static IPv6 address, but that's provided via Native / PPP ('Bridge' router service provider's own setup choice!), then there is a regular and totally unnecessary (!) DDNS restart. In my case, its every 10 mins... :( This DDNS restart totally over-rules any greater than 10 mins period = SEC value that you have included / specified in your own /jffs/configs/inadyn.conf file and as has already been pointed out now, this only takes effect (annoyingly) with IPv6 NOT iPv4 addresses...
 

RMerlin

Asuswrt-Merlin dev
@RMerlin You made this post previously, thank you, which made perfect sense back then, but is it still NOT possible to 'fix' this issue? Say as per the quoted text suggestion above?
No, in the 7 months since that post, my ISP hasn't added IPv6... I don't expect them to do for years.
 

learning_curve

Occasional Visitor

RMerlin

Asuswrt-Merlin dev
Nice ISP.
It's tied to a major incumbent who has been "testing" IPv6 since 2012. So until that incumbent formally deploys IPv6, my ISP cannot do anything. And after years of having a half-public 6rd test that was suddenly terminated 4-5 years ago, that incumbent only started deploying IPv6 to some of their IPTV customers a few months ago as part of a test, with nobody able to even guess if/when they would broaden the deployment. Until they do, my ISP itself cannot do anything.
 

learning_curve

Occasional Visitor
It's tied to a major incumbent who has been "testing" IPv6 since 2012. So until that incumbent formally deploys IPv6, my ISP cannot do anything. And after years of having a half-public 6rd test that was suddenly terminated 4-5 years ago, that incumbent only started deploying IPv6 to some of their IPTV customers a few months ago as part of a test, with nobody able to even guess if/when they would broaden the deployment. Until they do, my ISP itself cannot do anything.
That does sound 100% sub-optimal :oops: Yet, Here I am, in 'supposedly 3rd World VN', where ironically, we've had FTTH / IPv6 for absolutely ages and are now right in the middle of the big 5G Mobile rollout etc.

To move on from that ^ and thinking of acting on THIS previous post, if I understand correctly, this could be a script, that just includes these two relevant IPv6 elements (under the main #ifdef RTCONFIG_IPV6 section):

static int
deconfig6(char *wan_ifname, const int mode)

and

static int
bound6(char *wan_ifname, int bound)

but... simply nullifies the line: notify_rc("restart_ddns"); that already exists in both of these?

That would in theory leave the period = SEC value that's been included / specified in the self-written /jffs/configs/inadyn.conf file, to determine the correct, chosen DDNS restart (for both IPv4 and IPv6)?

If I've missed the 'glaringly obvious' :D then please advise. If not, I'll happily try that ^ this weekend.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top