このスレッドで最も有力な検証結果は、ルーターを交換したテストです。TP-Link Decoメッシュ経由では互いを検出できなかった同じZimaOSサーバーとモバイルクライアントが、ISP提供のZTEルーターの背後でサーバーをテストすると、すぐに動作しました。これは、元のケースがローカル検出／マルチキャストの問題であり、ZimaOSサーバー自体がオフラインだったことを示すものではありません。
その後、スレッドではmDNSリフレクターの有効化など、コミュニティで提案されたAvahiの変更を試しましたが、投稿者はそれらの変更でもDecoのケースは解決しなかったと報告しています。現在のZimaOSには、より優れた代替手段があります。現在の「はじめに」ドキュメントでは、ローカル検出に失敗した場合、ブラウザーでデバイスのIPアドレスを直接開けると説明されています。また、Remote ID／Network IDも別のデバイス識別手段になります。
これは本当にiOSだけの問題ではなかった
2ページ目で、santhoraはAndroidでもサーバーを検出できなかったと強調しました。これにより、iOSの権限やApple固有のクライアントの問題に限定される可能性は排除されました。
ネットワーク構成は単純でした。Decoのメインユニット → 2.5GbE → Beelink ZimaOSサーバーで、スマートフォンはDecoシステムにWi-Fi接続していました。
ISPルーターでのテストが最良の切り分けテストだった
クライアント分離はすでに無効になっていた
検証では、Decoのクライアント分離／分離制御を確認し、無効になっていることが報告されています。スマートフォンとZimaOSデバイスを同じDecoユニットに接続しても、検出は復旧しませんでした。
この点は重要です。「AP分離を無効にする」は最初に確認すべき項目ですが、今回の最終的な解決策ではありませんでした。
Avahiリフレクターの編集では解決しなかった
コミュニティからは、/etc/avahi/avahi-daemon.confを編集してリフレクターを有効にする提案がありました。ユーザーは試しましたが、変化はなかったと報告しています。
この回避策は失敗したため、スレッドでは変更を元に戻すよう案内しました。フォーラムで提案されたというだけで、古い検出設定を残しておかないでください。
現在のZimaOSはIPアドレスによるブラウザーアクセスを明示的にサポートしている
現在のIceWhaleの「はじめに」ドキュメントでは、ZimaClientがデバイスを見つけられない場合、ルーターのDHCPクライアント一覧でサーバーのIPアドレスを確認し、そのIPアドレスをブラウザーに入力するよう案内しています。表示されるセットアップ／ダッシュボード画面は同じです。
Avahiを変更する前に、現在のIPアドレス直接入力による代替手段を使用してください。
Remote IDは、もう1つのサポート対象の識別手段を提供する
現在のZimaOSドキュメントでは、「設定」→「ネットワーク」にRemote ID／NetworkIDが表示されます。これはデバイスの識別やアクセス共有に使用できるため、認証情報と同様に扱ってください。
現在のRemote IDアクセスモデルを参照してください。
Decoまたは他のメッシュシステムで確認する項目
- クライアント／AP分離;
- ゲストネットワークの分離;
- 有線セグメントと無線セグメント間のマルチキャスト／mDNS転送;
- VLANによる分離;
- クライアントがローミングする際のメッシュノードの動作;
- ファームウェアの更新と、ベンダー固有のマルチキャスト設定。
通常のインターネットアクセスやpingの成功だけでは、マルチキャストによるサービス検出が転送されていることは証明できません。
ZimaClient検出に関するよくある質問
IPv6を無効にすると元のケースは解決しましたか？
いいえ。ユーザーは、IPv6を無効にしても改善しなかったと明確に報告しています。
Avahiリフレクターを有効にするとDecoメッシュは解決しましたか？
いいえ。投稿者は試しましたが、変化はなかったと報告しています。
ローカル検出に失敗した場合、現在最も安全な代替手段は何ですか？
ブラウザーでデバイスのLAN IPアドレスを使用するか、検証されていないホストサービスの設定を変更せず、サポート対象のRemote ID／リモートアクセス経路を使用してください。
