Context
On the current bench setup, the host and ESP32 devices sit on the home LAN and share the home router's DHCP server. That blocks two things we want for prod:
- Custom DHCP options (e.g. advertising the broker endpoint via a DHCP option) and DHCP reservations under our own control.
- Network isolation, which bounds the rogue-broker / discovery-spoofing risk (a spoofed broker could push malicious configs, since our config channel is a control channel, not just data).
For dev this is fine and NOT a blocker: firmware bootstrap uses PlatformIO build flags, host services use env vars. This issue tracks the prod-stage network decisions only.
Decisions needed for prod
- Dedicated isolated segment for rack telemetry (VLAN on a managed switch, or a separate physical subnet), separate from general/home/office traffic.
- Its own DHCP authority on that segment (could be the Radxa running dnsmasq), enabling:
- a DHCP reservation for a fixed, well-known broker IP so firmware bootstraps to one stable address, and/or
- a DHCP option to distribute the broker endpoint to devices.
- How firmware resolves the broker on that segment: reserved static IP vs DHCP option vs mDNS (each carrying the auth caveat below).
Considerations
- Isolation is also a security control: removing untrusted hosts from the segment bounds the discovery-spoofing / rogue-broker threat. Pairs with broker TLS/auth as defense in depth.
- Any move to network discovery (DHCP option / mDNS) must come with broker authentication, or a spoofed announcement can redirect devices to a malicious broker.
- Cost: a managed switch / VLAN capability, and running a DHCP service on the segment.
- Benefit: our own addressing means a stable broker location, no dependence on a home router, and deterministic device bring-up.
Acceptance criteria
- A documented prod network design: segment isolation approach, DHCP/addressing authority, the broker's fixed or advertised address, and how firmware bootstrap resolves it.
- The design states whether network discovery is used and, if so, that broker authentication is required alongside it.
Prod-stage, not dev-blocking. Relates to the broker endpoint config work, a future broker TLS/auth item, and the discovery-security discussion. See docs/mqtt-contract.md for where the endpoint is defined on each side.
Context
On the current bench setup, the host and ESP32 devices sit on the home LAN and share the home router's DHCP server. That blocks two things we want for prod:
For dev this is fine and NOT a blocker: firmware bootstrap uses PlatformIO build flags, host services use env vars. This issue tracks the prod-stage network decisions only.
Decisions needed for prod
Considerations
Acceptance criteria
Prod-stage, not dev-blocking. Relates to the broker endpoint config work, a future broker TLS/auth item, and the discovery-security discussion. See docs/mqtt-contract.md for where the endpoint is defined on each side.