DDNS, whose configuration was working in previous releases, is now showing a cURL error 132 when attempting to update my WAN IP to my dns provider (cloudflare). All packages (including ca-certs and ca-bundle, curl) current along with DNS providers list. All credentials with cloudflare are confirmed working.
Looking for suggestions to troubleshoot or repair as I am at a loss on how to proceed short of a full rebuild with the latest stable release and fresh config (rather than restore from backup).
No luck - I have those pkgs installed, and the path is good. I have repeated the install on an identical router, with the most current release of openwrt. Still getting curl 132 error when ddns tries to update the IP address with cloudflare.
I have tried to force ddns to use wget-ssl instead of curl (Global Settings); however, the logs continue to show curl is used as evidenced by the 132 error. EDIT: I see that the cloudflare script requires curl so there is that.
If your curl --version output lists wolfssl, I'd try switching to official release. curl has been migrated to mbedtls at some point very close to release. If the same issue persists with mbedtls, I have no further suggestions.
I've also just merged PR for curl 7.85 for OpenWrt 22.03 repo, so if you migrate to official release in a day or so, the new version should be built and maybe it will help.
Thanks for the suggestion. My original post was using a router with openwrt rc6. I also have built an identical router with OpenWrt 22.03.0 r19685-512e76967f. Curl error is persisting across both.
Here is the output from that command on the 22.03.0 r19685 router:
stangri - I appreciate the idea but I am not nearly that advanced with openwrt. If you can point me to a reference or guidance on how to do what you are suggesting, I can give it a shot. Thanks.
All - UPDATE: reconfigured ddns to use my uhttpd.crt file (2048 bit key) and still getting curl 132 error. I have tried using /etc/ssl/certs and /etc/ssl/certs/ca-certificates.crt and now uhttpd.crt and all have failed.
I have learned from another user in this forum that this is an issue that was working fine but broke in later releases. I am going to close this thread and continue to monitor and test ddns but not on my head-end router/firewall.
Unfortunately, updating curl did not work but I appreciate the suggestion!