deadlord
2023年12月6日 16時01分
いつもお世話になっております。
■問題概要
・Armadillo 2台でマルチアドミン機能を試したところ、うまくできなかった
■資材
・Armadillo640＋BT/THモジュール ×2
・Matterエッジデバイス（Matter Light） ×1
■問題詳細
・【OK】下記公式のブログを参考して、Armadillo640＋BT/THモジュールを2台（①と②で区別）セットアップし、同じネットワークに配置（それぞれ単独でエッジデバイスとのコミッショニング可能であることを確認済み）
https://armadillo.atmark-techno.com/howto/a640_matter_over_thread
・【OK】Armadillo640①でエッジデバイスと接続
・【OK】下記のリンクの手順通り（Step1〜Step3）に、Armadillo640①でコミッショニングコードを発行
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/matter/chip…
・【NG】Armadillo640②でコミッショニングコードを使って、エッジデバイスと接続（Step4）
■調査
・「■問題詳細」のArmadillo640①の代わりに、Google Nest Hubを利用する場合、
Armadillo640②でGoogle Nest Hubで発行したコミッショニングコードを使って、
エッジデバイスと接続できたことを確認済み
・Armadillo640②で「./chip-tool discover commissionables」コマンドを実行して、
Armadillo640①の場合エッジデバイスの情報が見えなかったことまで判明
以上です。
ご確認をお願い申し上げます。
ご回答をお待ちします。
コメント
deadlord
古賀さん
早速の返事ありがとうございました。
＞ 引数の値を 1 にするか 0 にするかに関わらず
はい、こちらも試しましたが、
②からのコミッショニングは失敗でした。
引数はもちろん、
multi-admin機能のコマンドも2種類やってみましたが、
いずれも次のStepで失敗しました。
・chip-tool pairing open-commissioning-window
・chip-tool administratorcommissioning open-basic-commissioning-window
①のThread情報（commissioning window）を②から見えない（アクセスできない）のが問題で、
①内部のIPv6情報がうまく公開できてないような気がします。
at_shinya.koga
アットマークテクノの古賀です。
deadlordさん：
>早速の返事ありがとうございました。
あ、いえいえ。Howto を読んでくださって、有難うございます。
>>引数の値を 1 にするか 0 にするかに関わらず
>
>はい、こちらも試しましたが、
>②からのコミッショニングは失敗でした。
了解しました。ご確認有り難うございます。
>引数はもちろん、
>multi-admin機能のコマンドも2種類やってみましたが、
>いずれも次のStepで失敗しました。
>・chip-tool pairing open-commissioning-window
>・chip-tool administratorcommissioning open-basic-commissioning-window
>
>①のThread情報（commissioning window）を②から見えない（アクセスできない）のが問題で、
>①内部のIPv6情報がうまく公開できてないような気がします。
chip-tool のログをご覧になっていらっしゃると思いますが、コミッショニング開始時の BLE 通信まではできていて、その後の、Thread ネットワーク経由での DNS-SD クエリで失敗している感じでしょうか？
もしそうであれば、おっしゃるように、IPv6 over Thread 通信回りが要因の可能性が高いですね。
現在試していらっしゃるシステム構成についてお聞きしたいのですが、二つの Armadillo-640 + BT/TH モジュールでは、それぞれ何が動いているでしょうか？
Howto では、一台の Armadillo-640 + BT/TH オプションモジュールで Thread ボーダールーターと chip-tool を稼働させる構成でしたが、二台構成の場合に、どう動かしていらっしゃるのかを知りたい次第です。
deadlord
＞Thread ネットワーク経由での DNS-SD クエリで失敗している感じでしょうか
そんな感じです。
ログを添付します。
＞二つの Armadillo-640 + BT/TH モジュールでは、それぞれ何が動いているでしょうか？
■事前準備＆確認
・Armadillo二台とも完全にHowto通りにセットアップして、
それぞれThread ボーダールーター＋ chip-tool でデバイスを制御できたところを確認した
・Armadillo二台をlanで同じルーターに接続、お互いのIPv4のアドレスをpingできたことを確認した
■確認の詳細手順
１．二台（①と②）とも再起動
２．①でHowtoの「Matter over Thread デバイスをコミッショニングする」ブロックの手順を実施
⇒①とデバイスがコミッショニング済み状態になった
３．②でHowtoの「Matter over Thread デバイスをコミッショニングする」ブロックの手順（「コミッショニングを実行する」以外）を実施
⇒chip-tool利用できる状態になった
４．「一台目open_commisioning_window.log」通りに「open-commissioning-window」を実施
⇒pairing codeを取得
５．「二台目pairing.log」通りにpairing codeを利用して、「pairing」を実施
⇒commissioning-windowが開放済みはずのデバイスをdiscoverできず、コミッショニングが失敗
| ファイル | ファイルの説明 |
|---|---|
| 一台目open_commisioning_window.log | L254付近 pairing codeを生成できた |
| 二台目pairing.log | L61、L62付近 discover開始して30秒立ったところ、 見つからなかったため終了した |
at_shinya.koga
アットマークテクノの古賀です。
deadlordさん：
>>Thread ネットワーク経由での DNS-SD クエリで失敗している感じでしょうか
>
>そんな感じです。
>ログを添付します。
有難うございます。'二台目pairing.log' の内容を見ると、BLE 通信せずに、いきなり DNS-SD クエリを出している感じですね。
'一台目open_commisioning_window.log' に出力されている、生成された QR コード内容を chip-tool でデコードしてみたところ、Discovery Bitmask の値が 0x04 (On IP network) ですので、IPv6 で discovery しようとするので正しいのかなとも思いますが。
# Multi-admin scenario の場合の discovery の流れがどうなっているか、Matter の
# 仕様書を見ずにコメントしていますので、間抜けなことを書いているかも知れま
# せん。その場合は、ごめんなさい。
>>二つの Armadillo-640 + BT/TH モジュールでは、それぞれ何が動いているでしょうか？
>
>■事前準備＆確認
>・Armadillo二台とも完全にHowto通りにセットアップして、
> それぞれThread ボーダールーター＋ chip-tool でデバイスを制御できたところを確認した
>・Armadillo二台をlanで同じルーターに接続、お互いのIPv4のアドレスをpingできたことを確認した
最初の質問にも書いていらっしゃいましたね。ごめんなさい。
最初の質問で書いていらしたように、Armadillo (1) の代わりに Google Nest Hub （※こいつの上でも、Thread ボーダールーターが稼働しているはず）を使うと Armadillo (2) からもコミッショニングできるということでしたので、二台の Armadillo の両方で Thread ボーダールーターが動作すること自体は、問題ないのかも知れません。
が、このあたりを少し調べてみる必要がありそうです。
deadlordさん（2023年12月6日 16時01分）：
>■調査
>・「■問題詳細」のArmadillo640①の代わりに、Google Nest Hubを利用する場合、
> Armadillo640②でGoogle Nest Hubで発行したコミッショニングコードを使って、
> エッジデバイスと接続できたことを確認済み
次のことを試してみて頂いてもよいでしょうか？
(1) Armadillo (2) の方で、chip-tool が動いているコンテナで 'rm /tmp/chip_*' を実行して、chip-tool の構成情報キャッシュデータを削除してから実行しなおすと、どうなるか：
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/matter/chip…
(2) Armadillo (2) の代わりに Google Nest Hub で QR コードを生成した場合に、生成された QR コードを chip-tool でデコードすると、Discovery Bitmask の値が何になるか。
(3) Armadillo (2) で otbr コンテナを動作させずにコミッショニングを行う場合、どうなるか。
←この場合、Armadillo (2) から Armadillo (1) 上の Thread ボーダールーターに、LAN/WLAN 経由で IPv6 パケットが疎通しなければいけませんが。
こちらで確認せずのお願いになってしまい恐縮ですが、どうぞ宜しくお願いします。
deadlord
deadlord
古賀さん：
返信遅くなりました。
以下試しましたので、連絡いたします。
> (1) Armadillo (2) の方で、chip-tool が動いているコンテナで 'rm /tmp/chip_*' を実行...
特に改善はなかったです。
> (2) Armadillo (2) の代わりに Google Nest Hub で QR コードを生成した場合に、...、Discovery Bitmask の値が何になるか。
同じく「0x04 (On IP network)」でした。
> (3) Armadillo (2) で otbr コンテナを動作させずにコミッショニングを行う場合、どうなるか。
マルチアドミンの場合、二台目Commissionerのotbrは起動しなくてもいけました（Matter仕様でかつGoogle NestHubで確認）。
おそらくそこは問題ではなくて、
一台目Commissionerが自身のThread情報を公開（WIFI/ETHからアクセスできるように）することかと思います。
koga
アットマークテクノの古賀です。
deadlordさん：
>返信遅くなりました。
>以下試しましたので、連絡いたします。
確認有難うございます。
>>(1) Armadillo (2) の方で、chip-tool が動いているコンテナで 'rm /tmp/chip_*' を実行...
>特に改善はなかったです。
>
>>(2) Armadillo (2) の代わりに Google Nest Hub で QR コードを生成した場合に、...、Discovery Bitmask の値が何になるか。
>同じく「0x04 (On IP network)」でした。
了解しました。
>>(3) Armadillo (2) で otbr コンテナを動作させずにコミッショニングを行う場合、どうなるか。
>
>マルチアドミンの場合、二台目Commissionerのotbrは起動しなくてもいけました（Matter仕様でかつGoogle NestHubで確認）。
「いけました」というのは、Armadillo (2) の代わりに Google NestHub を使った場合という認識で、合っているでしょうか？
>おそらくそこは問題ではなくて、
>一台目Commissionerが自身のThread情報を公開（WIFI/ETHからアクセスできるように）することかと思います。
Armadillo (2) の方ですが、avahi-daemon サービスは、どうされているでしょうか？
Howto の手順では、Armadillo Base OS で直接動作している方の avahi-daemon を停止していましたが、otbr コンテナを動かさずにコミッショニングする際に、avahi-daemon を停止させたままだったのか、起動してから試されたのかを教えてください。
deadlord
古賀さん：
> 「いけました」というのは、Armadillo (2) の代わりに Google NestHub を使った場合という認識で、合っているでしょうか？
説明不足ですみません。
Google NestHubで先にコミッショニングして、
NestHubからもらったパスコード／QRコードでArmadillo（OTBR起動なし）でコミッショニングできました。
> otbr コンテナを動かさずにコミッショニングする際に、avahi-daemon を停止させたままだったのか、起動してから試されたのか
停止させたままで確認しました。
Armadillo Base OSのavahi-daemonを起動して確認してみます。
あと以下のアクションも実施する予定です。
Raspberry Pi でThread環境を作って、OMR アドレスにアクセスできるかをArmadilloと比較してみます。
https://openthread.io/codelabs/openthread-border-router?hl=ja#0
deadlord
古賀さん：
問題箇所を特定しました。
結論から申し上げますと、Howto通りに構築したArmadilloのThread（otbrコンテナ）環境に問題があるように思います。
マルチアドミン云々以前の問題です。
下記Thread公式ドキュメントを参考して、RaspberryPIのThread環境を構築しました。
https://openthread.io/codelabs/openthread-border-router
#1 〜 #3
下記コマンドでoff-mesh-routable (OMR) アドレスを特定して、
ot-ctl netdata show
ot-ctl ipaddr
RaspberryPIと同じネットワーク内にあるPCからOMRをpingすると、問題なく通りました。
ところが、Armadillo環境の場合、「OpenThread Border Router (otbr) コンテナを起動する」手順の後に、
OMRを取得して、他のPCからpingしても通りませんでした。
簡単に再現できると思いますので、ご確認ください。
問題の原因はまだ究明していないが、
Raspberry環境との差分として、
Armadilloはコンテナを使っているため、
podmanのブリッジネットワーク設定あたりがうまくできていない可能性があると思います。
at_shinya.koga
アットマーテクノの古賀です。
deadlordさん：
>問題箇所を特定しました。
ご確認有り難うございます。
>結論から申し上げますと、Howto通りに構築したArmadilloのThread（otbrコンテナ）環境に問題があるように思います。
>マルチアドミン云々以前の問題です。
そのようですね。
>ところが、Armadillo環境の場合、「OpenThread Border Router (otbr) コンテナを起動する」手順の後に、
>OMRを取得して、他のPCからpingしても通りませんでした。
>
>簡単に再現できると思いますので、ご確認ください。
Howto 作成時の確認が足りておらず、お手数をかけてしまいましたね。ごめんなさい。
確認のうえ、対処を加えたいと思います。
>問題の原因はまだ究明していないが、
>Raspberry環境との差分として、
>Armadilloはコンテナを使っているため、
>podmanのブリッジネットワーク設定あたりがうまくできていない可能性があると思います。
そうですね。そのあたりが要因だろうと思います。
対応版のコンテナを提供できるようにしますので、対応が終わりましたら連絡します。
ひとまず、有難うございました。
koga
アットマークテクノの古賀です。
古賀（2023年12月13日 11時33分）：
>>結論から申し上げますと、Howto通りに構築したArmadilloのThread（otbrコンテナ）環境に問題があるように思います。
>>マルチアドミン云々以前の問題です。
>
>そのようですね。
>
>>ところが、Armadillo環境の場合、「OpenThread Border Router (otbr) コンテナを起動する」手順の後に、
>>OMRを取得して、他のPCからpingしても通りませんでした。
>>
>>簡単に再現できると思いますので、ご確認ください。
>
>Howto 作成時の確認が足りておらず、お手数をかけてしまいましたね。ごめんなさい。
>確認のうえ、対処を加えたいと思います。
まだ調査途中ですが、途中経過としてお知らせします。
otbr コンテナのネットワークをブリッジにせず、ホストのものを共有すれば、otbr の OMR な IPv6 アドレスに対して別ホストから ping が通ることは確認しました。つまり、コンテナ作成時に、podman run を次のようにすれば通ります：
[armadillo ~]# podman run -d --privileged --name otbr --net host \ --volume /dev/ttyACM0:/dev/radio nrfconnect/otbr:9185bda --radio-url spinel+hdlc+uart:///dev/radio?uart-baudrate=1000000
この場合、otbr の Web GUI にアクセスする場合は、ポート番号を指定せず、デフォルトの 80 を使用してください。
otbr の Web GUI のポート番号は、ソース中に定数定義されており、設定ファイルなどで変更することは、できないようです。
>>問題の原因はまだ究明していないが、
>>Raspberry環境との差分として、
>>Armadilloはコンテナを使っているため、
>>podmanのブリッジネットワーク設定あたりがうまくできていない可能性があると思います。
>
>そうですね。そのあたりが要因だろうと思います。
>対応版のコンテナを提供できるようにしますので、対応が終わりましたら連絡します。
まだ ping の疎通までしか確認していませんが、取り急ぎお知らせです。
deadlord
deadlord
at_shinya.koga
2023年12月6日 17時02分
アットマークテクノの古賀です。
deadlordさん：
>■問題概要
>・Armadillo 2台でマルチアドミン機能を試したところ、うまくできなかった
ごめんなさい。このケースは試したことがないので、失敗する原因は分からないです。
取り急ぎ、一点確認です。
>■資材
>・Armadillo640＋BT/THモジュール ×2
>・Matterエッジデバイス（Matter Light） ×1
>
>■問題詳細
>・【OK】下記公式のブログを参考して、Armadillo640＋BT/THモジュールを2台（①と②で区別）セットアップし、同じネットワークに配置（それぞれ単独でエッジデバイスとのコミッショニング可能であることを確認済み）
> https://armadillo.atmark-techno.com/howto/a640_matter_over_thread
>・【OK】Armadillo640①でエッジデバイスと接続
>・【OK】下記のリンクの手順通り（Step1〜Step3）に、Armadillo640①でコミッショニングコードを発行
> https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/matter/chip…
>・【NG】Armadillo640②でコミッショニングコードを使って、エッジデバイスと接続（Step4）
Multi-admin scenario の "Step 2: Open the commissioning window" で chip-tool pairing open-commissioning-window コマンドを実行する際、<open> 引数の値を 1 にするか 0 にするかに関わらず、その後の、Armadillo-640 (2) でのコミッショニングに失敗するでしょうか？
>■調査
>・「■問題詳細」のArmadillo640①の代わりに、Google Nest Hubを利用する場合、
> Armadillo640②でGoogle Nest Hubで発行したコミッショニングコードを使って、
> エッジデバイスと接続できたことを確認済み
>・Armadillo640②で「./chip-tool discover commissionables」コマンドを実行して、
> Armadillo640①の場合エッジデバイスの情報が見えなかったことまで判明
>
>
>以上です。
>ご確認をお願い申し上げます。
>ご回答をお待ちします。
以上、ひとまずのコメントです。