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

Tunneler Apps Ziti Edge Tunnel
1

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.

2

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
3

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

4

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.

5

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:~#
6

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.

7

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!