render_livekit_yaml emits invalid CIDR for IPv4 node_ip — `/128` hardcoded #36

New issue

Closed

opened 2026-04-30 12:38:20 +00:00 by sameh-farouk · 0 comments

sameh-farouk commented

2026-04-30 12:38:20 +00:00

Member

Symptom

On a single-user / public deploy where node_ip is an IPv4 address (e.g. 185.206.122.48), the supervisor writes a config that crashes livekit-server immediately on startup:

2026-04-30T11:12:41.351Z	INFO	livekit	hwstats/memory_linux.go:74	failed reading cgroup specific memory stats, falling back to system wide implementation
2026-04-30T11:12:41.351Z	INFO	livekit	redis/redis.go:144	connecting to redis	{"simple": true, "addr": "127.0.0.1:6379"}
invalid CIDR address: 185.206.122.48/128

No signaling, no media, no huddles. Hard-fails before binding any port.

Cause

render_livekit_yaml (crates/hero_livekit_server/src/livekit/rpc.rs ~L939) hardcodes /128 in rtc.ips.includes:

y.push_str(&format!(
    "  ips:\n    includes:\n      - \"{}/128\"\n",
    cfg.node_ip,
));

/128 is a valid single-host prefix for IPv6 but invalid for IPv4 (where the equivalent is /32). Pion (the Go UDP layer in livekit-server) parses the CIDR strictly and rejects.

Why it worked until now

The hardcoded /128 was added by PR #32 to defend against UDP port-mux EADDRINUSE collisions on multi-user mycelium hosts, where node_ip is always an IPv6 address. Single-user / public-IP deploys weren't part of the test matrix.

Reproduction

# Single-user TF Grid VM, public IPv4 in env.sh:
MYCELIUM_IP=185.206.122.48 service_livekit start --reset
# → livekit-server crashes; check ~/hero/var/hero_livekit/logs/livekit-server.log

Fix (PR #36)

Detect address family at render time:

IPv4 literal → emit /32
IPv6 literal → emit /128 (unchanged — multi-user mycelium path is preserved)
Hostname / non-literal → skip the include block (binding on all global IPs is safe on single-user hosts)

Verified on both deploy shapes:

Single-user IPv4 (TF Grid VM, public 185.206.122.48): yaml gets /32, livekit-server binds all 3 ports cleanly
Multi-user mycelium (shared host, sameh's slot 4a0:6976:8fa7:efc:5::1): yaml unchanged at /128, no regression

## Symptom On a single-user / public deploy where `node_ip` is an IPv4 address (e.g. `185.206.122.48`), the supervisor writes a config that crashes livekit-server immediately on startup: ``` 2026-04-30T11:12:41.351Z INFO livekit hwstats/memory_linux.go:74 failed reading cgroup specific memory stats, falling back to system wide implementation 2026-04-30T11:12:41.351Z INFO livekit redis/redis.go:144 connecting to redis {"simple": true, "addr": "127.0.0.1:6379"} invalid CIDR address: 185.206.122.48/128 ``` No signaling, no media, no huddles. Hard-fails before binding any port. ## Cause `render_livekit_yaml` (`crates/hero_livekit_server/src/livekit/rpc.rs` ~L939) hardcodes `/128` in `rtc.ips.includes`: ```rust y.push_str(&format!( " ips:\n includes:\n - \"{}/128\"\n", cfg.node_ip, )); ``` `/128` is a valid single-host prefix for IPv6 but invalid for IPv4 (where the equivalent is `/32`). Pion (the Go UDP layer in livekit-server) parses the CIDR strictly and rejects. ## Why it worked until now The hardcoded `/128` was added by PR #32 to defend against UDP port-mux EADDRINUSE collisions on multi-user mycelium hosts, where `node_ip` is *always* an IPv6 address. Single-user / public-IP deploys weren't part of the test matrix. ## Reproduction ```bash # Single-user TF Grid VM, public IPv4 in env.sh: MYCELIUM_IP=185.206.122.48 service_livekit start --reset # → livekit-server crashes; check ~/hero/var/hero_livekit/logs/livekit-server.log ``` ## Fix (PR #36) Detect address family at render time: - IPv4 literal → emit `/32` - IPv6 literal → emit `/128` (unchanged — multi-user mycelium path is preserved) - Hostname / non-literal → skip the include block (binding on all global IPs is safe on single-user hosts) Verified on both deploy shapes: - Single-user IPv4 (TF Grid VM, public 185.206.122.48): yaml gets `/32`, livekit-server binds all 3 ports cleanly - Multi-user mycelium (shared host, sameh's slot `4a0:6976:8fa7:efc:5::1`): yaml unchanged at `/128`, no regression