Meta's Muse agent fails to reach IoT via SORACOM Arc

SORACOM's Shibata set out to see if Meta's Muse agent, which runs commands inside its own Linux VM, could act as an always-on IoT watchdog. The plan was to connect the Muse VM to SORACOM Arc, place it in the same Virtual Private Gateway as the devices, and use SORACOM Gate's device-to-device communication to reach them directly. SORACOM already offers API and MCP server access to SIM status and Harvest Data, but logging into a device to check logs or change settings requires IP-level reachability, which Arc would provide.

The test hit three hurdles. First, Muse's VM blocked UDP sends from unconnected sockets with EPERM, so the official soratun client could not complete the WireGuard handshake. Second, Muse's UDP relay allowed only the first packet per socket, breaking the key renegotiation that WireGuard expects about every two minutes. Third, even after patches solved those, incoming packets to listening sockets never became connections. Shibata's patches to wireguard-go—forcing connect(), freezing the destination, rotating sockets per packet, and sending keepalives on receive—kept the tunnel alive for 43 minutes until a VM restart. But from a Raspberry Pi on a separate SORACOM account, only slow pings and RSTs from closed ports returned; TCP and UDP to open ports, and any Muse-initiated traffic, failed.

Shibata suspects Muse's VM restricts application-socket communication with private addresses (10.0.0.0/8) as a safety feature, though this is an inference from observation, not confirmed documentation. Muse itself indicated that a Tailscale client is preinstalled and outbound communication is allowed, suggesting WireGuard is not blocked wholesale but controlled by direction and client type—a claim Shibata did not verify. For now, the practical path for IoT monitoring is to skip Arc: have devices send data to Harvest Data and let Muse read it via the SORACOM API over HTTPS, using a SAM user key limited to read-only access.