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 /packaging/caddy | |
| 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 'packaging/caddy')
0 files changed, 0 insertions, 0 deletions