Zenoh default endpoint configuration behaviour

[tjrmarques]

Hello,

When not configuring any endpoints, Zenoh (1.0.0) seems to default to listening on a "random" TCP port on all interfaces.
This is really useful for some setups where one doesn't need/want to specifically select a port.

However, with this kind of configuration on Windows and nodes on the same computer, I'm seeing that (at least sometimes) a Zenoh peer does not actually bind to the port it claims to be bound on the trace (checked via netstat), and so connecting nodes fail during the TCP handshake (checked via Wireshark). Discovery seems to be working fine, as nodes do know what port to connect to. Also, I have multiple sessions being started by the same binary, which might not be the standard approach.

Is this expected behaviour?
I haven't found any issue filed for this, so I'm assuming I'm doing something weird...

[YuanYuYuan]

Hi @tjrmarques! Could you please share the steps and the settings to reproduce the issue?

[tiagomarquestek]

Hi @YuanYuYuan

I seem to have fallen into some variant of this issue: eclipse-zenoh/zenoh#408, in my case because the specific machines are configured with IPV6 disabled.

Enabling IPv6 on the interfaces or specifying a tcp/0.0.0.0:0 listen endpoint solves the problem.

The really confusing bit is that:

1. Zenoh does not report a failure binding on the IPv6 endpoint(s)
2. Zenoh logs that it can be reached on IPv4 addresses, which is clearly not the case - as per netstat

Relevant part of anonymised log below

�[2m2025-07-24T13:39:11.753047Z�[0m �[34mDEBUG�[0m ThreadId(02) �[2mzenoh::net::runtime::orchestrator�[0m�[2m:�[0m Listener added: tcp/[::]:60781
�[2m2025-07-24T13:39:11.753113Z�[0m �[35mTRACE�[0m acc-0 ThreadId(04) �[2mzenoh_link_tcp::unicast�[0m�[2m:�[0m Ready to accept TCP connections on: [::]:60781
�[2m2025-07-24T13:39:11.760405Z�[0m �[32m INFO�[0m ThreadId(02) �[2mzenoh::net::runtime::orchestrator�[0m�[2m:�[0m Zenoh can be reached at: tcp/[fe80::xxxx:xxxx:xxxx:xxxx]:60781
�[2m2025-07-24T13:39:11.760426Z�[0m �[32m INFO�[0m ThreadId(02) �[2mzenoh::net::runtime::orchestrator�[0m�[2m:�[0m Zenoh can be reached at: tcp/[fe80::xxxx:xxxx:xxxx:xxxx]:60781
�[2m2025-07-24T13:39:11.760435Z�[0m �[32m INFO�[0m ThreadId(02) �[2mzenoh::net::runtime::orchestrator�[0m�[2m:�[0m Zenoh can be reached at: tcp/[fe80::xxxx:xxxx:xxxx:xxxx]:60781
�[2m2025-07-24T13:39:11.760443Z�[0m �[32m INFO�[0m ThreadId(02) �[2mzenoh::net::runtime::orchestrator�[0m�[2m:�[0m Zenoh can be reached at: tcp/[fe80::xxxx:xxxx:xxxx:xxxx]:60781
�[2m2025-07-24T13:39:11.760451Z�[0m �[32m INFO�[0m ThreadId(02) �[2mzenoh::net::runtime::orchestrator�[0m�[2m:�[0m Zenoh can be reached at: tcp/[fe80::xxxx:xxxx:xxxx:xxxx]:60781
�[2m2025-07-24T13:39:11.760459Z�[0m �[32m INFO�[0m ThreadId(02) �[2mzenoh::net::runtime::orchestrator�[0m�[2m:�[0m Zenoh can be reached at: tcp/[fe80::xxxx:xxxx:xxxx:xxxx]:60781
�[2m2025-07-24T13:39:11.760467Z�[0m �[32m INFO�[0m ThreadId(02) �[2mzenoh::net::runtime::orchestrator�[0m�[2m:�[0m Zenoh can be reached at: tcp/10.xxx.xxx.xxx:60781
�[2m2025-07-24T13:39:11.760474Z�[0m �[32m INFO�[0m ThreadId(02) �[2mzenoh::net::runtime::orchestrator�[0m�[2m:�[0m Zenoh can be reached at: tcp/192.168.xxx.xxx:60781
�[2m2025-07-24T13:39:11.760545Z�[0m �[34mDEBUG�[0m ThreadId(02) �[2mzenoh::net::runtime::orchestrator�[0m�[2m:�[0m UDP port bound to 224.0.0.224:7446
�[2m2025-07-24T13:39:11.760569Z�[0m �[34mDEBUG�[0m ThreadId(02) �[2mzenoh::net::runtime::orchestrator�[0m�[2m:�[0m Joined multicast group 224.0.0.224 on interface 0.0.0.0
�[2m2025-07-24T13:39:11.760580Z�[0m �[32m INFO�[0m ThreadId(02) �[2mzenoh::net::runtime::orchestrator�[0m�[2m:�[0m zenohd listening scout messages on 224.0.0.224:7446
�[2m2025-07-24T13:39:11.760659Z�[0m �[34mDEBUG�[0m ThreadId(02) �[2mzenoh::net::runtime::orchestrator�[0m�[2m:�[0m UDP port bound to 0.0.0.0:49193

[YuanYuYuan]

Hi @tiagomarquestek! I just tested the z_sub example on my laptop (NixOS with an AMD CPU) with IPv6 disabled. It only shows the listeners available at IPV4. Maybe it's related to your platform/settings.