matter-server: bind the :5580 control WebSocket to the pod address #144
@@ -50,6 +50,19 @@ spec:
|
||||
args:
|
||||
- --storage-path=/data
|
||||
- --port=5580
|
||||
# Bind the :5580 control WebSocket to the pod's eth0 address,
|
||||
# not 0.0.0.0. This pod is multi-homed — net1 is a macvlan on
|
||||
# the IoT VLAN (below) — and macvlan traffic bypasses Cilium
|
||||
# policy, so a 0.0.0.0 bind exposes the unauthenticated Matter
|
||||
# control API to the whole IoT VLAN (verified 2026-07-10: GET
|
||||
# http://<net1 ip>:5580/ from the VLAN returned 200). An IoT
|
||||
# client could then drive the Matter fabric. `--listen-address`
|
||||
# is independent of `--primary-interface`: the WebSocket is the
|
||||
# HA control channel (reached via the ClusterIP Service, IPv4),
|
||||
# while Matter commissioning/discovery stays on net1. POD_IP is
|
||||
# the eth0 IPv4 (status.podIP). This is the matter-server twin
|
||||
# of the shelly-manager fix (PR #142).
|
||||
- --listen-address=$(POD_IP)
|
||||
# Pin Matter SDK link-local discovery to the macvlan attachment
|
||||
# on the IoT VLAN. Without this, the SDK picks the kernel's
|
||||
# default route interface (eth0, Cilium pod CIDR) for Matter
|
||||
@@ -63,6 +76,11 @@ spec:
|
||||
- --vendorid=4939
|
||||
- --fabricid=2
|
||||
- --log-level=debug
|
||||
env:
|
||||
- name: POD_IP
|
||||
valueFrom:
|
||||
fieldRef:
|
||||
fieldPath: status.podIP
|
||||
ports:
|
||||
- name: ws
|
||||
containerPort: 5580
|
||||
|
||||
Reference in New Issue
Block a user