Horizon Casas — diagnóstico de internet lento

Contexto

Grupo de clientes “Horizon Casas” en la región de Chihuahua reportando velocidad muy baja. Atendidos por un enlace inalámbrico Ubiquiti airMAX desde una sectorial Rocket Prism 5AC; 3 casas como suscriptores (PowerBeam 5AC). Aguas arriba se conectan vía EdgeRouter X al gateway principal de la red de Chihuahua.

Topología

Red de tipo WISP. Entre 192.168.37.10 (gateway Chihuahua) y 192.168.37.89 (ERX Horizon) hay varios saltos PtP — el detalle exacto lo da Sergio en otra sesión. Todos esos equipos comparten el /24 de management, pero el dataplane sí pasa por varios enlaces inalámbricos antes de llegar al ERX Horizon.

192.168.37.10  Gateway Chihuahua
        │
        │  >>> múltiples PtP intermedios (WISP backhaul) — detalle TBD <<<
        │
192.168.37.89  EdgeRouter X "erx-horizon"
        │ (eth al backhaul; otra eth a la sectorial)
        │
10.37.1.2/28   Rocket Prism 5AC "Sectorial-Horizon" (AP airMAX)
        │
        ├─ 10.37.1.4  PowerBeam 5AC — "ST-Horizon-Casa-2-Heinrich"
        ├─ 10.37.1.5  PowerBeam 5AC — "ST-Horizon-Casa-3-Franz-Knelssen"
        └─ 10.37.1.6  PowerBeam 5AC — "ST-Horizon-Casa-4-Lisa-Wiebe"

Implicación para el diagnóstico: la velocidad baja en Horizon Casas puede tener su causa raíz en cualquier punto del backhaul WISP, no necesariamente en la sectorial de Horizon. El recon del ERX + sector + estaciones nos va a decir si el cuello está aguas abajo o si llega ya saturado/degradado desde arriba. Si los stats del ERX muestran link WAN saturado o errores altos, hay que extender el diagnóstico a los PtP intermedios.

Tareas pendientes

• (2026-05-11) Provisionar id_rsa_es.pub en los 5 equipos. Sergio corrió scripts/provision_my_key.sh.
• (2026-05-11) Recon read-only en los 5 equipos → artifacts/2026-05-12-0341/.
• 📅 sin-fecha — Confirmar con Sergio: ¿cuál es la velocidad contratada por las 3 casas en agregado? Para decidir si el shaper de 70 Mbps en eth4 (CASAS) está bien o hay que subirlo.
• 📅 sin-fecha — Decidir cambio countrycode 511 → 484 en los 4 equipos airOS para destrabar TX power.
• 📅 sin-fecha — (Opcional) Evaluar pasar chanbw 40 → 80 MHz si hay espectro libre (correr AirView).
• 📅 sin-fecha — iperf3 gateway↔ERX y ERX↔cada estación para medir antes/después del cambio.
• 📅 sin-fecha — Documentar resultado final + verificar quejas resueltas con clientes.

Cierre

Diagnóstico cerrado el 2026-05-12. La queja “internet muy lento” tiene una causa administrativa, no técnica: el shaper de 70 Mbps DL en el ERX (eth4 out) es deliberado para proteger al cliente Horizon principal (200 Mbps) que comparte el mismo ERX. Las 3 casas no tienen velocidad contratada formal — el shaper sirve de protección.

El hipotético “problema 2” del TX power de 5 dBm en las PowerBeam resultó ser regla regulatoria (gain compensation en U-NII-2C), no misconfig. Se aplicó CC=484 en los 4 equipos por uniformidad y se obtuvieron mejoras menores (airTime del sector 9.8% → 1.8%, DL capacity por equipo +5-18%). El txPower siguió igual en los 4 equipos, como se esperaba después del análisis regulatorio.

Estado final por equipo

Si vuelven a quejarse

1. Primer chequeo: pregunta cómo están midiendo. Si usan speedtest.net o fast.com y reportan 10-15 Mbps no es problema real — esos tests usan pocos streams TCP y airMAX single-flow capa a ~30 Mbps por el polling/window-vs-RTT. Pídeles que prueben con descargas reales o que vean el speedtest de varios sitios paralelos.
2. Si el uso real (muchas conexiones simultáneas) también va lento: verificar si están alcanzando el cap del shaper (show queueing en ERX, contadores dropped y overlimit en eth4).
3. Si los clientes empiezan a pagar velocidad contratada formal, subir el shaper proporcionalmente.
4. Si el aire empieza a ser el cuello (UL capacity agregada cerca de 147 Mbps), considerar mover canal a U-NII-3 (5725-5850 MHz) para destrabar TX. Ver memoria reference_airos_tx_power_cap.md.

