Flint 2 (GL-MT6000): broken ddns plug-ins

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 :frowning:
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.


1 Like

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 [...]

root@flint:~# opkg list-installed | grep ddns
ddns-scripts - 2.8.2-12
ddns-scripts-services - 2.8.2-12
luci-app-ddns - git-21.187.20976-699b7f0

Flint 1, f/w 4.4.6-release1

1 Like

All required packages from OpenWRT are installed:

# opkg list-installed | grep ddns
ddns-scripts - 2.8.2-37
ddns-scripts-cloudflare - 2.8.2-37
ddns-scripts-services - 2.8.2-37
gl-sdk4-ddns - git-2023.304.23085-80dfab9-1
luci-app-ddns - git-23.158.77284-47a61bd

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/dynamic_dns_updater.sh                <- old file from ddns-scripts 2.7.x
/etc/dynamic_dns_functions.sh             <- old file from ddns-scripts 2.7.x

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 :frowning:

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.


1 Like
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.​

Nevertheless, it should be fixed in any way.


They’re currently breaking the terms of the GPL v2 license, so this needs to be addressed.

Ideally they should remove the scripts from their gl-sdk4-ddns package and then include an updated and unmodified ddns-scripts package.


Okay, I’ll bite. How are they breaking GPLv2?

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-scripts uses 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

So how is it a GPLv2 violation & not just a version conflict? There’s numerous examples of out of date packages in the stock GL feeds.

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.

This does not matter for most of the users and is a case for some license lawyer anyway.

Closed source, in my opinion, is fine as long as the source code is readable. Since it is, I would assume it’s satisfied.

  1. Modifying/reworking code (‘the script’) is perfectly acceptable per your source.
    • The source code is the the script. It is not a binary.
  2. 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.

When are a program and its plug-ins considered a single combined program?, 2023 Nov 30, Free Software Foundation, Inc.

I’d think it would be a bit ridiculous to assert a shell script constitutes ‘intimate communication’ or ‘share data structures.’

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.

  1. The modified scripts are within a binary (IPK file) and it’s the binary that’s being built and distributed.
  2. GL.iNet don’t state what code they’ve changed.
  3. 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.


Good explanation, thank you!

I’m not into licenses anyway :smile:

1 Like

jup i agree with this :+1:, especially with gpl licenses it always state you have to include a copy of the same license in your project.

In compiled form only its not accessible for anyone.

1 Like

You do understand IPKs are just tarballs by a different name, correct?

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 :man_shrugging:

opkg download $ipk --download-only --tmp-dir=/var/tmp

Be honest: you’ve never read the GPLv2, have you?