ulygit/asus_rt_ac68u

Configuration and script for Cloudflare DDNS on Asuswrt-Merlin

Cloudflare Dynamic DNS Update Script for Asuswrt-Merlin (on supported ASUS routers)

Note: Starting with version 384.7 (circa 2018), Asuswrt-Merlin uses In-a-dyn for DDNS updates. The In-a-dyn client adds support for many DDNS services now including Cloudflare. User @bengalih has reported initial success transitioning to In-a-dyn from this script. New users are encouraged to try that option first as it is likely better supported and includes features lacking from this script. For more information, please see the introduction to In-a-dyn in the asuswrt-merlin project documentation.

The Asuswrt-Merlin custom firmware adds support for custom dynamic DNS providers to various ASUS routers. This is great for Cloudflare users because, although Cloudflare is not one of the built-in providers, we can add support for it. This guide and accompanying script do exactly that. Confirmed works on the following model routers:

• GT-AX11000, and
• GT-AXE11000,
• RT-AC3200,
• RT-AC66U,
• RT-AC68U,
• RT-AC87U,
• RT-AC88U,
• RT-AX58U,
• RT-AX86U, and
• RT-AX88U.

Features include:

• Support for querying your Cloudflare DNS zone to determine record IDs
• Handling of Merlin firmware success/failure callbacks
• Logging of JSON responses for later inspection, and
• Configurable rate-limiting to comply with Cloudflare API TOS

Contributors

• @epicylon - Verified works on RT-AC66U
• @bengalih - Several contributions toward support for API Tokens, proxying, and other enhancements.
• @gumanov - Verified works on RT-AX88U
• @clayauld - Verified works on RT-AC87U
• @ilasoft - Verified works on RT-AX86U
• @sujitph - Verified works on GT-AX11000
• @Rapsssito - Verified works on RT-AC3200
• @vnlebaoduy - Verified works on RT-AX58U
• @Tech1k - Verified works on GT-AXE11000
• @maagmirror - Verified works on RT-AC88U

Known Issues

• Script fails on firmware running certain, older versions of curl. User @bengalih identified this bug as affecting curl version 7.54.1, other versions are likely also incompatible with this DDNS update implementation. See #23 for explanation and analysis of the problem and possible workarounds.

How to Configure

Prerequisites

You should have your Merlin-enabled ASUS router configured for your network with Internet access. Since you've found this guide, it's also assumed you have a Cloudflare account managing your own domain, and you've already created a subdomain you will use for dynamic DNS.

Configuration Overview

Configuration of Cloudflare DDNS involves changes through the router web portal as well as changes made through the router shell.

1. Enable shell access and JFFS partition
2. Install Cloudflare DDNS script
3. Enable custom DDNS
4. Verification
5. Clean up

Directions for disabling dynamic DNS and removal of the script and related files are at bottom.

Enable Shell Access and JFFS Partition

In the router portal, under Administration -> System,

• Persistent JFFS2 partition -> Enable JFFS custom scripts and configs: Yes
• Service -> Enable SSH: LAN only

Save the configuration. Ensure you are able to SSH into your router using your router portal credentials (or via public key crypto, depending on configuration) before continuing.

Note: If SSH will be left enabled after installation, disallow password login, enable brute force protection, and use public keys for login to enhance security.

Install Cloudflare DDNS Script

1. Log into your router via SSH, and navigate to /jffs/scripts.
2. Copy the cloudflare_ddns and .cloudflare.example files to that directory.
3. Rename .cloudflare.example to .cloudflare.
4. Edit .cloudflare with your Cloudflare API token and zone ID from your Cloudflare portal. The script also supports the legacy "API Key plus account e-mail" method of authentication, but this method is less secure and appears likely to be eliminated in future.
5. Run chmod 700 cloudflare_ddns.
6. Run chmod 600 .cloudflare.
7. Run ./cloudflare_ddns list.
8. Step 7 should have resulted in the creation of a log file named cloudflare_ddns.log. Open the log file and review the JSON response object, which should be a listing of your Cloudflare DNS records for the zone ID specified in Step 4.