Throughput medido (2026-05-12)

Con shaper deshabilitado temporalmente y firewall abierto para iperf3:

• iperf3 single-stream (TCP -P 1) PB → ERX: 10-15 Mbps
• iperf3 multi-stream (TCP -P 10) PB → ERX: 80-100 Mbps

La diferencia 10× confirma que el cuello en single-flow es CPU+TCP-window del enlace airMAX, no la capacidad real. En uso normal (cliente con múltiples conexiones simultáneas: navegador con varias pestañas, streaming, apps), el throughput agregado es saludable (80-100 Mbps por PB).

Causa raíz (preliminar)

Dos problemas independientes degradan la experiencia. El primero es el cuello administrativo, el segundo es físico-RF.

Problema 1 — Shaper de 70 Mbps en el ERX (out eth4 CASAS)

El ERX erx-horizon tiene traffic-policy shaper CASAS bandwidth 70mbit aplicado out en eth4 (la interfaz hacia la sectorial). Eso limita el download agregado de las 3 casas a 70 Mbps. Si una sola casa baja un archivo grande satura el shaper y las otras dos ven latencia/jitter.

Evidencia (erx-queueing.txt):

eth4    shaper   TX=268 GB   dropped=1,346,091   overlimit=27,084,383

El shaper está activamente descartando. No es “pasivo”.

Pregunta para Sergio: ¿70 Mbps agregado es lo contratado por las 3 casas? Si cada casa paga, por ejemplo, 50 Mbps individuales = 150 Mbps agregado, este shaper está mal puesto. Si es 25 Mbps c/u = 75 Mbps agregado, está justo en el borde.

Problema 2 — TX power efectivo de 5 dBm en las 3 PowerBeam (REFRAME: causa regulatoria, no de config)

Hipótesis inicial (descartada el 2026-05-12 04:00 UTC): countrycode=511 (“Compliance Test/World”) era el culpable y cambiarlo a 484 (México) destrabaría el TX.

Resultado de la prueba en PB Casa 4 Lisa: el countrycode SÍ cambió a 484, pero txPower siguió en 5 dBm. Mejoraron wlanDownlinkCapacity (+18%) y airTime (6.0 → 0.4%), pero el TX no se movió.

Causa real: la PowerBeam 5AC tiene antena integrada de 25 dBi, opera en 5585 MHz que cae en U-NII-2C (5470-5725 MHz), banda que requiere DFS y aplica la regla antenna gain compensation: por cada dBi de antena arriba de 6 dBi se quita 1 dB del conducted permitido. Cálculo:

24 dBm conducted (cfg) − (25 dBi − 6 dBi) = 24 − 19 = 5 dBm conducted máximo

Coincide exactamente con lo medido. Esa regla aplica igual en FCC y IFETEL (México), por eso CC=484 no la levantó. El Rocket Prism (sectorial) llega a 13 dBm porque tiene antena de 19 dBi (cap = 24 − 13 = 11 dBm; reporta 13 por margen del driver). reg_obey=enabled está respetando la ley correctamente.

Impacto en el aire (visto desde el AP):

• DL linkscore: 96-100 % (OK, el AP transmite a 13 dBm y las PB lo reciben fuerte)
• UL linkscore: 42-49 % (las PB transmiten a 5 dBm y el AP las recibe muy débiles)
• ul_signal_expect=-56 dBm, real -73 a -75 dBm → ~17-19 dB peor de lo esperado
• rxModRate=4x (MCS4) en UL vs MCS7+ esperado
• wlanUplinkCapacity agregada del AP ~147 Mbps vs ~312 Mbps que se esperaría con TX correcto

Opciones para resolver:

1. Aceptar como está. El sistema funciona; UL agregado ~147 Mbps es más de lo que el shaper deja pasar (70 Mbps), así que el “lento” que sienten los clientes NO es por el TX de las PB.
2. Mover canal a U-NII-3 (5725-5850 MHz). No requiere DFS y permite hasta 53 dBm EIRP en PtMP fixed: con 25 dBi recuperaríamos hasta ~28 dBm conducted. Antes hay que verificar congestión con AirView — U-NII-3 es muy poblado en WISP.
3. reg_obey=disabled en los 4 equipos. Levanta el cap pero es zona gris legal — no recomendado.
4. Replicar CC=484 en los otros 3 equipos. Por uniformidad y por la pequeña ganancia de DL capacity observada en Lisa (+18%). No resuelve el problema raíz pero es mejora marginal sin riesgo.

Hallazgos secundarios (no críticos)

1. chanbw=40 MHz, podría escalarse a 80 MHz si el espectro lo permite. Doblaría capacidad teórica DL.
2. atpc.status=disabled en el AP. Si se enciende después de resolver el problema 2, el AP ajustaría dinámicamente la TX power de cada PB. Útil pero secundario.
3. wlanRxErrNwid=27317 en el AP — el AP descarta ~27k tramas de SSIDs ajenos en su canal. Indica APs vecinos co-canal (esperable en WISP, no urgente).
4. gmedina@venus tiene llave SSH autorizada en el ERX — nota, no acción.
5. CPU del ERX OK (load 1.3, hwnat offload activo). No hay cuello en el ERX más allá del shaper.

Topología confirmada (del ERX)

eth0 (192.168.37.89/24)  ←→  backhaul WISP a Cd. Chihuahua (gateway 192.168.37.10)
eth1 (10.37.2.1/29)      ←→  red "Horizon" (otra red de clientes, shaper 200 Mbit)
eth4 (10.37.1.1/28)      ←→  Rocket Prism 5AC → 3 PowerBeam (shaper CASAS 70 Mbit)  ← problema
eth2, eth3               unused

El bloque /28 (10.37.1.0/28) y el /29 de Horizon (10.37.2.0/29) son DHCP servidos por el propio ERX.

Hallazgos iniciales (read-only)

El +14 ms entre .10 y .89 es consistente con WISP de varios saltos PtP (confirmado por Sergio 2026-05-11). No es por sí mismo evidencia de problema, pero sí significa que cualquier degradación aguas arriba se acumula al usuario final.

Hipótesis a validar tras tener acceso shell:

1. Saturación de la sectorial (>80% airtime, capacidad baja, MCS bajo).
2. Interferencia / canal congestionado (CCQ < 90%, retries altos).
3. Un PB con mal apuntamiento o cadena rota (asimetría chain0/chain1 > 6 dB).
4. ACK timeout mal calculado por distancia.
5. QoS/shaper mal configurado en el ERX (límite agresivo o cola saturada).
6. Enlace ascendente del ERX saturado (todo Horizon Casas comparte el enlace).
7. Degradación en algún PtP intermedio del backhaul WISP — sale del scope de este proyecto si se confirma; abrir proyecto/incidente separado del PtP afectado.
8. Firmware buggy de airMAX (raro pero ha pasado).

Notas técnicas

Acceso

• VPN: ssh wireguard (10.255.255.1/24).
• SSH a equipos: -J wireguard, llave ~/.ssh/id_rsa_es, usuario ubnt.
• airOS XM dropbear v2018 requiere flags legacy: -o KexAlgorithms=+diffie-hellman-group1-sha1,diffie-hellman-group14-sha1 -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa
• La llave id_rsa_es.pub no está autorizada en estos equipos al 2026-05-11. Solo el usuario oxidized (servicio de respaldo) tiene acceso. Provisionar antes de cualquier diagnóstico.

Inventario en el backup-system

Estos 5 equipos ya están bajo Oxidized; backup OK al 2026-04-29:

• ~/agy/electrosystems/backup-system/auto-docs/sites/chihuahua/erx-horizon.md
• ~/agy/electrosystems/backup-system/auto-docs/sites/chihuahua/Sectorial-Horizon.md
• ~/agy/electrosystems/backup-system/auto-docs/sites/chihuahua/ST-Horizon-Casa-2-Heinrich.md
• ~/agy/electrosystems/backup-system/auto-docs/sites/chihuahua/ST-Horizon-Casa-3-Franz-Knelssen.md
• ~/agy/electrosystems/backup-system/auto-docs/sites/chihuahua/ST-Horizon-Casa-4-Lisa-Wiebe.md

Plan de comandos (orden propuesto, todos read-only)

