Det starkaste testet i den här tråden är bytet av router. Samma ZimaOS-server och mobilklient som inte kunde upptäcka varandra via TP-Link Deco-meshnätverket fungerade omedelbart när servern testades bakom den router från ZTE som internetleverantören tillhandahöll. Det visar att problemet i det aktuella fallet handlade om lokal upptäckt/multicast, inte att ZimaOS-servern i sig var offline.
Tråden testade sedan community-föreslagna Avahi-ändringar, bland annat att aktivera mDNS-reflektorn, men trådstartaren bekräftade att ändringarna inte löste Deco-problemet. Aktuella versioner av ZimaOS erbjuder bättre alternativ: den aktuella dokumentationen för Kom igång anger att användare kan öppna enheten direkt via dess IP-adress i en webbläsare när lokal upptäckt misslyckas, och Remote ID/Network ID erbjuder ytterligare en väg för enhetsidentifiering.
Det här var egentligen inte ett iOS-specifikt problem
På sidan 2 betonade santhora att Android också misslyckades med att upptäcka servern. Det uteslöt ett snävt problem med iOS-behörigheter eller en Apple-specifik klient.
Nätverkstopologin var enkel: Deco-huvudenhet → 2,5 GbE → Beelink ZimaOS-server, medan telefonerna var anslutna via Wi-Fi till Deco-systemet.
Testet med internetleverantörens router var det bästa isoleringstestet
Klientisolering var redan inaktiverad
Källan kontrollerade Decos klient-/isoleringsinställning och uppgav att den var avstängd. Telefonerna och ZimaOS-enheten testades också mot samma Deco-enhet utan att upptäckten återställdes.
Det är viktigt eftersom ”stäng av AP-isolering” är en bra första kontroll, men det var inte den slutliga lösningen här.
Ändringen av Avahi-reflektorn fungerade inte
Ett community-svar föreslog att redigera /etc/avahi/avahi-daemon.conf och aktivera reflektorn. Användaren testade detta och rapporterade ingen förändring.
Eftersom lösningen inte fungerade rekommenderade tråden att ändringen återställdes. Låt inte gamla upptäcktsjusteringar ligga kvar enbart för att de föreslogs i ett forum.
Aktuella versioner av ZimaOS stöder uttryckligen åtkomst via direkt IP-adress i webbläsaren
Den aktuella dokumentationen för IceWhale Kom igång anger nu att man ska leta upp serverns IP-adress i routerns DHCP-klientlista och ange IP-adressen i en webbläsare om ZimaClient inte hittar enheten. Inställnings-/instrumentpanelsskärmen är densamma.
Använd det aktuella alternativet med direkt IP-adress innan du ändrar Avahi.
Remote ID erbjuder ytterligare en stödd identitetsväg
Den aktuella dokumentationen för ZimaOS visar ett Remote ID/NetworkID under Inställningar → Nätverk. Hantera det som en autentiseringsuppgift eftersom det kan identifiera enheten och dela åtkomst till den.
Se den aktuella åtkomstmodellen med Remote ID.
Det här bör du kontrollera på Deco- eller andra mesh-system
- klient-/AP-isolering;
- separering av gästnätverk;
- vidarebefordran av multicast/mDNS mellan trådanslutna och trådlösa segment;
- VLAN-separering;
- mesh-nodernas beteende när klienter byter nod;
- uppdateringar av fast programvara och leverantörsspecifika multicast-alternativ.
Normal internetåtkomst och lyckad ping bevisar inte att tjänsteupptäckt via multicast vidarebefordras.
Vanliga frågor om ZimaClient-upptäckt
Löste det ursprungliga problemet att inaktivera IPv6?
Nej. Användaren rapporterade uttryckligen att det inte hjälpte att inaktivera IPv6.
Löste aktivering av Avahi-reflektorn Deco-meshproblemet?
Nej. Trådstartaren testade det och rapporterade ingen förändring.
Vilket är det säkraste aktuella alternativet när lokal upptäckt misslyckas?
Använd enhetens LAN-IP-adress i en webbläsare eller använd den stödda vägen med Remote ID/fjärråtkomst i stället för att göra overifierade ändringar av tjänster på värden.