Note: If there is an error in the log file or no log file is present, ensure permissions are correct and that the text of the script is copied accurately. Double-check your Cloudflare credentials. For large Cloudflare configurations, it may be necessary to increase the log file size limit in the script. If the error is from Cloudflare, you can review the text of the error in the JSON response and look for any error code online.

9. Edit .cloudflare with the DNS record information (i.e. ID, name and type) obtained from Step 8. Ensure your text matches exactly.
10. Run ./cloudflare_ddns 1.1.1.1.
11. Review the log file for the result of the last execution. If you see a successful response, verify against the Cloudflare portal. Otherwise, review the errors and correct as necessary.

Note: You may get a throttled response if you have queried too quickly after Step 7. The script rate-limits to one query every 5 seconds. This is configurable in the cloudflare_ddns script or you can simply wait.

12. Ensure rate-limiting is working as expected by re-issuing the command in Step 10 a couple of times in quick succession and verifying that the log file shows frequent invocations are throttled.
13. If Steps 11 and 12 were successful, run ln -s cloudflare_ddns ddns-start. This creates a symbolic link with the name expected by the router firmware.

Enable Custom DDNS

In the router portal, under WAN -> DDNS,

• Enable the DDNS client: Yes
• Server: Custom
• Host name: the DNS host name you're using in Cloudflare
• HTTPS/SSL Certificate: None

Save the configuration.

Verification

If all is configured correctly, you should see:

1. The DDNS Registration Result field indicating success.
2. In the router portal, under System Log, you should see entries as below.

Nov 5 6:57 start_ddns: update CUSTOM , wan_unit 0
Nov 5 6:57 custom_script: Running /jffs/scripts/ddns-start (args: x.x.x.x ) - max timeout = 120s
Nov 5 6:57 ddns: Completed custom ddns update

3. A new log file should have been created, and it should contain a successful log entry.
4. The Cloudflare portal should reflect the updated public IP address of your router.

Note: If any errors occur, review the router log file and the script log file for an indication of the error or manually re-run ./cloudflare_ddns list and ./cloudflare_ddns 1.1.1.1 to identify and troubleshoot.

Clean Up

Once everything is configured and working properly, you may delete the cloudflare_ddns.log file from the /jffs/scripts/ directory on the router. If SSH access is no longer needed, disable SSH on the router portal for security (especially if password authentication was used).

Script Removal

To remove the script, the process is essentially reversed.

1. In the router portal, disable DDNS client and save. It may be worthwhile to restart your router to ensure any in-memory settings are cleared.
2. Log into the router via SSH and delete (in order): a) ddns-start, b) cloudflare_ddns, c) .cloudflare, d) cloudflare_ddns.log, and e) ddns-start.log.

asus_rt_ac68u's Issues

"Invalid TTL. Must be between 120 and 2,147,483,647 seconds, or 1 for automatic"

I'm not sure what is going on here with CF API.
Seems like they made a few changes.

I can't update my records anymore because I get the above error. Log looks more like:

"errors": [ { "code": 9021, "message": "Invalid TTL. Must be between 120 and 2,147,483,647 seconds, or 1 for automatic" } ], "messages": []

Seems they are insisting the TTL is actually sent as part of the request now as opposed to just assuming the default (Auto). To set to auto you need to send integer 1.

Existing code can be fixed by changing:

asus_rt_ac68u/cloudflare_ddns

