Stuck on status

[abolix]

I get stuck here

sudo bash dnstm-setup.sh --status


  ╔══════════════════════════════════════════════════════╗
  ║                                                      ║
  ║                  dnstm-setup v1.3.1                  ║
  ║             Interactive DNS Tunnel Setup             ║
  ║                                                      ║
  ╚══════════════════════════════════════════════════════╝

  Server IP:

  Tunnel Status
  ────────────────────────────────────────

Mode: Multi-tunnel

TAG              TRANSPORT    BACKEND          PORT     DOMAIN               STATUS
------------------------------------------------------------------------------------------
slip1            Slipstream   socks            5310            Running (default)
dnstt1           DNSTT        socks            5311                Stopped
slip-ssh         Slipstream   ssh              5312                 Running
dnstt-ssh        DNSTT        ssh              5313                Stopped
noiz1            DNSTT        socks            5314                Running
noiz-ssh         DNSTT        ssh              5315                Running

  SOCKS Proxy Authentication
  ────────────────────────────────────────
  No authentication (open proxy)

  microsocks Port: 35800

after this nothing happens and I get stuck. any idea for debugging here ?
using ubuntu 22.04
tried in both turkey and germany server
DNS are set by cloudflare API automatically

[abolix]

Tried on another server, worked, but I think it's worth so investigate. if not you can close.

[SamNet-dev]

Fixed in 6e19b02.

Root cause: dnstm tunnel share -t <tag> had no timeout. When DNS/domain config is missing or a tunnel is stopped, it hangs indefinitely — blocking the entire --status output after the microsocks port line.

Fix: Added timeout --kill-after=3 10 to all dnstm subcommand calls in the status path:

• dnstm tunnel list
• dnstm backend status -t socks
• dnstm tunnel share -t <tag> (the critical one)
• sshtun-user list (added --kill-after to existing timeout)

This ensures --status always completes within a bounded time, even if dnstm hangs internally.