Running exo on two Ubuntu machines on the same local network (same /24 subnet, wired Ethernet). Both nodes start successfully, but neither discovers the other — each node elects itself as Master and only ever logs discovered: Some(<own_zid>), never the peer's ZID.
Environment
OS: Ubuntu (both machines)
Machine 1: IP 192.168.1.249/24, interface enp6s0
Machine 2: IP 192.168.1.160/24, interface enp6s0
Both on the same physical LAN, wired, verified with ip route show — same subnet, same gateway
exo installed via uv run exo
Steps taken to rule out network/firewall issues
ping between the two machines works both ways.
ufw opened on both machines for TCP+UDP on ports 52415 and 7447:
sudo ufw allow 52415/tcp
sudo ufw allow 52415/udp
sudo ufw allow 7447/tcp
sudo ufw allow 7447/udp
Direct UDP connectivity confirmed with nc:
machine 2 (receiver)
nc -ul 52415
machine 1 (sender)
echo "test" | nc -u 192.168.1.160 52415
Packet received successfully — confirms UDP is not blocked between the two hosts.
4. ip a confirms no conflicting interfaces are involved in routing (machine 1 has an unrelated, down docker0 interface at 172.17.0.1/16, but the LAN interface enp6s0 is correctly used per ip route show).
Logs (DEBUG=9, -v)
Both nodes start cleanly, subscribe to all topics, and repeatedly re-elect themselves as Master:
[ INFO ] Using ZID: 8807e9bcb506b1a3cd047fc8b73589a6
...
[ INFO ] discovered: Some("8807e9bcb506b1a3cd047fc8b73589a6")
[ INFO ] Node elected Master - maintaining self
This repeats indefinitely; the peer's ZID never appears in either node's logs. No errors or warnings are logged.
Code investigation
--bootstrap-peers (documented in --help) currently raises ValueError("Bootstrap peers has been temporarily removed") in main.py, so manual peer connection isn't currently possible as a workaround.
Discovery is initialized via Router.create() → NetworkingHandle.new(identity, namespace, listen_port, discovery_service_port) in exo/routing/router.py, which delegates to the compiled exo_rs native module — no further Python-level configuration (e.g. interface binding, multicast group) is exposed.
EXO_ZENOH_NAMESPACE is None (default/unset) on both machines, ruling out a namespace mismatch.
Expected behavior
Both nodes should discover each other automatically and form a 2-node cluster.
Additional context
This appears to be the same class of issue as #520, #1471, and #1682 — LAN-based discovery silently failing on Linux/mixed setups despite confirmed network connectivity and no visible errors. Happy to provide exo_rs version, full debug logs, or test any patches/workarounds (e.g. re-enabling --bootstrap-peers, or exposing a way to bind discovery to a specific interface/IP).
Running exo on two Ubuntu machines on the same local network (same /24 subnet, wired Ethernet). Both nodes start successfully, but neither discovers the other — each node elects itself as Master and only ever logs discovered: Some(<own_zid>), never the peer's ZID.
Environment
OS: Ubuntu (both machines)
Machine 1: IP 192.168.1.249/24, interface enp6s0
Machine 2: IP 192.168.1.160/24, interface enp6s0
Both on the same physical LAN, wired, verified with ip route show — same subnet, same gateway
exo installed via uv run exo
Steps taken to rule out network/firewall issues
ping between the two machines works both ways.
ufw opened on both machines for TCP+UDP on ports 52415 and 7447:
sudo ufw allow 52415/tcp
sudo ufw allow 52415/udp
sudo ufw allow 7447/tcp
sudo ufw allow 7447/udp
Direct UDP connectivity confirmed with nc:
machine 2 (receiver)
nc -ul 52415
machine 1 (sender)
echo "test" | nc -u 192.168.1.160 52415
Packet received successfully — confirms UDP is not blocked between the two hosts.
4. ip a confirms no conflicting interfaces are involved in routing (machine 1 has an unrelated, down docker0 interface at 172.17.0.1/16, but the LAN interface enp6s0 is correctly used per ip route show).
Logs (DEBUG=9, -v)
Both nodes start cleanly, subscribe to all topics, and repeatedly re-elect themselves as Master:
[ INFO ] Using ZID: 8807e9bcb506b1a3cd047fc8b73589a6
...
[ INFO ] discovered: Some("8807e9bcb506b1a3cd047fc8b73589a6")
[ INFO ] Node elected Master - maintaining self
This repeats indefinitely; the peer's ZID never appears in either node's logs. No errors or warnings are logged.
Code investigation
--bootstrap-peers (documented in --help) currently raises ValueError("Bootstrap peers has been temporarily removed") in main.py, so manual peer connection isn't currently possible as a workaround.
Discovery is initialized via Router.create() → NetworkingHandle.new(identity, namespace, listen_port, discovery_service_port) in exo/routing/router.py, which delegates to the compiled exo_rs native module — no further Python-level configuration (e.g. interface binding, multicast group) is exposed.
EXO_ZENOH_NAMESPACE is None (default/unset) on both machines, ruling out a namespace mismatch.
Expected behavior
Both nodes should discover each other automatically and form a 2-node cluster.
Additional context
This appears to be the same class of issue as #520, #1471, and #1682 — LAN-based discovery silently failing on Linux/mixed setups despite confirmed network connectivity and no visible errors. Happy to provide exo_rs version, full debug logs, or test any patches/workarounds (e.g. re-enabling --bootstrap-peers, or exposing a way to bind discovery to a specific interface/IP).