Lines 51 to 52 in 116e522

	curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$DNS_ZONE_ID/dns_records/$DNS_RECORD_ID" \
	--data "{\"type\":\"$DNS_RECORD_TYPE\",\"name\":\"$DNS_RECORD_NAME\",\"content\":\"$NEW_IP\"}" \

to:

curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$DNS_ZONE_ID/dns_records/$DNS_RECORD_ID" \ --data "{\"type\":\"$DNS_RECORD_TYPE\",\"name\":\"$DNS_RECORD_NAME\",\"content\":\"$NEW_IP\",\"TTL\":1}"

After that I was able to successfully update.

Throttling/logging broken with 'date: invalid date '}''

So again, I'm going to assume that CF API is returning data differently as we now get the following error on all runs after initial run where log file is created:

# ./cloudflare_ddns 6.6.6.7 
date: invalid date '}'
expr: syntax error
[: 1579631234: unknown operand

Issue appears to be from the following:

asus_rt_ac68u/cloudflare_ddns

Line 84 in 116e522

last_run_time=$(date -d "$(sort -r $LOGFILE | grep -vm1 THROTTLED | cut -f 1)" +%s)

When we sort and grep on the log file we get entries like the following:

s# sort -r cloudflare_ddns.log | grep -vm1 THROTTLED
}

Head of sorted log:

s# sort -r cloudflare_ddns.log | head -n7
}
}
}
}
2020-01-21 12:27        UPDATE_SUCCESS  {
2020-01-21 12:26        UPDATE_THROTTLED
2020-01-21 12:26        UPDATE_SUCCESS  {

So the operand is failing because it isn't matching a date on the "}" entries.
As I don't recall this being a problem before I can only assume that the return output from CF is now different and it appends this extra bracket on.

Seems like we can fix this by skipping those entries, like:

last_run_time=$(date -d "$(sort -r $LOGFILE | grep -v '}' | grep -vm1 THROTTLED | cut -f 1)" +%s)

Occasional duplicate calls to update ddns

Hey - haven't been here in a while! Script has for the most part been running fine so not much need to revisit.
Are you still using it?

I noticed a problem on my RT-AC68U that I'm wondering if you've seen anything like it?
My ISP is apparently sending me a lease time of only 1 hour on my IPv6 lease which causes a refresh every 30 minutes.
Even though I don't update IPv6 via ddns, this still triggers a custom ddns event on the router.
Normally, this wouldn't be an issue as running the script once every 30 minutes shouldn't be a problem at all (i.e. still well under any limits to update the record with an API call once every 30 minutes).

But if you take a look at my logs you will see something like this:

2023-04-06 12:13:19 UPDATE_SUCCESS {"result":{"id":REDACTED} 2023-04-06 12:43:19 UPDATE_SUCCESS {"result":{"id":REDACTED} 2023-04-06 13:13:19 UPDATE_SUCCESS {"result":{"id":REDACTED} 2023-04-06 13:43:19 UPDATE_SUCCESS {"result":{"id":REDACTED} 2023-04-06 14:13:19 UPDATE_SUCCESS {"result":{"id":REDACTED} 2023-04-06 14:43:20 UPDATE_SUCCESS {"result":{"id":REDACTED} 2023-04-06 15:13:20 UPDATE_SUCCESS {"result":{"id":REDACTED} 2023-04-06 15:43:20 UPDATE_SUCCESS {"result":{"id":REDACTED} 2023-04-06 15:43:22 UPDATE_THROTTLED 2023-04-06 15:43:52 UPDATE_THROTTLED 2023-04-06 15:44:22 UPDATE_THROTTLED 2023-04-06 15:44:52 UPDATE_THROTTLED 2023-04-06 15:45:22 UPDATE_THROTTLED 2023-04-06 15:45:52 UPDATE_THROTTLED 2023-04-06 15:46:22 UPDATE_THROTTLED 2023-04-06 15:46:52 UPDATE_THROTTLED 2023-04-06 15:47:22 UPDATE_THROTTLED 2023-04-06 15:47:52 UPDATE_THROTTLED 2023-04-06 15:48:23 UPDATE_SUCCESS {"result":{"id":REDACTED} 2023-04-06 16:13:20 UPDATE_SUCCESS {"result":{"id":REDACTED} 2023-04-06 16:43:21 UPDATE_SUCCESS {"result":{"id":REDACTED}
So what you are seeing is that most of the time everything is going fine every 30 mins. But occasionally you get what you see at the 15:43:20 timestamp. Namely that the update succeeds, but then the script is run again multiple times and keeps failing due to the throttling (since it was just properly updated). This continues for the 300 seconds of throttle until what you get at the 15:48:23 timestamp when it finally succeeds again.
Then you see it continues on normally working every 30 minutes.

This isn't a failure of the script, but rather something funky happening on the merlin. This is what the normal syslog entries look like when it updates properly just the once:

Apr 6 15:13:18 rc_service: dhcp6c 23328:notify_rc restart_ddns Apr 6 15:13:18 custom_script: Running /jffs/scripts/service-event (args: restart ddns) Apr 6 15:13:18 start_ddns: update CUSTOM , wan_unit 0 Apr 6 15:13:18 custom_script: Running /jffs/scripts/ddns-start (args: XX.XX.XX.XX) Apr 6 15:13:20 ddns: Completed custom ddns update Apr 6 15:13:20 custom_script: Running /jffs/scripts/service-event-end (args: restart ddns)

But when it fails it looks like this:

Apr 6 15:43:18 rc_service: dhcp6c 28346:notify_rc restart_ddns Apr 6 15:43:18 custom_script: Running /jffs/scripts/service-event (args: restart ddns) Apr 6 15:43:19 start_ddns: update CUSTOM , wan_unit 0 Apr 6 15:43:19 custom_script: Running /jffs/scripts/ddns-start (args: XX.XX.XX.XX) Apr 6 15:43:20 watchdog: start ddns. Apr 6 15:43:20 rc_service: watchdog 396:notify_rc start_ddns Apr 6 15:43:20 rc_service: waitting "restart_ddns" via ... Apr 6 15:43:20 ddns: Completed custom ddns update Apr 6 15:43:20 custom_script: Running /jffs/scripts/service-event-end (args: restart ddns) Apr 6 15:43:21 custom_script: Running /jffs/scripts/service-event (args: start ddns) Apr 6 15:43:22 start_ddns: update CUSTOM , wan_unit 0 Apr 6 15:43:22 custom_script: Running /jffs/scripts/ddns-start (args: XX.XX.XX.XX) Apr 6 15:43:22 ddns: Custom ddns update failed Apr 6 15:43:22 custom_script: Running /jffs/scripts/service-event-end (args: start ddns) Apr 6 15:43:51 watchdog: start ddns. Apr 6 15:43:51 rc_service: watchdog 396:notify_rc start_ddns Apr 6 15:43:51 custom_script: Running /jffs/scripts/service-event (args: start ddns) Apr 6 15:43:52 start_ddns: update CUSTOM , wan_unit 0 Apr 6 15:43:52 custom_script: Running /jffs/scripts/ddns-start (args: XX.XX.XX.XX) Apr 6 15:43:52 ddns: Custom ddns update failed Apr 6 15:43:52 custom_script: Running /jffs/scripts/service-event-end (args: start ddns) Apr 6 15:44:21 watchdog: start ddns. Apr 6 15:44:21 rc_service: watchdog 396:notify_rc start_ddns Apr 6 15:44:21 custom_script: Running /jffs/scripts/service-event (args: start ddns) Apr 6 15:44:22 start_ddns: update CUSTOM , wan_unit 0 Apr 6 15:44:22 custom_script: Running /jffs/scripts/ddns-start (args: XX.XX.XX.XX) Apr 6 15:44:22 ddns: Custom ddns update failed Apr 6 15:44:22 custom_script: Running /jffs/scripts/service-event-end (args: start ddns) Apr 6 15:44:51 watchdog: start ddns. Apr 6 15:44:51 rc_service: watchdog 396:notify_rc start_ddns Apr 6 15:44:51 custom_script: Running /jffs/scripts/service-event (args: start ddns) Apr 6 15:44:52 start_ddns: update CUSTOM , wan_unit 0 Apr 6 15:44:52 custom_script: Running /jffs/scripts/ddns-start (args: XX.XX.XX.XX) Apr 6 15:44:52 ddns: Custom ddns update failed Apr 6 15:44:52 custom_script: Running /jffs/scripts/service-event-end (args: start ddns) Apr 6 15:45:21 watchdog: start ddns. Apr 6 15:45:21 rc_service: watchdog 396:notify_rc start_ddns Apr 6 15:45:21 custom_script: Running /jffs/scripts/service-event (args: start ddns) Apr 6 15:45:22 start_ddns: update CUSTOM , wan_unit 0 Apr 6 15:45:22 custom_script: Running /jffs/scripts/ddns-start (args: XX.XX.XX.XX) Apr 6 15:45:22 ddns: Custom ddns update failed Apr 6 15:45:22 custom_script: Running /jffs/scripts/service-event-end (args: start ddns) Apr 6 15:45:51 watchdog: start ddns. Apr 6 15:45:51 rc_service: watchdog 396:notify_rc start_ddns Apr 6 15:45:51 custom_script: Running /jffs/scripts/service-event (args: start ddns) Apr 6 15:45:52 start_ddns: update CUSTOM , wan_unit 0 Apr 6 15:45:52 custom_script: Running /jffs/scripts/ddns-start (args: XX.XX.XX.XX) Apr 6 15:45:52 ddns: Custom ddns update failed Apr 6 15:45:52 custom_script: Running /jffs/scripts/service-event-end (args: start ddns) Apr 6 15:46:21 watchdog: start ddns. Apr 6 15:46:21 rc_service: watchdog 396:notify_rc start_ddns Apr 6 15:46:21 custom_script: Running /jffs/scripts/service-event (args: start ddns) Apr 6 15:46:22 start_ddns: update CUSTOM , wan_unit 0 Apr 6 15:46:22 custom_script: Running /jffs/scripts/ddns-start (args: XX.XX.XX.XX) Apr 6 15:46:22 ddns: Custom ddns update failed Apr 6 15:46:22 custom_script: Running /jffs/scripts/service-event-end (args: start ddns) Apr 6 15:46:51 watchdog: start ddns. Apr 6 15:46:51 rc_service: watchdog 396:notify_rc start_ddns Apr 6 15:46:51 custom_script: Running /jffs/scripts/service-event (args: start ddns) Apr 6 15:46:52 start_ddns: update CUSTOM , wan_unit 0 Apr 6 15:46:52 custom_script: Running /jffs/scripts/ddns-start (args: XX.XX.XX.XX) Apr 6 15:46:52 ddns: Custom ddns update failed Apr 6 15:46:52 custom_script: Running /jffs/scripts/service-event-end (args: start ddns) Apr 6 15:47:21 watchdog: start ddns. Apr 6 15:47:21 rc_service: watchdog 396:notify_rc start_ddns Apr 6 15:47:21 custom_script: Running /jffs/scripts/service-event (args: start ddns) Apr 6 15:47:22 start_ddns: update CUSTOM , wan_unit 0 Apr 6 15:47:22 custom_script: Running /jffs/scripts/ddns-start (args: XX.XX.XX.XX) Apr 6 15:47:22 ddns: Custom ddns update failed Apr 6 15:47:22 custom_script: Running /jffs/scripts/service-event-end (args: start ddns) Apr 6 15:47:51 watchdog: start ddns. Apr 6 15:47:51 rc_service: watchdog 396:notify_rc start_ddns Apr 6 15:47:51 custom_script: Running /jffs/scripts/service-event (args: start ddns) Apr 6 15:47:52 start_ddns: update CUSTOM , wan_unit 0 Apr 6 15:47:52 custom_script: Running /jffs/scripts/ddns-start (args: XX.XX.XX.XX) Apr 6 15:47:52 ddns: Custom ddns update failed Apr 6 15:47:52 custom_script: Running /jffs/scripts/service-event-end (args: start ddns) Apr 6 15:48:21 watchdog: start ddns. Apr 6 15:48:21 rc_service: watchdog 396:notify_rc start_ddns Apr 6 15:48:21 custom_script: Running /jffs/scripts/service-event (args: start ddns) Apr 6 15:48:22 start_ddns: update CUSTOM , wan_unit 0 Apr 6 15:48:22 custom_script: Running /jffs/scripts/ddns-start (args: XX.XX.XX.XX) Apr 6 15:48:23 ddns: Completed custom ddns update Apr 6 15:48:23 custom_script: Running /jffs/scripts/service-event-end (args: start ddns)

There is that "watchdog" line near the top of the problematic set. I'm not exactly sure what is happening but it is like this watchdog is jumping in and doing another restart right after the normal update is triggered causing this throttle loop.

I know this isn't a direct script issue, but I'm thinking about ways to mitigate this. Maybe there is something malfunctioning on my device, but I can't see what that is. I posted over in the merlin forums (no good feedback yet), but because those using this script are more likely to be paying attention to these matters I wanted to bring it up here to see if there were any ideas?

Works on RT-AC3200 (384.13_10)

I can confirm it works on RT-AC3200 (firmware version 384.13_10).

Thanks a lot!

Throttling broken when set to a value below 1 minute (60)

If the throttle value is set below 60 seconds it appears that the last_run_time comparison to current_time will be inaccurate because the last_run_time is recorded in the log only in minutes and thus any call to compare them within the same minute will cause the update to succeed instead of be throttled.

This isn't normally an issue except in testing. However if the value was set to below 60 and a script were to call it frequently, it would execute continuously making calls to cloudflare possibly several times per second.

Working on RT-AX58U

I can confirm it works on RT-AX58U (firmware version 388.1). Thanks a lot!

Feature Request - Update multiple DNS records

I've got a unique need to update multiple records, one set to proxy and the other not proxied but both updated from the same router.

Working on GT-AX11000

Tried it on Asus GT-AX11000 and it worked flawlessly, merlin 386.2_6.

Thanks for your script and keep up the great work. :)

Cheers

Multiple subdomains?

Thanks for this! Works flawlessly on my AC66U.

But how can I configure this for multiple subdomains (sub1.domain.com, sub2.domain.com)?

Can I just setup 'domain.com' and the scripts gets the records automatically from the subdomains as I add them in the Cloudflare GUI?

Also, thanks for your very detailed instructions, you made it possible for a noob to set it up! :)

cannot leave hostname entry on router blank

is this correct in your docs to leave it blank or should i input a hostname here? also i ran your find / -name ddns-start.log 2>&1 command and it just returned new line. is that correct or should it have returned something?

HEREDOC Format appears to not function on some older Routers/Firmware

Hey - So I know I mentioned that I had moved off the script to the inadyn services, but it turns out I actually needed to use the script again for another purpose. I had an older Asus RT-N66 router that only supports up to FW 380.70 and therefore doesn't have inadyn support. I was setting this device up as a VPN Server box for my folks and needed the ability to keep the ddns functionality.

Anyway, I could not get the script to function at all on the box, even after a fresh install or porting it directly over from my other config. After messing around for a while, it seems to me that something about this RT-N66/FW 380.70 combination does not properly support the HEREDOC format used in the script.

Specifically, I'm talking about these lines:

asus_rt_ac68u/cloudflare_ddns

Line 92 in 37c6e6c

debug "update_record"

update_record()
{
	debug "update_record"
	curl --silent --show-error --request PUT "https://api.cloudflare.com/client/v4/zones/$DNS_ZONE_ID/dns_records/$DNS_RECORD_ID" \
		--data "{\"type\":\"$DNS_RECORD_TYPE\",\"name\":\"$DNS_RECORD_NAME\",\"content\":\"$NEW_IP\",\"ttl\":1,\"proxied\":$DNS_RECORD_PROXIED}" \
		-H @- <<- HEADERS
			$CLOUDFLARE_AUTH_HEADERS
			Content-Type: application/json
		HEADERS
}

I attempted to execute similar command entirely outside of the script using the following:

admin@RT-N66W-19D8:/jffs/scripts/cloudflare-ddns# CLOUDFLARE_AUTH_HEADERS="Authorization: Bearer XXXXXXXXXXXXXXXXXXXXX"
admin@RT-N66W-19D8:/jffs/scripts/cloudflare-ddns# curl --show-error --request PUT https://api.cloudflare.com/client/v4/zones/XXX/dns_records/XXX --data {\"type\":\"A\",\"name\":\"access.mydomain.com\",\"content\":\"75.X.X.X\",\"ttl\":1,\"proxied\":false} -H @- <<- HEADERS
> $CLOUDFLARE_AUTH_HEADERS
> Content-Type: application/json
> HEADERS
{"success":false,"errors":[{"code":9106,"message":"Missing X-Auth-Key, X-Auth-Email or Authorization headers"}]}

You can see this command fails saying that there are no Authorization headers because somehow the HEREDOC syntax isn't working on this box. These exact same commands function properly on my AC68U which is where I have previously used the script for years.

If instead of using the HEREDOC format I simply append the headers as normal variables as such, the operation succeeds:

admin@RT-N66W-19D8:/jffs/scripts/cloudflare-ddns# curl --show-error --request PUT https://api.cloudflare.com/client/v4/zones/XXX/dns_records/XXX
73460b95896bf --data {\"type\":\"A\",\"name\":\"access.mydomain.com\",\"content\":\"75.X.X.X\",\"ttl\":1,\"proxied\":false} -H "$CLOUDFLARE_AUTH_HEADERS" -H "Content-Type: application/js
on"
{"result":{"id":"XXXXXX","zone_id":"XXXXXXX","zone_name":"mydomain.com","name":"access.mydomain.com","type":"A","content":"75.X.X.X","proxiable":true,"proxied":false,"ttl":1,"locked":false,"meta":{"auto_added":false,"managed_by_apps":false,"managed_by_argo_tunnel":false},"comment":null,"tags":[],"created_on":"2020-10-11T22:35:14.994266Z","modified_on":"2023-04-25T16:22:25.756244Z"},"success":true,"errors":[],"messages":[]}

I can't explain this. The "sh" shell on the router doesn't support a --version command, but using the following script I determined that both systems report as:

SVR4 Bourne shell (SunOS 5 schily variant, since 2016-08-08, in posix mode)

So the shells report exactly the same and as such I would expect them to support the same syntax. The version of curl on my N66 is a bit older, but I don't think that would account for the issue using this syntax.

Finally, my AC68U does have entware installed whereas the N66 did not. But, just like the curl version above, I don't think updated versions of grep, etc would make the difference here for this syntax.

I don't recall (if I knew) why the original script preferred the HEREDOC format here instead of simply appending the variables as per my workaround. If anything, the HEREDOC format would probably have made the --data string more readable instead of using for headers.

In any event, I don't know if the script needs updating due to its deprecation, but I did want to log this issue here in case anyone else might happen to come across it and face a similar issue. Again, this seems to be an inability of some shell versions to not support HEREDOC.

EDIT: Upon some more testing I'm not sure if HEREDOC is the issue or the way that the shell is accepting standard in (@-)

weird.

Tested on RT-AX88U

Just wanted to give you a heads up, I tested the script on my ASUS RT-AX88U, merlin 384.11_2.

Works great :)

Thank you

symbolic link

ive moved some of my stuffs to a vps, what is the best way to disable the script? just delete everything?
.cloudflare
cloudflare_ddns
cloudflare_ddns.log
ddns-start -> cloudflare_ddns

ive left it alone but notice that it kicks my vps ip off and sets the A name to my local ip so i need to do something with it. if i run something locally again i will point it to a subaddress i think.

i think the symbolic link will need to go because i tried to see if i could just switch the DDNS setting back to the free no-ip one i was using before but i think that triggered it to kick my A name back again.

it works on RT-AC88U

it works on RT-AC88U tested!

Question - how exactly does the script get the router IP when it's executed automatically?

Hello,

The title pretty much covers the question I have, I see no way within the script to determine the router's WAN IP so I was wondering if there's a wrapper script I need to create, or if the router provides its WAN IP as input when it executes the script.

Thank you.