s.kurachi
2024年9月17日 16時05分
WLANモジュールについてのご相談です。
Armadillo-IoT G4 WLAN モデルをアクセスポイントモードで使用しています。
様々な施設に設置して運用をするのですが、施設の停電などによって、Armadilloの電源が突然切れることがあります。
その時、poweroffコマンドによって正常なシャットダウンが行われないためか、
次に再起動したときに、WLANモジュールがアクセスポイントとして正常に動作しません。
nmcliコマンドで見る限り、デバイスのステータスは「connected」になっているのですが、
他のデバイスからアクセスポイントのSSIDが見えず、接続できない状態です。
この場合、一度poweroffコマンドによって電源を落とし、再びArmadilloに電源を入れて起動し直すと、
正常にアクセスポイントが利用できるようになります。
こういったトラブルの時に、自動でWLANモジュールが復旧されるようにできないでしょうか？
例えば、Armadillo起動後にWLANモジュールの再起動が実施されるようになどできないでしょうか？
GPIO4_IO01を操作して、M.2 インターフェースの電源を制御することで、
WLANモジュールの再起動ができるのではないかと考えましたが、GPIO4_IO01はResource busyとなって
gpiodコマンドから制御できませんでした。
お手数ですが、ご教示いただけますと幸いです。
コメント
s.kurachi
2024年9月17日 19時13分
> s.kurachiさん
>
> お世話になっています、
> マルティネです。
>
> > GPIO4_IO01を操作して、M.2 インターフェースの電源を制御することで、
> > WLANモジュールの再起動ができるのではないかと考えましたが、GPIO4_IO01はResource busyとなって
> > gpiodコマンドから制御できませんでした。
>
> regulator で予約していますので、その regulator を外せば制御できます... が、そういうふうに電源を落とすとドライバーは簡単に復帰できませんので、昔 m.2 の disable ピンを制御できる方法を追加して、以下の様にほぼ完全にリセットできます：
>
>
> # /sys のパスは長いので変数に保存 > armadillo:~# SYS_PLATFORM_PCI="/sys/devices/platform/soc@0/33800000.pcie" > armadillo:~# SYS_BT_DRIVER="/sys/bus/serial/drivers/hci_uart_h4" > > # 使用中のデバイスを外します > armadillo:~# echo serial0-0 > "$SYS_BT_DRIVER/unbind" > armadillo:~# nmcli r wifi off # 必要であれば hostapd 停止も > armadillo:~# modprobe -r moal > > # disable1 ピンを1秒 assert します > armadillo:~# echo 1000 > "$SYS_PLATFORM_PCI/dis1" > > # PCI レベルで再スキャンします > armadillo:~# echo 1 > "$SYS_PLATFORM_PCI/pci0000:00/0000:00:00.0/remove" > armadillo:~# echo 1 > "$SYS_PLATFORM_PCI/pci0000:00/pci_bus/0000:00/rescan" > > # 1秒ぐらい立つと moal ドライバが自動的に復帰して、wlan を利用可能となります > armadillo:~# nmcli r wifi on >
>
>
> ただし、それを自動的に実行できるかって聞かれたら少し違和感ありますので、本件の問題をもう少し調べたいと思います。
> （起動時にすでに dis1 のピンが少し assert されているはずですので、ただ時間を長くするなどは考えれますが、それで快活されるかどうかは不明です）
>
> 以下の質問を回答いただけますでしょうか？
>
> * ABOS・カーネルのバージョン (cat /etc/atmark-release; uname -r)
> * 問い合わせの説明では AP モードと記載していただきましたが、nmcli での connected というのはなんでしょうか？ AP モードの場合は nmcli 上で wifi を無効化していて hostapd で AP を設定しているはずですので、よくわかりませんでした。その不具合の発生する armadillo で hostapd を起動していて、そこにエラーがないですが他の機器から scan を行っても SSID が見えないじょうたいでよろしいですね？
> また、hostapd サービスのリスタートで復帰しないですね？コンソールで「hostapd -d /etc/hostapd/hostapd.conf」でデバグ出力を有効にした実行例があればみてみたいです。
> * 本件の不具合は再現できますか？それか一度実際に発生しただけですか？再現できる場合に電源が切断されている時間の長さに影響ありますか？（すみません、まだ試してませんが、こちらの環境でも電源を切ってる場合があってそういう不具合は確認してません。APモードだけの問題でしたら気づかない可能性が高いですが、ひとまず確認していただければ助かります）
>
> よろしくお願いします
迅速なご返信ありがとうございます。
> * ABOS・カーネルのバージョン (cat /etc/atmark-release; uname -r)
次のようになりました。
armadillo:~# cat /etc/atmark-release; uname -r 3.20.2-at.2 5.10.209
> * 問い合わせの説明では AP モードと記載していただきましたが、、、、
APの設定は、以下を参考にして、ABOSWebで設定しました。
https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e-d…
「connected」というのはnmcli device コマンドの出力の、「br_ap」のstateを見て判断したものです。
armadillo:~# nmcli device DEVICE TYPE STATE CONNECTION ttyCommModem gsm connected gsm-ttyCommModem eth0 ethernet connected Wired connection 1 br_ap bridge connected abos_web_br_ap lo loopback connected (externally) lo eth1 ethernet unavailable -- ppp0 ppp unmanaged -- mlan0 wifi unmanaged -- uap0 wifi unmanaged --
不勉強で申し訳ありませんが、hostapdというものが良く分かっておりません…。
上記のマニュアル上の説明に従って設定していたのですが、他に必要な設定がありましたでしょうか。
>* 本件の不具合は再現できますか？それか一度実際に発生しただけですか？再現できる場合に電源が切断されている時間の長さに影響ありますか？
これまで電源ケーブルを抜いて切断した場合は、必ずこの症状が出ています。
切断後すぐに起動した場合も、切断後1日以上経ってから起動した場合でも生じました。
よろしくお願いいたします。
at_dominique.m…
2024年9月17日 21時31分
s.kurachiさん、
ご返事ありがとうございます、
順番バラバラで回答します。
> 「connected」というのはnmcli device コマンドの出力の、「br_ap」のstateを見て判断したものです。
了解しました。
マニュアルに説明が不足していますが、br_ap の state だけでは判断できません。
br_ap は、APを生成する際に abos-web の都合で生成するインターフェースですが、生成したら無線LANのインターフェースが存在しなくても connected と表示されます。
> 不勉強で申し訳ありませんが、hostapdというものが良く分かっておりません…。
hostapd というのは、AP インターフェースを実際に制御するサービスです。
（例えば、クライアントが接続すると接続鍵を確認したりしますので、何かのサービスが必要です）
> 上記のマニュアル上の説明に従って設定していたのですが、他に必要な設定がありましたでしょうか。
SSID を見えない環境で以下のを確認していただけたら助かります：
* 「nmcli device」か「ip addr」等で uap0 インターフェースが表示されているかどうか
* hostapd が起動されているかどうか：「ps aux|grep hostapd」
* hostapd サービス再起動で復帰するかどうか：「rc-service hostapd restart」
* 復帰しなかったばあい、手動に実行していただいてログをみれたら何か分かるかもしれません:「rc-service hostapd stop; hostapd -d /etc/hostapd/hostapd.conf」
* カーネルやsyslog に何かの手がかりがあるかもしれませんので、/var/log/messages を添付していただければ拝見します。（本フォーラムで messages のファイルをそのまま添付できませんので、messages.txt にリネームするか zip ファイルに入れていただければと思います。標準ではこのファイルに秘密はありませんが、心配でしたら問題が発生された起動の分だけを確認して送ってください。）
> これまで電源ケーブルを抜いて切断した場合は、必ずこの症状が出ています。
> 切断後すぐに起動した場合も、切断後1日以上経ってから起動した場合でも生じました。
確認ありがとうございます。
残念ですが、同じバージョンをインストールしてみて abos-web で AP を設定してみましたが、AP が見える状態で電源を抜いても再現できませんでした。
関係ないと思いますが、設定しているチャネルも教えていただけますか？
「grep channel /etc/hostapd/hostapd.conf; grep mode /etc/hostapd/hostapd.conf」
> armadillo:~# cat /etc/atmark-release; uname -r > 3.20.2-at.2 > 5.10.209
恐らく問題ないと思いますが、古いカーネルバージョンを使ってますので、ファームウェアとドライバーのバージョンは完全に一致してないと思います。
今のバージョンになってファームウェアの変更はほぼないので、更新する際にバージョン違う環境で動作確認を行って問題ありませんでしたが、念のためカーネルを 5.10.222以上に更新するかファームウェアのバージョンをダウングレードしてみるといいかもしれません。
通常のカーネルで起動できる場合は armadillo をネットワークに接続して「abos-ctrl restore-kernel」を実行すると最新のカーネルがインストールされますので、それで再起動して試していただければ幸いです。
restore-kernel で B 面に現在のソフトウェアを保存しますので、確認ができたら「abos-ctrl rollback --allow-downgrade --reboot」で前のバージョンに戻れます（試す間に swu 等でB面を書き込むと戻れなくなりますのでご了承ください）
また、参考までにカーネルをビルドした理由を教えていただけますか？
場合によっては通常のカーネルのオプションを変更できますので、参考にさせてください。
以上、
よろしくお願いします
s.kurachi
2024年9月18日 16時24分
マルティネさま
ご返信遅くなりました。
> マニュアルに説明が不足していますが、br_ap の state だけでは判断できません。
> br_ap は、APを生成する際に abos-web の都合で生成するインターフェースですが、生成したら無線LANのインターフェースが存在しなくても connected と表示されます。
> hostapd というのは、AP インターフェースを実際に制御するサービスです。
> （例えば、クライアントが接続すると接続鍵を確認したりしますので、何かのサービスが必要です）
そうでしたか…。ありがとうございます。
> SSID を見えない環境で以下のを確認していただけたら助かります：
>
> * 「nmcli device」か「ip addr」等で uap0 インターフェースが表示されているかどうか
SSIDが表示されない症状が出ているときに確認しました。
nmcli deviceコマンドで「uap0」は表示されました。
uap0 wifi unmanaged --
> * hostapd が起動されているかどうか：「ps aux|grep hostapd」
hostapdは起動していませんでした。これが原因ですね。
armadillo:~# ps aux|grep hostapd 5254 root 0:00 grep hostapd
> * hostapd サービス再起動で復帰するかどうか：「rc-service hostapd restart」
hostapdサービスを起動することでSSIDが表示されるようになり、復帰しました！
> * 復帰しなかったばあい、手動に実行していただいてログをみれたら何か分かるかもしれません:「rc-service hostapd stop; hostapd -d /etc/hostapd/hostapd.conf」
> * カーネルやsyslog に何かの手がかりがあるかもしれませんので、/var/log/messages を添付していただければ拝見します。（本フォーラムで messages のファイルをそのまま添付できませんので、messages.txt にリネームするか zip ファイルに入れていただければと思います。標準ではこのファイルに秘密はありませんが、心配でしたら問題が発生された起動の分だけを確認して送ってください。）
SSIDが表示されない症状が出ているときの、起動してからの/var/log/messagesを添付いたします。
この時、hostapdのサービスは立ち上がっていませんでした。
> 残念ですが、同じバージョンをインストールしてみて abos-web で AP を設定してみましたが、AP が見える状態で電源を抜いても再現できませんでした。
> 関係ないと思いますが、設定しているチャネルも教えていただけますか？
> 「grep channel /etc/hostapd/hostapd.conf; grep mode /etc/hostapd/hostapd.conf」
以下のようになりました。
channel=36
hw_mode=a
> 恐らく問題ないと思いますが、古いカーネルバージョンを使ってますので、ファームウェアとドライバーのバージョンは完全に一致してないと思います。
> 今のバージョンになってファームウェアの変更はほぼないので、更新する際にバージョン違う環境で動作確認を行って問題ありませんでしたが、念のためカーネルを 5.10.222以上に更新するかファームウェアのバージョンをダウングレードしてみるといいかもしれません。
>
> 通常のカーネルで起動できる場合は armadillo をネットワークに接続して「abos-ctrl restore-kernel」を実行すると最新のカーネルがインストールされますので、それで再起動して試していただければ幸いです。
> restore-kernel で B 面に現在のソフトウェアを保存しますので、確認ができたら「abos-ctrl rollback --allow-downgrade --reboot」で前のバージョンに戻れます（試す間に swu 等でB面を書き込むと戻れなくなりますのでご了承ください）
ありがとうございます。
最新のカーネルに更新いたします。
> また、参考までにカーネルをビルドした理由を教えていただけますか？
> 場合によっては通常のカーネルのオプションを変更できますので、参考にさせてください。
カーネルをビルドしている理由は二つあります。
一つはFTDIのUSBドライバを対応させるためです。
ftdi_sio.cを編集して、以下のデバイスを追加しています。
VID: 0x150E, PID: 0x0018
二つ目はWatchDogTimerの出力ログを抑制するためです。
アプリケーションから定期的にWDTをキックするたびに以下のログが出力されます。
watchdog did not stop!
watchdog_dev.cの該当箇所をコメントアウトしてしまっています。
以上、よろしくお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| messages.txt |
at_dominique.m…
2024年9月18日 17時05分
s.kurachiさん
マルティネです
> > * hostapd が起動されているかどうか：「ps aux|grep hostapd」
> hostapdは起動していませんでした。これが原因ですね。
>
> > * hostapd サービス再起動で復帰するかどうか：「rc-service hostapd restart」
> hostapdサービスを起動することでSSIDが表示されるようになり、復帰しました！
複雑な操作が不要でよかったです！
> SSIDが表示されない症状が出ているときの、起動してからの/var/log/messagesを添付いたします。
> この時、hostapdのサービスは立ち上がっていませんでした。
ログありがとうございます。
見たところで、hostapd の起動が早すぎて、wifi ドライバの初期化処理がまだ終わってなかったころにリトライを諦めただけですね…
電源切断の後に起動処理が遅いかもしれません？ 38秒もかかってしまったみたいですね、そこまで遅いのは初めてみました。
/etc/conf.d/hostapd ファイルを編集して supervise-daemon のオプションを変更すれば自動的に起動するようになります。
この行 supervise_daemon_args="--respawn-delay 3" を supervise_daemon_args="--respawn-delay 10 --respawn-max 0" に変更してみてください。 (デフォルトは 10 回しか起動させませんが、リトライ数を無限にして、リトライの間の時間を3秒から10秒へ増やしました）
> > また、参考までにカーネルをビルドした理由を教えていただけますか？
> > 場合によっては通常のカーネルのオプションを変更できますので、参考にさせてください。
> カーネルをビルドしている理由は二つあります。
共有ありがとうございます。
> 一つはFTDIのUSBドライバを対応させるためです。
> ftdi_sio.cを編集して、以下のデバイスを追加しています。
> VID: 0x150E, PID: 0x0018
ono sokkiさんの何かのデバイスですね。
アップストリームされないので、勝手に弊社のカーネルには入れにくいと思います（何か別のデバイスが動かなくなるなどの恐れ）ので、ちょっと時間かかりますが一度そちらに問い合わせしてからアップストリームに出して、ようやく弊社のカーネルにも入れれます。
しばらくは自分でビルドした方がよさそうですね…
> 二つ目はWatchDogTimerの出力ログを抑制するためです。
> アプリケーションから定期的にWDTをキックするたびに以下のログが出力されます。
>
> watchdog did not stop! >
> watchdog_dev.cの該当箇所をコメントアウトしてしまっています。
本題から離れますが、こちらについては watchdog の使い方として問題があるかもしれません。
このメッセージは、/dev/watchdog0 を close する時に、「watchdog を止めれなかったからカーネル側で watchdog を制御しますよ」というお知らせです。
なので、アプリでしばらくキックしなくても wdt がタイムアウトしません。
アプリで wdt を開いて、キックしてすぐクロースすると意味はないので、アプリでずっと wdt を開いておいて適切なタイミングでキックしているのであれば、このメッセージが表示することはないです（再起動前など、アプリを停止するぐらいです）
よろしくお願いします
s.kurachi
2024年9月18日 17時51分
マルティネさま
> ログありがとうございます。
> 見たところで、hostapd の起動が早すぎて、wifi ドライバの初期化処理がまだ終わってなかったころにリトライを諦めただけですね…
> 電源切断の後に起動処理が遅いかもしれません？ 38秒もかかってしまったみたいですね、そこまで遅いのは初めてみました。
ありがとうございます。
起動が遅れているのは他のデバイス等の影響なんでしょうかね。
> /etc/conf.d/hostapd ファイルを編集して supervise-daemon のオプションを変更すれば自動的に起動するようになります。
>
> この行 > supervise_daemon_args="--respawn-delay 3" > を > supervise_daemon_args="--respawn-delay 10 --respawn-max 0" > に変更してみてください。 > (デフォルトは 10 回しか起動させませんが、リトライ数を無限にして、リトライの間の時間を3秒から10秒へ増やしました） >
こちら試したところ、電源を切断してもSSIDが表示されなくなることはなくなりました。
ありがとうございます。
> ono sokkiさんの何かのデバイスですね。
> アップストリームされないので、勝手に弊社のカーネルには入れにくいと思います（何か別のデバイスが動かなくなるなどの恐れ）ので、ちょっと時間かかりますが一度そちらに問い合わせしてからアップストリームに出して、ようやく弊社のカーネルにも入れれます。
>
> しばらくは自分でビルドした方がよさそうですね…
おっしゃる通り、ono sokkiさんのデバイスです。
これまで通りリビルドして対応します。
> 本題から離れますが、こちらについては watchdog の使い方として問題があるかもしれません。
> このメッセージは、/dev/watchdog0 を close する時に、「watchdog を止めれなかったからカーネル側で watchdog を制御しますよ」というお知らせです。
> なので、アプリでしばらくキックしなくても wdt がタイムアウトしません。
> アプリで wdt を開いて、キックしてすぐクロースすると意味はないので、アプリでずっと wdt を開いておいて適切なタイミングでキックしているのであれば、このメッセージが表示することはないです（再起動前など、アプリを停止するぐらいです）
アプリの実装を確認したところ、キックするたびにファイルを閉じるようになっていました。
こちらの実装を見直そうと思います。
ありがとうございます。
もう一点お聞きしたいのですが、
wifi1の有効無効状態の確認について、nmcliコマンドでのbr_apのstatusは無関係ということでした。
wifiの状態を確認するにはどのステータスを参照するのが正しいのでしょうか？
ご教示ください。よろしくお願いいたします。
at_dominique.m…
2024年9月18日 18時16分
> > 見たところで、hostapd の起動が早すぎて、wifi ドライバの初期化処理がまだ終わってなかったころにリトライを諦めただけですね…
> > 電源切断の後に起動処理が遅いかもしれません？ 38秒もかかってしまったみたいですね、そこまで遅いのは初めてみました。
>
> ありがとうございます。
> 起動が遅れているのは他のデバイス等の影響なんでしょうかね。
はい、待つ理由が分かりませんが USB に接続されているストレージ(sda)が何かのエラー・タイムアウトをしていて、wifi の初期化がそれの復帰を待っていたように見えます。（ファームウェアを eMMC から読み取るコードの対応かもしれません？）
> もう一点お聞きしたいのですが、
> wifi1の有効無効状態の確認について、nmcliコマンドでのbr_apのstatusは無関係ということでした。
はい
> wifiの状態を確認するにはどのステータスを参照するのが正しいのでしょうか？
雑な確認方法でよければ、hostapd が実行されているかどうかでいいと思います。
何かの問題があれば大体停止されますが、新しい /etc/conf.d/hostapd の設定で永遠に起動され直しますので、その問題がなくなります…
細かいところまでみると hostapd からステータスをもらえます
armadillo:~# hostapd_cli status Selected interface 'uap0' state=ENABLED [...省略]
state=ENABLED で正常です。
よろしくお願いします。
s.kurachi
2024年9月18日 18時21分
マルティネさま
> 雑な確認方法でよければ、hostapd が実行されているかどうかでいいと思います。
> 何かの問題があれば大体停止されますが、新しい /etc/conf.d/hostapd の設定で永遠に起動され直しますので、その問題がなくなります…
>
> 細かいところまでみると hostapd からステータスをもらえます
>
> armadillo:~# hostapd_cli status > Selected interface 'uap0' > state=ENABLED > [...省略] >
> state=ENABLED で正常です。
>
> よろしくお願いします。
そのように確認するようにします。
ご対応、ありがとうございました。
at_dominique.m…
2024年9月17日 18時04分
s.kurachiさん
お世話になっています、
マルティネです。
> GPIO4_IO01を操作して、M.2 インターフェースの電源を制御することで、
> WLANモジュールの再起動ができるのではないかと考えましたが、GPIO4_IO01はResource busyとなって
> gpiodコマンドから制御できませんでした。
regulator で予約していますので、その regulator を外せば制御できます... が、そういうふうに電源を落とすとドライバーは簡単に復帰できませんので、昔 m.2 の disable ピンを制御できる方法を追加して、以下の様にほぼ完全にリセットできます：
ただし、それを自動的に実行できるかって聞かれたら少し違和感ありますので、本件の問題をもう少し調べたいと思います。
（起動時にすでに dis1 のピンが少し assert されているはずですので、ただ時間を長くするなどは考えれますが、それで快活されるかどうかは不明です）
以下の質問を回答いただけますでしょうか？
* ABOS・カーネルのバージョン (cat /etc/atmark-release; uname -r)
* 問い合わせの説明では AP モードと記載していただきましたが、nmcli での connected というのはなんでしょうか？ AP モードの場合は nmcli 上で wifi を無効化していて hostapd で AP を設定しているはずですので、よくわかりませんでした。その不具合の発生する armadillo で hostapd を起動していて、そこにエラーがないですが他の機器から scan を行っても SSID が見えないじょうたいでよろしいですね？
また、hostapd サービスのリスタートで復帰しないですね？コンソールで「hostapd -d /etc/hostapd/hostapd.conf」でデバグ出力を有効にした実行例があればみてみたいです。
* 本件の不具合は再現できますか？それか一度実際に発生しただけですか？再現できる場合に電源が切断されている時間の長さに影響ありますか？（すみません、まだ試してませんが、こちらの環境でも電源を切ってる場合があってそういう不具合は確認してません。APモードだけの問題でしたら気づかない可能性が高いですが、ひとまず確認していただければ助かります）
よろしくお願いします