RT-AC68U - Why does the 'restart ddns' script run, when then ddns client is not enabled?

[dave14305]

Setup a benign /jffs/scripts/dhcpc-event script which will be harmlessly invoked on wan dhcp events. The ddns restart will be called for IPv6 stopped or bound events. You can see the code by searching for ddns in https://github.com/RMerl/asuswrt-merlin.ng/blob/master/release/src/router/rc/udhcpc.c.

 

[archiel]

Hi @learning_curve

Thanks for your answer

• The full reset (WPS followed by manual re-configuration) was AFTER upgrading directly from 384.19 to 386.1_2 (i never installed 386.1)
• Correct, the IPv4 address is the same in each line
• Despite being on 386.1_2, the lines are still there.
• Could you set your log levels to debug, just to check the lines are gone and let me know

Hi @dave14305

Thanks for the suggestion, can you walk me though how I do this

Using WinSCP I can create /jffs/scripts/dhcpc-event
I searched for DDNS and I can see what looks like a script starting at line 1222 running to 1556
Do I copy & paste this 'as is' or do I need to edit it / process it in any way first?
Do I need to add #!/bin/sh at the start of the file?
Do I set properties to 0755?
Do I need to restart the router for the new script to be recognised?

Thanks

Archiel

 

[dave14305]

Thanks for the suggestion, can you walk me though how I do this

Using WinSCP I can create /jffs/scripts/dhcpc-event
I searched for DDNS and I can see what looks like a script starting at line 1222 running to 1556
Do I copy & paste this 'as is' or do I need to edit it / process it in any way first?
Do I need to add #!/bin/sh at the start of the file?
Do I set properties to 0755?
Do I need to restart the router for the new script to be recognised?

You don’t need anything in the script except the #!/bin/sh. You don’t need it to do anything. Just needs to be present and executable so that the firmware will log its invocation to syslog during a dhcp event on the WAN.

The source code reference was only to let you all see where or why ddns is being called, if you are curious.

 

[learning_curve]

Could you set your log levels to debug, just to check the lines are gone and let me know

Setting the logs to 'debug' status and then waiting sufficient time for any IPv6 related log entries to occur, produces no relevant or connected output from my current setup. FWIW I connected via SSH and ran the command from there; # inadyn −1, −-once The entries in the log after doing that are as follows:

Feb 17 20:49:22 dropbear[10298]: Pubkey auth succeeded for '***-***' with key ************
Feb 17 20:50:55 inadyn[10386]: In-a-dyn version 2.8.1 -- Dynamic DNS update client.
Feb 17 20:50:57 inadyn[10386]: Update forced for alias *****.strangled.net, new IP# *********
Feb 17 20:51:00 inadyn[10386]: Remove old cache file /var/cache/inadyn for *****.strangled.net
Feb 17 20:51:00 inadyn[10386]: Updating cache for *****.strangled.net
Feb 17 20:52:37 inadyn[10564]: In-a-dyn version 2.8.1 -- Dynamic DNS update client.

These entries are exactly as expected - in my case anyway.

 

[archiel]

Setting the logs to 'debug' status and then waiting sufficient time for any IPv6 related log entries to occur, produces no relevant or connected output from my current setup. FWIW I connected via SSH and ran the command from there; # inadyn −1, −-once The entries in the log after doing that are as follows:

These entries are exactly as expected - in my case anyway.

Thanks for checking, I think (hope) I am almost there

Using the script suggested by @dave14305 I can see that there is is lease renewal request every 30 minutes and looking at Network Map > Internet Status this would correspond with my ISP setting the lease time at 60 minutes. What is the lease time with your ISP?

What seems different (in 386.1_2) is that this now triggers the restart ddns service event, even though the old and new addresses (IPv4 & IPv6) are the same. I am guessing that for IPv4, the logic that determines whether to trigger inadyn or not includes something that recognises old address=new address. I am also guessing that this was also the case for IPv6 running on 384.19, but that this is no longer the case for 386.1_2.

 

[learning_curve]

....and looking at Network Map > Internet Status this would correspond with my ISP setting the lease time at 60 minutes. What is the lease time with your ISP?

I have static IPv4 and IPv6 addresses from my ISP, so I'm not sure / aware that there is a short term lease that is applied to either. Edited image below for Network Map > Internet Status

