Node.js os.networkInterfaces() fails with EINVAL inside sandbox (uv_interface_addresses Unknown system error 1)

[derekhsu]

Bug Summary

When OpenClaw Gateway runs inside an OpenShell sandbox, os.networkInterfaces() fails with:

Unhandled promise rejection: SystemError: A system error occurred: uv_interface_addresses returned Unknown system error 1 (Unknown system error 1)
    at Object.networkInterfaces (node:os:218:16)
    at Function.assumeNetworkInterfaceNames (/usr/lib/node_modules/openclaw/node_modules/@homebridge/ciao/src/NetworkManager.ts:527:23)
    at NetworkManager.getCurrentNetworkInterfaces (/usr/lib/node_modules/openclaw/node_modules/@homebridge/ciao/src/NetworkManager.ts:370:32)

The error originates from Node.js's os.networkInterfaces() → libuv's uv_interface_addresses() → getifaddrs() system call returning EINVAL (error code 1) inside the sandbox environment.

Environment

• OpenClaw Gateway running inside OpenShell sandbox (proxy mode, network namespace isolated)
• The sandbox uses a network namespace with veth pair (10.200.0.1 host side, 10.200.0.2 sandbox side)
• After process startup, the following restrictions are applied in order:
  1. setns(CLONE_NEWNET) to enter the network namespace
  2. prctl(PR_SET_DUMPABLE, 0) (via harden_child_process())
  3. Landlock filesystem restrictions
  4. seccomp filter (blocks AF_INET/AF_INET6 socket domains in proxy mode)

Root Cause Analysis

The error "Unknown system error 1" corresponds to EINVAL (error code 1 on Linux). The getifaddrs() system call fails inside the sandbox environment, likely due to one of:

1. PR_SET_DUMPABLE=0 interaction: After harden_child_process() sets PR_SET_DUMPABLE=0, the process cannot access /proc/{pid}/net/ in the normal way. This is because when dumpable=0, the gid/uid privilege checks for /proc filesystem access behave differently.

2. Network namespace state: The sandbox's network namespace has only lo and veth-s-{id} interfaces. The getifaddrs() call may encounter an unexpected kernel state when enumerating interfaces in this minimal namespace.

3. Seccomp filter side effect: While the seccomp filter only blocks AF_INET/AF_INET6 socket syscalls (not getifaddrs), there may be an indirect interaction when the filter is applied after PR_SET_DUMPABLE=0.

The error is not directly caused by seccomp blocking getifaddrs() — the syscall itself is allowed. The problem is an environment mismatch where getifaddrs() returns EINVAL inside the sandbox.

Impact

• OpenClaw Gateway fails to start inside the sandbox because @homebridge/ciao (mDNS advertiser) requires os.networkInterfaces() to function
• The ciao NetworkManager.getCurrentNetworkInterfaces() is called during initialization and throws an unhandled promise rejection

Related Issues in openclaw/openclaw

The OpenClaw repo has several related issues about @homebridge/ciao crashing:

• #70232: Bonjour mDNS crashes Gateway on VPS/cloud ("CIAO PROBING CANCELLED")
• #70197: ciao arp -a probe flashes cmd.exe window on Windows
• #67578: ciao assertion failure on malformed mDNS packet

None of these are the same issue — this is specifically about getifaddrs() returning EINVAL in a network namespace environment.

Questions for Investigation

1. Does getifaddrs() work correctly inside a network namespace when PR_SET_DUMPABLE=0?
2. Is there a way to make the sandbox environment more compatible with getifaddrs()?
3. Should OpenShell provide a fallback or workaround when getifaddrs() fails inside the sandbox?

References

• Node.js os.networkInterfaces(): https://nodejs.org/api/os.html#osnetworkinterfaces
• libuv uv_interface_addresses(): https://github.com/libuv/libuv/blob/main/src/unix/getifaddrs.c
• PR_SET_DUMPABLE man page: https://man7.org/linux/man-pages/man2/prctl.2.html

[derekhsu]

Workaround

Setting OPENCLAW_DISABLE_BONJOUR=1 in the sandbox environment prevents @homebridge/ciao from initializing, which avoids the getifaddrs() failure entirely:

openshell sandbox create \
  --name <tenant_name> \
  --from openclaw \
  --forward <local_port>:18789 \
  --env OPENCLAW_DISABLE_BONJOUR=1 \
  --provider <provider_name>

This works because the ciao NetworkManager that calls os.networkInterfaces() is only instantiated when Bonjour/mDNS advertising is enabled. Disabling it bypasses the problematic code path entirely.

Note: Issue #70232 in openclaw/openclaw reports that OPENCLAW_DISABLE_BONJOUR=1 was not recognized in v2026.4.21, so the workaround may depend on the OpenClaw version being used. If the env var is not effective, disabling via gateway.mdns.mode: "off" in openclaw.json should also work (though #70232 also notes this config may be ignored).