diff options
Diffstat (limited to 'packaging/win/README.md')
| -rw-r--r-- | packaging/win/README.md | 41 |
1 files changed, 41 insertions, 0 deletions
diff --git a/packaging/win/README.md b/packaging/win/README.md index 0ba18ca..8c29785 100644 --- a/packaging/win/README.md +++ b/packaging/win/README.md @@ -80,6 +80,47 @@ embeddable zip would need pip to make a `meshbay-node.exe` wrapper, and that wrapper bakes in an **absolute** interpreter path — it stops working the moment the tree is installed somewhere other than where it was built. +## Networking (running the node) + +The node's admin API is loopback-only, but its **transport is not**. WebRTC +binds an ephemeral UDP port per connection and — because browsers/Electron +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.** On the daemon's first run Windows pops a prompt +for `meshbay-node.exe`. Tick **both Private and Public** — a libvirt/VM adapter, +and sometimes a plain Ethernet one, registers as Public, and a Private-only rule +then silently drops every peer. The installer cannot pre-create this rule (it is +per-user and never elevates); the prompt is the mechanism. If you dismissed it, +add the rule by hand: *Windows Defender Firewall → Advanced → Inbound Rules → +New Rule → Program →* the bundled `…\resources\node-runtime\meshbay-node.exe` *→ +Allow → all profiles*. + +**A flat LAN needs nothing else.** The node offers a routable `192.168.x.y` host +candidate and browsers on the same subnet connect straight to it — same as the +residential-NAT cases that work without TURN. + +**A routed or multi-subnet LAN** (peers on `192.168.1.x` reaching a node on +`192.168.2.x`, or a VM) additionally needs: + +- routing between the subnets (the two ends must have a path to each other's + host-candidate address); +- inbound UDP on the ephemeral range allowed for `meshbay-node.exe` **and** for + any Linux host in the path — see the packaged `packaging/firewall/` profiles + and the "inbound WebRTC" section of `docs/PACKAGING-GUIDE.md`; +- `MESHBAY_WEBRTC_EXPOSE_LOCAL_IPS` is not relevant to the node — that switch is + the *client's*, and it is already on by default (`src/main.js`). + +**libvirt NAT is the awkward case.** A guest on the default NAT network is +reachable from its own hypervisor but not from other LAN machines, and its only +host candidate is the `192.168.122.x`/`192.168.200.x` address no third machine +can route to. Give the guest bridged (or macvtap) networking so it gets a real +LAN address, or run the node on the host. The node log now prints the host +addresses it offered — `WebRTC answer ready for peer=… (… host: 192.168.200.173, +1 srflx)` — so "did the node even offer something routable" is answerable from +the journal. + ## Dependency surface that needs watching `meshbay-node.spec` pulls the awkward packages in whole (`collect_all`) because |