Flint 2 running latest v4.5.3 firmware.
After installing ddns-scripts-cloudflare (2.8.2-37) plug-in and configuration as in standard 23.05 there is an error “No update_url found/defined or no update_script found/defined! - TERMINATE” on every run.
The problem is ddns-scripts plug-in is broken - its core scripts are overwritten with very old versions from gl-sdk4-ddns package. All openwrt ddns plug-ins listed in Flint GUI are from 23.05 and requires original ddns-scripts - where /usr/lib/ddns/dynamic_dns_functions.sh can read services definitions from JSON with get_service_data() function.
Now all DDNS services except glddns.com are unusable
Could you update gl-sdk4-ddns package to use scripts from OpenWrt 23.05 (not over-writing ddns-scripts package)? After that all ddns plug-ins should work OK without any changes.
Have you tried manually adding the OWRT 23.05 feeds… as a matter of ‘last resort’? I’d also jump into LuCI, disable/stop the stock GL ddns service. opkg update; opkg install [...]
ddns-scripts 2.8.2-37 should work with cloudflare without problems, BUT proprietary gl-sdk4-ddns package overwrites original scripts with an ancient version (from 2020, v2.7.x) thus making Flint 2 firmware incompatible with 23.05:
# opkg files gl-sdk4-ddns
Package gl-sdk4-ddns (git-2023.304.23085-80dfab9-1) is installed on root and has the following files:
/etc/95-ddns
/etc/dynamic_dns_updater.sh <- old file from ddns-scripts 2.7.x
/etc/uci-defaults/zzz-ddns-glsdk4-config
/etc/ddns_services
/etc/config/gl_ddns
/usr/lib/oui-httpd/rpc/ddns.so
/etc/dynamic_dns_functions.sh <- old file from ddns-scripts 2.7.x
/etc/ddns_services_ipv6
/etc/ddns.init
I can force overwrite these files from ddns-package available from GL.iNet repo, but I expect it will broke theirs official ddns service listed in web GUI and mobile app
GL.iNet should port their ddns service to 23.05 base, then use proper scripts from openwrt 23.05 ddns-scripts packages (removing marked files from gl-sdk4-ddns package). Or remove original OpenWRT ddns packages from Flint2 repos as incompatible with current firmware.
root@flint:~# service | grep ddns
/etc/init.d/ddns enabled stopped
In my case my Flint is behind a main router. The Flint has ddns, per my previous post. I used LuCI’s Services → DDNS to config ddns rather than GL GUI & then Monit (opkg install monit) to ensure its uptime & to start/stop if there’s a problem:
root@flint:~# cat /etc/monit.d/ddns_desec_ipv4
check process ddns_desec_ipv4 with pidfile /var/run/ddns/desec_ipv4.pid
group ddns
group vpn
# start program = "/etc/init.d/ddns start"
# https://serverfault.com/a/800576
start program = "/bin/bash -c '/usr/lib/ddns/dynamic_dns_updater.sh -v 0 -S desec_ipv4 -- start < /dev/null &'"
stop program = "/etc/init.d/ddns stop"
depends on ddns_bin
depends on ddns_rc
depends on ddns_conf
# depends on dnscrypt-proxy
if total cpu > 5% for 10 cycles then restart
if total memory usage > 2 MB for 10 cycles then restart
if failed host checkipv4.dedyn.io
port 443
protocol https
with tls options {verify: enable}
type tcp
then unmonitor
if failed host dedyn.io
port 443
protocol https
with tls options {verify: enable}
type tcp
then unmonitor
if does not exist then start
check file ddns_bin with path /usr/lib/ddns/dynamic_dns_updater.sh
group ddns
group vpn
if failed checksum then unmonitor
if failed permission 0755 then unmonitor
if failed uid root then unmonitor
if failed gid root then unmonitor
check file ddns_rc with path /etc/init.d/ddns
group ddns
group vpn
if failed checksum then unmonitor
if failed permission 0755 then unmonitor
if failed uid root then unmonitor
if failed gid root then unmonitor
check file ddns_conf with path /etc/config/ddns
group ddns
group vpn
if failed checksum then unmonitor
if failed permission 0644 then unmonitor
if failed uid root then unmonitor
if failed gid root then unmonitor
I’ve never used GL GUI for ddns. All packages are fr the GL feeds. FWIW.
This issue is not only for MT6000 Flint 2 or OpenWrt 23, but also other models with different versions.
Including MT3000 Beryl AX, MT2500 Brume 2, MT300N-V2 Mango, ALL devices I tested have same issue on their latest stable firmware based on OpenWrt 21 or 22.
Actually not every DDNS services have been broken, but updating a Cloudflare record always fails just like OP’s.
Removing gl-sdk4-ddns and then reinstall ddns-scripts solves the problem. This doesn’t seem to broke something until now. GL.iNet GUI just silently hide the DDNS menu item on both web page and mobile app.
If someone wants to do this to use one’s favorite DDNS service and knows how to do this, then probably losing the built-in DDNS menu which very limited and even doesn’t have any option would be fine.
gl-sdk4-ddns is related to their glddns.com service as a dependency. ddns-scripts is ‘untethered’. I’d keep in mind the target audience/market for these devices.
Simple. Their plugin contains the script files from ddns-scripts and ddns-scriptsuses the GPL v2 licence.
If recall (since I’m no longer using the stock firmware) when you install ddns-scripts-cloudflare it’ll also install ddns-scripts as a dependency. And this might work at first, but then when you reboot the router the files will be replaced by the modified ones from gl-sdk4-ddns.
You can even download the ddns IPK file from GL.iNet’s GitHub page and explore it’s contents. You’ll find the same modified versions of dynamic_dns_functions.sh and dynamic_dns_updater.sh.
They modified the contents of the scripts (I’ve checked) and included them in their closed source plugin without sharing their modified code or the original code, which you’re not supposed to do.
Nope, I’m still not seeing it. Your citation even mentions
Organizations may incorporate the licensed code into their software, then sell that software to customers
Users can make changes to or rework the code, but if they distribute these changes/modifications in binary form, they must also release these updates in source code form under the GPL v2 license.
The ‘source code’ in this case is the very script (.sh) itself.
They modified the scripts and they’re within a closed source plugin. So even though you can dig through the files and read the contents it doesn’t satisfy the GPL v2 license.
To satisfy the GPL v2 licence the scripts need to be easily accessible by everyone and shared in source code form.
Honestly though, if GL.iNet only offer GLDDNS via their UI then I don’t think they even depend on the scripts anymore since that looks to be done by their library (libddnsapi.so). So they could remove the scripts and then exclude or include an unmodified ddns-scripts package.
Modifying/reworking code (‘the script’) is perfectly acceptable per your source.
The source code is the the script. It is not a binary.
I think we have vastly different definitions of ‘plug-in’:
It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program.
If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins. If the main program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.
Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.
I disagree. As a programmer myself and a supporter of OpenWrt, GL.iNet should make every effort to respect licenses.
I’m fairly certain that if this were posted on the OpenWrt forum you’d see many people agreeing with me. Especially the developers.
That’s unfortunately not how it works since the modified scripts are within a precompiled binary, so it’s not easily accessible by everyone and it’s not in source code form.
Source code form would be the scripts uploaded to a website like GitHub with a commit history or a downloadable archive with the source code and maybe a patch file.
The modified scripts are within a binary (IPK file) and it’s the binary that’s being built and distributed.
GL.iNet don’t state what code they’ve changed.
GL.iNet don’t openly share their changes or the original source code online.
You might think it’s ridiculous, but you shouldn’t take an open source project that uses a certain license and then try to ignore that license. Especially in a commercial product.
Keep in mind that we’ve had to go digging through closed source files to find out exactly why the cloudflare plugin wasn’t working and why the scripts were getting replaced, despite ddns-scripts being a somewhat recent version. And it all could of been avoided if GL.iNet cleaned up their gl-sdk4-ddns package.
Of course. But it’s still not a valid way to distribute the code, since the scripts come bundled with other binaries and there’s no changelog or original source code to compare against. Plus you can’t download an IPK file for the GL-MT6000
, especially with gpl licenses it always state you have to include a copy of the same license in your project.