Soluzione della community

ZimaClient non riesce a trovare ZimaOS sulla stessa LAN: rilevamento locale, mDNS e un caso irrisolto

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.

Questo caso separa due percorsi di connessione che gli utenti spesso considerano la stessa cosa. ZimaClient riusciva a connettersi quando l’utente inseriva il Remote ID, sia a casa sia fuori casa, ma la rilevazione automatica sulla rete locale mostrava Nessun dispositivo trovato. Ciò significa che il collegamento con il server e il percorso remoto funzionavano, mentre la rilevazione locale non riusciva.

La discussione non ha portato a una soluzione finale confermata. L’autorizzazione alla rete locale su iOS era già abilitata, Avahi era in esecuzione, una reinstallazione completa di ZimaOS non aveva modificato il comportamento e in seguito l’utente aveva installato il client Android, scoprendo che anche Android non riusciva a rilevare automaticamente il server.

Il Remote ID funzionava, mentre la rilevazione sulla LAN falliva

Zima Client su iPhone che mostra Nessun dispositivo trovato con un pulsante Connetti tramite Remote ID
Il client poteva comunque usare il Remote ID, ma la rilevazione automatica sulla stessa LAN non trovava alcun dispositivo.

Questa differenza costituisce un utile limite diagnostico: non è necessario risolvere i problemi di autenticazione del Remote ID quando il malfunzionamento riguarda solo la rilevazione locale.

L’autorizzazione alla rete locale su iOS era già abilitata

Una risposta della community suggeriva correttamente di controllare le impostazioni di iOS, poiché Apple richiede un’autorizzazione esplicita per le app che rilevano o comunicano con dispositivi sulla rete locale.

Impostazioni Rete locale di iOS che mostrano l’autorizzazione per Zima Client abilitata
L’utente del caso aveva già concesso a Zima Client l’accesso alla rete locale, quindi la semplice impostazione della privacy di iOS non costituiva la spiegazione finale.

La reinstallazione dell’app e di ZimaOS non ha risolto il problema

L’utente ha reinstallato più volte l’app iOS, riavviato e spento il NAS e infine formattato e reinstallato ZimaOS. Nessuno di questi passaggi ha ripristinato la rilevazione automatica.

Questi elementi escludono una semplice cache dell’app obsoleta o una singola installazione di ZimaOS danneggiata.

La community sospettava mDNS/Bonjour

La rilevazione automatica dei dispositivi in molte applicazioni locali dipende dal DNS multicast o da trasmissioni correlate per la rilevazione sulla LAN. I membri della community sospettavano che il client non ricevesse questi annunci e suggerivano di controllare l’isolamento degli access point/client e l’inoltro del multicast.

L’utente ha obiettato che AirPrint, AirPlay, la rilevazione QNAP e altri servizi locali di iOS funzionavano attraverso la stessa rete TP-Link Deco.

Avahi era in esecuzione su ZimaOS

Terminale di ZimaOS che mostra avahi-daemon attivo e la registrazione delle interfacce mDNS durante la risoluzione dei problemi di rilevazione locale
Il servizio Avahi lato server era attivo. Ciò eliminava un’altra spiegazione semplice, ma non dimostrava che gli annunci raggiungessero correttamente la LAN fisica.

Avahi sui bridge virtuali era solo un’ipotesi della community

Una risposta successiva ha notato attività di Avahi sulle interfacce Docker/virtuali e ha suggerito che il servizio potesse pubblicizzare gli annunci sul bridge sbagliato anziché sulla LAN principale. Il rispondente ha richiesto ulteriori informazioni dai log.

La discussione pubblica termina prima che questa ipotesi venga verificata. Non presentare “Avahi è associato a Docker” come causa principale confermata.

Il fallimento anche su Android ha modificato la diagnosi

L’utente del caso ha installato il client Android e ha riferito che anche quest’ultimo non riusciva a rilevare automaticamente il server. Ciò ha indebolito le spiegazioni legate specificamente a Enhanced Privacy di iOS, alle impostazioni VPN o all’autorizzazione alla rete locale di Apple.

Le variabili rimanenti erano l’host ZimaOS, il percorso di rilevazione sulla LAN o un’interazione tra i due.

IceWhale ha richiesto dettagli sulla topologia e sulla privacy

Zima-Giorgio ha chiesto informazioni su VLAN, firewall, filtraggio dei protocolli, funzioni Enhanced Privacy/VPN di iOS, IP Restriction Tracking e test con un altro dispositivo Apple. Si trattava di una richiesta ufficiale di risoluzione dei problemi, non dell’affermazione che una di queste impostazioni fosse la causa del malfunzionamento.

ZimaClient attuale ha continuato a evolversi

Lo ZimaClient attuale è molto più avanzato rispetto alla versione di ottobre 2025 e include continui miglioramenti all’affidabilità della connessione e del passaggio tra dispositivi. In un caso moderno, aggiorna sia ZimaOS sia ZimaClient prima di ripetere gli esperimenti di reinstallazione del caso precedente.

Usa l’attuale procedura di installazione e connessione di ZimaClient come riferimento.

Domande frequenti sulla rilevazione LAN di ZimaClient

Il Remote ID funzionava nel caso descritto?

Sì. L’utente poteva connettersi tramite Remote ID sia sulla rete domestica sia fuori da essa.

L’accesso alla rete locale di iOS era disabilitato?

No. L’utente ha pubblicato uno screenshot che lo mostrava abilitato.

Avahi era arrestato?

No. Lo screenshot del caso mostrava avahi-daemon in esecuzione.

La causa principale è stata confermata?

No. La discussione pubblica si è conclusa mentre si stavano ancora analizzando ulteriori test sulla topologia e sulle interfacce Avahi.