What's new

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

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

learning_curve

Senior Member
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:
~~~~~

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 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.
 
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.
 
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.


EDIT: This was solved by me, elsewhere, by pure chance: The details are all in this specific post:
 
Last edited:
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?
 
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.
 
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.
 
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.
 
@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!
 
APNIC ran out of IPV4 before everyone else, that's why they had to rush IPV6 deployment before the rest of the world.
 
: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.
 
: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.
 
I have also problems using DDNS with IPv6.
I have a IPv6 Dual-Stack Lite connection, so my ISP does not provide a public IPv4, but only a public IPv6-address / subnet. I have a AVM Fritzbox as provide device before my ASUS AC86U.
On every forced disconnect (all 24h through ISP) the WAN IPv6 address of my AC86U is renewed. But this does not cause a ddns update event.

It seems that all 24h an automatic renews of the DDNS is done:

The update of the IPv6 address is done at 3:19 in the night, but the ddns only executes the script 24h after the last execution/restart.
Code:
Apr  2 16:33:40 rc_service: dhcp6c 2575:notify_rc restart_ddns
Apr  2 16:33:40 start_ddns: update CUSTOM , wan_unit 0
Apr  2 16:33:40 start_ddns: Clear ddns cache.
Apr  2 16:33:40 custom_script: Running /jffs/scripts/ddns-start (args: 192.168.178.20)
Apr  2 16:33:40 rc_service: ntpd_synced 2574:notify_rc restart_diskmon
Apr  2 16:33:40 rc_service: waitting "restart_ddns" via  ...
Apr  2 16:33:40 ddns: Completed custom ddns update
Apr  2 16:33:41 disk_monitor: Finish
Apr  2 16:33:41 start_ddns: update CUSTOM , wan_unit 0
Apr  2 16:33:41 disk_monitor: be idle
Apr  2 16:33:41 start_ddns: Clear ddns cache.
Apr  2 16:33:41 custom_script: Running /jffs/scripts/ddns-start (args: 192.168.178.20)
Apr  2 16:33:41 ddns: Completed custom ddns update

It would be good if the update could be triggered when the IPv6 address of the eth0/br0 device changed.

I don't know if this is Asus related or can be solved within AsuswrtMerlin. But i found a thread where changes on IPv6 and DDNS seem to be done by Asus:
 
~ ~ I have a IPv6 Dual-Stack Lite connection, so my ISP does not provide a public IPv4, but only a public IPv6-address / subnet. I have a AVM Fritzbox as provide device before my ASUS AC86U.
Can't comment on your setup, as I have Dual Stack with both IPv4 and IPv6 addresses / I use a different router / I have a different ISP etc and you've not detailed which firmware you're using...
On every forced disconnect (all 24h through ISP) the WAN IPv6 address of my AC86U is renewed. But this does not cause a ddns update event. It seems that all 24h an automatic renews of the DDNS is done:

The update of the IPv6 address is done at 3:19 in the night, but the ddns only executes the script 24h after the last execution/restart.
Code:
Apr  2 16:33:40 rc_service: dhcp6c 2575:notify_rc restart_ddns
Apr  2 16:33:40 start_ddns: update CUSTOM , wan_unit 0
Apr  2 16:33:40 start_ddns: Clear ddns cache.
Apr  2 16:33:40 custom_script: Running /jffs/scripts/ddns-start (args: 192.168.178.20)
Apr  2 16:33:40 rc_service: ntpd_synced 2574:notify_rc restart_diskmon
Apr  2 16:33:40 rc_service: waitting "restart_ddns" via  ...
Apr  2 16:33:40 ddns: Completed custom ddns update
Apr  2 16:33:41 disk_monitor: Finish
Apr  2 16:33:41 start_ddns: update CUSTOM , wan_unit 0
Apr  2 16:33:41 disk_monitor: be idle
Apr  2 16:33:41 start_ddns: Clear ddns cache.
Apr  2 16:33:41 custom_script: Running /jffs/scripts/ddns-start (args: 192.168.178.20)
Apr  2 16:33:41 ddns: Completed custom ddns update

