Management of DDNS when using IPv6 / Overcoming the default: notify_rc("restart_ddns"); command

  • 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
The final re-edited / updated / posted errors removed, version of all 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 was 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 was 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 is still apparently IPv4 only at present (although the coding is in place it seems...) So... I went back to reading all of this again: 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 inadyn data https://github.com/troglobit/inadyn#configuration and even this broad overview / simplified version: https://fossies.org/linux/inadyn/man/inadyn.conf.5 just for good measure. All make perfect sense.

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 relative guidance above clearly says, completely replaces the config file generated by the firmware, which indeed it does and so it all works perfectly (including IPv6 DDNS).

It seems that the ONLY remaining issue (not one that causes any actual problems other than far too 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 aspect is NOT covered in ANY of the above because the notify_rc("restart_ddns"); command ONLY takes place IF your router uses IPv6 & DDNS.

See the following posts (my errors removed / corrected) in this thread, for more relevant after-thoughts to this issue too.
 
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.
 

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
So, after much digging, this issue appears to be unsolvable - currently - anyway, because of these factors:

This code: https://github.com/RMerl/asuswrt-merlin.ng/blob/master/release/src/router/rc/udhcpc.c which is the provider of the notify_rc("restart_ddns"); command that is IPv6 related only & thus the cause of the regular but totally unnecessary (!) DDNS restarts, cannot be altered/corrected via a script. It would need changing and then a re-compile to produce a custom version of the Merlin provided firmware, which, I have no deep desire to do because.... AFAIK (@RMerlin ?) there is no current ability to include a modified copy of the udhcpc.c file (link above) within the /jffs/configs/ area, which therefore, leads back to a re-compile & resultant custom version of the Merlin provided firmware being the only - current - workaround, that's available to solve this.

In the future though; This older thread touches on this issue, with the last three paragraphs in THIS the final post in that thread, being a suggested future, possible 'fix' which could be included at some stage.
 

N/A

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.
Is Videotron still limiting native IPv6 to helix only? Feel bad for all the TPIA customers. Just a random thought but would it be possible for you to test IPv6 with mobile hotspot?
 

RMerlin

Asuswrt-Merlin dev
Is Videotron still limiting native IPv6 to helix only?
Probably (and even then I believe it was still a gradual rollout, maybe still in a testing phase for just a few nodes, I don't think they are rolling out to all Helix customers).

Nobody knows if they will eventually open that to TPIAs as well. Telus did in the west I believe (I think TSI support IPv6 over Telus). Don't remember if that's the case with Rogers.

Personally, I'm more interested in seeing Vidéotron complete the switch to DOCSIS 3.1, and start offering faster upstream speeds. Right now it's an hybrid setup, with DS being 3.0, and US being 3.1.

Just a random thought but would it be possible for you to test IPv6 with mobile hotspot?

I can't connect a router to a hotspot (Asuswrt does not support Wireless Client mode).

A few months ago I managed to create a virtual machine that can act basically like a "Virtual ISP", using an IPv6 HE tunnel, then delegating a /64 out of my /48 to a router connected to that virtual machine. But doing any testing/development on that setup is a lot more complicated than my daily development done on my primary LAN (since I'd need my dev machine to be connected behind that second router). Not something I have the motivation to devote the extra time to right now, sorry. Already have too much on my plate as it is.
 

N/A

Occasional Visitor
Probably (and even then I believe it was still a gradual rollout, maybe still in a testing phase for just a few nodes, I don't think they are rolling out to all Helix customers).

Nobody knows if they will eventually open that to TPIAs as well. Telus did in the west I believe (I think TSI support IPv6 over Telus). Don't remember if that's the case with Rogers.

Personally, I'm more interested in seeing Vidéotron complete the switch to DOCSIS 3.1, and start offering faster upstream speeds. Right now it's an hybrid setup, with DS being 3.0, and US being 3.1.



I can't connect a router to a hotspot (Asuswrt does not support Wireless Client mode).

A few months ago I managed to create a virtual machine that can act basically like a "Virtual ISP", using an IPv6 HE tunnel, then delegating a /64 out of my /48 to a router connected to that virtual machine. But doing any testing/development on that setup is a lot more complicated than my daily development done on my primary LAN (since I'd need my dev machine to be connected behind that second router). Not something I have the motivation to devote the extra time to right now, sorry. Already have too much on my plate as it is.
Not sure if it's possible in Quebec but Fido has FREE (need to chat online with retention) 4GB tablet data SIM in other provinces. Rogers and its subsidiaries have native IPv6 enabled on mobile network. Get a cheap old mobile hotspot device that has an ethernet port and you are all set. Cost little money but takes some time to set up. Hopefully Videotron can allow TPIA IPv6 soon.

DOCSIS 3.1 upload isn't coming anytime soon. Your best chance is to get FTTH with Bell or EBOX when they come to your neighbourhood. Even Rogers is switching to FTTH XGS-PON in Newfoundland and Ontario.
 

RMerlin

Asuswrt-Merlin dev
DOCSIS 3.1 upload isn't coming anytime soon. Your best chance is to get FTTH with Bell or EBOX when they come to your neighbourhood. Even Rogers is switching to FTTH XGS-PON in Newfoundland and Ontario.
I already have DOCSIS 3.1 upload. It's the download that's still using 32 DOCSIS 3.0 channels. They need to get rid of the old Illico junk to free up some frequency channels.
 

learning_curve

Occasional Visitor
@RMerlin @N/A FWIW ;) The irony of this thread, is, that I'm the one with the IPv6 / DDNS / Firmware coding related issue mentioned, yet I'm located in '3rd World' Vietnam but, here, we have FTTH practically everywhere, really! Thus my ISP doesn't use any release of DOCSIS. Yet, back in my home country (The UK) one of the biggest ISP's Virgin Media, who are using DOCSIS 3.1 everywhere (because there's miles and miles of existing coaxial cable systems in most location) also, still don't provide IPv6 addresses to users, yet they could do, if... they wanted to!
 

RMerlin

Asuswrt-Merlin dev
APNIC ran out of IPV4 before everyone else, that's why they had to rush IPV6 deployment before the rest of the world.
 

learning_curve

Occasional Visitor
:D Yes, they are quite good at rushing here. Things that would get delayed elsewhere, by either red tape / H&S 'issues' / committee meetings... Somehow, just get done. Next, is a full 5G rollout!

Having a Communist Government in charge, unsurprisingly, Vietnam 'manage their own shop': https://www.vnnic.vn/en?lang=en/ which is an NIR within APNIC, but IPv4 and IPv6 (rushed or not) all work extremely well here & nearly all ISP devices have a Dual Stack setup by default, too.
 

PeterR

Regular Contributor
:D Yes, they are quite good at rushing here. Things that would get delayed elsewhere, by either red tape / H&S 'issues' / committee meetings... Somehow, just get done. Next, is a full 5G rollout!

Having a Communist Government in charge, unsurprisingly, Vietnam 'manage their own shop': https://www.vnnic.vn/en?lang=en/ which is an NIR within APNIC, but IPv4 and IPv6 (rushed or not) all work extremely well here & nearly all ISP devices have a Dual Stack setup by default, too.
Same in Malaysia, we've had FTTH for several years. I'm very thankful for the change, as we have the third highest frequency of lightning strikes in the world & I can tell you whatever 'surge protector' you put between a copper telephone line and a modem doesn't work.

The lack of ipv4 addresses is also being felt here.
 

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