Det här källfallet skiljer mellan två anslutningsvägar som användare ofta behandlar som samma sak. ZimaClient kunde ansluta utan problem när användaren angav fjärr-ID:t, både hemma och utanför hemmet, men automatisk identifiering i det lokala nätverket visade Ingen enhet hittades. Det innebär att serverrelationen och fjärrvägen fungerade, medan den lokala identifieringen misslyckades.
Tråden ledde aldrig fram till en bekräftad slutgiltig lösning. Behörigheten för lokalt nätverk i iOS var redan aktiverad, Avahi körde, en fullständig ominstallation av ZimaOS ändrade inte beteendet, och användaren installerade senare Android-klienten, bara för att upptäcka att Android inte heller kunde hitta servern automatiskt.
Fjärr-ID fungerade medan identifiering via LAN misslyckades
Den här skillnaden är en användbar diagnostisk skiljelinje: felsök inte autentisering via fjärr-ID när problemet endast gäller lokal identifiering.
Behörigheten för lokalt nätverk i iOS var redan aktiverad
Ett svar i communityn föreslog korrekt att kontrollera iOS-inställningarna, eftersom Apple kräver uttryckligt tillstånd för appar som identifierar eller kommunicerar med enheter i det lokala nätverket.
Att installera om appen och ZimaOS löste inte problemet
Användaren installerade om iOS-appen upprepade gånger, startade om och stängde av NAS-enheten och formaterade slutligen enheten och installerade om ZimaOS. Inget av detta återställde den automatiska identifieringen.
Den här negativa evidensen talar mot en enkel gammal appcache eller en enda skadad ZimaOS-installation.
Communityn misstänkte mDNS/Bonjour
Automatisk identifiering av enheter i många lokala appar är beroende av multicast-DNS eller liknande identifieringssändningar i LAN-nätverket. Medlemmar i communityn misstänkte att klienten inte tog emot dessa meddelanden och föreslog att AP-/klientisolering och vidarebefordran av multicast skulle kontrolleras.
Användaren invände eftersom AirPrint, AirPlay, identifiering av QNAP och andra lokala iOS-tjänster fungerade via samma TP-Link Deco-nätverk.
Avahi körde på ZimaOS
Avahi på virtuella bryggor var endast en hypotes från communityn
Ett senare svar uppmärksammade Avahi-aktivitet på Docker-/virtuella gränssnitt och föreslog att tjänsten kanske annonserade via fel brygga i stället för huvudnätverket. Svarsgivaren bad om ytterligare journalutdata.
Den offentliga tråden avslutas innan hypotesen validerades. Presentera inte ”Avahi är bundet till Docker” som den bekräftade grundorsaken.
Att Android också misslyckades ändrade diagnosen
Källanvändaren installerade Android-klienten och rapporterade att den inte heller kunde hitta servern automatiskt. Det försvagade förklaringar som specifikt var kopplade till Enhanced Privacy i iOS, VPN-inställningar eller Apples behörighet för lokalt nätverk.
De återstående variablerna var ZimaOS-värden, vägen för identifiering via LAN eller ett samspel mellan de två.
IceWhale efterfrågade information om nätverkstopologi och integritetsinställningar
Zima-Giorgio frågade om VLAN, brandväggar, protokollfiltrering, Enhanced Privacy/VPN-funktioner i iOS, IP-begränsad spårning och testning med en annan Apple-enhet. Detta var en officiell felsökningsförfrågan, inte ett påstående om att någon av dessa inställningar orsakade felet.
Den aktuella ZimaClient har fortsatt att utvecklas
Den aktuella ZimaClient ligger långt före versionen från oktober 2025 och innehåller löpande förbättringar av tillförlitligheten vid enhetsanslutning och enhetsväxling. I ett modernt fall bör du uppdatera både ZimaOS och ZimaClient innan du återskapar de gamla ominstallationsexperimenten.
Använd den aktuella installations- och anslutningsprocessen för ZimaClient som utgångspunkt.
Vanliga frågor om identifiering via LAN i ZimaClient
Fungerade fjärr-ID i källfallet?
Ja. Användaren kunde ansluta via fjärr-ID både på och utanför hemnätverket.
Var åtkomst till det lokala nätverket i iOS inaktiverad?
Nej. Användaren publicerade en skärmbild som visade att åtkomsten var aktiverad.
Var Avahi stoppad?
Nej. Skärmbilden från källan visade att avahi-daemon körde.
Bekräftades den slutgiltiga grundorsaken?
Nej. Den offentliga tråden avslutades medan ytterligare tester av nätverkstopologi och Avahi-gränssnitt fortfarande diskuterades.