It would be good if the update could be triggered when the IPv6 address of the eth0/br0 device changed.

I don't know if this is Asus related or can be solved within AsuswrtMerlin. But i found a thread where changes on IPv6 and DDNS seem to be done by Asus:
Have you had chance to read all of this thread? Including everything that links are provided for?
These questions ^ are because the answers to your questions & your suggestion are already there...

Included in the above, AFAIK, is that in the current Official (not Beta) Firmware releases from Asus, the IPv6 DDNS issues have still not been resolved by Asus themselves (yet) thus, this specific service is still disabled in the current releases of Merlin firmware as a direct result (otherwise too many errors etc). The date this was first disabled is in the Merlin Change-log. It's not (yet) been re-enabled... AFAIK
 
To be honest I did not understand everything what was written here / in the links and what exactly the problem is.
I am using AC86U with most recent firmware AsusWRTMerlin 386.5_2.

Just wanted to express that I also have a problem and I did not understand if this is because of my specific setup (ipv6 dual stack lite using AC86U as second router behind the main router from the ISP). But what I understood from your words is, that IPv6 DDNS is not working correctly in many (all?) setups, even with the most recent (beta) firmwares from Asus.
 
~~
Just wanted to express that I also have a problem and I did not understand if this is because of my specific setup (ipv6 dual stack lite using AC86U as second router behind the main router from the ISP). But what I understood from your words is, that IPv6 DDNS is not working correctly in many (all?) setups, even with the most recent (beta) firmwares from Asus.
Can't comment on any unofficial Asus releases made available via this forum (you could try one for your own router i.e. follow that thread that you posted etc and see) but it's been stated that the Asus fixes for the IPv6 DDNS issues are "expected" (don't hold your breath...:D ) in the Official Asus 386.5.* firmware releases.

The latest (March 25th 2022) Official Asus firmware release for your RT-AC86U is HERE but that's still 386.4.* so it's definitely not fixed in that release (you could also try that, if still in doubt, but can't see any real sense in doing that...). We're both using the latest Merlin firmware release anyway, where it's definitely not fixed yet, because as mentioned, it's been disabled. It will remain that way until after Asus send official 386.5 firmware GPL's direct to Merlin, where they can be enhanced, improved, alpha & beta tested, then released by Merlin.
 
I now have 386.8 which does support IPv6 DDNS but have run into a different problem, that inadyn for asuscomm is set to a default iface=eth0 which in my setup does not have a Global IPv6 address associated.

My ISP is Sky in the UK which uses Option61 to verify/connect (and possibly because of this or possibly because of how the network is configured - I don't have a clear window for a factory reset and rebuild) so while my IPv4 Global IP is on eth0, the IPv6 Global IP is on br0.

I can get DDNS to work by adding the IPv6 address to eth0
Code:
ip -6 address add dev eth0 {ipv6 address}
and probably automate it by editing wan-event to include
Code:
if [ "$1" = "0" ] && [ "$2" = "connected" ]; then
  ip -6 address add dev eth0 $(nvram get ipv6_rtr_addr)
  fi

Alternatively, could I add a second iface setting to inadyn.conf (or inadyn.conf.add) and if so, should it be in the format
Code:
iface=eth0, br0
or
Code:
iface=eth0 br0
or
Code:
iface=eth0
iface=br0
or something else

Does anyone have any views on which is better; adding the WAN IPv6 address to eth0 or expanding the scope of iface in inadyn.conf and if so what the relative merits/ demerits are?

Finally, if anyone else has dynamic IPv6 and Sky (or another option61 connection), do you have your global IPv6 on eth0, br0 or both?

Thanks,

Archiel
 

Similar threads

Sign Up For SNBForums Daily Digest

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