kirihara
2024年1月29日 15時08分
Armadillo IoT A6E （AG6271）のLTE通信についてです。
当該機器で、長時間LTE通信を継続的に動作させていると、LTE通信が途中で切れてしまう事象が発生します。
１度切れた後は、５分程度待機しても通信が復旧せず、Armadilloが再起動すると復旧します。
（アプリケーションにて、５分待機しても通信復旧しなければ再起動するように実装しております。）
本事象が発生したときの/var/log/messagesのログを添付します。
こちらのログからは、ArmadilloのLTE通信にか関して、どのような現象が発生していると考えられますでしょうか。
なお、LTE通信の「自動再起動サービス」は、
FORCE_REBOOT
REBOOT_IF_SIM_NOT_FOUND
を両方とも有効にして、使用しております。
よろしくお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| 【抽出】LTE通信不良_20240126.txt |
コメント
kirihara
2024年1月29日 17時06分
早速のご回答ありがとうございます。
>
> 製品マニュアルに動作詳細を記載しておらず申し訳ありません。
> FORCE_REBOOT を有効にした場合、 ping 導通チェックが 4 回連続 NG だった場合にArmadillo を再起動します。
> ping 導通チェックは初期状態では120 秒間隔で をしておりますので、360 秒 ～ 480 秒の間で Armadillo の再接続を行う動作となります。
>
⇒理解いたしました。
> 添付いただいたログは再接続が成功したパターンと認識いたします。
⇒つまり、
１．最初にpingの導通チェックで失敗を判定
２．LTEのコネクション無効化→有効化を実施
３．LTE通信が復帰
という動作をしている、ということでよいでしょうか？
（この挙動は、FORCE_REBOOT/REBOOT_IF_SIM_NOT_FOUNDの設定とは関係なく動作する…という認識であっていますでしょうか。）
at_mitsuhiro.yoshida
2024年1月29日 17時13分
吉田です。
> ⇒つまり、
> １．最初にpingの導通チェックで失敗を判定
> ２．LTEのコネクション無効化→有効化を実施
> ３．LTE通信が復帰
> という動作をしている、ということでよいでしょうか？
> （この挙動は、FORCE_REBOOT/REBOOT_IF_SIM_NOT_FOUNDの設定とは関係なく動作する…という認識であっていますでしょうか。）
はい、おっしゃるとおりです。
動作概要は製品マニュアル「LTE 再接続サービス」に記載しておりますので、ご確認ください。
https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…
よろしくお願いします。
kirihara
2024年1月30日 16時26分
at_mitsuhiro.yoshida
2024年1月30日 17時05分
吉田です。
> ・ArmadilloのLTE再接続サービスでのpingの導通チェックによる失敗判定ですが、
> 現在はpingが１回失敗した時点でLTEのコネクション無効化/有効化を実施となっています。
> このコネクション無効化/有効化のためのpingの失敗回数を3回連続、5回連続などのように変更することはできるのでしょうか。
標準のものでは対応しておりません。
対応する場合、ソースコード変更する必要がありますが、
ABOS 3.18.6-at.10 時点のソースコードですと、
/usr/bin/connection-recover 内
reconnect を call しているところで新たに変数を追加して判定する
対処を追加する必要があります。
以下の ★ の箇所で別な定義を用意して FORCE_RECONNECT_PING_NG_COUNT の値を 2 より大きな値に設定する様な変更になります。
追加した定義値より PING_NG_COUNT_TMP が大きい場合は reconnect を実施
FORCE_RECONNECT_PING_NG_COUNT より PING_NG_COUNT_TMP が大きい場合は wwan-force-restart を実施
といった動きでしょうか。
*connected*)
SIM_NOT_FOUND_COUNT=0
DEVICE_UNMANAGED_COUNT=0
is_connected
PING_STATUS=$?
if [ $PING_STATUS -ne 0 ]; then
# if reboot or restart wwan, do not reconnect
PING_NG_COUNT_TMP=$((PING_NG_COUNT+1))
★ if [ $PING_NG_COUNT_TMP -lt $FORCE_RECONNECT_PING_NG_COUNT ]; then
reconnect
fi
else
WWAN_RESTART_COUNT=0
fi ;;> ・pingの確認先をIPアドレスは初期では"8.8.8.8"ですが、これを特定にドメイン(URL)に設定することはできるのでしょうか。
DNS が有効な環境でしたら、
/etc/atmark/connection-recover.conf
の PING_DEST_IP にドメインを記載いただければそちらに ping 導通確認を実施します。
kirihara
2024年1月30日 19時58分
吉田様
桐原です。
> > ・ArmadilloのLTE再接続サービスでのpingの導通チェックによる失敗判定ですが、
> > 現在はpingが１回失敗した時点でLTEのコネクション無効化/有効化を実施となっています。
> > このコネクション無効化/有効化のためのpingの失敗回数を3回連続、5回連続などのように変更することはできるのでしょうか。
>
> 標準のものでは対応しておりません。
>
> 対応する場合、ソースコード変更する必要がありますが、
> ABOS 3.18.6-at.10 時点のソースコードですと、
> /usr/bin/connection-recover 内
> reconnect を call しているところで新たに変数を追加して判定する
> 対処を追加する必要があります。
> 以下の ★ の箇所で別な定義を用意して FORCE_RECONNECT_PING_NG_COUNT の値を 2 より大きな値に設定する様な変更になります。
>
> 追加した定義値より PING_NG_COUNT_TMP が大きい場合は reconnect を実施
⇒ありがとうございます。
下記のような感じで修正すると、5回連続のping失敗で再接続をするという認識ですが、
合っていますでしょうか。
#ソースコードの上の方に、以下の変数を定義
EX_FORCE_RECONNECT_PING_NG_COUNT=6
#----途中割愛-----
*connected*)
SIM_NOT_FOUND_COUNT=0
DEVICE_UNMANAGED_COUNT=0
is_connected
PING_STATUS=$?
if [ $PING_STATUS -ne 0 ]; then
# if reboot or restart wwan, do not reconnect
PING_NG_COUNT_TMP=$((PING_NG_COUNT+1))
★ if [ $PING_NG_COUNT_TMP -lt $EX_FORCE_RECONNECT_PING_NG_COUNT ]; then
reconnect
fi
else
WWAN_RESTART_COUNT=0
fi ;;
★部分の「FORCE_RECONNECT_PING_NG_COUNT」を「EX_FORCE_RECONNECT_PING_NG_COUNT」に変更
（一応、修正後のソースコードも添付します。）
> FORCE_RECONNECT_PING_NG_COUNT より PING_NG_COUNT_TMP が大きい場合は wwan-force-restart を実施
> といった動きでしょうか。
>
⇒「wwan-force-restart」の方は、PING_NG_COUNTが設定ファイルのWWAN_FORCE_RESTART_COUNTを超えたら動作する…という認識です。
合っていますでしょうか。
よろしくお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| connection-recover.txt |
kirihara
2024年2月5日 11時39分
桐原です。
> そうですね、EX_FORCE_RECONNECT_PING_NG_COUNT までは
> reconnect (nmcli の up/down) を実施するのであればこれでいいかと思われます。
ご確認ありがとうございました。
"EX_FORCE_RECONNECT_PING_NG_COUNT"分だけ連続して、pingが失敗したときにreconnect (nmcli の up/down) を実施したいと思っていましたので、
改修方法が違ったようです。
その場合は、下記のようになりますかね。
*connected*) SIM_NOT_FOUND_COUNT=0 is_connected PING_STATUS=$? if [ $PING_STATUS -ne 0 ]; then # if reboot or restart wwan, do not reconnect PING_NG_COUNT_TMP=$((PING_NG_COUNT+1)) ★ if [ $PING_NG_COUNT_TMP -ge $EX_FORCE_RECONNECT_PING_NG_COUNT ]; then reconnect fi else WWAN_RESTART_COUNT=0 fi ;;
★の箇所の条件判定式を "-lt" から "-ge" にしました。
すみませんが、よろしくお願いいたします。
at_mitsuhiro.yoshida
2024年2月5日 14時45分
kirihara
2024年3月18日 8時43分
吉田様
LTE 再接続サービスの実装に変更を加えて上で、動作検証を行っていたところ、以下のような不具合が発生しました。
(AG6271/BaseOSはver3.18.5-at8)
原因および対処方法について、教えていただけますでしょうか。
発生事象（添付しているログ(/var/log/messages)の1006行目～1948行目です。）
１．Armadilloの電源を投入
２．LTE再接続サービスにより、Armadilloが自動で再起動される
（SYSランプ点灯、WWANランプ消灯状態であったことから、SIMカードが認識できずに再起動されたと判断）
（添付ログの1501行目～）
３．再起動後も再びSYSランプ点灯、WWANランプ消灯の状態となったが、1時間程度待機しても、再起動されず。
（再び、LTE再接続サービスによって、自動で再起動される…という動作を期待していました。）
LTE再起動サービスについては、/usr/bin/connection-recover 内の以下の箇所を変更しています。
#!/bin/sh
# SPDX-License-Identifier: MIT
LANG=C
PING_COUNT=2
FORCE_RECONNECT_PING_NG_COUNT=2
FORCE_REBOOT_PING_NG_COUNT=$((FORCE_RECONNECT_PING_NG_COUNT+1)) #起動時にsimを読みとれないときの再起動を早めるために、"+2"を"+1"に変更。
CONFIG_FILE_EXT=_connection-recover.conf
NEW_CONFIG_FILE=/etc/atmark/connection-recover.conf
OLD_CONFIG_FILE_DIR=/etc/atmark/connection-recover/
NMCLI_UP_TIMEOUT_SEC=150
RESTART_SIM_NOT_FOUND_COUNT=2
EX_FORCE_RECONNECT_PING_NG_COUNT=3 #Ping失敗時のRECONNECTを連続3回失敗時にするために、変数を追加
#----途中割愛-----
*connected*)
SIM_NOT_FOUND_COUNT=0
DEVICE_UNMANAGED_COUNT=0
is_connected
PING_STATUS=$?
if [ $PING_STATUS -ne 0 ]; then
# if reboot or restart wwan, do not reconnect
PING_NG_COUNT_TMP=$((PING_NG_COUNT+1))
★ if [ $PING_NG_COUNT_TMP -lt $EX_FORCE_RECONNECT_PING_NG_COUNT ]; then #Ping失敗時のRECONNECTを連続3回失敗時にするために、条件を追加
reconnect
fi
else
WWAN_RESTART_COUNT=0
fi ;;なにとぞ、よろしくお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| 【抜粋】messages_20240315_3.txt |
kirihara
2024年3月18日 14時22分
吉田様
上記の件ですが、Armadillo BaseOSのバージョンが誤っていました。
誤）ver3.18.5-at8
正）ver3.18.5-at4
BaseOSのバージョンアップを行うと改善しますでしょうか？
（下記のアップデートにて改善しているのでしょうか。）
https://armadillo.atmark-techno.com/news/20231226/software-update-aiota…
よろしくお願いいたします
at_mitsuhiro.yoshida
2024年3月18日 16時04分
吉田です。
ログを確認したところ connection-recover 要因というよりは、
再起動時にうまく動作していない様ですので、
バージョン 3.19.1-at.1 を適用頂いたほうが対処になるかと思われます。
こちらで A6E Cat.1 モデル LTE モジュール再起動時の動作改善を実施しております。
Armadillo 製品アップデートのお知らせ (2024年2月/Armadillo-IoT A6E対象 2回目)
https://armadillo.atmark-techno.com/news/20240228/software-update-aiota…
よろしくお願いします。
kirihara
2024年3月18日 17時09分
吉田様
ご連絡ありがとうございました。
とりあえず、バージョン 3.19.1-at.1 を適用し、確認をしてみます。
> ログを確認したところ connection-recover 要因というよりは、
> 再起動時にうまく動作していない様ですので、
> バージョン 3.19.1-at.1 を適用頂いたほうが対処になるかと思われます。
> こちらで A6E Cat.1 モデル LTE モジュール再起動時の動作改善を実施しております。
⇒
差し支えなければ、詳細について教えてください。
・"再起動時にうまく動作していない"というのは、3.19.1-at.1の改善内容に記載されている、poweroff 時のウェイト時間不足に起因するものなのでしょうか。
・上記の不具合が発生した場合には、「LTE再接続サービス」にて回避することはできないのでしょうか。
（"8.8.8.8"へのping失敗判定による再起動などの処理は動かないのでしょうか。）
以上、よろしくお願いいたします。
at_mitsuhiro.yoshida
2024年3月18日 17時25分
吉田です。
> ・"再起動時にうまく動作していない"というのは、3.19.1-at.1の改善内容に記載されている、poweroff 時のウェイト時間不足に起因するものなのでしょうか。
はい、Cat.1 モデルにて LTE モジュールを電源オフとみなす電圧まで低下する前に
Armadillo を再起動していることが判明したため、ウェイトを追加しております。
> ・上記の不具合が発生した場合には、「LTE再接続サービス」にて回避することはできないのでしょうか。
> （"8.8.8.8"へのping失敗判定による再起動などの処理は動かないのでしょうか。）
まだレビュー中なのですが、Cat.M1 モデルへの対応で LTE 接続中が
ずっと続いた場合のワークアラウンドを追加しようとしております。
message の内容を確認したところ、"state is now CONNECTING" になっており、
それ以降状態遷移をしていないので、本件もこのワークアラウンドで対応できると思われます。
kirihara
2024年3月19日 21時59分
> > ・上記の不具合が発生した場合には、「LTE再接続サービス」にて回避することはできないのでしょうか。
> > （"8.8.8.8"へのping失敗判定による再起動などの処理は動かないのでしょうか。）
>
> まだレビュー中なのですが、Cat.M1 モデルへの対応で LTE 接続中が
> ずっと続いた場合のワークアラウンドを追加しようとしております。
>
> message の内容を確認したところ、"state is now CONNECTING" になっており、
> それ以降状態遷移をしていないので、本件もこのワークアラウンドで対応できると思われます。
⇒
ver 3.19.1 at1へと更新した上で動作確認を行っております。
Armadilloに対して、「電源投入状態⇒電源断後、すぐに電源再投入」のような動作をすると、
「/var/log/message」に以下のログはでるものの、結局10分以上待っても、LTE通信ができない＋再起動しないという状態が続きました。
Mar 19 20:32:44 armadillo user.notice connection-recover: device ttyCommModem not found Mar 19 20:33:46 armadillo user.notice connection-recover: exec wwan-force-restart cause device ttyCommModem not found
準備頂いているワークアラウンドにて、この部分は対処できるということでしょうか？
また、暫定的に/usr/bin/connection-recoverの以下の部分を変更して、対応しようと思いますが、問題は考えられますでしょうか？
（195行目～209行目 ）
while true; do
sleep ${CHECK_INTERVAL_SEC}
CONNECTION="${TYPE}-${DEVICE}"
if active_connection_exists; then
PING_STATUS=1
STATUS=$(get_connection_status)
if [ -z "$STATUS" ]; then
nmcli_device_unmanaged_or_not_found "not found"
★ reboot#見つからなかったら即時再起動
fi
★：変更箇所
起動時にLTEモジュールのデバイスが見つからなかった場合には、即時再起動する、という動作を期待しています。
（通常の起動中にLTEモジュールが見つからなくなる…ということは起こりますでしょうか？）
よろしくお願いいたします。
at_mitsuhiro.yoshida
2024年3月21日 16時56分
吉田です。
> ver 3.19.1 at1へと更新した上で動作確認を行っております。
> Armadilloに対して、「電源投入状態⇒電源断後、すぐに電源再投入」のような動作をすると、
> 「/var/log/message」に以下のログはでるものの、結局10分以上待っても、LTE通信ができない＋再起動しないという状態が続きました。
Mar 19 20:32:44 armadillo user.notice connection-recover: device ttyCommModem not found Mar 19 20:33:46 armadillo user.notice connection-recover: exec wwan-force-restart cause device ttyCommModem not found
> 準備頂いているワークアラウンドにて、この部分は対処できるということでしょうか？
こちらは LTE モジュールの再起動をしていまずが、それでも再度接続できなかった状況ですので、これに関しては対処はできません。
再起動後も device ttyCommModem not found ログが周期的に表示される状況が続いていますでしょうか？
> また、暫定的に/usr/bin/connection-recoverの以下の部分を変更して、対応しようと思いますが、問題は考えられますでしょうか？
どららかといえば、nmcli_device_unmanaged_or_not_found の中で
wwan-force-restart を実施している箇所を reboot に置き換えたほうがいいです。
そうしないと
nmcli_device_unmanaged_or_not_found の中で LTE モジュールの再起動を実施した後に
reboot することになりますので。
よろしくお願いします。
at_mitsuhiro.yoshida
2024年1月29日 15時50分
吉田です。
製品マニュアルに動作詳細を記載しておらず申し訳ありません。
FORCE_REBOOT を有効にした場合、 ping 導通チェックが 4 回連続 NG だった場合にArmadillo を再起動します。
ping 導通チェックは初期状態では120 秒間隔で をしておりますので、360 秒 ～ 480 秒の間で Armadillo の再接続を行う動作となります。
その為、5 分で再起動としているアプリケーションの方が先に動作する結果となっていると思われます。
REBOOT_IF_SIM_NOT_FOUND に関しては SIM が検出できなくなったと状況で Armadillo の再起動を試みますので、今回は稼働していないと思われます。
添付いただいたログは再接続が成功したパターンと認識いたします。