Deze broncasus maakt onderscheid tussen twee verbindingspaden die gebruikers vaak als hetzelfde beschouwen. ZimaClient kon succesvol verbinding maken wanneer de gebruiker de Remote ID invoerde, zowel thuis als buitenshuis, maar automatische detectie op het lokale netwerk toonde Geen apparaat gevonden. Dat betekent dat de serverrelatie en externe verbindingsroute functioneerden, terwijl lokale detectie niet werkte.
In de thread werd nooit een definitieve oplossing bevestigd. De lokale-netwerktoestemming voor iOS was al ingeschakeld, Avahi draaide, een volledige herinstallatie van ZimaOS veranderde het gedrag niet en de gebruiker installeerde later de Android-client, om vervolgens vast te stellen dat Android de server ook niet automatisch kon detecteren.
Remote ID werkte, terwijl LAN-detectie mislukte
Dit verschil vormt een nuttige diagnostische grens: probeer Remote ID-authenticatie niet op te lossen wanneer alleen lokale detectie mislukt.
Toestemming voor lokaal netwerk op iOS was al ingeschakeld
Een reactie uit de community stelde terecht voor om de iOS-instellingen te controleren, omdat Apple expliciete toestemming vereist voor apps die apparaten op het lokale netwerk detecteren of ermee communiceren.
Opnieuw installeren van de app en ZimaOS loste het probleem niet op
De gebruiker installeerde de iOS-app meerdere keren opnieuw, startte de NAS opnieuw op en schakelde deze uit, en formatteerde en installeerde uiteindelijk ZimaOS opnieuw. Geen van deze stappen herstelde de automatische detectie.
Dit negatieve bewijs pleit tegen een eenvoudige verouderde appcache of één beschadigde ZimaOS-installatie.
De community vermoedde mDNS/Bonjour
Automatische apparaatdetectie in veel lokale applicaties is afhankelijk van multicast DNS of vergelijkbare LAN-detectieberichten. Communityleden vermoedden dat de client deze aankondigingen niet ontving en stelden voor AP-/clientisolatie en multicast-doorsturing te controleren.
De gebruiker wierp tegen dat AirPrint, AirPlay, QNAP-detectie en andere lokale iOS-diensten via hetzelfde TP-Link Deco-netwerk wel werkten.
Avahi draaide op ZimaOS
Avahi op virtuele bridges was slechts een hypothese uit de community
Een latere reactie merkte Avahi-activiteit op Docker-/virtuele interfaces op en suggereerde dat de service mogelijk via de verkeerde bridge uitzond in plaats van via het hoofd-LAN. De beantwoorder vroeg om meer uitvoer uit het journal.
De openbare thread eindigt voordat deze hypothese werd gevalideerd. Presenteer “Avahi is aan Docker gebonden” niet als de bevestigde hoofdoorzaak.
Dat Android ook faalde, veranderde de diagnose
De gebruiker installeerde de Android-client en meldde dat ook deze de server niet automatisch kon detecteren. Daarmee werden verklaringen die specifiek verband hielden met iOS Enhanced Privacy, VPN-instellingen of Apple's toestemming voor lokaal netwerk minder waarschijnlijk.
De resterende variabelen waren de ZimaOS-host, het LAN-detectiepad of een interactie tussen beide.
IceWhale vroeg om details over topologie en privacy
Zima-Giorgio vroeg naar VLAN's, firewalls, protocolfiltering, iOS Enhanced Privacy/VPN-functies, IP Restriction Tracking en tests met een ander Apple-apparaat. Dit was een officieel verzoek om problemen op te lossen, geen bewering dat een van deze instellingen de storing veroorzaakte.
De huidige ZimaClient is verder ontwikkeld
De huidige ZimaClient is veel verder ontwikkeld dan de versie van oktober 2025 en bevat doorlopend verbeteringen voor de betrouwbaarheid van apparaatverbindingen en het wisselen tussen apparaten. Werk in een moderne casus zowel ZimaOS als ZimaClient bij voordat je de oude herinstallatietests opnieuw uitvoert.
Gebruik de huidige installatie- en verbindingsworkflow voor ZimaClient als uitgangspunt.
Veelgestelde vragen over LAN-detectie in ZimaClient
Werkte Remote ID in de broncasus?
Ja. De gebruiker kon via Remote ID verbinding maken, zowel binnen als buiten het thuisnetwerk.
Was toegang tot het lokale netwerk op iOS uitgeschakeld?
Nee. De gebruiker plaatste een screenshot waarop deze optie was ingeschakeld.
Was Avahi gestopt?
Nee. Op de screenshot uit de broncasus was avahi-daemon actief.
Was de uiteindelijke hoofdoorzaak bevestigd?
Nee. De openbare thread eindigde terwijl aanvullende tests met de netwerktopologie en Avahi-interfaces nog werden besproken.