Sectorial Rocket Prism 5AC 10.37.1.2:

mca-status
wstalist
iwconfig ath0
cat /var/log/messages | tail -100
cat /tmp/system.cfg | egrep '^radio|^wireless|^netconf' | head -40

Cada PowerBeam (10.37.1.4, .5, .6):

mca-status
iwconfig ath0
cat /tmp/system.cfg | egrep '^radio|^wireless'

ERX 192.168.37.89:

show interfaces
show interfaces ethernet eth0
show interfaces ethernet eth1
show interfaces ethernet eth2
show system processes summary
show queueing
show traffic-analysis top
show nat statistics
cat /proc/loadavg

Bitácora

2026-05-12 ~05:15 UTC — Incidente: close-all rompió el firewall (bug en regex)

• Hice: versión inicial de fw_diag_open.sh close-all usaba grep -- "--comment" para identificar las reglas TEMP-iperf3-diag, pero matcheaba cualquier regla con --comment — incluyendo las auto-generadas por Vyatta (TRAFICO_INTERNO-1, TRAFICO_INTERNO-2, TRAFICO_INTERNO-10000 default-action, TRAFICO_LOCAL-1, TRAFICO_LOCAL-10000). El loop borró todas hasta no quedar ninguna con --comment.
• Impacto: la rule “RELATED,ESTABLISHED accept” desapareció de ambos chains. Resultado: tráfico SSH desde wireguard a las PB se rompió (las respuestas a 10.255.255.1 matcheaban DROP IPS_LOCALES). DHCP de clientes hacia 10.37.1.1 también roto. Navegación a internet seguía OK (rule “default accept” residual). No catastrófico.
• Detección: verificación final post-cleanup mostró 2 reglas en TRAFICO_INTERNO (debían ser 3) y 1 sola en TRAFICO_LOCAL (debían ser 2). SSH a Franz timeout durante banner — confirmación.
• Fix inmediato: Sergio corrió iptables -I TRAFICO_INTERNO 1 -m state --state RELATED,ESTABLISHED -j RETURN ... + equivalente en TRAFICO_LOCAL. Reglas restauradas en ~2s, sin reboot.
• Fix en el script: reemplazado grep -- "--comment" por grep -F "$COMMENT" que filtra por el contenido exacto del comment (TEMP-iperf3-diag), no por la presencia del flag. Probado por inspección.
• Lección: cuando se borran reglas iptables por comment, filtrar por el valor del comment, no por la flag --comment. Las reglas Vyatta-generadas también tienen comments y un filtro amplio las elimina.

2026-05-12 ~05:00 UTC — Pruebas de throughput con iperf3

• Pidió Sergio: correr iperf3 PB → ERX para medir bandwidth real, y temporalmente deshabilitar el shaper de 70 Mbps + abrir firewall del ERX para ver la diferencia.
• Hice:
  • Diagnóstico de firewall: descubrimos que TRAFICO_INTERNO está aplicado en eth1+eth4 y modificarlo via Vyatta config tree falla con “Cannot delete rule set (still in use)”.
  • Workaround: script fw_diag_open.sh que usa iptables -I directo sobre los chains (no toca config tree, se revierte solo en cualquier commit o reboot).
  • Descubrimos también que TRAFICO_LOCAL aplica al tráfico destinado al propio ERX (10.37.1.1, 192.168.37.89), no TRAFICO_INTERNO. Hubo que abrir ambos chains.
  • Script shaper_toggle.sh para desasignar traffic-policy out CASAS de eth4 vía Vyatta con commit sin save.
• Hallazgos iperf3:
  • Single-stream: 10-15 Mbps (10× menos que la capacidad teórica del aire).
  • Multi-stream -P 10: 80-100 Mbps.
  • El cuello de single-flow es la combinación CPU PowerBeam (AR9342 560 MHz) + TCP window vs polling RTT del airMAX. NO es falla del aire ni del shaper.
• Implicación para la queja original: si los clientes miden con speedtest.net o fast.com (típicamente single/few streams), van a ver 10-15 Mbps y reportar “lento”. Es percepción del método de medición, no problema real.
• Cleanup: Sergio corre shaper_toggle.sh enable para restaurar el cap de 70 Mbps y fw_diag_open.sh close-all para limpiar las reglas temporales.
• Memoria actualizada: se agregó nota en reference_airos_tx_power_cap.md sobre el comportamiento de TCP single-stream en airMAX.

