Three items from the 2026-08-12 follow-up session: (1) the long-parked AirPlay-broken open item is RESOLVED — root-caused to OpenWrt auto-injecting ap_isolate=1 into the generated hostapd config, fixed by patching /lib/netifd/netifd-wireless.sh (the old uci isolate=0 recipe was wrong/insufficient); (2) the dead-Ethernet HP LaserJet M203dw was set up on USB-to-CUPS, then moved to WiFi; (3) the wifi-hunterwlan0 AP on raspi was brought down.
The parked “AirPlay broken” item (wired→WiFi mDNS discovery of telep-tv blocked) is fixed. This is a hard-won gotcha — read the full chain before touching Wi-Fi isolation on telep-router.
The old parked fix was WRONG — do not use uci isolate=0 alone
The telep-mainframe-handover parked recipe uci set wireless.telep1_5.isolate='0' (+ telep1_2) + wifi reload does NOT clear ap_isolate=1. Neither does wifi down; wifi up, nor /etc/init.d/network reload. The generated /var/run/hostapd-phy*.conf stays byte-identical with ap_isolate=1. That recipe is tried-and-insufficient; it was replaced by the netifd patch below.
Symptom
Wired→WiFi mDNS multicast (AirPlay discovery of telep-tv) blocked.
Running hostapd config had ap_isolate=1 on the telep1 client BSSes — both bands: 5 GHz telep1_5 (radio0) and 2.4 GHz telep1_2 (radio1).
“No uci backing” — uci show wireless reported isolate=0, and ubus call network.wireless status showed isolate:false, yet the generated conf still had ap_isolate=1.
Router: telep-router, OpenWrt 24.10.0. Reached via ssh root@telep-router FROM the mainframe (ssh levander@telep-mainframe first).
Root cause
OpenWrt’s /lib/netifd/netifd-wireless.sh function _wireless_set_brsnoop_isolation (~lines 303–309) auto-injects ap_isolate into the hostapd config for any bridged, non-isolated AP when multicast_to_unicast is on. Line 309 was:
multicast_to_unicast is promoted to the interface top-level as 1 (the effective default), so isolate=1 gets injected transiently at config-generation time → hostapd.sh writes ap_isolate=1. That is why uci/ubus reported isolate:false (the uci-level value) while the generated conf disagreed (the injected value).
For Agents — why the "clean" fixes fail
The wifi-iface multicast_to_unicast=0 uci option does NOT propagate to the top-level value that for_each_interface reads (line 327, before json_select config). Nothing in mac80211.sh promotes it.
Changing line 309’s default ${multicast_to_unicast:-1} → :-0also didn’t help — the value is explicitly promoted as 1, not merely unset, so a different default is never consulted.
The fix that worked
Commented out line 309 of /lib/netifd/netifd-wireless.sh (prefixed with a marker), then re-brought-up Wi-Fi:
# on telep-router, verify line 309 is the isolate-injection line first:grep -n 'json_add_boolean isolate 1' /lib/netifd/netifd-wireless.sh# backup + disable it:cp /lib/netifd/netifd-wireless.sh /lib/netifd/netifd-wireless.sh.baksed -i '309s/^/#DISABLED-airplay-fix#/' /lib/netifd/netifd-wireless.shwifi down; wifi up
Result:
telep1 (both bands) now has NOap_isolate line → not isolated → mDNS/AirPlay flows.
telepcc (cameras, SSID telep-cc, network cams) KEEPSap_isolate=1 — its explicit isolate=1 makes line 308 early-return before reaching the disabled line 309. Camera isolation is preserved.
Backup saved at /lib/netifd/netifd-wireless.sh.bak.
Also committed (harmless, intent-consistent, but NOT sufficient alone — kept for clarity):
uci set wireless.telep1_5.isolate=0, telep1_2.isolate=0, telep1_5.multicast_to_unicast=0, telep1_2.multicast_to_unicast=0, uci commit.
CRITICAL — reapply after any firmware upgrade
This patches a system file under /lib/netifd/, so an OpenWrt sysupgrade will revert it and AirPlay will break again. To reapply (verify the line first — line numbers shift across versions, so grep for the injection line):
Confirm afterward: telep1_* BSSes have no ap_isolate line, telepcc still has ap_isolate=1.
2. Printer (HP LaserJet M203dw) — Ethernet dead → USB → WiFi
Ethernet NIC confirmed hardware-dead
Surge from the power outage killed the printer’s on-board NIC. Serial VNC3920651, USB id 03f0:632a. Repointing CUPS at a network queue is moot until it’s back on a network.
Device URI usb://HP/LaserJet%20M203-M206?serial=VNC3920651.
Reused the existing model PPD /etc/cups/ppd/HP_LaserJet_M203dw_B8AE8C.ppd.
usblp must be unloaded + blacklisted for the CUPS libusb backend
The kernel usblp module claims the device and blocks the CUPS libusb backend. Fix: unload it and blacklist it via /etc/modprobe.d/blacklist-usblp.conf, then the queue works. Also installed hplip — but note hp-wificonfig is gone in this version and hp-probe needs root.
Moved to WiFi (user needed the USB cable back)
The M203dw has WiFi. Onboarded via the HP Smart iOS app:
Wi-Fi Direct default password 12345678.
Embedded Web Server (EWS) at 192.168.223.1, no admin password by default.
STILL PENDING — finish the WiFi migration
Once the printer’s WiFi IP is known:
Repoint CUPS to a network queue.
Add a DHCP reservation on telep-router for the printer.
Remove the interim USB queue HP_M203dw_USBand the two stale dead-NIC network queues HP_LaserJet_M203dw_B8AE8C and …@NPIB8AE8C.local.
3. wifi-hunter AP killed on raspi
On raspi (the Pi 5 shared with the wifi-hunter project and the KrakenSDR DoA rig), brought down the wlan0 NetworkManager “Hotspot” AP so the single WiFi radio is free — e.g. for the future car-deploy client link where wlan0 flips AP→client on the driver’s hotspot.
sudo nmcli connection down Hotspotsudo nmcli con mod Hotspot connection.autoconnect no
wlan0 is now free/disconnected.
This stops wifi-hunter's AP
The “Hotspot” connection is wifi-hunter’s AP (see Network Topology). Bringing it down + disabling autoconnect means wifi-hunter no longer serves its AP until re-enabled.
Related
telep-router — the netifd patch lives here; see its 2026-08-12 changes + open items