What seems different (in 386.1_2) is that this now triggers the restart ddns service event, even though the old and new addresses (IPv4 & IPv6) are the same. I am guessing that for IPv4, the logic that determines whether to trigger inadyn or not includes something that recognises old address=new address. I am also guessing that this was also the case for IPv6 running on 384.19, but that this is no longer the case for 386.1_2.

In theory you could confirm that ^^ by comparing specific areas of code in 384.19 & 386.1_2. It would be interesting to glean the actual true reasons, after all of your previous investigative work.

.

 

[dave14305]

It looks like ASUS added IPv6 support for their DDNS service in 386_41350.

 

[archiel]

It looks like ASUS added IPv6 support for their DDNS service in 386_41350.

Learner question - where would I find details of this / what is included in the firmware? Their current FAQ still says no support ASUS Wireless Router DDNS service and VPN function both not support IPv6 | Official Support | ASUS Global

Also does this just mean that the router DDNS service now supports IPV6 for DDNS providers that have this option (e.g. FreeDNS) or does it also mean that Asus's own DDNS service ***asuscomm.com supports this

 

[dave14305]

Learner question - where would I find details of this / what is included in the firmware? Their current FAQ still says no support ASUS Wireless Router DDNS service and VPN function both not support IPv6 | Official Support | ASUS Global

Also does this just mean that the router DDNS service now supports IPV6 for DDNS providers that have this option (e.g. FreeDNS) or does it also mean that Asus's own DDNS service ***asuscomm.com supports this

All I can say is 386 added awareness of IPv6 addresses to the asuscomm inadyn plugin. Whether it's truly active or not is another question.

asuswrt-merlin.ng/release/src/router/inadyn/plugins/asuscomm.c at master · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

 

[archiel]

I have static IPv4 and IPv6 addresses from my ISP, so I'm not sure / aware that there is a short term lease that is applied to either. Edited image below for Network Map > Internet Status

In theory you could confirm that ^^ by comparing specific areas of code in 384.19 & 386.1_2. It would be interesting to glean the actual true reasons, after all of your previous investigative work.

View attachment 30902.

I have to concede that I would not know where to even find the relevant bits of code, let alone how to compare them, but as @dave14305 noticed that Asus DDNS now supports IPV6 (not sure how) combined with your confirmation that your ISP has allocated static IPs (which would mean there is no regular lease event to trigger DDNS checking) leads me to suggest that it may work something like

At any point the router will have external address(es) (IPv4 & IPv6)

1. Those IP addresses need to be stored for comparison in /var/cache/inadyn/{DDNS name}.cache and provided to the DDNS service
2. When there is some form of renewal event (in my case every 30 minutes) the old and new addresses are compared and where there is a change the data is updated (cache and DDNS provider)

In my case, although I am running IPv6 native there is no IPv6 address stored in the the cache file, so when there is a renewal or similar event, while the logic can see that the IPv4 address is unchanged (and so no further action is required) there is nothing to flag that the IPv6 is unchanged and so the DDNS update process kicks off.

Just a guess, happy to be corrected.

 

[archiel]

All I can say is 386 added awareness of IPv6 addresses to the asuscomm inadyn plugin. Whether it's truly active or not is another question.

asuswrt-merlin.ng/release/src/router/inadyn/plugins/asuscomm.c at master · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

Missed this posting my last reply, but looking at the code (of which I understand about 1%) it does seem to imply the the asuscomm service can support IPV6, but I cannot see how to check if it working. Using lines 40 and 42 to get ns1.asuscomm.com/myip.php, I get my IPv4 address but I do not see what command / URL I can use to see if it is also picking up the IPv6 address.

 

[learning_curve]

....In my case, although I am running IPv6 native there is no IPv6 address stored in the the cache file, so when there is a renewal or similar event, while the logic can see that the IPv4 address is unchanged (and so no further action is required) there is nothing to flag that the IPv6 is unchanged and so the DDNS update process kicks off.

All of that makes logical sense to me, but then produces the question; How / where / how can the time period / occurrence in between renewals (or a similar event) be customised or changed? That would then reduce the number of entries in your log & minimise the wasted IPv6 checks wouldn't it?

 

[archiel]

