Najmocniejszym testem w tym wątku była zamiana routera. Ten sam serwer ZimaOS i klient mobilny, które nie mogły wykryć się nawzajem przez sieć mesh TP-Link Deco, zaczęły działać natychmiast, gdy serwer przetestowano za routerem ZTE dostarczonym przez dostawcę internetu. Wskazuje to na problem z lokalnym wykrywaniem urządzeń/multicastingiem, a nie na to, że sam serwer ZimaOS był offline.
W wątku wypróbowano następnie społecznościowe modyfikacje Avahi, w tym włączenie reflektora mDNS, ale autor oryginalnego wpisu potwierdził, że zmiany te nie rozwiązały problemu z Deco. Obecny ZimaOS oferuje lepsze rozwiązania awaryjne: aktualna dokumentacja „Get Started” informuje, że gdy lokalne wykrywanie zawiedzie, użytkownik może otworzyć urządzenie bezpośrednio po adresie IP w przeglądarce, a Remote ID/Network ID zapewnia dodatkową ścieżkę identyfikacji urządzenia.
To nie był w rzeczywistości problem wyłącznie z iOS
Na stronie 2 santhora podkreślił, że Android również nie mógł wykryć serwera. Wykluczało to wąski problem z uprawnieniami iOS lub klientem specyficznym dla urządzeń Apple.
Topologia była prosta: główne urządzenie Deco → 2,5 GbE → serwer Beelink ZimaOS, podczas gdy telefony łączyły się z systemem Deco przez Wi-Fi.
Test z routerem dostawcy internetu był najlepszym testem izolacyjnym
Izolacja klientów była już wyłączona
W źródle sprawdzono ustawienie kontroli klientów/izolacji w Deco i poinformowano, że było wyłączone. Telefony i urządzenie ZimaOS testowano również z tym samym urządzeniem Deco, ale wykrywanie nadal nie działało.
Ma to znaczenie, ponieważ „wyłącz izolację punktu dostępowego” to dobre pierwsze sprawdzenie, ale w tym przypadku nie było ostatecznym rozwiązaniem.
Edycja reflektora Avahi nie zadziałała
W odpowiedzi społeczność zasugerowała edycję pliku /etc/avahi/avahi-daemon.conf i włączenie reflektora. Użytkownik to wypróbował i poinformował, że nic się nie zmieniło.
Ponieważ obejście nie zadziałało, wątek zalecał cofnięcie zmiany. Nie pozostawiaj starych modyfikacji związanych z wykrywaniem urządzeń tylko dlatego, że zasugerowano je na forum.
Obecny ZimaOS oficjalnie obsługuje dostęp przez adres IP w przeglądarce
Aktualna dokumentacja IceWhale „Get Started” informuje, że jeśli ZimaClient nie może znaleźć urządzenia, należy odszukać adres IP serwera na liście klientów DHCP routera i wpisać ten adres w przeglądarce. Ekran konfiguracji/pulpitu pozostaje taki sam.
Skorzystaj z aktualnego rozwiązania awaryjnego z bezpośrednim dostępem po adresie IP, zanim zmodyfikujesz Avahi.
Remote ID zapewnia inną obsługiwaną ścieżkę identyfikacji
Aktualna dokumentacja ZimaOS udostępnia Remote ID/NetworkID w sekcji Ustawienia → Sieć. Traktuj je jak dane uwierzytelniające, ponieważ mogą służyć do identyfikacji urządzenia i udostępniania do niego dostępu.
Zobacz obecny model dostępu z użyciem Remote ID.
Co sprawdzić w systemie Deco lub innej sieci mesh
- izolację klientów/punktu dostępowego;
- separację sieci gościnnej;
- przekazywanie multicastu/mDNS między segmentami przewodowymi i bezprzewodowymi;
- separację VLAN;
- sposób działania węzłów mesh podczas przełączania klientów;
- aktualizacje oprogramowania układowego i opcje multicastu dostępne u producenta.
Normalny dostęp do internetu i pomyślna odpowiedź na ping nie dowodzą, że multicastowe wykrywanie usług jest przekazywane.
Często zadawane pytania dotyczące wykrywania urządzeń przez ZimaClient
Czy wyłączenie IPv6 rozwiązało problem opisany w źródle?
Nie. Użytkownik wyraźnie poinformował, że wyłączenie IPv6 nie pomogło.
Czy włączenie reflektora Avahi naprawiło sieć mesh Deco?
Nie. Autor oryginalnego wpisu wypróbował to rozwiązanie i poinformował, że nic się nie zmieniło.
Jakie jest obecnie najbezpieczniejsze rozwiązanie awaryjne, gdy lokalne wykrywanie urządzeń zawiedzie?
Użyj lokalnego adresu IP urządzenia w przeglądarce albo skorzystaj z obsługiwanej ścieżki Remote ID/dostępu zdalnego, zamiast wprowadzać niezweryfikowane zmiany w usługach systemowych.
