From 5022f2be149e40ac5bdd5fc362e926f3edcf44f0 Mon Sep 17 00:00:00 2001
From: Christophe Besson <cbesson@gmail.com>
Date: Fri, 4 Sep 2026 01:47:45 +0200
Subject: fix(client): resolve STUN hostnames in the main process

Chromium's P2P socket manager failed every STUN hostname with
ERR_NAME_NOT_RESOLVED in a restricted-resolver environment (a Windows KVM
guest), even though its own general network stack, the OS resolver and
Node's resolver all resolved the same names -- and mapping the names to IPs
with --host-resolver-rules changed nothing, so it is not ordinary
resolution. WebRTC was left with no server-reflexive candidate.

The desktop client now resolves the STUN hostnames in the main process
(`ice:resolve-stun`, Node's dns.resolve4) and hands `transport.js` the
IP form; a name that will not resolve (the decommissioned Mozilla host) is
dropped. In a browser there is no `meshbay` bridge and the hostnames are
used unchanged -- a browser resolves them fine, so that path is untouched.
Falls back to the hostname form if the bridge call throws.

Also, scoped to win32: disable WebRtcHideLocalIpsWithMdns, so the client
publishes its real local IP instead of a `.local` name the node's ICE stack
cannot resolve across the KVM bridge. Changes nothing on Linux/macOS.
Test-env workaround, revisit before release.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 .../src/meshbay_hub/static/transport.js            | 39 +++++++++++++++++-----
 1 file changed, 31 insertions(+), 8 deletions(-)

(limited to 'packages/meshbay-hub')

diff --git a/packages/meshbay-hub/src/meshbay_hub/static/transport.js b/packages/meshbay-hub/src/meshbay_hub/static/transport.js
index 329baf1..809bb83 100644
--- a/packages/meshbay-hub/src/meshbay_hub/static/transport.js
+++ b/packages/meshbay-hub/src/meshbay_hub/static/transport.js
@@ -136,6 +136,36 @@ window.MeshBayTrace = {
   clear() { try { localStorage.removeItem(TRACE_LOG_KEY); } catch { /* ignore */ } },
 };
 
+// STUN, two providers deep. On the desktop client the hostnames are resolved in
+// the main process (Node's resolver) and handed back as IPs: Chromium's P2P
+// socket manager fails every STUN hostname with ERR_NAME_NOT_RESOLVED in some
+// restricted-resolver environments (a libvirt/KVM guest was where this surfaced)
+// even though every other resolver on the box works. In a browser there is no
+// `meshbay` bridge and the hostnames are used directly — a browser resolves them
+// fine. Resolved once per run; a provider changing IPs is picked up on restart.
+const STUN_URLS = [
+  'stun:stun.l.google.com:19302',
+  'stun:stun1.l.google.com:19302',
+  'stun:stun.cloudflare.com:3478',
+  'stun:stun.services.mozilla.com:3478',
+];
+let _iceServersPromise = null;
+function iceServers() {
+  if (!_iceServersPromise) {
+    _iceServersPromise = (async () => {
+      let urls = STUN_URLS;
+      if (window.meshbay && typeof window.meshbay.resolveStun === 'function') {
+        try {
+          const r = await window.meshbay.resolveStun(STUN_URLS);
+          if (Array.isArray(r) && r.length) urls = r;
+        } catch { /* keep the hostname form */ }
+      }
+      return urls.map((u) => ({ urls: u }));
+    })();
+  }
+  return _iceServersPromise;
+}
+
 function _showTraceView() {
   {
     const renderTraceView = () => {
@@ -355,14 +385,7 @@ class MeshBayTransport {
     this._newNodeBundle = null;
     this._newNodeBundleRecovery = null;
     this._joinError = null;
-    this._pc = new RTCPeerConnection({
-      iceServers: [
-        { urls: 'stun:stun.l.google.com:19302' },
-        { urls: 'stun:stun1.l.google.com:19302' },
-        { urls: 'stun:stun.cloudflare.com:3478' },
-        { urls: 'stun:stun.services.mozilla.com:3478' },
-      ],
-    });
+    this._pc = new RTCPeerConnection({ iceServers: await iceServers() });
 
     this._channel = this._pc.createDataChannel('mnp', { ordered: true });
     this._channel.binaryType = 'arraybuffer';
-- 
cgit v1.2.3