Ziti-edge-tunnel binary for Teltonika RUT956 unable to connect with Openziti controller after successfully built

I've successfully built ziti-edge-tunnel binary to run inside Teltonika router RUT956. My original source of info was this Netfoundry blog: https://support.netfoundry.io/hc/en-us/articles/4413015431949-NetFoundry-for-Zero-Trust-IOT-Edge-embedded-Networking

After that, I've tried to connect to my openziti controller. In the meantime every tunneler has successfully connected: macOS, Linux, Windows. But ziti-edge-tunnel is unable to enroll the JWT identity from the controller.

This is the error message:

root@RUT956:~# /usr/bin/ziti-edge-tunnel enroll --jwt /tmp/rut956-kimi.jwt --identity /etc/ziti/rut956-kimi.json
(14670)[        0.000]    INFO ziti-sdk:utils.c:199 ziti_log_set_level() set log level: root=3/INFO
(14670)[        0.000]    INFO ziti-sdk:utils.c:170 ziti_log_init() Ziti C SDK version 1.15.0 @gf66be3f(HEAD) starting at (2026-05-02T05:51:09.323)
(14670)[        0.000]    INFO ziti-sdk:ziti_enroll.c:124 ziti_enroll() Ziti C SDK version 1.15.0 @gf66be3f(HEAD) starting enrollment at (2026-05-02T05:51:09.325)
(14670)[        0.000]    INFO ziti-sdk:ziti_ctrl.c:617 ziti_ctrl_init() ctrl[``https://zerotrust.example:1280``] controller initialized
(14670)[        0.000]    INFO ziti-sdk:ziti_ctrl.c:617 ziti_ctrl_init() ctrl[``https://zerotrust.example:1280``] controller initialized
(14670)[        0.000]    WARN ziti-sdk:ziti_ctrl.c:179 ctrl_resp_cb() ctrl[``https://zerotrust.example:1280``] request[/version] failed: -130(software caused connection abort)
(14670)[        0.000]    WARN ziti-sdk:ziti_ctrl.c:338 internal_version_cb() ctrl[``https://zerotrust.example:1280``] CONTROLLER_UNAVAILABLE(software caused connection abort)
(14670)[        0.000]    WARN ziti-sdk:ziti_ctrl.c:179 ctrl_resp_cb() ctrl[``https://zerotrust.example:1280``] request[/enroll] failed: -130(software caused connection abort)
(14670)[        0.000]    INFO ziti-sdk:ziti_ctrl.c:182 ctrl_resp_cb() ctrl[``https://zerotrust.example:1280``] attempting to switch endpoint
(14670)[        0.000]    WARN ziti-sdk:ziti_ctrl.c:582 ctrl_next_ep() ctrl[``https://zerotrust.example:1280``] no controllers are online
(14670)[        0.000]   ERROR ziti-sdk:ziti_enroll.c:446 enroll_cb() failed to enroll with controller: ``https://zerotrust.example:1280`` CONTROLLER_UNAVAILABLE[software caused connection abort] reason`[ ]
(14670)[        0.000]   ERROR ziti-edge-tunnel:ziti-edge-tunnel.c:1767 enroll_cb() enrollment failed: ziti controller is not available(-16)

I know troubleshooting like this could be hard, so I need help for how to document this case and which part of the compilation, maybe like:

  • SDK version

  • Target

  • Toolchain version

  • TLS: mbedTLS version

  • ziti-tunnel-sdk-c version

I'm not looking for easy/magical way to troubleshoot this case, but I'm willing to help someone in this forum who would like to give me the systematic way to solve this problem. But if any of you who already has tested Teltonika RUT956 ziti-edge-tunnel binary which successfully enrolled and run the openziti tunnel, and can give me the file & dependencies to tried it out, I'm more than welcome.

Hi @affanzbasalamah, welcome to the community and to OpenZiti!

My guess is that you're hitting some kind of bad crypto type error. (i edited your post btw for clarity). Can you try running the tunneler with something like:

ZITI_LOG="6;tlsuv=6" ziti-edge-tunnel run -i tlsuv.json 2>&1

For example you should get a lot of extra debugging:

$ ZITI_LOG="6;tlsuv=6" ziti-edge-tunnel run -i tlsuv.json 2>&1 | grep "tlsuv\:"
(931574)[        0.015] VERBOSE tlsuv:engine.c:248 C=US, L=Charlotte, O=NetFoundry, OU=ADV-DEV, CN=ip-172-31-47-200-signing-intermediate root[false]
(931574)[        0.015] VERBOSE tlsuv:engine.c:248 C=US, L=Charlotte, O=NetFoundry, OU=ADV-DEV, CN=ip-172-31-47-200-signing-root-ca Root CA root[true]
(931574)[        0.015] VERBOSE tlsuv:engine.c:248 C=US, L=Charlotte, O=NetFoundry, OU=ADV-DEV, CN=ip-172-31-47-200-signing-intermediate_grandparent_intermediate root[false]
(931574)[        0.015] VERBOSE tlsuv:engine.c:248 C=US, L=Charlotte, O=NetFoundry, OU=ADV-DEV, CN=ec2-3-18-113-172.us-east-2.compute.amazonaws.com-root-ca Root CA root[true]
(931574)[        0.015] VERBOSE tlsuv:engine.c:248 C=US, L=Charlotte, O=NetFoundry, OU=ADV-DEV, CN=ip-172-31-47-200-edge-controller-root-ca Root CA-root-ca Root CA root[true]
(931574)[        0.015] VERBOSE tlsuv:engine.c:248 C=US, O=NetFoundry, CN=9sF.h8Vyh OU=ADV-DEV, CN=ip-172-31-47-200-edge-controller-root-ca Root CA-root-ca Root CA root[false]
(931574)[        0.015] VERBOSE tlsuv:engine.c:248 C=US, L=Charlotte, O=NetFoundry, OU=ADV-DEV, CN=ip-172-31-47-200-signing-intermediate-ca Root CA-root-ca Root CA root[false]
(931574)[        0.015] VERBOSE tlsuv:engine.c:248 C=US, L=Charlotte, O=NetFoundry, OU=ADV-DEV, CN=ip-172-31-47-200-signing-intermediate_grandparent_intermediateCA root[false]
(931574)[        0.030] VERBOSE tlsuv:http.c:411 client not connected, starting connect sequence
(931574)[        0.032]   TRACE tlsuv:connector.c:223 fd[16] connecting to 172.31.47.200
(931574)[        0.032]   TRACE tlsuv:connector.c:310 fd[16] is connected
(931574)[        0.034] VERBOSE tlsuv:http.c:261 src connected status = 0

Thanks Clint for your response.

After see your example, I tried to enroll the identity in other Linux VM, and use the identity with ziti-edge-tunnel run command. The command generate lots of logs and running on loop. I give you the snippet below:

root@RUT956:~# ZITI_LOG="6;tlsuv=6" ziti-edge-tunnel run -i /tmp/rut956-claude.json 2>&1 | grep "tlsuv\:"
(6071)[        0.236] VERBOSE tlsuv:http.c:632 http[zerotrust.salamahsystems.com:1280](0x77d07de0): starting request[/version]
(6071)[        0.236] VERBOSE tlsuv:http.c:650 http[zerotrust.salamahsystems.com:1280](0x77d07de0): client not connected, starting connect sequence timeout[15000]
(6071)[        0.236] VERBOSE tlsuv:http.c:660 http[zerotrust.salamahsystems.com:1280](0x77d07de0): staring connect
(6071)[        0.236]   TRACE tlsuv:connector.c:332 connect(0x77d07340): connecting to zerotrust.salamahsystems.com:1280
(6071)[        0.244]   TRACE tlsuv:connector.c:298 connect(0x77d07340): fd[10] connecting to 103.93.129.137
(6071)[       10.533]   TRACE tlsuv:connector.c:228 connect(0x77d07340): poll fd[10] status=0 events=2
(6071)[       10.533]   TRACE tlsuv:connector.c:252 connect(0x77d07340): connected fd[10]
(6071)[       10.533]   DEBUG tlsuv:http.c:375 http[zerotrust.salamahsystems.com:1280](0x77d07de0): tr_connect_cb sock[10] status = 0
(6071)[       10.533] VERBOSE tlsuv:http.c:391 http[zerotrust.salamahsystems.com:1280](0x77d07de0): starting TLS handshake
(6071)[       10.533]   TRACE tlsuv:tlsuv.c:254 tls[zerotrust.salamahsystems.com@0x77d4e9b0]process_connect status=0
(6071)[       10.533]   TRACE tlsuv:tlsuv.c:307 tls[zerotrust.salamahsystems.com@0x77d4e9b0]waiting for handshake data
(6071)[       10.533]   TRACE tlsuv:http.c:403 http[zerotrust.salamahsystems.com:1280](0x77d07de0): created TLS tr[0x77d4e9b0] with fd[10]
(6071)[       10.533]   TRACE tlsuv:connector.c:197 connect(0x77d07340): closing connect request
(6071)[       15.236]    WARN tlsuv:http.c:463 http[zerotrust.salamahsystems.com:1280](0x77d07de0): connection timed out
(6071)[       15.236] VERBOSE tlsuv:http.c:586 http[zerotrust.salamahsystems.com:1280](0x77d07de0): src_connect_timeout:472: closing connection
(6071)[       15.236] VERBOSE tlsuv:tlsuv.c:182 tls[zerotrust.salamahsystems.com@0x77d4e9b0]closing stream
(6071)[       15.237] VERBOSE tlsuv:tlsuv.c:144 tls[zerotrust.salamahsystems.com@0x77d4e9b0]internal close
(6071)[       15.237]    WARN tlsuv:http.c:327 http[zerotrust.salamahsystems.com] TLS handshake was canceled
(6071)[       20.237] VERBOSE tlsuv:http.c:632 http[zerotrust.salamahsystems.com:1280](0x77d07de0): starting request[/external-jwt-signers?limit=25&offset=0]
(6071)[       20.237] VERBOSE tlsuv:http.c:650 http[zerotrust.salamahsystems.com:1280](0x77d07de0): client not connected, starting connect sequence timeout[15000]
(6071)[       20.237] VERBOSE tlsuv:http.c:660 http[zerotrust.salamahsystems.com:1280](0x77d07de0): staring connect
(6071)[       20.237]   TRACE tlsuv:connector.c:332 connect(0x77d07350): connecting to zerotrust.salamahsystems.com:1280
(6071)[       20.252]   TRACE tlsuv:connector.c:298 connect(0x77d07350): fd[10] connecting to 103.93.129.137
(6071)[       28.883]   TRACE tlsuv:connector.c:228 connect(0x77d07350): poll fd[10] status=0 events=2
(6071)[       28.883]   TRACE tlsuv:connector.c:252 connect(0x77d07350): connected fd[10]
(6071)[       28.883]   DEBUG tlsuv:http.c:375 http[zerotrust.salamahsystems.com:1280](0x77d07de0): tr_connect_cb sock[10] status = 0
(6071)[       28.883] VERBOSE tlsuv:http.c:391 http[zerotrust.salamahsystems.com:1280](0x77d07de0): starting TLS handshake
(6071)[       28.883]   TRACE tlsuv:tlsuv.c:254 tls[zerotrust.salamahsystems.com@0x77d4e9c0]process_connect status=0
(6071)[       28.883]   TRACE tlsuv:tlsuv.c:307 tls[zerotrust.salamahsystems.com@0x77d4e9c0]waiting for handshake data
(6071)[       28.883]   TRACE tlsuv:http.c:403 http[zerotrust.salamahsystems.com:1280](0x77d07de0): created TLS tr[0x77d4e9c0] with fd[10]
(6071)[       28.883]   TRACE tlsuv:connector.c:197 connect(0x77d07350): closing connect request
(6071)[       35.237]    WARN tlsuv:http.c:463 http[zerotrust.salamahsystems.com:1280](0x77d07de0): connection timed out
(6071)[       35.237] VERBOSE tlsuv:http.c:586 http[zerotrust.salamahsystems.com:1280](0x77d07de0): src_connect_timeout:472: closing connection
(6071)[       35.237] VERBOSE tlsuv:tlsuv.c:182 tls[zerotrust.salamahsystems.com@0x77d4e9c0]closing stream
(6071)[       35.238] VERBOSE tlsuv:tlsuv.c:144 tls[zerotrust.salamahsystems.com@0x77d4e9c0]internal close
(6071)[       35.238]    WARN tlsuv:http.c:327 http[zerotrust.salamahsystems.com] TLS handshake was canceled

Do I need to provide configuration & logs from the controller (that I've set up myself), and which one?

Best regards,

Affan

Is there any chance that you have endpoint protection software running or something that might get in the way of that handshake completing?

(6071)[ 28.883] VERBOSE tlsuv:http.c:391 httpzerotrust.salamahsystems.com:1280: starting TLS handshake
...
(6071)[ 35.237] WARN tlsuv:http.c:463 httpzerotrust.salamahsystems.com:1280: connection timed out

seems pretty odd to me. On your controller, are there any logs that are useful at the time you perform this operation?

On your 'regular' machine, are you able to enroll an identity (not on the RUT956)? let's take your build out of the equation and just make sure OUR build of ziti-edge-tunnel is able to work against your controller first to reduce the parts we need to focus on.

If stock (provided by us) ziti-edge-tunnel works, well we'll know that it's somehow entirely your build that is the problem.

This is the log for root@RUT956:~# ZITI_LOG="6;tlsuv=6" ziti-edge-tunnel run -i /tmp/rut956-claude.json 2>&1 | grep "tlsuv:" , I've put it in here: log of ziti-edge-tunnel with tlsuv filter - Pastebin.com

the regular log still ends at segfault:

root@RUT956:~# ziti-edge-tunnel run -i /tmp/rut956-claude.json
About to run tunnel service... ziti-edge-tunnel
(6765)[        0.000]    INFO ziti-sdk:utils.c:197 ziti_log_set_level() set log level: root=3/INFO
(6765)[        0.000]    INFO ziti-sdk:utils.c:168 ziti_log_init() Ziti C SDK version 1.11.9 @gedd871d(HEAD) starting at (2026-05-05T16:08:45.140)
(6765)[        0.000]    INFO tunnel-sdk:ziti_tunnel.c:60 create_tunneler_ctx() Ziti Tunneler SDK (v1.12.1.v1.12.1)
(6765)[        0.000]    INFO tunnel-cbs:ziti_dns.c:176 seed_dns() DNS configured with range 100.64.0.0 - 100.127.255.255 (4194302 ips)
(6765)[        0.000]    WARN ziti-edge-tunnel:ziti-edge-tunnel.c:930 make_socket_path() local 'ziti' group not found.
(6765)[        0.000]    WARN ziti-edge-tunnel:ziti-edge-tunnel.c:931 make_socket_path() please create the 'ziti' group by running these commands:
(6765)[        0.000]    WARN ziti-edge-tunnel:ziti-edge-tunnel.c:933 make_socket_path() sudo groupadd --system ziti
(6765)[        0.000]    WARN ziti-edge-tunnel:ziti-edge-tunnel.c:934 make_socket_path() users can then be added to the 'ziti' group with:
(6765)[        0.000]    WARN ziti-edge-tunnel:ziti-edge-tunnel.c:935 make_socket_path() sudo usermod --append --groups ziti <USER>
(6765)[        0.000]    WARN ziti-edge-tunnel:ziti-edge-tunnel.c:1081 run_tunneler_loop() One or more socket servers did not properly start.
(6765)[        0.107]    WARN ziti-edge-tunnel:tun.c:277 find_dns_updater() Adding ziti resolver to /etc/resolv.conf. Ziti DNS functionality may be impaired
(6765)[        0.107]    INFO ziti-edge-tunnel:resolvers.c:470 make_copy() attempting copy of: /etc/resolv.conf
(6765)[        0.107]    INFO ziti-edge-tunnel:resolvers.c:484 make_copy() copy successful: /etc/resolv.conf.bkp
(6765)[        0.109]    WARN ziti-edge-tunnel:instance.c:51 find_tunnel_identity() Identity ztx[/tmp/rut956-claude.json] is not loaded yet or already removed.
(6765)[        0.109]    INFO tunnel-cbs:ziti_tunnel_ctrl.c:1192 load_ziti_async() attempting to load ziti instance[/tmp/rut956-claude.json]
(6765)[        0.109]    INFO tunnel-cbs:ziti_tunnel_ctrl.c:1199 load_ziti_async() loading ziti instance[/tmp/rut956-claude.json]
(6765)[        0.109]    INFO ziti-edge-tunnel:ziti-edge-tunnel.c:424 load_id_cb() identity[/tmp/rut956-claude.json] loaded
(6765)[        0.124]    INFO ziti-sdk:ziti.c:514 ziti_start_internal() ztx[1] enabling Ziti Context
(6765)[        0.124]    INFO ziti-sdk:ziti.c:538 ziti_start_internal() ztx[1] using tlsuv[v0.41.1/Mbed TLS 2.28.9]
(6765)[        0.124]    INFO ziti-sdk:ziti_ctrl.c:617 ziti_ctrl_init() ctrl[https://zerotrust.salamahsystems.com:1280/edge/client/v1] controller initialized
(6765)[        0.124]    INFO ziti-sdk:ziti.c:615 ztx_init_controller() ztx[1] Loading ziti context with controller[https://zerotrust.salamahsystems.com:1280/edge/client/v1]
(6765)[        3.214]    INFO ziti-sdk:ziti.c:2161 version_pre_auth_cb() ztx[1] connected to controller https://zerotrust.salamahsystems.com:1280/edge/client/v1 version v1.6.14(1bbe418d1e3e 2026-03-13T20:13:26Z)
(6765)[        3.214]    INFO ziti-sdk:ziti.c:2162 version_pre_auth_cb() ztx[1] using OIDC authentication method
(6765)[        3.214]    INFO ziti-sdk:oidc.c:88 oidc_client_init() oidc[internal] initializing with provider[https://ctrl.ziti.internal:1280/oidc]
(6765)[        6.095]    INFO ziti-sdk:oidc.c:263 request_token() oidc[internal] requesting token path[https://zerotrust.salamahsystems.com:1280/oidc/oauth/token] auth[-S4Lc4YLlhXl3XV-5tyoGxlBrpttn2rGAh1L9KZo6RemZ_P2EWvTe57Q_3enC1_5G3br8Q&state=MkBRFShT8DDxMYfIyKMmypEC2JcD-HvodOAkTBrr]
(6765)[        9.140]   ERROR ziti-edge-tunnel:ziti-edge-tunnel.c:1020 on_crash() received signal: Segmentation fault
root@RUT956:~#

I noticed that you're building with mbedTLS(v2.28.9).
We are no longer supporting that (and mbedTLS v2.x versions are out of support).
You should change your build to use OpenSSL.

Thank you Eugene for your help,

I've been using this script to build https://raw.githubusercontent.com/netfoundry/iot_build_scripts/main/build_teltonika.bash and it still using mbedTLS.

Give me the clue how to update it using OpenSSL?

Thanks!

Dear @TheLumberjack and @ekoby, @PhilipGriffiths emailed me few days ago and tell me to use the methods from this Github: https://github.com/NicFragale/NetFoundry/tree/main/Utilities/OpenZITI-OWRT

And I've successfully compiled it, and it managed to enroll the identity and run the tunneler using the identity. Right now the RUT956 SSH and web GUI management can be accessed from Openziti client, and service at the same LAN can also be advertised through Openziti.

Thank you so much for your generous help,

Affan

Hi, I also tried to build OpenZiti for Teltonika RUT206 (RUTE_R_00.07.23) but not succeed.

Here is what I did

# quide says tested on Ubuntu 22.04, but it has  too old CMAke version...
docker run -it ubuntu:24.04
apt update && apt install git -y
git clone https://github.com/NicFragale/NetFoundry.git
cd NetFoundry/Utilities/OpenZITI-OWRT/
# RUT206 cat /etc/os-release
# VERSION="21.02.0"
# OPENWRT_BOARD="ramips/mt76x8"
bash OWRT_Builder.bash "21.02.0" "ramips" "mt76x8" "latest"

But build fails

                                           Begin Step 9: Build Dependencies via VCPKG [Target target-mipsel_24kc_musl].
VCPKG SYNTAX: /tmp/OpenWRT-21.02.0-ramips_mt76x8/vcpkg/vcpkg install --x-install-root=/tmp/OpenWRT-21.02.0-ramips_mt76x8/openwrt-sdk-21.02.0-ramips-mt76x8_gcc-8.4.0_musl.Linux-x86_64/staging_dir/toolchain-mipsel_24kc_gcc-8.4.0_musl --x-manifest-root=/tmp/OpenWRT-21.02.0-ramips_mt76x8/ziti-tunnel-sdk-c-1.16.1 --triplet mipsel-linux --overlay-triplets=/tmp/OpenWRT-21.02.0-ramips_mt76x8/vcpkg/custom-triplets
Detecting compiler hash for triplet x64-linux...
Compiler found: /usr/bin/c++
Detecting compiler hash for triplet mipsel-linux...
Compiler found: /tmp/OpenWRT-21.02.0-ramips_mt76x8/openwrt-sdk-21.02.0-ramips-mt76x8_gcc-8.4.0_musl.Linux-x86_64/staging_dir/toolchain-mipsel_24kc_gcc-8.4.0_musl/bin/mipsel-openwrt-linux-g++
The following packages will be built and installed:
  * abseil:mipsel-linux@20250814.1
  * abseil:x64-linux@20250814.1
    json-c:mipsel-linux@0.18-20240915
    libsodium:mipsel-linux@1.0.20#3
    libuv:mipsel-linux@1.52.1
    llhttp:mipsel-linux@9.3.1
    openssl:mipsel-linux@3.6.1#3
  * protobuf:x64-linux@6.33.4#1
  * protobuf:mipsel-linux@6.33.4#1
    protobuf-c:mipsel-linux@1.5.2
    stc:mipsel-linux@5.0
  * utf8-range:mipsel-linux@6.33.4
  * utf8-range:x64-linux@6.33.4
  * vcpkg-cmake:x64-linux@2024-04-23
  * vcpkg-cmake-config:x64-linux@2024-05-23
  * vcpkg-cmake-get-vars:x64-linux@2025-05-29
  * vcpkg-tool-meson:x64-linux@1.9.0#4
    zlib:mipsel-linux@1.3.1
Additional packages (*) will be modified to complete this operation.
Restored 13 package(s) from /root/.cache/vcpkg/archives in 3.5 s. Use --debug to see more details.
Installing 1/18 vcpkg-cmake-config:x64-linux@2024-05-23...
vcpkg-cmake-config:x64-linux@2024-05-23 package ABI: 554b7dd3ebc0e2ef3f5b4330c4297c155fd29fbff111a3f2873b61bfaca42c4b
Elapsed time to handle vcpkg-cmake-config:x64-linux: 1.08 ms
Installing 2/18 vcpkg-cmake:x64-linux@2024-04-23...
vcpkg-cmake:x64-linux@2024-04-23 package ABI: 67c0eaadc8637d0bf6f730b19cfbbba4e40392f8a3e4c279b5c8781a731d128b
Elapsed time to handle vcpkg-cmake:x64-linux: 894 us
Installing 3/18 json-c:mipsel-linux@0.18-20240915...
json-c:mipsel-linux@0.18-20240915 package ABI: 9156d8f808cfee95c513aa62d787c2aa5673cd05ceb11e65b370742481ea631f
Elapsed time to handle json-c:mipsel-linux: 1.33 ms
Installing 4/18 libsodium:mipsel-linux@1.0.20#3...
libsodium:mipsel-linux@1.0.20#3 package ABI: 01eb07f9b3f60c1df3a4e2ca05ce4f4f441986a6cf578b787548d225eff62b2d
Elapsed time to handle libsodium:mipsel-linux: 2.42 ms
Installing 5/18 libuv:mipsel-linux@1.52.1...
libuv:mipsel-linux@1.52.1 package ABI: 319585316dc7240aadd679b477de10175f2e5a14752f17d70dc07dd38c0656de
Elapsed time to handle libuv:mipsel-linux: 1.5 ms
Installing 6/18 llhttp:mipsel-linux@9.3.1...
llhttp:mipsel-linux@9.3.1 package ABI: 9dc87c1bedf5f4ef0600678ca9d3874173cb75e634e1a2b87ff9e6857ef7345a
Elapsed time to handle llhttp:mipsel-linux: 1.13 ms
Installing 7/18 vcpkg-cmake-get-vars:x64-linux@2025-05-29...
vcpkg-cmake-get-vars:x64-linux@2025-05-29 package ABI: ea4f26ea2c177b4f1ae7546f9d1c24ecb4051217cadbf0a272c9015eba05e901
Elapsed time to handle vcpkg-cmake-get-vars:x64-linux: 1.05 ms
Installing 8/18 openssl:mipsel-linux@3.6.1#3...
openssl:mipsel-linux@3.6.1#3 package ABI: b57a991ecf185b07ac92e41d6dee16871a7ea4f12356ae55642bb805a5a76e96
Elapsed time to handle openssl:mipsel-linux: 4.66 ms
Installing 9/18 abseil:mipsel-linux@20250814.1...
abseil:mipsel-linux@20250814.1 package ABI: 2b6b99b899c8ab3a9b94985c3df66e0925da8574d7b4e1f98c06851e39ba1fb8
Elapsed time to handle abseil:mipsel-linux: 13.7 ms
Installing 10/18 utf8-range:mipsel-linux@6.33.4...
utf8-range:mipsel-linux@6.33.4 package ABI: d39a974c24352421a0a35abb6e19f4357bab20f217fe6ff89e2c1fd5dda42e1f
Elapsed time to handle utf8-range:mipsel-linux: 1.68 ms
Installing 11/18 abseil:x64-linux@20250814.1...
abseil:x64-linux@20250814.1 package ABI: ddb1b9c11bf763f4dcd59348a63db5e7d3b003de64de6e95ea00384bd63ff650
Elapsed time to handle abseil:x64-linux: 20 ms
Installing 12/18 utf8-range:x64-linux@6.33.4...
utf8-range:x64-linux@6.33.4 package ABI: aded53983bb5f3e0a34194aa4cdb83e8a34b01adb3dc7e6ccec82137afd2c783
Elapsed time to handle utf8-range:x64-linux: 1.85 ms
Installing 13/18 protobuf:x64-linux@6.33.4#1...
protobuf:x64-linux@6.33.4#1 package ABI: b50edebb1d9a75f880a3d16219595ce4dd43e3c34fd2830752a6d9cc74cf5d43
Elapsed time to handle protobuf:x64-linux: 4.9 ms
Installing 14/18 protobuf:mipsel-linux@6.33.4#1...
protobuf:mipsel-linux@6.33.4#1 package ABI: 9a2b5d32fd585cecb3b93110b0aab511610c8a2c5e4056bb6e43649acdc566cc
Building protobuf:mipsel-linux@6.33.4#1...
/tmp/OpenWRT-21.02.0-ramips_mt76x8/vcpkg/custom-triplets/mipsel-linux.cmake: info: loaded overlay triplet from here
Downloading https://github.com/protocolbuffers/protobuf/archive/v33.4.tar.gz -> protocolbuffers-protobuf-v33.4.tar.gz
Successfully downloaded protocolbuffers-protobuf-v33.4.tar.gz
-- Extracting source /tmp/OpenWRT-21.02.0-ramips_mt76x8/vcpkg/downloads/protocolbuffers-protobuf-v33.4.tar.gz
-- Applying patch fix-static-build.patch
-- Applying patch fix-default-proto-file-path.patch
-- Applying patch fix-utf8-range.patch
-- Applying patch fix-install-dirs.patch
-- Applying patch fix-constinit-with-clang-cl.patch
-- Applying patch fix-upb.patch
-- Using source at /tmp/OpenWRT-21.02.0-ramips_mt76x8/vcpkg/buildtrees/protobuf/src/v33.4-f8b43d71cd.clean
-- Configuring mipsel-linux
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:127 (message):
    Command failed: /usr/bin/ninja -v
    Working Directory: /tmp/OpenWRT-21.02.0-ramips_mt76x8/vcpkg/buildtrees/protobuf/mipsel-linux-rel/vcpkg-parallel-configure
    Error code: 1
    See logs for more information:
      /tmp/OpenWRT-21.02.0-ramips_mt76x8/vcpkg/buildtrees/protobuf/config-mipsel-linux-rel-CMakeCache.txt.log
      /tmp/OpenWRT-21.02.0-ramips_mt76x8/vcpkg/buildtrees/protobuf/config-mipsel-linux-rel-CMakeConfigureLog.yaml.log
      /tmp/OpenWRT-21.02.0-ramips_mt76x8/vcpkg/buildtrees/protobuf/config-mipsel-linux-out.log

Call Stack (most recent call first):
  /tmp/OpenWRT-21.02.0-ramips_mt76x8/openwrt-sdk-21.02.0-ramips-mt76x8_gcc-8.4.0_musl.Linux-x86_64/staging_dir/toolchain-mipsel_24kc_gcc-8.4.0_musl/x64-linux/share/vcpkg-cmake/vcpkg_cmake_configure.cmake:269 (vcpkg_execute_required_process)
  buildtrees/versioning_/versions/protobuf/82a850caf35034a45596845a1d6e734b82f6a79a/portfile.cmake:51 (vcpkg_cmake_configure)
  scripts/ports.cmake:206 (include)


error: building protobuf:mipsel-linux failed with: BUILD_FAILED
See https://learn.microsoft.com/vcpkg/troubleshoot/build-failures?WT.mc_id=vcpkg_inproduct_cli for more information.
Elapsed time to handle protobuf:mipsel-linux: 1.9 s
Please ensure you're using the latest port files with `git pull` and `vcpkg update`.
Then check for known issues at:
  https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+protobuf
You can submit a new issue at:
  https://github.com/microsoft/vcpkg/issues/new?title=%5Bprotobuf%5D%20build%20error%20on%20mipsel-linux&body=Copy%20issue%20body%20from%20%2Ftmp%2FOpenWRT-21.02.0-ramips_mt76x8%2Fopenwrt-sdk-21.02.0-ramips-mt76x8_gcc-8.4.0_musl.Linux-x86_64%2Fstaging_dir%2Ftoolchain-mipsel_24kc_gcc-8.4.0_musl%2Fvcpkg%2Fissue_body.md

                                                                   ERROR: Early Exit at Step 9.

And in last log file /tmp/OpenWRT-21.02.0-ramips_mt76x8/vcpkg/buildtrees/protobuf/config-mipsel-linux-out.log

-- Check for working CXX compiler: /tmp/OpenWRT-21.02.0-ramips_mt76x8/openwrt-sdk-21.02.0-ramips-mt76x8_gcc-8.4.0_musl.Linux-x86_64/staging_dir/toolchain-mipsel_24kc_gcc-8.4.0_musl/bin/mipsel-openwrt-linux-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- protobuf version: 33.4.0
-- Performing Test protobuf_HAVE_LD_VERSION_SCRIPT
-- Performing Test protobuf_HAVE_LD_VERSION_SCRIPT - Success
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Performing Test protobuf_HAVE_BUILTIN_ATOMICS
-- Performing Test protobuf_HAVE_BUILTIN_ATOMICS - Failed
CMake Error at cmake/protobuf-configure-target.cmake:11 (target_link_libraries):
  Cannot specify link libraries for target "libprotobuf" which is not built
  by this project.
Call Stack (most recent call first):
  cmake/libprotobuf-lite.cmake:28 (protobuf_configure_target)
  CMakeLists.txt:280 (include)


-- Configuring incomplete, errors occurred!
ninja: build stopped: subcommand failed.
(END)

Any ideas?

Also tested to build for Teltonika RUTM09 and got same error....

VERSION_ID="21.02.0"
OPENWRT_BOARD="ramips/mt7621"