Two things broke after telep-router was reflashed / reset (a fresh factory image): (1) the Mac’s Wi-Fi menu wouldn’t list the 5 GHz SSID telep1-5G, and (2) the Bambu Lab H2S printer went offline. Neither was what it first looked like. This note is the diagnosis runbook for both, plus the router SSH-access problem the reflash created.
For Agents
Router was reflashed → its SSH host key changed (clients will throw REMOTE HOST IDENTIFICATION HAS CHANGED) and previously-authorized pubkeys are gone — it now demands the root password. Re-add your key to /etc/dropbear/authorized_keys (or use LuCI / serial console).
Mac “not seeing 5 GHz” was NOT a disconnect. The interface was fully up the whole time. networksetup/system_profilerlie about association on modern macOS (Location-Services privacy redaction). The real cause the SSID was missing from the menu: telep1-5G is on a DFS channel and macOS often won’t list DFS SSIDs (phones do). Fix is router-side: move the 5 GHz radio to a non-DFS channel.
Bambu H2S offline was collateral damage from the reflash disrupting Wi-Fi. The H2S is dual-band (2.4 + 5 GHz) — observed 2026-08-26 associated to the 5 GHz SSID telep1 (phy0-ap0, ch36, −40 dBm, 150 Mbit); NOT “2.4-only”. The outage was independent of the 5 GHz/DFS issue regardless of band. A router Wi-Fi restart brought it back; SSDP replies from .202 and all LAN-mode ports reopened.
Standby gotcha (reusable): a Bambu printer in STANDBY/SLEEP keeps its network up (answers ping/ARP, stays associated) but shuts down its app services — MQTT 8883, FTPS 990, camera 6000 all closed, and it stops announcing via SSDP. So “pings but all Bambu ports closed + no SSDP” = printer asleep, not a network fault. Wake it via the touchscreen / start a job → services and SSDP resume.
Router access after a reflash (do this first)
The reflash wiped the router’s SSH identity and authorized keys.
Host-key changed — your Mac will refuse to connect with REMOTE HOST IDENTIFICATION HAS CHANGED. Clear the stale entry, then reconnect and accept the new key:
ssh-keygen -R 192.168.1.1/usr/bin/ssh root@192.168.1.1 # bare `ssh` is shadowed on the Mac — use the absolute path
Key auth fails — the server offers publickey,password but your key isn’t installed yet, so it falls back to demanding the root password. Log in with the password once, then re-authorize your key:
# on the router, after password login:mkdir -p /etc/dropbearcat >> /etc/dropbear/authorized_keys # paste your pubkey, Ctrl-Dchmod 600 /etc/dropbear/authorized_keys
Or do it via LuCI → System → Administration → SSH-Keys, or from the serial console.
Reach the router over the LAN, not the tailnet
From the telep-mainframe use ssh root@192.168.1.1 — the mainframe cannot reach the router’s tailnet IP (100.69.112.32 pings time out; the asymmetry bites scripts). A reflash also re-registers Tailscale (new tailnet IP), so don’t rely on a cached one.
Correction (later on 2026-08-26): the DFS theory below was WRONG
On re-inspection the 5 GHz SSID is telep1 (a single roaming name, not telep1-5G) sitting on channel 36 — a NON-DFS channel. So DFS cannot explain a Mac not listing it; ch36 (UNII-1) has no radar/CAC wait. Treat Problem 1’s root-cause section as superseded. The real cross-band story turned out to be driver-level Wi-Fi client isolation → see Problem 3 — Wi-Fi cross-band client isolation (driver-level). Keep the CLI-tools-lie and don’t-toggle-Wi-Fi-power lessons — those still hold.
Problem 1 — macOS Wi-Fi menu won’t list telep1-5G
Symptoms
The 5 GHz SSID telep1-5G is absent from the Mac’s Wi-Fi menu, while phones see it instantly.
CLI tools claim the Mac is offline: networksetup -getairportnetwork en0 → “You are not associated with an AirPort network”; system_profiler SPAirPortDataType shows SSID names redacted.
The CLI tools are lying — the interface was fine
networksetup/system_profiler reporting “not associated” / redacting SSIDs is the macOS Location-Services privacy restriction on CLI tools, NOT a real disconnect. The Mac was connected, had a valid IP, and internet + DNS worked throughout.
Do NOT trust networksetup -getairportnetwork / system_profiler SPAirPortDataType for association state
On modern macOS these are gated by Location Services and will falsely report “not associated” and redact SSIDs even while Wi-Fi is fully up. Verify association with the low-level tools instead:
ifconfig en0 | grep -E 'status|inet ' # status: active + an inet = associated with an IPipconfig getifaddr en0 # prints the current IPv4 (empty = truly no IP)route -n get default # a valid gateway = routedping -c2 1.1.1.1 && ping -c2 google.com # internet + DNS
Don't toggle Wi-Fi power to "fix" it
networksetup -setairportpower en0 off; ... on left the interface unable to re-associate (error -3900) for a while — mildly disruptive and unnecessary. Avoid unless actually needed.
Root cause — telep1-5G is on a DFS channel
The reason the SSID is missing from the Mac’s menu (while phones show it) is that telep1-5G sits on a DFS channel (52–144). macOS passive-scans DFS channels and frequently won’t list such SSIDs until it hears a beacon under radar-avoidance rules; phones surface them immediately. In short: “it’s the Mac.”
Fix — move the 5 GHz radio to a non-DFS channel (router-side)
Non-DFS 5 GHz channels: 36 / 40 / 44 / 48 (UNII-1) or 149 / 153 / 157 / 161 (UNII-3). These bring the SSID up instantly — no radar/CAC wait.
iwinfo # identify the 5 GHz device (radioX)uci set wireless.radioX.channel='149' # any non-DFS channeluci commit wirelesswifi reload
May still be open
This item is only resolved once telep1-5G’s channel is confirmed non-DFS. If the Mac still can’t see it, check iwinfo <5ghz-iface> info for the current channel — anything in 52–144 is DFS.
Saved-network naming note
The Mac’s saved networks list telep1-2G and telep1 but no telep1-5G — a naming split. Historically (§handover 3d) the 5 GHz SSID was telep1; post-reflash the 5 GHz SSID is telep1-5G. Re-save the correct 5 GHz SSID on the Mac after the channel fix.
Problem 2 — Bambu Lab H2S offline
Printer identity (from SSDP)
Field
Value
Model (marketing)
Bambu Lab H2S
DevModel.bambu.com (SSDP)
O1S (internal code)
DevName
3DP-093-31
Serial
0938BJ641800310
MAC
50:31:23:c9:63:ba
LAN IP (reserved)
192.168.1.202 — DHCP static host name='bambu', resolves as bambu.lan
Band
Dual-band (2.4 + 5 GHz) — observed 2026-08-26 on 5 GHz telep1 (phy0-ap0, ch36, −40 dBm, 150 Mbit). Can also land on 2.4 GHz telep1-2G.
The printer outage is unrelated to the DFS/5 GHz issue
The H2S is dual-band — it was observed associated to the 5 GHz SSID telep1, so the earlier “Bambu is 2.4 GHz-only” claim was wrong. Whatever band it’s on, Problem 1 (Mac can’t see the 5 GHz SSID) and Problem 2 (printer offline) share a common trigger (the reflash disrupted Wi-Fi) but are otherwise independent.
Diagnosis (reusable)
Bambu Studio’s own log is a symptom, not the cause.~/Library/Application Support/BambuStudio/log/log_iotc.txt showed only:
[IOTC_Check_Session_Status] Error: Not Initialized! ErrCode -12
That’s Studio failing to reach an absent printer — it does not tell you why it’s absent.
Confirm reachability at the network layer — SSDP M-SEARCH probe (no reply = printer not on the network), ping, and a port check:
# SSDP discovery probe (Bambu listens on 239.255.255.250 ports 1990 and 2021)printf 'M-SEARCH * HTTP/1.1\r\nHOST: 239.255.255.250:1990\r\nMAN: "ssdp:discover"\r\nMX: 2\r\nST: urn:bambulab-com:device:3dprinter:1\r\n\r\n' \ | nc -u -w2 239.255.255.250 1990 # repeat with :2021ping -c3 192.168.1.202 # no reply = offlinenc -z 192.168.1.202 8883 990 6000 # Bambu LAN-mode service ports
During the outage: no SSDP reply, no ping at .202, and no Bambu service ports open anywhere on the subnet → printer confirmed off the network.
Distinguish "off the network" from "asleep"
A printer in STANDBY/SLEEP stays associated and answers ping/ARP at .202, but shuts down its app services — 8883 / 990 / 6000 all closed and it stops announcing via SSDP. So the two signatures differ: no ping + ports closed + no SSDP = off the network (Wi-Fi/router event → router Wi-Fi restart); pings fine but ports closed + no SSDP = asleep (wake it via the touchscreen or start a job → services and SSDP resume).
Root cause + recovery
The router reflash disrupted Wi-Fi; the printer lost its association. A Wi-Fi restart on the router brought it straight back:
SSDP now replies from .202.
All Bambu Studio LAN-mode ports open: 8883 (MQTT/TLS control), 990 (FTPS file transfer), 6000 (camera), 322.
Bambu Studio LAN mode connects again.
Follow-ups
✅ DONE 2026-08-26 — reserved 192.168.1.202 for the printer in DHCP on telep-router. Added a static host name='bambu', mac='50:31:23:c9:63:ba', ip='192.168.1.202', dns='1'; committed dhcp + reloaded dnsmasq. It now resolves as bambu.lan (local domain is lan) from the router and the Mac. Pre-checked per the duplicate-reservation lesson. ⚠️ The hostname is convenience only — it maps to .202 but does NOT change any route, so it does not fix the cross-band reachability of Problem 3 — Wi-Fi cross-band client isolation (driver-level). Bambu Studio’s manual-add wants an IP anyway.
Wire the H2S over Ethernet if it has a port — removes it from Wi-Fi entirely, immunizes it against router/Wi-Fi restarts, AND is the proper fix for the cross-band isolation in Problem 3.
Problem 3 — Wi-Fi cross-band client isolation (driver-level)
Even with both devices online, Bambu Studio on the Mac cannot reach the H2S printer when the two sit on different bands: e.g. Mac on telep1 (5 GHz, phy0-ap0), printer on telep1-2G (2.4 GHz, phy1-ap0). This is a separate issue from the post-reflash outage in Problem 2 — the printer is up, just unreachable across bands.
This blocker only applies when the two are on DIFFERENT bands
The H2S is dual-band and was observed on the 5 GHz telep1 — the same band/BSS as the Mac. When both sit on telep1 (5 GHz) it just works (intra-band forwarding). The cross-band isolation only bites when the printer happens to land on 2.4 GHz (telep1-2G) while the Mac is on 5 GHz. Ethernet is still the most robust option, but “the printer must be on 2.4” is not true.
Symptoms
Mac on 5 GHz cannot ping the printer at 192.168.1.202; TCP 8883 / 990 / 6000 all blocked; SSDP M-SEARCH gets no reply.
Put the Mac on the same band (telep1-2G, 2.4 GHz) → everything works instantly. Classic band-dependent reachability.
Diagnostic chain (isolates it to the Wi-Fi driver)
All done via ssh root@100.69.112.32 (Tailscale SSH — the one access path that still worked when key/password auth was locked out right after the reflash).
Hub-and-spoke signature — the router reaches both the Mac and the printer, but the two clients can’t reach each other. Everyone reaches the gateway; nobody reaches a peer → textbook client isolation.
Every software knob is clean / non-isolating:
hostapd ap_isolate is set only on the telep-cc guest BSS (phy1-ap1), NOT on telep1 (phy0-ap0) or telep1-2G (phy1-ap0).
uci: wireless.*.isolate='0' on both client APs.
Bridge port flags on both APs are normal and identical to the wired ethernet port: learning=1 unicast_flood=1 broadcast_flood=1 isolated=0.
br-lanvlan_filtering=0; br_netfilter not loaded; both APs bridged to br-lan.
A full wifi down; wifi up did NOT fix it → not a config/runtime mismatch (rules out the stale-hostapd-conf class of bug from [[telep-router#airplay-mdns-fix—patched-out-netifds-ap_isolate-auto-injection|AirPlay mDNS fix — patched out netifd’s ap_isolate auto-injection]]).
DECISIVE TEST — Wi-Fi→ethernet works, Wi-Fi→Wi-Fi fails. From the Mac on 5 GHz:
Wi-Fi → ethernet clients: works — reaches telep-mainframe.123 and the raspi .200 (both wired).
Wi-Fi → Wi-Fi cross-band: fails — cannot reach the printer .202 on 2.4 GHz.
The reusable gem — "wifi→ethernet works but wifi→wifi fails = driver-level cross-band isolation"
If a wireless client can reach wired hosts through the bridge but cannot reach a wireless host on another radio/VAP — while every config layer (hostapd ap_isolate, uci isolate, bridge isolated flag, vlan_filtering) reads non-isolating and a wifi down/up changes nothing — the isolation lives in the radio driver/firmware (inter-radio / inter-VAP client isolation that hostapd ap_isolate=0 does not disable). It’s below every config knob. Likely a radio-driver limitation on this Asus RT-AX89X / OpenWrt 24.10 build. Don’t keep hunting the config; go to a physical/topology fix.
Fixes
Proper / permanent — wire the printer via Ethernet. It lands on the bridge’s wired side, and wifi→ethernet forwarding works, so it becomes reachable from any band. Recommended.
Instant workaround — same band. Put the client on the same band as the printer (Mac on telep1-2G, 2.4 GHz). Intra-band forwarding works.
Tailscale does NOT help for an on-LAN client
The Mac is directly on192.168.1.0/24, so its connected en0 route to .202 always wins over any tailnet subnet-route — traffic never enters Tailscale, so a subnet router can’t rescue a same-LAN client. (The printer also can’t run Tailscale — closed firmware — and Bambu’s SSDP discovery + 3-port model resists proxying.) Tailscale / a subnet router is the right tool only for reaching the printer from outside the LAN, not for two clients on the same subnet.
Related
telep-router — the OpenWrt router that was reflashed; WiFi radio/channel config lives here
WiFi — radio/SSID/channel table (set the 5 GHz radio to a non-DFS channel)