Solution communautaire

ZimaClient ne parvient pas à trouver ZimaOS sur le même réseau local : découverte locale, mDNS et cas non résolu

An October 2025 thread where ZimaClient could connect through Remote ID but automatic LAN discovery returned No Device Found. iOS Local Network permission was enabled, Avahi was running, reinstalling ZimaOS did not help, and Android later failed too. The public thread ended without a confirmed root cause.

Ce cas source distingue deux chemins de connexion que les utilisateurs confondent souvent. ZimaClient pouvait se connecter avec succès lorsque l’utilisateur saisissait l’identifiant distant, à domicile comme à l’extérieur, mais la découverte automatique sur le réseau local affichait Aucun appareil trouvé. Cela signifie que la relation avec le serveur et le chemin distant fonctionnaient, tandis que la découverte locale échouait.

La discussion n’a jamais abouti à une résolution finale confirmée. L’autorisation d’accès au réseau local d’iOS était déjà activée, Avahi fonctionnait, une réinstallation complète de ZimaOS n’a rien changé et l’utilisateur a ensuite installé le client Android, pour constater qu’Android ne parvenait pas non plus à détecter automatiquement le serveur.

L’identifiant distant fonctionnait, mais pas la découverte sur le réseau local

Zima Client sur un iPhone affichant Aucun appareil trouvé avec un bouton Se connecter via l’identifiant distant
Le client pouvait toujours utiliser l’identifiant distant, mais la découverte automatique sur le même réseau local ne trouvait aucun appareil.

Cette différence constitue une limite de diagnostic utile : ne cherchez pas du côté de l’authentification de l’identifiant distant lorsque le problème concerne uniquement la découverte locale.

L’autorisation d’accès au réseau local d’iOS était déjà activée

Une réponse de la communauté a recommandé à juste titre de vérifier les réglages iOS, car Apple exige une autorisation explicite pour les apps qui détectent ou communiquent avec des appareils du réseau local.

Réglages du réseau local d’iOS affichant l’autorisation activée pour Zima Client
L’utilisateur source avait déjà accordé à Zima Client l’accès au réseau local ; le réglage de confidentialité iOS de base n’était donc pas l’explication finale.

La réinstallation de l’app et de ZimaOS n’a rien résolu

L’utilisateur a réinstallé plusieurs fois l’app iOS, redémarré et éteint le NAS, puis a finalement formaté et réinstallé ZimaOS. Aucune de ces étapes n’a rétabli la découverte automatique.

Ces résultats négatifs écartent l’hypothèse d’un simple cache d’application obsolète ou d’une installation de ZimaOS endommagée.

La communauté a soupçonné mDNS/Bonjour

La découverte automatique des appareils dans de nombreuses applications locales dépend du DNS multidiffusion ou de mécanismes de diffusion similaires sur le réseau local. Des membres de la communauté ont supposé que le client ne recevait pas ces annonces et ont suggéré de vérifier l’isolation des points d’accès ou des clients ainsi que la transmission du trafic multidiffusion.

L’utilisateur a objecté que AirPrint, AirPlay, la découverte QNAP et d’autres services iOS locaux fonctionnaient sur le même réseau TP-Link Deco.

Avahi fonctionnait sur ZimaOS

Terminal ZimaOS affichant avahi-daemon actif et enregistrant des interfaces mDNS pendant le dépannage de la découverte locale
Le service Avahi côté serveur était actif, ce qui écartait une autre explication simple, sans toutefois prouver que les annonces atteignaient correctement le réseau local physique.

Avahi sur les ponts virtuels n’était qu’une hypothèse de la communauté

Une réponse ultérieure a relevé l’activité d’Avahi sur des interfaces Docker ou virtuelles et a suggéré qu’il pouvait diffuser sur le mauvais pont plutôt que sur le réseau local principal. La personne ayant répondu a demandé davantage de sortie des journaux.

La discussion publique s’arrête avant la validation de cette hypothèse. Ne présentez pas « Avahi est lié à Docker » comme la cause première confirmée.

L’échec d’Android a modifié le diagnostic

L’utilisateur source a installé le client Android et indiqué qu’il ne pouvait pas non plus détecter automatiquement le serveur. Cela a affaibli les explications liées spécifiquement à la confidentialité renforcée d’iOS, aux réglages VPN ou à l’autorisation d’accès au réseau local d’Apple.

Les variables restantes étaient l’hôte ZimaOS, le chemin de découverte sur le réseau local ou une interaction entre les deux.

IceWhale a demandé des informations sur la topologie et la confidentialité

Zima-Giorgio a demandé des précisions sur les VLAN, les pare-feu, le filtrage des protocoles, les fonctions de confidentialité renforcée ou VPN d’iOS, le suivi des restrictions IP et les essais avec un autre appareil Apple. Il s’agissait d’une demande officielle de dépannage, et non d’une affirmation selon laquelle l’un de ces réglages était à l’origine du problème.

La version actuelle de ZimaClient a continué d’évoluer

La version actuelle de ZimaClient est bien plus récente que la version d’octobre 2025 et comprend des améliorations continues de la fiabilité de la connexion et du changement d’appareil. Pour un cas actuel, mettez à jour ZimaOS et ZimaClient avant de reproduire les anciens tests de réinstallation.

Utilisez la procédure actuelle d’installation et de connexion de ZimaClient comme point de départ.

FAQ sur la découverte LAN de ZimaClient

L’identifiant distant fonctionnait-il dans le cas source ?

Oui. L’utilisateur pouvait se connecter via l’identifiant distant sur le réseau domestique comme à l’extérieur.

L’accès au réseau local d’iOS était-il désactivé ?

Non. L’utilisateur a publié une capture d’écran montrant qu’il était activé.

Avahi était-il arrêté ?

Non. La capture d’écran source montrait que avahi-daemon fonctionnait.

La cause première finale a-t-elle été confirmée ?

Non. La discussion publique s’est terminée alors que des tests supplémentaires de la topologie et des interfaces Avahi étaient encore en cours.