aboutsummaryrefslogtreecommitdiffstats
path: root/packages/meshbay-node/tests
diff options
context:
space:
mode:
authorChristophe Besson <cbesson@gmail.com>2026-09-04 15:54:05 +0200
committerChristophe Besson <cbesson@gmail.com>2026-09-04 15:54:05 +0200
commit7ff675fdc0866ca40bdb703bc95c0cc60e3edd87 (patch)
tree46a3cd561a876dfea9aa511b3410b5224a032613 /packages/meshbay-node/tests
parent74941aae5451c03a296413710fe888b1924e8c27 (diff)
downloadmeshbay-7ff675fdc0866ca40bdb703bc95c0cc60e3edd87.tar.gz
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 <noreply@anthropic.com>
Diffstat (limited to 'packages/meshbay-node/tests')
-rw-r--r--packages/meshbay-node/tests/test_packaging_win.py24
1 files changed, 24 insertions, 0 deletions
diff --git a/packages/meshbay-node/tests/test_packaging_win.py b/packages/meshbay-node/tests/test_packaging_win.py
index 47a2842..ba3568c 100644
--- a/packages/meshbay-node/tests/test_packaging_win.py
+++ b/packages/meshbay-node/tests/test_packaging_win.py
@@ -221,6 +221,30 @@ def test_firewall_ps1_targets_both_executables_and_is_idempotent():
assert src.index("Remove-NetFirewallRule") < src.index("New-NetFirewallRule")
+def test_firewall_ps1_also_covers_lan_casting():
+ """
+ The WebRTC rules only reach MeshBay.exe / meshbay-node.exe; the cast HTTP
+ relay (src/cast-relay.js, fixed TCP 19550-19553) and mDNS device discovery
+ (src/cast-chromecast.js, bonjour-service, UDP 5353) are a separate surface
+ on the client alone, and need their own ports and protocols. Ports here
+ must agree with cast-relay.js's own constants and with the Linux
+ definitions in packaging/firewall/*/meshbay-cast.xml — three descriptions
+ of one port range that must not drift apart.
+ """
+ src = (ROOT / "packaging" / "win" / "firewall.ps1").read_text(encoding="utf-8")
+ assert "19550-19553" in src, "cast TCP range missing or does not match cast-relay.js"
+ assert '"5353"' in src, "mDNS discovery port (UDP 5353) missing"
+
+ relay = (CLIENT / "src" / "cast-relay.js").read_text(encoding="utf-8")
+ assert "PORT_BASE = 19550" in relay and "PORT_COUNT = 4" in relay, (
+ "cast-relay.js's port range changed — update firewall.ps1 to match")
+
+ firewalld = (ROOT / "packaging" / "firewall" / "firewalld" / "meshbay-cast.xml").read_text(
+ encoding="utf-8")
+ assert "19550-19553" in firewalld and "5353" in firewalld, (
+ "the Linux and Windows cast firewall definitions have drifted apart")
+
+
def test_the_bundled_daemon_goes_on_the_user_path_and_comes_back_off():
"""
The installer has no console entry point of its own; without this the