Hi Team,
Does `listenOptions.connectTimeout` take effect in ziti-edge-tunnel on the hosting side, or am I misunderstanding the field?
The host.v1 docs- describe `connectTimeout` Timeout when making connections to the external server.
But with it set, a hosted service dialing an upstream that never completes the handshake (unreachable / drops the SYN) is not bounded by it, the connect stays pending until the OS's own TCP timeout, and changing the value makes no difference.
# tcpdump -ttt 'host <upstream> and tcp port 19999' (deltas between packets)
00:00:00.000000 Flags [S] <tunnel-host>.39868 > <upstream>.19999 seq 1165491979 # t = 0.0s
00:00:01.021534 Flags [S] (retransmit, same seq) # t ≈ 1.0s
00:00:02.016022 Flags [S] (retransmit, same seq) # t ≈ 3.0s <-- past connectTimeout=2s
00:00:04.255983 Flags [S] (retransmit, same seq) # t ≈ 7.3s
00:00:08.192034 Flags [S] (retransmit, same seq) # t ≈ 15.5s
```
The tunneler logs that single connect as `... failed: connection timed out` **~130s** later, not at 2s — i.e. it rides the OS default TCP connect timeout (`tcp_syn_retries`), measured from the terminator's own timestamps:
```
on_hosted_client_connect() ... dst_addr[tcp:<upstream>:28931]: incoming connection # t = 0.0s
on_hosted_tcp_connector_connect() ... connect to <upstream>:28931 failed: connection timed out # t = 130.5s
```
host.v1
{
"forwardProtocol": true,
"forwardPort": true,
"allowedProtocols": ["tcp", "udp"],
"allowedPortRanges": [{ "low": 1, "high": 65535 }],
"address": "<upstream>",
"listenOptions": {
"connectTimeout": "2s",
"connectTimeoutSeconds": 2
}
}
Controller: v1.6.15
ziti-edge-tunnel v1.16.2
Skimming the source, the hosting path on_hosted_client_connect in lib/ziti-tunnel-cbs/ziti_hosting.c calls connector->connect(...) with no timeout and never applies the value
Is connectTimeout meant to bound the hosted-side connect in the C tunneler, or is this a known limitation?
Thanks!