All of that makes logical sense to me, but then produces the question; How / where / how can the time period / occurrence in between renewals (or a similar event) be customised or changed? That would then reduce the number of entries in your log & minimise the wasted IPv6 checks wouldn't it?

AFAIK the default checks are run 30 minutes before the lease renewal time and at the lease renewal time, so with 60 minute lease from my ISP (Sky) then I think I am stuck with 2 checks per hour.

Also, although the inadyn plugin code asuscomm.c has been updated to include IPv6, I assume this is designed to work with any DDNS service that is accessed through the router DDNS page and that this also requires the DDNS service to support IPv6 at their end, otherwise there is no IPv6 address to check or update.

With IPv4, inadyn only runs the update sequence on lease checking/renewal if the address has changed (or at lease there are no log entries unless the lease has changed). As Sky addresses are sticky this is only rarely, usually the addresses only change on a reboot (router or modem) or if there has been some form of external line problem. This could explain why these entries were not there with 384 and also not there with IPv6 disabled.

With IPv6 enabled and using asuscomm.com as the DDNS service, no IPv6 address is obtained and inadyn runs the full update process, hence the log entries every 30 minutes.

@RMerlin Is the above a reasonable description if what is happening or, if I have got is all wrong, how is inadyn intended to work in conjunction with IPv6 and what else can I try to see why the renewal and update process runs every 30 minutes when there has been no change?

Thanks Archiel

 

[RMerlin]

Any inadyn update will be logged in the system log.

I can't comment on IPv6 support as I have no way of testing it.

 

[archiel]

Any inadyn update will be logged in the system log.

I can't comment on IPv6 support as I have no way of testing it.

Thank you. So as the lease renewal only triggers inadyn for IPv6, where the first step in the log sequence is

rc_service: dhcp6c 17123:notify_rc restart_ddns

which in turn triggers

custom_script: Running /jffs/scripts/service-event (args: restart ddns)
start_ddns: update WWW.ASUS.COM update@asus.com, wan_unit 0

do you know where can I look to see why the same lease renewal does not trigger service-event (args: restart ddns) for IPv4?

 

[dave14305]

do you know where can I look to see why the same lease renewal does not trigger service-event (args: restart ddns) for IPv4?

The restart_ddns is only present in the IPv6 deconfig6 and bound6 functions. It’s not present in the IPv4 deconfig or bound variants.

asuswrt-merlin.ng/release/src/router/rc/udhcpc.c at master · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

 

[learning_curve]

Thank you. So as the lease renewal only triggers inadyn for IPv6, where the first step in the log sequence is

rc_service: dhcp6c 17123:notify_rc restart_ddns

which in turn triggers

custom_script: Running /jffs/scripts/service-event (args: restart ddns)
start_ddns: update WWW.ASUS.COM update@asus.com, wan_unit 0

do you know where can I look to see why the same lease renewal does not trigger service-event (args: restart ddns) for IPv4?

AFIK and going back to my post #11 in this thread, the change of process, i.e. the active inclusion of IPv6 has happened only after the change in Merlin firmware from 384.19 and 386.1_2 (but as a result of an Asus firmware change...) hence, post #13 from @RMerlin still makes perfect sense IF, your IPv6 WAN address is being renewed and/or is not present and this is regardless of DDNS being active.

If DDNS IS active, then as you've seen yourself above @archiel (and as my own post #11 also confirms), the IPv6 action then triggers the IPv4 DDNS verification too (even if it's not actually necessary!)

The ideal solution to all, would appear to be, having the ability to disable the IPv6 check process, by way of adding a comment out # prefix in the right area of code or ultimately, a Yes/No GUI value.

This, would then accommodate a) All those that don't use IPv6 at all b) All those that have a static IPv6 address c) All those that have a static IPv6 address but only static as far as a firm, non variable LAN IPv6 Prefix (hence IPv6 pool of addresses below on the router) is concerned, as their own specific WAN IPv6 may / will change, after a router re-boot (unlike IPv4) but change only within the relative WAN IPv6 pool, thus still allowing the firm, non variable LAN IPv6 Prefix value on the router to remain. All those with a dynamic IPv6 address would / should be able to use this as intended i.e. check enabled I think?

The GUI value option is one for a possible inclusion in future firmware, but, after some detective work, it should be possible to work out how to comment out the specific requirement within the current code?