Move python3-gps, python3-bleak to REQUIRED_PACKAGES (needed for van-li3-battery,
van-gps-owntracks). Add modemmanager to REQUIRED_PACKAGES (provides mmcli for
van-sms-* services).
Deploy will now fail if these packages are missing, preventing silent failures
when GPS or SMS services are needed.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Replaced RTL8822CE with Mediatek MT7925E PCIe WiFi card. The mt76 driver
(MT7925E) properly supports AP bridge mode, unlike rtw88 (RTL8822CE).
R5C is now PRODUCTION-READY:
- 5GHz AP on channel 149 with 802.11ac/ax support
- WiFi clients bridge properly and receive DHCP
- Ethernet failover fully functional
- NAT/routing configured
RTL8822CE limitation: bridging in AP mode not supported by rtw88 driver.
MT7925E solution: mt76 driver stack supports full bridge forwarding.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
dnsmasq was failing to start or staying inactive because it was starting
before the bridge members were added. Updated van-ap-dnsmasq.service to
depend on van-br0-setup.service, ensuring the bridge is ready before
dnsmasq binds to br0.
Fixes: DHCP not provisioning addresses on boot.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
systemd-networkd Bridge= directive wasn't reliably adding interfaces to br0
on Armbian. Created persistent systemd service to ensure enP2p33s0 and wlp1s0
are added to the bridge after boot, maintaining 10.42.1.0/24 network.
This ensures the gateway bridge stays configured even after R5C reboots.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- Upgrade R5C from Debian to Armbian 6.18 fixes RTL8822CE 5GHz limitation
- Updated deploy.conf with Armbian's systemd network interface names:
- wlan1/wlan2 → wlp1s0 (single WiFi chip; both APs on same interface)
- eth0/eth1 → enP2p33s0/enP1p17s0 (MAC-derived naming)
- 5GHz AP now working on channel 149 with 802.11ac/ax support
- DHCP functional: devices receiving IPs from 10.42.1.10-254 range
- One test device successfully provisioned with lease at 10.42.1.66
Status: R5C AP operational, ready for production failover role
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
FriendlyElec R5C RTL8822CE WiFi chip does not support 5GHz AP mode.
Both wlan0 and wlan1 locked to 2.4GHz-only (mode 2) by firmware/driver.
Tested:
- Channel 149 (5GHz): fails with 'mode (2) not found'
- Channel 36 (5GHz): fails with 'mode (2) not found'
- Both wlan0 and wlan1: same limitation
- Regulatory domain persistence doesn't change mode
Solution: Configure hostapd for 2.4GHz (hw_mode=g, channel 6)
- VanLink2 now on wlan1, 2.4GHz channel 6
- VanLink2-2G still on wlan2, 2.4GHz channel 6
- Both working stably
R5C not recommended for 5GHz AP use; consider Pi 5 or other board
if 5GHz dual-band AP is required.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Problem: wlan1 regulatory domain not set on boot, defaults to 2.4GHz-only mode,
preventing channel 149 (5GHz) from being available. hostapd fails on startup.
Solution:
1. Modified regdomain.service to:
- Run BEFORE hostapd/hostapd-2g services (Before= directive)
- Run earlier in boot (After= sysinit.target)
- RemainAfterExit=yes to persist setting
2. Added 80-regdomain.rules udev rule:
- Triggers on regulatory device changes
- Executes 'iw reg set CA' automatically
3. Added hostapd drop-in config:
- Explicitly requires regdomain.service
- Adds Wants= to ensure it starts
This ensures the regulatory domain is set BEFORE hostapd attempts to use
channel 149, fixing the boot-time AP failure loop.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Problem: RTL8822CE driver caused kernel panic (watchdog hard LOCKUP) when
hostapd tried to use VHT 802.11ac with 80MHz channel width on channel 149.
Root cause: Driver/firmware instability with VHT capabilities on this chip.
Solution: Disable VHT, use HT40+ (802.11n) only.
- Removes ieee80211ac (VHT), ieee80211ax (802.11ax), and 80MHz channel width
- Keeps HT40+ with Short GI for reasonable performance
- Stable operation on channel 149 (5745 MHz)
This allows the 5GHz AP to start and beacon without lockup on R5C hardware.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Problem: R5C spontaneously rebooted due to hardware watchdog timeout
Cause 1: van-gps-owntracks in infinite restart loop (MQTT connect failed)
Cause 2: mosquitto only listening on localhost, so clients couldn't connect
Solution:
- Add restart limits to van-gps-owntracks and van-li3-battery services
(max 3 restarts per 5 minutes prevents infinite restart loops)
- Configure mosquitto to listen on all interfaces (0.0.0.0:1883)
- Deploy mosquitto listener config via deploy.sh
- Restart mosquitto during deploy to apply config changes
This prevents the system from hitting the 11-second hardware watchdog timeout
when services crash and systemd auto-restarts them indefinitely.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
The system dnsmasq.service from the Debian dnsmasq package conflicts with
van-ap-dnsmasq.service on port 53 (DNS/DHCP). Explicitly disable the system
service during deploy so only van-ap-dnsmasq (bound to br0 for AP DHCP) runs.
Fixes DHCP failures where clients connect to the AP but don't get IP addresses
because port 53 is already in use.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Check for required packages (hostapd, iw, nftables, dnsmasq, systemd-resolved)
at deploy start and fail if any are missing. Also warn about optional packages
used by specific components (rsync, mosquitto, gpsd, python3-paho-mqtt, etc.).
Missing required packages halt deployment with clear error message. Optional
packages generate warnings that are captured in deploy-warnings.json for the
router-status MQTT dashboard.
This prevents silent failures when the R5C or other hardware doesn't have
expected dependencies installed.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Clarify that WIFI_5G_IFACE=wlan1 uses the built-in RTL8822CE chip on
FriendlyElec R5C with rtl88x2ce driver, not the RTL8852BU from the Pi 5.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Add GATEWAY_IP, GATEWAY_PREFIX, GATEWAY_NETWORK, DHCP_RANGE_START, and
DHCP_RANGE_END variables to deploy.conf. Update ap/21-van-br0.network,
ap/van-ap-dnsmasq.conf, and ap/nftables.conf to use @TOKEN@ placeholders
for IP configuration instead of hardcoding 10.42.x addresses.
This allows deploying the same configuration to multiple routers on
different networks (e.g., Pi 5 on 10.42.0.x and R5C on 10.42.1.x) by
simply editing deploy.conf before running ./deploy.sh.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
andreas
