From 7ff675fdc0866ca40bdb703bc95c0cc60e3edd87 Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Fri, 4 Sep 2026 15:54:05 +0200 Subject: feat(packaging): cover LAN casting in the Windows firewall step, too firewall.ps1 only handled WebRTC. The cast HTTP relay (src/cast-relay.js, fixed TCP 19550-19553) and Chromecast/Smart TV mDNS discovery (src/cast-chromecast.js, bonjour-service, UDP 5353) are a separate surface on the client and were still hitting Windows' own "Allow access" dialog. Now four named rules: MeshBay / MeshBay Node stay program-scoped with no port restriction (there is no fixed WebRTC port to name -- the Windows equivalent of the broad 1024-65535/udp range the Linux packaging needs, since netfilter has no program scoping); MeshBay Cast / MeshBay Cast Discovery add the program AND the fixed port, matching packaging/firewall/*/meshbay-cast.xml exactly. test_packaging_win.py cross-checks the port numbers against cast-relay.js's own constants and the Linux firewalld definition, so the three descriptions of one port range can't quietly drift apart. Verified: rebuilt MeshBay-Setup-0.1.0.exe; the deployed firewall.ps1 carries all four rules. Node suite 836 pass / 25 skip. Co-Authored-By: Claude Sonnet 5 --- packaging/win/README.md | 41 +++++++++++++++++++++++++++++------------ 1 file changed, 29 insertions(+), 12 deletions(-) (limited to 'packaging/win/README.md') diff --git a/packaging/win/README.md b/packaging/win/README.md index 7bd7f67..5130e60 100644 --- a/packaging/win/README.md +++ b/packaging/win/README.md @@ -89,18 +89,35 @@ publish their host candidate as an unresolvable `.local` mDNS name that `aioice` discards — the browser always dials the node, never the reverse. So the node has to accept unsolicited inbound UDP from its peers. -**Windows Defender Firewall.** The setup wizard offers to add the inbound rules -for `MeshBay.exe` and `meshbay-node.exe` in one step — it needs one admin -confirmation (`build/installer.nsh` runs `firewall.ps1` via NSIS `ExecShellWait -"runas"`; the per-user install itself never elevates). Say yes and both -prompts you'd otherwise hit mid-use are gone; say no, or the UAC prompt is -dismissed, and Windows falls back to its own **"Allow access"** dialog the -first time each process binds a socket — tick **both Private and Public** then -(a libvirt/VM adapter, and sometimes a plain Ethernet one, registers as -Public; a Private-only rule silently drops every peer). Missed both? Add it by -hand: *Windows Defender Firewall → Advanced → Inbound Rules → New Rule → -Program →* the bundled `…\resources\node-runtime\meshbay-node.exe` *→ Allow → -all profiles*. `firewall.ps1` is idempotent and re-runnable +**Windows Defender Firewall.** The setup wizard offers to add four inbound +rules in one step — it needs one admin confirmation (`build/installer.nsh` +runs `firewall.ps1` via NSIS `ExecShellWait "runas"`; the per-user install +itself never elevates): + +| Rule | Program | Protocol / port | For | +|---|---|---|---| +| `MeshBay` | `MeshBay.exe` | UDP, any port | WebRTC (ICE checks touch the client too) | +| `MeshBay Node` | `meshbay-node.exe` | UDP, any port | WebRTC (the node — unsolicited inbound, see above) | +| `MeshBay Cast` | `MeshBay.exe` | TCP 19550–19553 | LAN cast HTTP relay (`src/cast-relay.js`) | +| `MeshBay Cast Discovery` | `MeshBay.exe` | UDP 5353 | Chromecast/Smart TV mDNS discovery (`bonjour-service`) | + +The WebRTC rules have no port restriction because there is no fixed port to +name — aiortc binds a fresh one per connection — so they are scoped by +*program* instead, which is the Windows-native answer to the same problem the +Linux packaging solves with a broad `1024-65535/udp` range +(`packaging/firewall/`). The cast rules are scoped by program *and* port, +since those two are fixed and known — matching +`packaging/firewall/*/meshbay-cast.xml` exactly. + +Say yes and every prompt you'd otherwise hit mid-use — connecting, or the +first cast — is gone. Say no, or the UAC prompt is dismissed, and Windows +falls back to its own **"Allow access"** dialog the first time each +program/port combination is used — tick **both Private and Public** then (a +libvirt/VM adapter, and sometimes a plain Ethernet one, registers as Public; a +Private-only rule silently drops every peer). Missed one? Add it by hand: +*Windows Defender Firewall → Advanced → Inbound Rules → New Rule → Program →* +the exe *→ Allow → all profiles*, restricting to the port above if it is a +cast rule. `firewall.ps1` is idempotent and re-runnable (`powershell -File resources\firewall.ps1 add`, elevated); it logs to `%TEMP%\meshbay-firewall.log`. -- cgit v1.2.3