Este caso de origem separa dois caminhos de ligação que os utilizadores frequentemente tratam como se fossem a mesma coisa. O ZimaClient conseguia ligar-se quando o utilizador introduzia o ID remoto, tanto em casa como fora de casa, mas a deteção automática na rede local apresentava Nenhum dispositivo encontrado. Isto significa que a relação com o servidor e o acesso remoto estavam funcionais, enquanto a deteção local falhava.
A discussão nunca chegou a uma solução final confirmada. A permissão de rede local no iOS já estava ativada, o Avahi estava em execução, uma reinstalação completa do ZimaOS não alterou o comportamento e, mais tarde, o utilizador instalou o cliente Android, apenas para descobrir que o Android também não conseguia detetar automaticamente o servidor.
O ID remoto funcionava, mas a deteção na LAN falhava
Esta diferença constitui uma fronteira de diagnóstico útil: não investigue a autenticação do ID remoto quando a falha ocorre apenas na deteção local.
A permissão de rede local do iOS já estava ativada
Uma resposta da comunidade sugeriu corretamente verificar as Definições do iOS, uma vez que a Apple exige permissão explícita para as aplicações que detetam ou comunicam com dispositivos na rede local.
Reinstalar a aplicação e o ZimaOS não resolveu o problema
O utilizador reinstalou repetidamente a aplicação iOS, reiniciou e desligou o NAS e, por fim, formatou e reinstalou o ZimaOS. Nenhum desses passos restaurou a deteção automática.
Estas evidências negativas apontam contra uma simples cache desatualizada da aplicação ou uma única instalação danificada do ZimaOS.
A comunidade suspeitou de mDNS/Bonjour
A deteção automática de dispositivos em muitas aplicações locais depende de DNS multicast ou de transmissões relacionadas de deteção na LAN. Os membros da comunidade suspeitaram que o cliente não estava a receber esses anúncios e sugeriram verificar o isolamento de clientes/AP e o encaminhamento multicast.
O utilizador contrapôs que o AirPrint, o AirPlay, a deteção QNAP e outros serviços locais do iOS funcionavam através da mesma rede TP-Link Deco.
O Avahi estava em execução no ZimaOS
O Avahi em pontes virtuais era apenas uma hipótese da comunidade
Uma resposta posterior detetou atividade do Avahi em interfaces Docker/virtuais e sugeriu que este poderia estar a anunciar na ponte errada, em vez da LAN principal. O autor da resposta pediu mais dados do journal.
A discussão pública termina antes de essa hipótese ser validada. Não apresente “o Avahi está associado ao Docker” como a causa-raiz confirmada.
A falha também no Android alterou o diagnóstico
O utilizador instalou o cliente Android e comunicou que este também não conseguia detetar automaticamente o servidor. Isto enfraqueceu as explicações especificamente relacionadas com a Privacidade Avançada do iOS, as definições de VPN ou a permissão de rede local da Apple.
As variáveis restantes eram o anfitrião ZimaOS, o caminho de deteção na LAN ou uma interação entre ambos.
A IceWhale pediu detalhes sobre a topologia e a privacidade
Zima-Giorgio perguntou sobre VLANs, firewalls, filtragem de protocolos, funcionalidades de Privacidade Avançada/VPN do iOS, o Rastreio de restrições de IP e testes com outro dispositivo Apple. Tratava-se de um pedido oficial de resolução de problemas, não de uma afirmação de que alguma dessas definições causava a falha.
O ZimaClient atual continuou a evoluir
O ZimaClient atual está muito além da compilação de outubro de 2025 e inclui trabalho contínuo de melhoria da fiabilidade da ligação e da alternância entre dispositivos. Num caso moderno, atualize o ZimaOS e o ZimaClient antes de repetir as antigas experiências de reinstalação.
Utilize o procedimento atual de instalação e ligação do ZimaClient como referência.
Perguntas frequentes sobre a deteção na LAN do ZimaClient
O ID remoto funcionava no caso de origem?
Sim. O utilizador conseguia ligar-se através do ID remoto dentro e fora da rede doméstica.
O acesso à rede local no iOS estava desativado?
Não. O utilizador publicou uma captura de ecrã que mostrava a opção ativada.
O Avahi estava parado?
Não. A captura de ecrã do caso de origem mostrava o avahi-daemon em execução.
A causa-raiz final foi confirmada?
Não. A discussão pública terminou enquanto ainda eram debatidos testes adicionais à topologia e às interfaces do Avahi.