2026-05-12 04:20 UTC — Incidente al limpiar scan_list de la sectorial vía UI

• Pidió Sergio: entró a la UI de la sectorial (10.37.1.2) y vio dos warnings: “New frequency selected” en center frequency y “Frequency List is invalid” al navegar. Imaginó que era por el cambio de CC.
• Diagnóstico inicial: efectivamente, scan_list del sectorial heredó 237 freqs del perfil “World” (CC=511); con CC=484 quedaron 96 freqs fuera del rango legal MX. Creé scripts/fix_scan_list_mx.sh para reemplazar con 118 freqs MX-legal (5150-5350 + 5470-5850).
• Lo que pasó: Sergio corrió el script (que sí escribió la nueva scan_list y persistió con cfgmtd), pero la UI seguía mostrando el warning. Sergio aplicó “Change + Apply” desde la UI con la freq que la UI tenía cargada (5180). Eso disparó:
  1. Freq cambió de 5585 → 5180 MHz (canal 36, primer canal de la nueva scan_list).
  2. Output Power se reseteó a 0 dBm (1 mW).
  3. La UI regeneró authorized_keys borrando la llave id_rsa_es en la sectorial y en Heinrich. SSH bloqueado.
  4. DFS CAC en U-NII-1 (~90s) sin emisión de beacons → 3 PB desasociadas.
• Síntomas durante el incidente: 100% packet loss a las 3 PB durante el CAC; al volver, signal a -79/-81 dBm (vs -65/-67 baseline), capacity DL reducida a ~125 Mbps por estación.
• Recovery:
  1. Sergio cambió freq a 5580 desde la UI (5585 no estaba disponible — 5580 quedó como freq=5570/center=5580 en VHT40).
  2. DFS CAC otros ~90s; las 3 PB se reasociaron al final.
  3. Sergio subió Output Power de 0 → 13 dBm (máximo que la UI dejó después del CC change, consistente con el cap regulatorio).
  4. Sergio corrió provision_my_key.sh para reinstalar la llave SSH en los 4 equipos.
• Estado final (verificado por SSH a los 4): 3 PB asociadas, signal -68 a -70 dBm (≈ baseline), DL capacity por estación 218-234 Mbps (mejor que el baseline pre-CC, gracias a la mejora de airTime). Tres detalles a registrar:
  • La nueva freq operacional es 5570/5580 (antes 5585/5595) — diferencia de 15 MHz, sin impacto operativo.
  • Sectorial: scan_list quedó con 71 freqs MX-legal (la UI redujo de las 118 que metió el script).
  • Heinrich, Franz y Lisa: scan_list NO fue tocada. Heinrich quedó con scan_list=disabled (cómo o cuándo no quedó claro — la STA no necesita scan_list para operar). Franz y Lisa siguen con scan_list=enabled, 237 freqs heredadas, 96 fuera de rango MX → si Sergio entra a su UI verá el mismo warning.
• Falta: opcional, aplicar fix_scan_list_mx.sh preventivamente a Franz (10.37.1.5) y Lisa (10.37.1.6) si Sergio anticipa entrar a su UI.
• Lecciones guardadas: memoria reference_airos_tx_power_cap.md extendida con dos secciones nuevas: “Gotcha al cambiar countrycode” (scan_list inválida) y “Riesgos de Apply desde UI” (reset de Output Power, borrado de authorized_keys, DFS CAC con freq cambiada).

2026-05-12 04:10 UTC — CC=484 replicado en los 3 equipos restantes, proyecto cerrado

• Sergio: corrió apply_cc_fix.sh en 10.37.1.4, 10.37.1.5 y 10.37.1.2 (orden: las 2 PB primero, sectorial al final).
• Resultados confirmados: txPower NO cambió en ninguno (regulatorio, como se esperaba). Ganancias menores en airTime (sectorial 9.8% → 1.8%) y DL capacity. Los 4 equipos airOS unificados en CC=484.
• Estado final: ver tabla en sección Cierre. Proyecto marcado done.
• Artifacts: artifacts/cc-fix-2026-05-12-0358/ (Heinrich + Franz), artifacts/cc-fix-2026-05-12-0359/ (sectorial).
• Memoria creada: reference_airos_tx_power_cap.md para no volver a perseguir la hipótesis del countrycode cuando reaparezca el síntoma “txPower muy bajo”.

