DDNS Error DSL-AX82U-AX5400

[TrebleTA]

Since this new firmware I've been getting a DDNS error, on my DSL-AX82U-AX5400.
Aug 30 17:45:00 rc_service: service 17995:notify_rc restart_letsencrypt
Aug 30 17:45:00 Let's Encrypt: Err, DDNS update failed.

Also on the DDNS page I get its active then it's not see picture.

[TrebleTA]

On the above page all sudden I got a new option about ipv6 setup or something I clicked it applyed and it worked untill I reset the device. If i get it show again i will screen shot.

[STARRAIN_ROG]

Hi TrebleTA,
Did you see DDNS error in syslog?
Was DDNS function working fine when you see the error?
If it was not working and the issue occurs again, may I know how you check it?
Thank you.

[TrebleTA]

If you look at the above picture your see at bottom it says active, yet ddns status is inactive, it's not updating. I have not changed anything just noticed it after a reboot of the device, yet changing the settings to external has fix it, see pic.



Yet I did not change anything, untill I've noticed the ab9ve errors in the system log.

Not sure what you mean, how do I check it, I can type my ddns name in the asus iplook up and was my older IP address, or I can use my ddns name and it shows nothing.

[Murph_9000]

The "Active" at the bottom of the page is only for the TLS (SSL/HTTPS) certificate, which only renews every 90 days. The certificate is name based, not numeric address based, so doesn't need to update when the IP changes. The DDNS binds the name to the address; it updates when your WAN interface comes up, periodically, and if your WAN IP changes. Essentially that active status at the bottom of the page is cached from when it last successfully obtained/updated the encryption certificate. The "Let's Encrypt" service on the router aborts as it's supposed to do when the DDNS service fails and the DDNS hostname (configured on the page) hasn't changed, and is really just log noise that should be ignored when the DDNS has issues (fix the DDNS first, then worry about Let's Encrypt only if it continues to log errors).

Seems like there's a bug in the DDNS service on the new firmware, sounds like it's not detecting the WAN IP correctly (with the internal method, but the external method apparently works). The above is just to clarify that you need to ignore the Let's Encrypt side of it when looking at a DDNS problem, and what the two halves of that config page are about.

It may not be the problem here, but incorrect external address by the internal method could be due to a problem at the ISP end. You should check that your WAN interface isn't being assigned a RFC1918 private address (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 ranges) or falling back to a RFC3927 automatic address (169.254.0.0/16 range), and that you're seeing the a correct public IP address on the interface.

There are various sites out there which will tell you the your public IP address, to confirm what's sites outside your ISP see. You can just stick "what is my IP" into Google search, or Google recommend a couple of sites for getting that info in more detail:

• whatsmyip.org
  
• whatismyip.com
  

Although the problem appeared to coincide with a firmware update, the restart of the router which accompanied the update would request/renegotiate the IP address with your ISP, so it's possible the problem was at their end. If your ISP service is supposed to include a public IP address and doesn't have any NAT or proxy setup on the ISP end, the address on your WAN interface should normally match the address reported by those sites (or be on the same subnet if your service includes multiple addresses).

[TrebleTA]

Aye the router was rebooted, from a local power cut. I got a new ip address from my ISP, but it was not getting updated somewhere on the ddns, untill I changed the above, else all was running fine till I went to connect remotely.

[Murph_9000]

TrebleTA wrote:
Aye the router was rebooted, from a local power cut. I got a new ip address from my ISP, but it was not getting updated somewhere on the ddns, untill I changed the above, else all was running fine till I went to connect remotely.

If the external IP looks good/correct when you look at the WAN interface, then it's almost certainly a bug in the DDNS service's internal mechanism for determining the WAN IP. There shouldn't be any significant downside to just leaving that set as external; it basically just pings (likely over HTTP/HTTPS, but I'm not certain of that) an external server saying "what is my IP?" and uses the response. If that's working ok, it should be fine as a medium term workaround for the bug. It should just be able to use the address directly off the interface, which is a bit more optimal, but it seems that it's not doing that correctly for you.

For what it's worth, DDNS works normally using the internal method for the address on the GT-AX6000 running 3.0.0.4.386_49556 with PPPoE to VDSL via an Ethernet modem-bridge (simple ISP router in bridge mode). That doesn't directly help you, but may narrow down the version range for where the bug was introduced.

[TrebleTA]

Aye, I'd say there is a bug there with the internal side. Yet could be down to my ISP being full IPV6, as I did get some other option, yet I cant use ipv6 on the device as QOS dont work also some other features at the moment, that dont work correctly, so ipv6 is off client side yet DSL side hope its correct

[STARRAIN_ROG]

Hi TrebleTA,
May I double confirm DDNS was not updated after the router was rebooted from a local power cut? and fix it by choosing "external" of method to retrieve WAN IP option in DDNS setting and apply it again?
If the issue occurs again, could you please send feedback to us right after the issue occurring and share me the following information via PM?
- the email address you filled in feedback
- the issue occurred time and feedback sent time
- your DDNS host name and WAN IP before/after router rebooted
Thank you.

[TrebleTA]

Hi ya, that is correct. I still have a log to send for wifi it will all be in there will do in the next day or two. Also noticed a new error today.
acsd: acsd_main_loop(1176): sync_id: 6731, status:1, misc.error/abort.