diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-09-04 15:54:05 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-09-04 15:54:05 +0200 |
| commit | 7ff675fdc0866ca40bdb703bc95c0cc60e3edd87 (patch) | |
| tree | 46a3cd561a876dfea9aa511b3410b5224a032613 /packages | |
| parent | 74941aae5451c03a296413710fe888b1924e8c27 (diff) | |
| download | meshbay-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')
| -rw-r--r-- | packages/meshbay-node/tests/test_packaging_win.py | 24 |
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 |