La prueba más concluyente de este hilo es el cambio de router. El mismo servidor ZimaOS y el mismo cliente móvil que no podían descubrirse a través de la red en malla TP-Link Deco funcionaron de inmediato cuando se probó el servidor detrás del router ZTE proporcionado por el ISP. Esto indica que el problema del caso original era de descubrimiento local/multidifusión, no una evidencia de que el servidor ZimaOS estuviera desconectado.
Después, el hilo probó cambios comunitarios en Avahi, incluida la activación del reflector mDNS, pero el autor original confirmó que esos cambios no resolvieron el caso con Deco. Las versiones actuales de ZimaOS ofrecen mejores alternativas: la documentación actual de introducción indica que los usuarios pueden abrir el dispositivo directamente mediante su dirección IP en un navegador cuando falla el descubrimiento local, y Remote ID/Network ID proporciona otra vía de identificación del dispositivo.
En realidad, no era un problema exclusivo de iOS
En la página 2, santhora destacó que Android tampoco podía descubrir el servidor. Eso descartó un problema limitado de permisos de iOS o específico del cliente de Apple.
La topología era sencilla: unidad principal Deco → 2,5 GbE → servidor Beelink ZimaOS, mientras los teléfonos se conectaban por Wi-Fi al sistema Deco.
La prueba con el router del ISP fue la mejor prueba de aislamiento
El aislamiento de clientes ya estaba desactivado
El caso original comprobó el control de clientes/aislamiento de Deco y confirmó que estaba desactivado. También se probaron los teléfonos y el dispositivo ZimaOS con la misma unidad Deco, sin recuperar el descubrimiento.
Esto es importante porque «desactivar el aislamiento de AP» es una buena primera comprobación, pero no fue la solución definitiva en este caso.
La modificación del reflector de Avahi no funcionó
Una respuesta de la comunidad sugirió editar /etc/avahi/avahi-daemon.conf y activar el reflector. El usuario lo probó e informó que no hubo cambios.
Como la solución alternativa falló, el hilo recomendó revertir el cambio. No dejes configuraciones antiguas de descubrimiento simplemente porque se hayan sugerido en un foro.
Las versiones actuales de ZimaOS admiten explícitamente el acceso mediante IP directa en el navegador
La documentación actual de introducción de IceWhale indica que, si ZimaClient no puede encontrar el dispositivo, hay que buscar la IP del servidor en la lista de clientes DHCP del router e introducir esa IP en un navegador. La pantalla de configuración/panel es la misma.
Utiliza la alternativa actual mediante IP directa antes de modificar Avahi.
Remote ID ofrece otra vía de identidad compatible
La documentación actual de ZimaOS muestra un Remote ID/NetworkID en Ajustes → Red. Trátalo como una credencial, ya que puede identificar el dispositivo y compartir el acceso a él.
Consulta el modelo actual de acceso mediante Remote ID.
Qué comprobar en Deco u otro sistema de red en malla
- aislamiento de clientes/AP;
- separación de la red de invitados;
- reenvío de multidifusión/mDNS entre segmentos cableados e inalámbricos;
- separación mediante VLAN;
- comportamiento de los nodos de la red en malla cuando los clientes cambian de nodo;
- actualizaciones de firmware y opciones de multidifusión específicas del fabricante.
El acceso normal a Internet y un ping correcto no demuestran que se esté reenviando el descubrimiento de servicios mediante multidifusión.
Preguntas frecuentes sobre el descubrimiento de ZimaClient
¿Desactivar IPv6 resolvió el caso original?
No. El usuario informó explícitamente que desactivar IPv6 no ayudó.
¿Activar el reflector de Avahi solucionó la red Deco?
No. El autor original lo probó e informó que no hubo cambios.
¿Cuál es la alternativa actual más segura cuando falla el descubrimiento local?
Usa la IP LAN del dispositivo en un navegador o la vía compatible de Remote ID/acceso remoto, en lugar de realizar modificaciones no verificadas en los servicios del equipo.