2026-05-12 04:00 UTC — Prueba CC=484 en Casa 4 Lisa: causa real es regulatoria

• Sergio: autorizó cambio en una PB de prueba (Casa 4 Lisa, 10.37.1.6). Corrió scripts/apply_cc_fix.sh 10.37.1.6.
• Resultado: countrycode cambió a 484 OK, pero txPower siguió en 5 dBm. wlanDownlinkCapacity subió +18%, airTime bajó de 6.0% a 0.4%, signal/UL prácticamente sin cambio.
• Causa identificada: regla “antenna gain compensation” en U-NII-2C (5470-5725 MHz). PowerBeam 5AC con antena de 25 dBi queda topada a 5 dBm conducted (24 − (25−6) = 5). Aplica igual MX y US. Ver detalle en sección “Causa raíz / Problema 2”.
• Reframe: el problema 2 NO se resuelve con countrycode. La queja real (“internet lento”) sigue siendo el shaper de 70 Mbps en el ERX, que es deliberado.
• Falta: decisión de Sergio sobre las 4 opciones (aceptar / mover a U-NII-3 / disable reg_obey / replicar CC en los otros 3 por uniformidad).
• Artifacts: artifacts/cc-fix-2026-05-12-0351/.

2026-05-12 — Recon completo y causa raíz preliminar (dos problemas)

• Sergio: corrió scripts/provision_my_key.sh y la llave quedó en los 5 equipos.
• Verificación de key-auth: OK en los 5 (ERX, sectorial, 3 PB).
• Hice: corrí scripts/recon.sh → 32 archivos en artifacts/2026-05-12-0341/. Luego re-corrí los comandos del ERX con vbash -ic "..." porque la primera pasada salía con vbash: show: command not found.
• Encontré dos problemas independientes:
  1. ERX tiene traffic-policy shaper CASAS bandwidth 70mbit aplicado out en eth4 → cap a 70 Mbps DL agregado para las 3 casas. Drops y overlimits confirmados.
  2. Las 4 radios airOS tienen countrycode=511 (perfil “Compliance Test / World”), que capa la TX power efectiva a 5 dBm en las PB y 13 dBm en la sectorial, aunque tengan 24/28 dBm configurados.
• Falta: decidir con Sergio si el shaper de 70 Mbps es correcto y autorizar el cambio de countrycode → 484 (México).

2026-05-11 — Topología confirmada como WISP multi-hop

• Sergio confirma que entre 192.168.37.10 y 192.168.37.89 hay varios PtP (infraestructura WISP). Detalle exacto del backhaul pendiente.
• Reescribo sección Topología, agrego hipótesis #7 (degradación en PtP intermedio) y aclaro que sale del scope de este proyecto si se confirma allá.

2026-05-11 — Diagnóstico inicial bloqueado por auth

• Pidió Sergio: diagnosticar internet lento de clientes Horizon Casas (Chihuahua), describiendo topología (gateway .10 → ERX .89 → Rocket Prism 10.37.1.2 → 3 PowerBeam 10.37.1.4/5/6).
• Hice:
  • VPN OK por ssh wireguard; ping a los 6 equipos OK (ver tabla de latencias arriba).
  • Identifiqué los 5 equipos en el backup-system, todos con backup exitoso al 2026-04-29 → significa que están vivos administrativamente.
  • Detecté +14 ms anómalos entre el gateway y el ERX (en el mismo /24).
  • Intenté SSH como ubnt con id_rsa_es → Permission denied (publickey,password). La llave de Sergio no está en authorized_keys de estos 5 equipos.
  • Intenté usar la cuenta oxidized como proxy → bloqueado correctamente por el clasificador (esa credencial es de respaldo, no diagnóstico).
• Falta:
  • Sergio corre scripts/provision_my_key.sh con SSHPASS exportado para instalar id_rsa_es.pub en los 5 equipos.
  • Luego ejecuto el plan de comandos read-only de arriba y aterrizo causa raíz + plan.

Scripts

• scripts/provision_my_key.sh — instala ~/.ssh/id_rsa_es.pub en ubnt@ de los 5 equipos (4 airOS + 1 EdgeOS). Idempotente.
• scripts/recon.sh — corre el plan de diagnóstico read-only sobre los 5 equipos y volca todo a artifacts/<fecha>/.