aboutsummaryrefslogtreecommitdiffstats
path: root/packaging/win/README.md
diff options
context:
space:
mode:
Diffstat (limited to 'packaging/win/README.md')
-rw-r--r--packaging/win/README.md41
1 files changed, 29 insertions, 12 deletions
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 `<uuid>.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`.