De sterkste test in deze thread is het vervangen van de router. Dezelfde ZimaOS-server en mobiele client die elkaar via het TP-Link Deco-meshnetwerk niet konden vinden, werkten direct toen de server achter de door de internetprovider geleverde ZTE-router werd getest. Dat maakt de oorspronkelijke situatie tot een lokaal ontdekkings-/multicastprobleem en niet tot bewijs dat de ZimaOS-server zelf offline was.
Daarna werden in de thread communitywijzigingen voor Avahi geprobeerd, waaronder het inschakelen van de mDNS-reflector, maar de oorspronkelijke poster bevestigde dat deze wijzigingen het Deco-probleem niet oplosten. Het huidige ZimaOS biedt betere alternatieven: in de huidige Get Started-documentatie staat dat gebruikers het apparaat rechtstreeks op IP-adres in een browser kunnen openen wanneer lokale detectie mislukt, en Remote ID/Network ID biedt een andere route voor apparaatidentificatie.
Dit was niet echt een probleem dat alleen iOS betrof
Op pagina 2 benadrukte santhora dat Android de server ook niet kon detecteren. Daarmee viel een specifiek iOS-permissieprobleem of een probleem met de Apple-client uit.
De netwerkopstelling was eenvoudig: de hoofdunit van Deco → 2,5GbE → de Beelink ZimaOS-server, terwijl telefoons via wifi met het Deco-systeem waren verbonden.
De test met de router van de internetprovider was de beste isolatietest
Clientisolatie was al uitgeschakeld
De bron controleerde de client-/isolatie-instelling van Deco en gaf aan dat deze was uitgeschakeld. De telefoons en het ZimaOS-apparaat werden ook met dezelfde Deco-unit getest, zonder dat detectie werd hersteld.
Dat is belangrijk, want “AP-isolatie uitschakelen” is een goede eerste controle, maar het was hier niet de uiteindelijke oplossing.
De wijziging aan de Avahi-reflector werkte niet
Een communityreactie stelde voor om /etc/avahi/avahi-daemon.conf te bewerken en de reflector in te schakelen. De gebruiker probeerde dit en meldde geen verandering.
Omdat de tijdelijke oplossing niet werkte, adviseerde de thread om de wijziging terug te draaien. Laat oude aanpassingen voor detectie niet staan alleen omdat ze op een forum zijn voorgesteld.
Het huidige ZimaOS ondersteunt expliciet browsertoegang via het directe IP-adres
In de huidige IceWhale Get Started-documentatie staat dat je, als ZimaClient het apparaat niet kan vinden, het server-IP-adres kunt opzoeken in de DHCP-clientlijst van de router en dat IP-adres in een browser kunt invoeren. Het installatie-/dashboardscherm is hetzelfde.
Gebruik de huidige fallback via het directe IP-adres voordat je Avahi aanpast.
Remote ID biedt een andere ondersteunde identificatiemethode
De huidige ZimaOS-documentatie vermeldt een Remote ID/NetworkID onder Instellingen → Netwerk. Behandel deze als een toegangsgegeven, omdat hiermee het apparaat kan worden geïdentificeerd en toegang kan worden gedeeld.
Zie het huidige toegangsmodel met Remote ID.
Wat je op het Deco- of andere mesh-systeem moet controleren
- client-/AP-isolatie;
- scheiding van het gastnetwerk;
- doorsturen van multicast/mDNS tussen bekabelde en draadloze segmenten;
- scheiding via VLAN's;
- het gedrag van meshnodes wanneer clients rondlopen;
- firmware-updates en multicastopties die specifiek zijn voor de fabrikant.
Normale internettoegang en een succesvolle ping bewijzen niet dat multicastservicedetectie wordt doorgestuurd.
Veelgestelde vragen over ZimaClient-detectie
Heeft het uitschakelen van IPv6 de oorspronkelijke situatie opgelost?
Nee. De gebruiker meldde expliciet dat het uitschakelen van IPv6 niet hielp.
Heeft het inschakelen van de Avahi-reflector het Deco-meshnetwerk hersteld?
Nee. De oorspronkelijke poster probeerde dit en meldde geen verandering.
Wat is momenteel de veiligste fallback wanneer lokale detectie mislukt?
Gebruik het LAN-IP-adres van het apparaat in een browser of gebruik de ondersteunde Remote ID-/toegangsroute op afstand, in plaats van niet-geverifieerde wijzigingen aan hostservices aan te brengen.
