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

[learning_curve]

As per the thread title really; ddns is NOT enabled on the GUI page; /Advanced_ASUSDDNS_Content.asp on this router, yet, every ten minutes; this 2 line script runs:

Feb 4 16:26:30 rc_service: dhcp6c 16211:notify_rc restart_ddns
Feb 4 16:26:30 custom_script: Running /jffs/scripts/service-event (args: restart ddns)

Everything else runs perfectly, with no other errors or similar restarts etc including, IPv6, which although it has a static IPv6 address from the service provider, it's setup with a Native connection type & a PPP Interface on this page: /Advanced_IPv6_Content.asp because, having perviously experimented with both, it works much better this way with this specific service provider! The excellent jackyaz/YazDHCP from @Jack Yaz is used for DHCP / Static Addresses but reasonably sure that's not a contributory factor in this case. First guess is... that this might need a small config change somewhere within this file: ./tmp/etc/dnsmasq.conf but that might be completely wrong and the not my 1st choice option of a factory reset / re-config might be the only answer. Anybody have a clearer insight / previous experience / know how to fix for this? There are lots of threads with pretty similar, but not exactly the same content (that I've seen do far anyway).

 

[L&LD]

What firmware did you upgrade from to the 386.1_0 release final version?

When was the last time you did a full reset?

I don't see this as an issue if you don't also test first with a full reset. Too many possible interactions between firmware versions to account for them all.

Best Practice Update/Setup Router/AiMesh Node(s) 2021

 

[learning_curve]

What firmware did you upgrade from to the 386.1_0 release final version?

When was the last time you did a full reset?

I don't see this as an issue if you don't also test first with a full reset. Too many possible interactions between firmware versions to account for them all.

Best Practice Update/Setup Router/AiMesh Node(s) 2021

The last firmware upgrade was from 384.19 which had run perfectly (and without this producing 'restart ddns' script) The upgrade process from 384.19 > 386.1 all went faultlessly, with no problems or setbacks at all... other than the addition if this 'new' script

The last full reset was made prior to using Asuswrt-Merlin i.e. back in the Asuswrt days.

It looks like I'll have to do a full reset to see if this removes this script, so I'll do it this coming weekend & update after that.

 

[L&LD]

Well, you've had a good run then. If you last reset the router when it was on stock/Official Asus firmware and you've flashed RMerlin firmware and updated it multiple times since then, you're now due.

There are no guarantees if what you've noticed is fixed by doing the above, but it will definitely rule out the possibility of any old interactions with all the firmware installed previously and the one in use today.

 

[learning_curve]

@L&LD Out of interest / advance prep removing all custom scripts and then changing "Enable JFFS custom scripts and configs' followed by a re-boot doesn't remove the script.

It just 'mutes' it (see below). I'm not completely convinced at this stage, that this script will be removed by a full reset, but will update once done at weekend. It does look more like a config setting, somewhere...?

Feb 4 18:39:56 rc_service: dhcp6c 2990:notify_rc restart_ddns
Feb 4 18:39:56 custom_script: Found service-event, but custom script execution is disabled!

 

[L&LD]

No, I wouldn't expect it to.

Are you using a USB drive with amtm powered scripts?

 

[learning_curve]

No, I wouldn't expect it to.

Are you using a USB drive with amtm powered scripts?

No. I don't use many custom scripts at all, so it's easy to add / remove / replace them / re-boot if needed etc There's no USB device plugged in or used at all, for anything.

 

[L&LD]

Then I would still do this part from the link I provided you above.

Beta - Asuswrt-Merlin 386.1 Beta is now available

I recently factory reset my AX88U and currently on Beta 2. After manually setting up everything up again (painfully) my router ALWAYS "crashes" if I make changes now. well I just loses internet and I have to end up rebooting it even though some of the changes made by default doesn't require a...

www.snbforums.com

This should clear out any/all 'scripts' living in JFFS.

But don't forget that amtm 'lives' in newer RMerlin firmware since 384.15_0 and is what is recommended for installing/configuring Entware and (possibly) many other things (via internal scripts).

Also note that doing the above steps will remove OpenVPN clients, servers, and other settings/features you've set. That is why you want to follow all the steps, in order, at once to not need to repeat things needlessly.

 

[learning_curve]

@L&LD There's plenty of work in that post, so this coming weekend it is then...

It just seems odd, that this small, inoffensive but totally unnecessary script, has only appeared in 386.1 and was never seen before in any previous firmware release. I'm somehow... still drawn to an edit of./tmp/etc/dnsmasq.conf & then a re-boot, which I might try, before the full reset process at weekend.

 

[L&LD]

Be sure to check out the following links and any others too before you go down that rabbit hole.

Changelog | Asuswrt-Merlin (asuswrt-merlin.net)

Home · RMerl/asuswrt-merlin.ng Wiki · GitHub

User scripts · RMerl/asuswrt-merlin.ng Wiki · GitHub

Custom config files · RMerl/asuswrt-merlin.ng Wiki · GitHub

 

[learning_curve]

Be sure to check out the following links and any others too before you go down that rabbit hole.
~

Annndddddd the update I followed all the steps given in post #8 above and added an extra NVRAM clearance step too, just for good measure! No problems (apart from the time taken ) and the benefits are clearly visible; slightly reduced operating temperature / reduced NVRAM size / Reduced JFFS size / lower default RAM usage etc. In fact, it was well worth doing, so thanks for that recommendation. I've also added back the scMerlin & YazDHCP scripts and overall, using 386.1 on my router is outstanding. But...

As predicted my myself in an earlier post the every ten minute 're-start ddns' script is still present. To alter the perspective slightly though, I've now enabled ddns (which functions perfectly!) but that just becomes part of the script too. To recap, the thread title is still correct, but now with ddns, it's like this:

Without ddns disabled:

Feb 6 07:15:30 rc_service: dhcp6c 16314:notify_rc restart_ddns
Feb 6 07:15:30 custom_script: Running /jffs/scripts/service-event (args: restart ddns)

With ddns enabled:

Feb 6 08:15:30 rc_service: dhcp6c 17123:notify_rc restart_ddns
Feb 6 08:15:30 start_ddns: update FREEDNS.AFRAID.ORG default@freedns.afraid.org, wan_unit 0
Feb 6 08:15:31 inadyn[17126]: In-a-dyn version 2.7 -- Dynamic DNS update client.
Feb 6 08:15:32 inadyn[17126]: Update forced for alias ******.strangled.net, new IP# ***.***.***.***
Feb 6 08:15:35 inadyn[17126]: Remove old cache file /var/cache/inadyn for ******.strangled.net
Feb 6 08:15:35 inadyn[17126]: Updating cache for ******.strangled.net

So, the only questions remaining now, are these:

Is this 'restart ddns' script only a feature of the Asuswrt-Merlin 386.1 firmware and NOT included in the current Asuswrt firmware? So, other than the fact it clogs up the logs, it causes no detrimental effects anywhere else and therefore, stops complaining, accept it and move on

Or, as above but, the repeat time can be altered by editing ***.*** and changing this 10 minute config?

I cannot find the exact same questions posted anywhere else in this forum (so far).
Maybe, only @RMerlin knows the correct answers to the two questions above but if you have anything further @L&LD I'm happy to listen.

Note: I thought about it, but I did NOT make an edit of./tmp/etc/dnsmasq.conf & then carry out a re-boot.

 

[learning_curve]

@L&LD The conclusion (as I see it) is the 1st option from my previous post, but, continuing after having amended the log level settings on this page: /Main_LogStatus_Content.asp which I've now done c/w the resultant far less log entries Unless, in the future @RMerlin advises differently re the 2nd option.

 

[RMerlin]

Is this 'restart ddns' script only a feature of the Asuswrt-Merlin 386.1 firmware and NOT included in the current Asuswrt firmware?

Based on your log, DDNS gets restarted because you just got an IPv6 lease renewal.

The custom script will always be executed on these events regardless of whether you have DDNS configured, in case someone has a custom DDNS setup that does not use the router's built-in inadyn client. If you don't create that script, then nothing will happen.

 

[learning_curve]

Based on your log, DDNS gets restarted because you just got an IPv6 lease renewal.

The custom script will always be executed on these events regardless of whether you have DDNS configured, in case someone has a custom DDNS setup that does not use the router's built-in inadyn client. If you don't create that script, then nothing will happen.

I didn't expect this little oddity to feature in your 'urgent reply needed' list anytime soon but that's great! & thanks for the pointer @RMerlin

I'd spotted a 'possible' IPv6 link, when I mentioned my current IPv6 setup in post #1 which, ironically, is the same setup now on 386.1 as it was when I used it on 384.19. I haven't (ever) created any scripts myself (so far) so it must be to do with my current chosen IPv6 / ISP interface. I'll experiment more then...

 

[learning_curve]

The 2nd conclusion

My ISP provides a fibre optic connection that's fast, the same speed upload as download and it's 99.99% reliable. No complaints at all on that front. However, despite it being all of this, the static IPv4 and IPv6 addresses that are supplied, only work with them when setup on my RT-AC68U as; IPv4 via PPPoE and IPv6 via PPP. No other setup configs work, apart from IPv6 on Passthrough which is a bit pointless really. This might be because the ISP provides a router, which is using a bridge setup, prior to the RT-AC68U.

IF... the RT-AC68U router supported IPv6 via PPPoE then that might have changed things, but, as per the line at the very bottom of these recently updated ASUS IPv6 notes - "Currently, ASUS Wireless router does not support setting up PPPoE in IPV6". No slight or subtle changes to the working setups above makes any difference to the script running. I haven't written the script myself and it isn't part of my add-on scMerlin & YazDHCP scripts (as far as I can see). Finally, no IPv4 or IPv6 leases are being renewed every 10 mins by my ISP. I can't identify what appears to be, an IPv6 lease-renewal related instigator for the script, but I can adjust the system log levels settings, so that I haven't got endless repetitive notifications of this script in the logs. 386.1 runs faultlessly on my RT-AC68U apart from, this script, so it is what it is!

 

[learning_curve]

Both the 1st and 2nd conclusions that I made earlier in this thread were wrong as the real 'clue' wasn't visible until I ran a dirty upgrade from 381.1 to 381.1_2 (plus an additional re-boot afterwards).

386.1_2 runs even better for me that 386.1 did - If that's possible(!) so no complaints there, but having re-examined the logs (by altering the settings again, just to double check things), it became clear that this post :http://www.snbforums.com/threads/asuswrt-merlin-386-1-is-now-available.69783/post-663216 by you @RMerlin and in detail, these two lines, although specifically the 2nd line in this case:

- UPDATED: inadyn to 2.8.1.

- FIXED: IPv6 ending with "::" were considered invalid on the
webui (was breaking the Prefix field on the 6in4 tunnel
page for instance).

was the reason behind the IPv6 'glitch' mentioned previously. That's because on my setup, the LAN IPv6 Prefix DOES end with "::" hence the constant calls for a "recognised" IPv6 address etc etc. The updated inadyn default setup can be changed (if required) using this reference page (or several others): https://fossies.org/linux/inadyn/man/inadyn.8

So @RMerlin this post is '...just in case...' this comes up again somewhere, as there's now a reference to it and the info is over and above the existing details included in the fix details you've already posted.

 

[archiel]

Both the 1st and 2nd conclusions that I made earlier in this thread were wrong as the real 'clue' wasn't visible until I ran a dirty upgrade from 381.1 to 381.1_2 (plus an additional re-boot afterwards).

386.1_2 runs even better for me that 386.1 did - If that's possible(!) so no complaints there, but having re-examined the logs (by altering the settings again, just to double check things), it became clear that this post :http://www.snbforums.com/threads/asuswrt-merlin-386-1-is-now-available.69783/post-663216 by you @RMerlin and in detail, these two lines, although specifically the 2nd line in this case:


was the reason behind the IPv6 'glitch' mentioned previously. That's because on my setup, the LAN IPv6 Prefix DOES end with "::" hence the constant calls for a "recognised" IPv6 address etc etc. The updated inadyn default setup can be changed (if required) using this reference page (or several others): https://fossies.org/linux/inadyn/man/inadyn.8

So @RMerlin this post is '...just in case...' this comes up again somewhere, as there's now a reference to it and the info is over and above the existing details included in the fix details you've already posted.

Hi @learning_curve can you help?

I am running 386.1_2 and still getting the rc_service: dhcp6c 2990:notify_rc restart_ddns every 30 minutes. As with your setup, my ipv6 prefix ends with ::
I am currently using the Asus DDNS service, even though it does not support IPv6, as the programs I need DDNS for also don't support IPv6.
What I do not understand is how to update the setup to prevent the constant checks. I am guessing that the issue is with verify-address and the resultant IPv6 verification failure due to :: What I cannot see is how to verify just IPv4, or to otherwise fix this.

Thanks Archiel

 

[learning_curve]

....I am guessing that the issue is with verify-address and the resultant IPv6 verification failure due to :: What I cannot see is how to verify just IPv4, or to otherwise fix this...

It certainly was in my case yes. Surprised that's not been rectified in your case too, seeing as you're also running 386.1._2 now. Having said that, I am using freedns.afraid.org hence the ******.strangled.net ddns name that's now being used i.e. I am NOT using the Asus ddns service any more. I changed that as part of trying to figure out what was wrong earlier on (prior to post #11 on here). I made the change because, I had read lots of posts on here, where others had posted that the Asus ddns was somewhat '...not consistent and/or reliable...' in terms of its usage and also with Let's Encrypt, so I changed it.

Out of interest, If you disable DDNS and then re-enable it, what do your logs show then? Same as my post #11 above? Plus, did you (at some point) do the full belt and braces reset, as shown ^ in post #8?

 

[archiel]

It certainly was in my case yes. Surprised that's not been rectified in your case too, seeing as you're also running 386.1._2 now. Having said that, I am using freedns.afraid.org hence the ******.strangled.net ddns name that's now being used i.e. I am NOT using the Asus ddns service any more. I changed that as part of trying to figure out what was wrong earlier on (prior to post #11 on here). I made the change because, I had read lots of posts on here, where others had posted that the Asus ddns was somewhat '...not consistent and/or reliable...' in terms of its usage and also with Let's Encrypt, so I changed it.

Out of interest, If you disable DDNS and then re-enable it, what do your logs show then? Same as my post #11 above? Plus, did you (at some point) do the full belt and braces reset, as shown ^ in post #8?

I have been playing around with this a bit more and am still very confused. In respect of your last point, yes this was a full a full belt and braces reset, with all settings re-added manually.

I have IPv6 native and I get the 7 log lines every 30 minutes
The IPv6 (and IPv4) addresses do not change (or if they are renewed it is to the same values - is there a way to check this)?
If I disable IPv6 then the script stops running
If I enable IPv6 and disable DDNS, then the script runs every 30 minutes but with only 2 lines

Feb 16 14:19:16 RT-AX88U-5050 rc_service: dhcp6c 3942:notify_rc restart_ddns
Feb 16 14:19:16 RT-AX88U-5050 custom_script: Running /jffs/scripts/service-event (args: restart ddns)
Feb 16 14:49:06 RT-AX88U-5050 rc_service: dhcp6c 29027:notify_rc restart_ddns
Feb 16 14:49:06 RT-AX88U-5050 custom_script: Running /jffs/scripts/service-event (args: restart ddns)

etc.
The entries did not appear in the logs under 384.19 (or earlier)

In your case did using freedns.afraid.org result in the log lines going away (or is the IPv6 address actually changing)?
Or is the router still generating the messages, but you are no longer seeing them due to changing the logging levels (if you are using the default Syslog and have not installed Scribe)?
Have you set up your DDNS to work with IPv6? As noted earlier Asus DDNS does not support IPv6, so there is nothing for inadyn to change.

Thanks, Archiel.

 

[learning_curve]

I have been playing around with this a bit more and am still very confused. In respect of your last point, yes this was a full a full belt and braces reset, with all settings re-added manually.

That was prior to your firmware change from 384.19 to 386.1 presumably, just like I did? Well that's one possible contributory cause removed, although you might have to fallback to doing this again and setting up 386.1_2 from scratch in order to solve this, if it can't be cured any other way (eg IPv6 setup)

I have IPv6 native and I get the 7 log lines every 30 minutes
The IPv6 (and IPv4) addresses do not change (or if they are renewed it is to the same values - is there a way to check this)?

You've not posted them, but presumably, the 7 loglines are the two IPv6 lines that you have shown above/below plus five IPv4 lines, which correctly validate your IPv4 ddns address? Is that right?

If I disable IPv6 then the script stops running
If I enable IPv6 and disable DDNS, then the script runs every 30 minutes but with only 2 lines

Yes, with IPv6 disabled there's no reason to run any IPv6 checks, but with it enabled, there is, by default

Feb 16 14:19:16 RT-AX88U-5050 rc_service: dhcp6c 3942:notify_rc restart_ddns
Feb 16 14:19:16 RT-AX88U-5050 custom_script: Running /jffs/scripts/service-event (args: restart ddns)
Feb 16 14:49:06 RT-AX88U-5050 rc_service: dhcp6c 29027:notify_rc restart_ddns
Feb 16 14:49:06 RT-AX88U-5050 custom_script: Running /jffs/scripts/service-event (args: restart ddns)

etc.

These are more examples of the two IPv6 lines, that you have mentioned above.

The entries did not appear in the logs under 384.19 (or earlier)

Yes, that was the case for me too. They only appeared once the firmware was upgraded to 386.1 but then disappeared when this firmware became 386.1_2 c/w bug fixes, as I posted previously.

In your case did using freedns.afraid.org result in the log lines going away (or is the IPv6 address actually changing)?

No. It was the firmware change to 386.1_2 that made the corrective change not any ddns changes.

Or is the router still generating the messages, but you are no longer seeing them due to changing the logging levels (if you are using the default Syslog and have not installed Scribe)?

I can confirm that I do not receive any more of those specific IPv6 related messages that I used to receive, but, only after changing the firmware to 386.1_2. Yes, I can alter the log levels easily via the GUI to check/double check if/when/what etc but I have not installed Scribe as I have no current need for it.

Have you set up your DDNS to work with IPv6? As noted earlier Asus DDNS does not support IPv6, so there is nothing for inadyn to change.

You can set afraid.org to run IPv6 ddns yes - if you want to. You have the choice of referencing A records for IPv4 or AAAA records for IPv6 or, you can combine both methods - if you want to. Having said all of that, I don't believe that it is the "cure" for this particular issue. I still think it's firmware related.