inokuchi
2024年12月13日 16時16分
==========
製品型番：AGL3100-C13Z
Debian/ABOSバージョン：Debian12(bookworm)
カーネルバージョン：6.1.91-at5
3G/LTE モジュール情報 (Debianのみ)：
その他：
==========
armadillo内にWEBサーバーを作成し、wifi経由でPCからarmadilloにIPアドレスとポート番号を指定してダッシュボードアクセスするシステムを遠隔地で動作させています。
1,2か月ほど動作せていましたが途中でダッシュボードにアクセスできなくなり、ある日アクセスできるようになるという事例が発生しました。
アクセスできるようになった要因は、再起動をさせるソフトを入れていてそれが動作したからなのかなと思っています。
NetworkManagerのログを添付しますので、アクセスできなくなった原因をご教授いただきたく存じます。
| ファイル | ファイルの説明 |
|---|---|
| NetworkManagerログ.txt |
コメント
inokuchi
> 1. WEBサーバーにアクセスするタイミングとModemManagerのログでDISCONNECTEDになっているタイミングは一致するでしょうか？
> こちらはArmadilloに対してデバイスからpingした内容のログをとってみる、反対にArmadilloからデバイスにpingした内容のログをとるなどの方法が考えれます。
$logFilePath = "C:\pinglog.txt"
$targetIP = "192.168.128.103"
try {
while ($true) {
$pingResult = ping $targetIP -n 1 | Select-Object -Last 1
$timestamp = (Get-Date -Format 'yyyy/MM/dd HH:mm:ss')
$responseTime = ($pingResult -split 'time=')[1] -replace 'ms', ''
$ttl = ($pingResult -split 'TTL=')[1] -replace ' ', ''
# 文字列の結合部分に注意
Add-Content -Path $logFilePath -Value "$timestamp $targetIP $responseTime ms TTL=$ttl"
Start-Sleep -Seconds 1
}
} catch {
Write-Warning "処理が中断されました。"
}windowsPCで上記スクリプトを作成して、powershellで実行したら問題なくログは保存されますか。
>
> 2. wifiとのリンクの状態をログとして記録して頂けますでしょうか？
> 以下のコマンドで受信信号強度（signal）を確認できます。
>
> iw dev wlan0 link >
本現象が起こった機体をいま操作できない状況にあるため、ログの抽出を行った際に「nmcli dev wifi」で電波強度を確認した際の結果を添付いたします。
>
> 3. カーネル側が何かしらエラーを出力している可能性もあるので、その内容も確認して頂けますでしょうか？
> journalctl -k 実行するとカーネルログが出力されます。
> DISCONNECTEDになったタイミングの前後で何かしらのトラブルが発生していないか確認して頂ければ幸いです。
本現象が起こったものと同じシステムのものを準備して社内で動作確認を行っています。
社内で動作確認を行っているものでも2024/12/20 14:12:58,14:13:00で「～～ -> DISCONNECTED」の表記になっており、その時間の「journalctl -k」の結果を確認しましたが、特にトラブルが発生しているようには見えませんでした。
「journalctl -k」の結果も添付します。
以上、ご確認よろしくお願いいたします
| ファイル | ファイルの説明 |
|---|---|
| nmcli dev wifi結果.txt | |
| journalctl-k.txt |
at_satoshi.ohta
太田です。
ログを添付していただきありがとうございます。
> windowsPCで上記スクリプトを作成して、powershellで実行したら問題なくログは保存されますか。
実際に実行してみて、pinglog.txtの中身はどうなっているでしょうか？
実行結果例を教えて頂ければ幸いです。
> 本現象が起こった機体をいま操作できない状況にあるため、ログの抽出を行った際に「nmcli dev wifi」で電波強度を確認した際の結果を添付いたします。
通信状況のログをありがとうございます。このコマンドを実行したタイミングでは通信状況は悪くないように見えます。
こちらも、NetworkManagerにおいてDISCONNECTED（'supplicant-timeout'と'ssid-not-found'と'no-secrets'）になっているタイミングで通信状況のログが取れると分かりやすいのではないかと思います。
社内で動作確認を行っているArmadilloに対して、例えば、以下の内容を記載したシェルスクリプトを実行してログをとるのも一つ手かと思います。
#!/bin/sh
log_file="./log.txt"
# ネットワーク接続を確認できるIPアドレス
ip_address="8.8.8.8"
log_interval_sec=5
[ -f $log_file ] || touch $log_file
while : ;do
date="$(date "+%Y/%m/%d %H:%M:%S")"
signal="$(iw dev wlan0 link | grep "signal")" 2>/dev/nul
signal="${signal:-none}"
echo "$date iw dev wlan0 link: $signal" >> "$log_file"
ping_result="$(ping -c 1 $ip_address | grep "time=")"
ping_result="${ping_result:-DISCONNECTED}"
echo "$date ping: $ping_result" >> "$log_file"
sleep "$log_interval_sec"
done例えば、wifi接続したArmadillo上で上記のスクリプトを作成して実行した結果を以下に示します。
root@armadillo:~# vi log.sh root@armadillo:~# chmod +x log.sh root@armadillo:~# ./log.sh ^C root@armadillo:~# cat ./log.txt 2024/12/23 15:19:26 iw dev wlan0 link: signal: -48 dBm 2024/12/23 15:19:26 ping: 64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=16.6 ms 2024/12/23 15:19:31 iw dev wlan0 link: signal: -47 dBm 2024/12/23 15:19:31 ping: 64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=16.5 ms
Armadilloからのpingとiw dev wlan0 linkの結果をlog.txtに書き込んでいます。
こちらとNetworkManagerのログを比較して、NetworkManagerで'supplicant-timeout'と'ssid-not-found'と'no-secrets'が理由でDISCONNECTEDになっている期間と比較することで状況が少し見えてくるかもしれません。
> 本現象が起こったものと同じシステムのものを準備して社内で動作確認を行っています。
> 社内で動作確認を行っているものでも2024/12/20 14:12:58,14:13:00で「～～ -> DISCONNECTED」の表記になっており、その時間の「journalctl -k」の結果を確認しましたが、特にトラブルが発生しているようには見えませんでした。
> 「journalctl -k」の結果も添付します。
journalctl -kの結果も特にerrorやfailedもなくトラブルがないように見えます。
社内で準備したシステムでDISCONNECTEDになった時のNetworkManagerのログは同様に、'supplicant-timeout'と'ssid-not-found'と'no-secrets'が理由でDISCONNECTEDになっているのでしょうか？
どうぞよろしくお願いいたします。
inokuchi
> 太田です。
>
> ログを添付していただきありがとうございます。
>
>
> 実際に実行してみて、pinglog.txtの中身はどうなっているでしょうか？
> 実行結果例を教えて頂ければ幸いです。
PCとarmadilloでそれぞれ実行したpingの疎通と電波強度を確認するスクリプトの実行結果を添付します。(PC側：pinglog.txt、armadillo側：wifilog.txt)
内容を見た感じ、社内での動作ではpingの応答がない時もありましたが大きな問題があるようには見えませんでした。
>
> 通信状況のログをありがとうございます。このコマンドを実行したタイミングでは通信状況は悪くないように見えます。
> こちらも、NetworkManagerにおいてDISCONNECTED（'supplicant-timeout'と'ssid-not-found'と'no-secrets'）になっているタイミングで通信状況のログが取れると分かりやすいのではないかと思います。
> 社内で動作確認を行っているArmadilloに対して、例えば、以下の内容を記載したシェルスクリプトを実行してログをとるのも一つ手かと思います。
>
> #!/bin/sh
>
> log_file="./log.txt"
> # ネットワーク接続を確認できるIPアドレス
> ip_address="8.8.8.8"
> log_interval_sec=5
>
> [ -f $log_file ] || touch $log_file
>
> while : ;do
> date="$(date "+%Y/%m/%d %H:%M:%S")"
> signal="$(iw dev wlan0 link | grep "signal")" 2>/dev/nul
> signal="${signal:-none}"
> echo "$date iw dev wlan0 link: $signal" >> "$log_file"
> ping_result="$(ping -c 1 $ip_address | grep "time=")"
> ping_result="${ping_result:-DISCONNECTED}"
> echo "$date ping: $ping_result" >> "$log_file"
> sleep "$log_interval_sec"
> done
> >
> 例えば、wifi接続したArmadillo上で上記のスクリプトを作成して実行した結果を以下に示します。
>
> root@armadillo:~# vi log.sh > root@armadillo:~# chmod +x log.sh > root@armadillo:~# ./log.sh > ^C > root@armadillo:~# cat ./log.txt > 2024/12/23 15:19:26 iw dev wlan0 link: signal: -48 dBm > 2024/12/23 15:19:26 ping: 64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=16.6 ms > 2024/12/23 15:19:31 iw dev wlan0 link: signal: -47 dBm > 2024/12/23 15:19:31 ping: 64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=16.5 ms >
> Armadilloからのpingとiw dev wlan0 linkの結果をlog.txtに書き込んでいます。
>
> こちらとNetworkManagerのログを比較して、NetworkManagerで'supplicant-timeout'と'ssid-not-found'と'no-secrets'が理由でDISCONNECTEDになっている期間と比較することで状況が少し見えてくるかもしれません。
>
> journalctl -kの結果も特にerrorやfailedもなくトラブルがないように見えます。
> 社内で準備したシステムでDISCONNECTEDになった時のNetworkManagerのログは同様に、'supplicant-timeout'と'ssid-not-found'と'no-secrets'が理由でDISCONNECTEDになっているのでしょうか？
社内で動作確認しているものでは、「NetworkManager state is now DISCONNECTED」の記載が二か所あり、'ssid-not-found'と'no-secrets'が理由でDISCONNECTEDになっておりました。pingのログを取り始めてからは「NetworkManager state is now DISCONNECTED」になっていないので比較はできていません。
(遠隔地に置いている方の一時期wifiでの接続ができなくなったarmadilloのsyslogについて)
Networkmanagerのログ内に「device (wlan0): state change: ～～ -> disconnected (reason '～～', sys-iface-state: '～～')」の記載が複数みられるのですが、これはwifiが切断されたログではなく、特に問題ないのでしょうか。
また、2024/11/08/16:19:08に「NetworkManager-dispatcher.service: Deactivated successfully.」とあり、これ以降一定期間networkmanagerのログがないのですが、これはNetworkmanagerのサービスが停止してしまっているという認識で問題ないですか。サービスが停止してしまっている場合、なぜ停止してしまったのでしょうか。
上記の2024/11/08/16:19:08のログの後に下記の何かに失敗しているログが多数見受けられたのですが、これはNetworkmanagerが停止してしまっているからでしょうか。またはwifiが切断される要因になるものでしょうか。wifi切断の原因であるならこれは起きている理由もご教示ください。
「wpa_supplicant[1446]: dbus: fill_dict_with_properties dbus_interface=fi.w1.wpa_supplicant1.BSS dbus_property=RSN getter failed
wpa_supplicant[1446]: dbus: wpa_dbus_get_object_properties: failed to get object properties: (org.freedesktop.DBus.Error.Failed) failed to parse RSN IE
wpa_supplicant[1446]: dbus: Failed to construct signal」
遠隔地に置いている方の一時期wifiでの接続ができなくなったarmadilloのsyslogを添付いたします。ご確認お願いいたします。
以上、よろしくお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| pinglog.txt | 社内でPCで実行したpingの疎通を確認するスクリプトのログ |
| wifilog.txt | 社内でarmadilloで実行したpingの疎通と電波強度を確認するスクリプトのログ |
| syslog.txt | 遠隔地に置いている方のarmadilloのsyslog |
at_satoshi.ohta
太田です。
ログを添付して頂きありがとうございます。
> 社内で動作確認しているものでは、「NetworkManager state is now DISCONNECTED」の記載が二か所あり、'ssid-not-found'と'no-secrets'が理由で
> DISCONNECTEDになっておりました。pingのログを取り始めてからは「NetworkManager state is now DISCONNECTED」になっていないので比較はできて
> いません。
申し訳ありません。ネットワークが繋がらない状況を再現して「NetworkManager state is now DISCONNECTED」が発生した時間をログで比較したかったのですが、そのログが無いと、頂いたwifilog.txtとpinglog.txtからはなんとも言えないです。
ただ、wifilog.txtを拝見しましたが、
「2024/12/26 08:59:03 iw dev wlan0 link: signal: -54 dBm」以降はsignalがとれていますが、
それ以前は「2024/12/26 08:58:58 iw dev wlan0 link: none」となっておりsignalがとれていないにも関わらず、pingが成功していることが気になりました。
wlan0は受信できていないのにpingが取れている？という状況を想像するのですが、wlan0以外で実はネットワークに繋がっていてpingが成功していたという可能性はありますでしょうか？
遠隔地に置いている方のarmadilloのsyslog.txtを提供して頂きありがとうございます。
こちらは一番はじめに頂いた「NetworkManagerログ.txt」の内容も含まれているログですね。
> (遠隔地に置いている方の一時期wifiでの接続ができなくなったarmadilloのsyslogについて)
> Networkmanagerのログ内に「device (wlan0): state change: ～～ -> disconnected (reason '～～', sys-iface-state: '～～')」の記載が複数みられるので
> すが、これはwifiが切断されたログではなく、特に問題ないのでしょうか。
これはwifiの接続が切られた際に生じるログで「NetworkManagerログ.txt」で表示されていたものと同じものだと思います。
> また、2024/11/08/16:19:08に「NetworkManager-dispatcher.service: Deactivated successfully.」とあり、これ以降一定期間networkmanagerのログが
> ないのですが、これはNetworkmanagerのサービスが停止してしまっているという認識で問題ないですか。サービスが停止してしまっている場合、なぜ停止し
> てしまったのでしょうか。
NetworkManager-dispatcher.serviceについて調べてみると、ネットワークイベントが発生した場合に、ユーザーが提供したスクリプトを実行するサービスのようです。
どのようなスクリプトが実行されているかは調べていませんが、
2024-11-08T16:18:58.110622+09:00 armadillo systemd[1]: Started NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service. ... 2024-11-08T16:19:08.259849+09:00 armadillo systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
となり、NetworkManager-dispatcher.serviceが起動した後、正常にNetworkManager-dispatcher.serviceが終了しているように見えます。
リブートを行ったであろう「2024-11-25T14:23:48」の直前に、
2024-11-25T14:22:05.683251+09:00 armadillo NetworkManager[1427]: <info> [1732512125.6812] modem-manager: NetworkManager no longer available
とあるので、Networkmanagerのサービスは起動していたけれどもログに現れなかっただけだと考えています。
> 上記の2024/11/08/16:19:08のログの後に下記の何かに失敗しているログが多数見受けられたのですが、これはNetworkmanagerが停止してしまっているから
> でしょうか。またはwifiが切断される要因になるものでしょうか。wifi切断の原因であるならこれは起きている理由もご教示ください
>「wpa_supplicant[1446]: dbus: fill_dict_with_properties dbus_interface=fi.w1.wpa_supplicant1.BSS dbus_property=RSN getter failed
> wpa_supplicant[1446]: dbus: wpa_dbus_get_object_properties: failed to get object properties: (org.freedesktop.DBus.Error.Failed) failed to
> parse RSN IE
> wpa_supplicant[1446]: dbus: Failed to construct signal」
すみません、こちらのログの原因はよく分かりませんが、「2024-11-25T14:23:48」のリブートした後も発生しているようです。
以下のログのようにNetworkManagerが起動しているにもかかわらず発生しているので少なくともNetworkManagerは停止していないと思われます。
2024-11-29T19:57:10.497431+09:00 armadillo NetworkManager[1317]: <info> [1732877830.4962] device (p2p-dev-wlan0): supplicant management interface state: 4way_handshake -> completed 2024-11-29T21:28:40.919969+09:00 armadillo wpa_supplicant[1331]: dbus: fill_dict_with_properties dbus_interface=fi.w1.wpa_supplicant1.BSS dbus_property=RSN getter failed
こちらでもsyslog.txtの中身を基に調査してみました。
以下、ご参考になれば幸いです。
syslog.txtから、NetworkManager, wpa_supplicantとkernelのwlcoreの接続の成否に関連していそうな部分を抜き出したログ(extract_NetworkManager_wpa_supplicant.txt）を添付しました。
直接的な解決策を見つけることはできませんでしたが、これを見ていて、以下のパターンが多くあることに気づきました。
wpa_supplicant[1404]: wlan0: CTRL-EVENT-BEACON-LOSS kernel: [1420457.755367] wlcore: Beacon loss detected. roles:0x1 kernel: [1420460.967595] wlcore: Connection loss work (role_id: 0). kernel: [1420460.972948] wlan0: Connection to AP 76:3a:1e:83:72:46 lost wpa_supplicant[1404]: wlan0: CTRL-EVENT-DISCONNECTED bssid=76:3a:1e:83:72:46 reason=4 locally_generated=1 NetworkManager[1390]: <info> [1730601413.4656] device (wlan0): supplicant interface state: associating -> 4way_handshake wpa_supplicant[1404]: wlan0: WPA: Key negotiation completed with 76:3a:1e:83:72:46 [PTK=CCMP GTK=CCMP] wpa_supplicant[1404]: wlan0: CTRL-EVENT-CONNECTED - Connection to 76:3a:1e:83:72:46 completed [id=0 id_str=]
これをみると、
APが発信しているBeaconの検出ができなくなった後にAPとのコネクションを失うものの、
NetworkManagerが4way_handshakeを行い、接続をし直しているように見えます。
この挙動は数分以内に復帰することが多いようです。
また、リブートを行ったであろう「2024-11-25T14:23:48」以降も見られます。
CTRL-EVENT-DISCONNECTEDにおいて「reason=4」という理由で発生しているパターンに以下の状態もありました。
同じように、
kernel: [1573977.395056] wlan0: disassociated from 76:3a:1e:83:72:46 (Reason: 4=DISASSOC_DUE_TO_INACTIVITY) wpa_supplicant[1404]: wlan0: CTRL-EVENT-DISCONNECTED bssid=76:3a:1e:83:72:46 reason=4 NetworkManager[1390]: <info> [1730754923.3435] device (wlan0): supplicant interface state: associating -> associated wpa_supplicant[1404]: wlan0: WPA: Key negotiation completed with 76:3a:1e:83:72:46 [PTK=CCMP GTK=CCMP] wpa_supplicant[1404]: wlan0: CTRL-EVENT-CONNECTED - Connection to 76:3a:1e:83:72:46 completed [id=0 id_str=]
「Reason: 4=DISASSOC_DUE_TO_INACTIVITY」という理由が書いているため、調べてみるとアットマークテクノのサイトではないですが、以下のサイトを見つけました。
https://www.allied-telesis.co.jp/support/list/faq/wireless/list/qa/qa_a…
これによると、APから見た時に無線端末が非アクティブになっているため接続を解除したようです。
また、「NetworkManager state is now DISCONNECTED」についてですが、
'ssid-not-found'の場合、
kernel: [96190.345066] wlcore: Beacon loss detected. roles:0x1 kernel: [96195.207642] wlcore: Connection loss work (role_id: 0). kernel: [96195.213123] wlan0: Connection to AP 76:3a:1e:83:72:46 lost wpa_supplicant[1446]: wlan0: CTRL-EVENT-DISCONNECTED bssid=76:3a:1e:83:72:46 reason=4 locally_generated=1 # syslog.txtを見ると何かしらやり取りした後 NetworkManager[1427]: <warn> [1730949799.1537] device (wlan0): link timed out. NetworkManager[1427]: <info> [1730949799.1607] device (wlan0): state change: activated -> failed (reason 'ssid-not-found', sys-iface-state: 'managed') NetworkManager[1427]: <info> [1730949799.1647] manager: NetworkManager state is now DISCONNECTED NetworkManager[1427]: <info> [1730887778.4282] device (wlan0): supplicant interface state: associating -> 4way_handshake wpa_supplicant[1446]: wlan0: WPA: Key negotiation completed with 76:3a:1e:83:72:46 [PTK=CCMP GTK=CCMP] wpa_supplicant[1446]: wlan0: CTRL-EVENT-CONNECTED - Connection to 76:3a:1e:83:72:46 completed [id=0 id_str=]
'supplicant-timeout'の場合、
wpa_supplicant[1446]: wlan0: CTRL-EVENT-BEACON-LOSS kernel: [175031.413842] wlcore: Beacon loss detected. roles:0x1 kernel: [175033.287648] wlcore: Connection loss work (role_id: 0). kernel: [175033.292915] wlan0: Connection to AP 76:3a:1e:83:72:46 lost wpa_supplicant[1446]: wlan0: CTRL-EVENT-DISCONNECTED bssid=76:3a:1e:83:72:46 reason=4 locally_generated=1 NetworkManager[1427]: <info> [1731028628.3886] device (wlan0): supplicant interface state: associating -> disconnected # syslog.txtを見ると何かしらやり取りした後 NetworkManager[1427]: <warn> [1731028637.1558] device (wlan0): link timed out. NetworkManager[1427]: <info> [1731028637.1601] device (wlan0): state change: activated -> failed (reason 'supplicant-timeout', sys-iface-state: 'managed') NetworkManager[1427]: <info> [1731028637.1647] manager: NetworkManager state is now DISCONNECTED NetworkManager[1427]: <info> [1731028658.0050] device (wlan0): supplicant interface state: associating -> 4way_handshake wpa_supplicant[1446]: wlan0: WPA: Key negotiation completed with 76:3a:1e:83:72:46 [PTK=CCMP GTK=CCMP] wpa_supplicant[1446]: wlan0: CTRL-EVENT-CONNECTED - Connection to 76:3a:1e:83:72:46 completed [id=0 id_str=]
となり、初めの原因は「CTRL-EVENT-BEACON-LOSS」が多いようにみえます。
ですが、その後はコネクションを回復しています。
また、接続が切られる理由に、
kernel: [129733.844258] wlan0: deauthenticated from 76:3a:1e:83:72:46 (Reason: 6=CLASS2_FRAME_FROM_NONAUTH_STA) wpa_supplicant[1446]: wlan0: CTRL-EVENT-DISCONNECTED bssid=76:3a:1e:83:72:46 reason=6 NetworkManager[1427]: <info> [1730983322.6042] device (wlan0): supplicant interface state: associating -> 4way_handshake wpa_supplicant[1446]: wlan0: WPA: Key negotiation completed with 76:3a:1e:83:72:46 [PTK=CCMP GTK=CCMP] wpa_supplicant[1446]: wlan0: CTRL-EVENT-CONNECTED - Connection to 76:3a:1e:83:72:46 completed [id=0 id_str=]
「Reason: 6=CLASS2_FRAME_FROM_NONAUTH_STA」というのもありました。
これは、上記のサイトによると「認証されていない無線端末からクラス２フレームを受信しました。」とのことでした。
認証していない端末から何かしらのデータが送られてきたことが原因？だと考えられます。
改めてフォーラムの初めに立ち返ると、ダッシュボードにアクセスできないことが問題だったと思います。
現在でも遠隔地のArmadilloでアクセスできない状況は発生しているでしょうか？
もし、アクセスできない状況が発生しているならば、syslogを見比べることができる精度でその状況の時の正確な日時が分かれば、もう少し詳しく調査できると思います。
どうぞよろしくお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| extract_NetworkManager_wpa_supplicant.txt | syslog.txtからwifi接続の成否に関連しそうな部分を抽出 |
at_dominique.m…
横からすみません。
マルティネです。
太田さんの指摘はほとんど正しいで、疑問はいくつかありますが、今回の問題の原因は「no-secrets」の NetworkManager のエラーだと思われます。
前回いただいた syslog も今回いただいた syslog でも、接続が失敗した後に NetworkManager が再接続を試して復帰はしますが、最後のエラーだけ「no-secrets」と言う違う原因が表示されていて、その後にもうリトライしないように見えます。
その状態で再起動せずに NetworkManager サービスをリスタートすると復帰できると思いますので、ひとまずの回避方法としては定期的に接続状態を確認して接続ない場合かつそのログを確認できた場合などの条件で systemctl restart NetworkManager を実行すれば復帰できると思います。
根本的な原因は分かりませんが、少し調べた結果ドライバの問題等で接続できなかった場合にまれに起きる問題らしいです。
今回は他の怪しいメッセージも多くて（regulatory domain の変更や wpa_supplicant の dbus エラー）、経験からするとエラーがまた別にあるかもしれませんおで、ひとまず回避方法でちゃんと復帰できるところからお願いします。
NetworkManager のリスタートで復帰できることを確認できたら、別のワークアラウンド（NetworkManager内でリトライさせる対応など）をNetworkManagerの開発者に相談しながら考えてみたいと思います。
よろしくお願いします。
at_satoshi.ohta
2024年12月16日 18時05分
太田です。
提供していただいたログをみると、NetworkManagerの状態がDISCONNECTEDになる直前に以下のパターンがあるようです。
そのため、DISCONNECTEDしている理由としては、'supplicant-timeout'と'ssid-not-found'と'no-secrets'の３つがあるようにみえます。
以下の３点を状況確認していただいてもよろしいでしょうか？
1. WEBサーバーにアクセスするタイミングとModemManagerのログでDISCONNECTEDになっているタイミングは一致するでしょうか？
こちらはArmadilloに対してデバイスからpingした内容のログをとってみる、反対にArmadilloからデバイスにpingした内容のログをとるなどの方法が考えれます。
2. wifiとのリンクの状態をログとして記録して頂けますでしょうか？
以下のコマンドで受信信号強度（signal）を確認できます。
3. カーネル側が何かしらエラーを出力している可能性もあるので、その内容も確認して頂けますでしょうか？
journalctl -k 実行するとカーネルログが出力されます。
DISCONNECTEDになったタイミングの前後で何かしらのトラブルが発生していないか確認して頂ければ幸いです。
どうぞよろしくお願いいたします。