mado_ando
2023年4月11日 15時26分
大変お世話になります。
Armadillo IoT A6 のLTE 再接続機能ですが、PING導通が失敗したときにLTE モデムの再起動が行われる場合と行われない場合がありました。
LTE モデムの再起動が行われるのが期待する動作になりますが、再起動が行われない場合があるのは何故でしょうか。
----------------------------------------------------------------------
＜設定＞
設定は以下のようにしています。
/etc/aiot-modem-control/startup.conf
register_check_interval=180
ping_check=true
ping_ip_addr=210.130.0.20
ping_failed_threshold=1
＜ログ＞
・LTE モデムの再起動が行われる場合のログは、添付ファイルの「LTE再接続成功ログ.txt」になります。（期待する動作）
以下のログ以降にLTE再接続が行われている。
Apr 4 18:02:38 armadillo aiot-modem-controld[225]: 10 packets transmitted, 0 received, 100% packet loss, time 362ms
Apr 4 18:02:38 armadillo aiot-modem-controld[225]: ping_check(2982): failed ping check.
・LTE モデムの再起動が行われない場合のログは、添付ファイルの「LTE再接続失敗ログ.txt」になります。（不明な動作）
以下のログ以降にLTE再接続が行われていない。
Apr 4 18:41:41 armadillo aiot-modem-controld[225]: 10 packets transmitted, 0 received, 100% packet loss, time 382ms
Apr 4 18:41:41 armadillo aiot-modem-controld[225]: ping_check(2982): failed ping check.
----------------------------------------------------------------------
よろしくお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| LTE再接続成功ログ.txt | LTE モデムの再起動が行われる場合のログ（期待する動作） |
| LTE再接続失敗ログ.txt | LTE モデムの再起動が行われない場合のログ（不明な動作） |
コメント
mado_ando
お世話になります。
ご回答ありがとうございます。
> LTEモデムを再起動しているのはems31-utils となりますが、これは ping 導通が2回連続で失敗した場合となります。
設定が以下の場合、LTEモデムを再起動するのはping 導通が2回連続で失敗した場合ではなく、1回失敗した場合ではないのでしょうか。
ping_failed_threshold=1
> 成功ログではfailed ping check. のログの次で再度ping 導通確認を行っており、そこで失敗しているように見えるため
> 再起動が行われているように見えます。
ping 導通確認で失敗しているのは以下の行のみで、failed ping check. のログ以降ではping 導通確認で失敗しているログは無いと思いますが、失敗しているように見えると言われているのはログの何行目を見られて判断されたのでしょうか。
Apr 4 18:02:38 armadillo aiot-modem-controld[225]: 10 packets transmitted, 0 received, 100% packet loss, time 362ms
よろしくお願いいたします。
at_syunya.ohshio
大塩です。
> 設定が以下の場合、LTEモデムを再起動するのはping 導通が2回連続で失敗した場合ではなく、1回失敗した場合ではないのでしょうか。
>
> ping_failed_threshold=1
> ping 導通確認で失敗しているのは以下の行のみで、failed ping check. のログ以降ではping 導通確認で失敗しているログは無いと思いますが、失敗しているように見えると言われているのはログの何行目を見られて判断されたのでしょうか。
>
> Apr 4 18:02:38 armadillo aiot-modem-controld[225]: 10 packets transmitted, 0 received, 100% packet loss, time 362ms
改めてログ等を確認したところ「成功ログ」の方はems31-utils のping check でのLTE再接続機能ではなく、
wvdial がppp再接続を行ったログになります。
よって、「成功」「失敗」のログどちらも ping check 失敗によるLTE再接続が行われていないというように見えます。
混乱させてしまい申し訳ありません。
次に、ping check を1回失敗した後、LTE再接続処理が行われていないように見える件につきまして
状況確認のため、以下情報をお教えいただけますでしょうか。
・カーネルバージョン
・ems31-utils バージョン
参考情報としてems31-utils のLTE再接続処理について説明いたしますと
ping check を一定回数失敗した場合、まずAT+CFUN=0 -> AT+CFUN=1によって通信の再接続を試みます。
次のping check でまた一定回数失敗した場合、wwan-force-restart 機能によってEMS31-Jが再起動します。
よって、ping check 失敗によるLTE再接続が行われた場合、まず AT+CFUN=0 コマンドが表示されると思われます。
以上です。
mado_ando
お世話になります。
> 改めてログ等を確認したところ「成功ログ」の方はems31-utils のping check でのLTE再接続機能ではなく、
> wvdial がppp再接続を行ったログになります。
> よって、「成功」「失敗」のログどちらも ping check 失敗によるLTE再接続が行われていないというように見えます。
> 混乱させてしまい申し訳ありません。
承知しました。
> 次に、ping check を1回失敗した後、LTE再接続処理が行われていないように見える件につきまして
> 状況確認のため、以下情報をお教えいただけますでしょうか。
> ・カーネルバージョン
> ・ems31-utils バージョン
カーネルバージョン：Linux armadillo 4.14-at43 #1 Tue Mar 29 17:10:21 JST 2022 armv7l GNU/Linux
ems31-utils バージョン：ii ems31-utils 1.3.0 armhf Utilities for Thales EMS31 on Armadillo board
> 参考情報としてems31-utils のLTE再接続処理について説明いたしますと
> ping check を一定回数失敗した場合、まずAT+CFUN=0 -> AT+CFUN=1によって通信の再接続を試みます。
> 次のping check でまた一定回数失敗した場合、wwan-force-restart 機能によってEMS31-Jが再起動します。
> よって、ping check 失敗によるLTE再接続が行われた場合、まず AT+CFUN=0 コマンドが表示されると思われます。
情報ありがとうございます。
よろしくお願いいたします。
at_syunya.ohshio
大塩です。
情報ありがとうございます。
> カーネルバージョン：Linux armadillo 4.14-at43 #1 Tue Mar 29 17:10:21 JST 2022 armv7l GNU/Linux
> ems31-utils バージョン：ii ems31-utils 1.3.0 armhf Utilities for Thales EMS31 on Armadillo board
カーネルバージョン、ems31-utils が共に旧バージョンであるため
可能であれば最新バージョンにアップデートしていただき、同様の現象が発生するかご確認いただけますでしょうか。
以上です。
mado_ando
mado_ando
お世話になります。
> カーネルバージョン、ems31-utils が共に旧バージョンであるため
> 可能であれば最新バージョンにアップデートしていただき、同様の現象が発生するかご確認いただけますでしょうか。
以下の最新バージョンにアップデートして、同様の現象が発生するか確認しました。
カーネルバージョン：Linux armadillo 4.14-at55 #1 Mon Mar 27 11:53:52 JST 2023 armv7l GNU/Linux
ems31-utils バージョン：ii ems31-utils 1.3.1 armhf Utilities for Thales EMS31 on Armadillo board
結果は添付ファイルの「LTE再接続失敗ログ.txt」のようになり、同様の現象が発生しました。
（LTE 再接続機能のPING導通が失敗したときにLTE モデムの再起動が行われませんでした。）
ping check 失敗によるLTE再接続が行われた場合、まず AT+CFUN=0 コマンドが表示されるということでしたが、ログを確認したところ再起動時の1回のみ表示されていて、添付ファイルの「LTE再接続失敗ログ.txt」ようになっていました。
最新バージョンにアップデートしても ping check 失敗によるLTE再接続が行われない現象は改善しませんでしたが、改善するにはどのようにすればよろしいでしょうか。
| ファイル | ファイルの説明 |
|---|---|
| LTE再接続失敗ログ.txt | LTE モデムの再起動が行われなかったログ |
| 再起動時 AT+CFUN=0 ログ.txt | 再起動時に出ていた「AT+CFUN=0」のログ |
at_syunya.ohshio
大塩です。
返答が遅くなり申し訳ありません。
アップデートと確認ありがとうございます。
起動時の、CFUN=0 -> CFUN=1 については、初期化時に行われる正常な動作であるため、こちらは問題ありません。
こちらでもご報告いただいた現象について調査しております。
こちらでは、今のところping失敗時にはLTE再接続機能が実行されています。
そちらで発生している現象としましては、以下の認識でよろしいでしょうか。
・ping 失敗時には、「failed ping check.」 というログは出るが、以下のようなログは出ない
May 8 16:11:45 armadillo aiot-modem-controld[233]: ping_check(2982): failed ping check. May 8 16:11:45 armadillo aiot-modem-controld[233]: ==> AT+CFUN=0<CR><LF> May 8 16:11:45 armadillo aiot-modem-controld[233]: <== AT+CFUN=0<CR> May 8 16:11:47 armadillo pppd[578]: LCP terminated by peer (User request) May 8 16:11:47 armadillo aiot-modem-controld[233]: --> pppd: @�� May 8 16:11:47 armadillo aiot-modem-controld[233]: --> Connect time 0.7 minutes. May 8 16:11:47 armadillo aiot-modem-controld[233]: --> pppd: @�� May 8 16:11:47 armadillo aiot-modem-controld[233]: --> pppd: @�� May 8 16:11:47 armadillo pppd[578]: Connect time 0.7 minutes. May 8 16:11:47 armadillo pppd[578]: Sent 1164 bytes, received 312 bytes. May 8 16:11:47 armadillo aiot-modem-controld[233]: <== <CR><LF> May 8 16:11:47 armadillo aiot-modem-controld[233]: <== OK<CR><LF> May 8 16:11:49 armadillo aiot-modem-controld[233]: ==> AT+CFUN=1<CR><LF> May 8 16:11:49 armadillo aiot-modem-controld[233]: <== AT+CFUN=1<CR> May 8 16:11:49 armadillo aiot-modem-controld[233]: <== <CR><LF> May 8 16:11:49 armadillo aiot-modem-controld[233]: <== OK<CR><LF>
またお手数ですが以下をご確認いただけますでしょうか。
・ping_ip_addr を存在しないアドレスに設定し、LTE再接続機能が動作するか
mado_ando
お世話になります。
ご回答ありがとうございます。
> そちらで発生している現象としましては、以下の認識でよろしいでしょうか。
> ・ping 失敗時には、「failed ping check.」 というログは出るが、以下のようなログは出ない
はい、そのようなログは出力されませんでした。
> またお手数ですが以下をご確認いただけますでしょうか。
> ・ping_ip_addr を存在しないアドレスに設定し、LTE再接続機能が動作するか
ping_ip_addr を存在しないアドレスに設定したところ、「AT+CFUN=0」のログが出力されず、LTE再接続機能は動作しませんでした。
尚、上記につきましては、Armadillo IoT A6 の最新のインストールディスクイメージ「install-disk-buster-aiota6-20230127.img」でLTE 再接続機能を動作確認しました。
また、startup.confは以下のように設定しました。
register_check_interval=180 ping_check=true ping_ip_addr=111.111.111.111 ping_failed_threshold=1
動作結果は添付「存在しないアドレス ログ.log」のようになりました。
Armadillo IoT A6 の最新のインストールディスクイメージでもLTE 再接続機能が動作できませんでしたので、動作しない原因につきましてご確認よろしくお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| 存在しないアドレス ログ.log |
at_syunya.ohshio
大塩です。
ご確認とログ送付ありがとうございます。
> ping_ip_addr を存在しないアドレスに設定したところ、「AT+CFUN=0」のログが出力されず、LTE再接続機能は動作しませんでした。
ログを確認したところ、「failed ping check. 連続2回目以降に実施される」wwan-force-restart 機能が実行されていますので、LTE再接続機能は実行されています。
「最後の成功から failed ping check. 1回目の失敗」時、ひとつ前の回答で記載した「CFUN=0 、CFUN=1」のログが表示されるはずです。
今回ご確認いただいた「最初から存在しないping_ip_addr を指定している」場合は、Armadillo 起動後から最初のfailed ping check.後です。
お手数ですが、今回ご確認頂いた ping_ip_addr=111.111.111.111 での動作確認につきまして
Armadillo 起動後からwwan-force-restart が実行されるまでのsyslog を差し支えない範囲でそのままいただけますでしょうか。
以上です。
mado_ando
お世話になります。
ご回答ありがとうございます。
> お手数ですが、今回ご確認頂いた ping_ip_addr=111.111.111.111 での動作確認につきまして
> Armadillo 起動後からwwan-force-restart が実行されるまでのsyslog を差し支えない範囲でそのままいただけますでしょうか。
「Armadillo 起動後から wwan-force-restart 実行.log」を添付しました。
（Armadillo起動 → CFUN=0、CFUN=1 → Armadillo再起動 → wwan-force-restartとなっていて、CFUN=0、CFUN=1はArmadilloを再起動する前に出力されていました。）
また、以前のログで wwan-force-restart のログが出力されている場合がありましたので、そのログ「以前のログで wwan-force-restart 実行.txt」を添付しました。
流れとしては failed ping check → failed ping check → wwan-force-restart となっていましたが、failed ping checkが2連続で発生したときにwwan-force-restartになるということでしょうか。
（failed ping check が1回のみで次のPINGが成功している場合は wwan-force-restart になっていませんでした。）
| ファイル | ファイルの説明 |
|---|---|
| Armadillo 起動後から wwan-force-restart 実行.txt | |
| 以前のログで wwan-force-restart 実行.txt |
at_syunya.ohshio
大塩です。
確認と送付ありがとうございます。
> 流れとしては failed ping check → failed ping check → wwan-force-restart となっていましたが、failed ping checkが2連続で発生したときにwwan-force-restartになるということでしょうか。
はい、 wwan-force-restart は 「failed ping check.」が 2連続以上となったとき、failed ping check. が発生するたびに実行されます。
よって、failed ping check. が1回だけ発生し、次の ping check が成功している場合は行われません。
送付いただいたログ「Armadillo 起動後から wwan-force-restart 実行.txt」を確認しました。
wwan-force-restart の挙動は正常ですが、最初と再起動後の「failed ping check.」後にCFUN=0 -> CFUN=1 のログが無いことが気になります。
Armadillo 起動直後に行われているCFUN=0 -> CFUN=1 は、LTE通信の初期セットアップで行われている処理のため、LTE再接続機能とは別のATコマンドになります。
参考までに、こちらで確認しましたのは最新インストールディスクイメージv20230427 で確認しております。
インストールディスクイメージでの初期化後、/etc/aiot-modem-control/startup.conf を修正して1度目の failed ping check. で CFUN=0 -> CFUN=1 のLTE再接続機能が実施されていることが確認出来ています。
以上です。
mado_ando
お世話になります。
ご回答ありがとうございます。
> はい、 wwan-force-restart は 「failed ping check.」が 2連続以上となったとき、failed ping check. が発生するたびに実行されます。
> よって、failed ping check. が1回だけ発生し、次の ping check が成功している場合は行われません。
ありがとうございます。
理解できました。
> wwan-force-restart の挙動は正常ですが、最初と再起動後の「failed ping check.」後にCFUN=0 -> CFUN=1 のログが無いことが気になります。
最新の「install-disk-buster-aiota6-20230427.img」で確認しましたが、最新でも CFUN=0 -> CFUN=1 のログが出力されませんでした。
/etc/aiot-modem-control/startup.conf の設定を見直したところ、
#multiplex=auto
をデフォルトの
multiplex=auto
に変更することにより CFUN=0 -> CFUN=1 のログが出力されるようになりました。
マニュアルのLTE 再接続機能には、
SIM カードが接続されており、 「LTE 設定ファイル (/etc/aiot-modem-control/startup.conf) の編集」 の設定 ping_check が true であり、 かつ register_check_interval , ping_ip_addr , ping_failed_threshold に有効な値が設定されている場合、LTE 再接続機能が有効化されます。
と記載されていてmultiplexの設定はLTE 再接続機能に関係ないように見えますが、LTE 再接続機能に関係ありますか。
at_syunya.ohshio
大塩です。
> /etc/aiot-modem-control/startup.conf の設定を見直したところ、
>
> #multiplex=auto >
> をデフォルトの
>
> multiplex=auto >
> に変更することにより CFUN=0 -> CFUN=1 のログが出力されるようになりました。
上記情報ありがとうございます、ping check failed. 時に CFUN コマンドが実行されない理由はmultiplex 機能がオフだからです。
multiplex 機能をオフにしている場合、ppp コネクションが確立している間はATコマンドが送信できなくなります。
そのため、ping check failed. 1回目のCFUN コマンドは実行されません。
一方、wwan-force-restart はppp コネクション等をオフにしてからEMS31-Jを再起動させるため、その過程でのATコマンドは実行されます。
よって、ping check failed. 1回目にて CFUNコマンドを実行してほしい場合は Multiplex機能を有効にすることをお勧めします。
wwan-force-restart でのEMS31-J 再起動のみで良い場合は、Multiplex 機能が無効化されていても問題ありません。
以上です。
mado_ando
お世話になります。
ご回答ありがとうございます。
> multiplex 機能をオフにしている場合、ppp コネクションが確立している間はATコマンドが送信できなくなります。
> そのため、ping check failed. 1回目のCFUN コマンドは実行されません。
> 一方、wwan-force-restart はppp コネクション等をオフにしてからEMS31-Jを再起動させるため、その過程でのATコマンドは実行されます。
multiplex の設定はLTE 再接続機能に関係あるということで理解しました。
> よって、ping check failed. 1回目にて CFUNコマンドを実行してほしい場合は Multiplex機能を有効にすることをお勧めします。
> wwan-force-restart でのEMS31-J 再起動のみで良い場合は、Multiplex 機能が無効化されていても問題ありません。
Multiplex機能を有効にしてLTE 再接続機能を使用することにしたいと思います。
これで LTE 再接続機能が期待する動作になりました。
ありがとうございました。
mado_ando
お世話になります。
LTE再接続機能の動作確認中に「AT+CFUN=0」のログが出力されず、添付「set_cfun → open serial failed ログ.txt」のように「set_cfun(461): open serial failed.」が出力されていました。
システム側がLTEを使用した通信を行っていますが、上記のようになった場合、その後システム側の通信が行われなくなるということはないでしょうか。
| ファイル | ファイルの説明 |
|---|---|
| set_cfun → open serial failed ログ.txt |
at_syunya.ohshio
大塩です。
> LTE再接続機能の動作確認中に「AT+CFUN=0」のログが出力されず、添付「set_cfun → open serial failed ログ.txt」のように「set_cfun(461): open serial failed.」が出力されていました。
>
> システム側がLTEを使用した通信を行っていますが、上記のようになった場合、その後システム側の通信が行われなくなるということはないでしょうか。
ログを確認したところ、EMS31-J とのシリアル通信が一時的にできない状態になっていますが、その後wvdial による再初期化が行われており、この中でシリアル通信が出来ているためこの時点でEMS31-Jとの通信は回復しています。
よって、この現象だけではLTE通信自体が行われなくなる可能性は低いと思われます。
以上です。
mado_ando
at_syunya.ohshio
2023年4月11日 16時56分
大塩です。
> LTE モデムの再起動が行われるのが期待する動作になりますが、再起動が行われない場合があるのは何故でしょうか。
LTEモデムを再起動しているのはems31-utils となりますが、これは ping 導通が2回連続で失敗した場合となります。
成功ログではfailed ping check. のログの次で再度ping 導通確認を行っており、そこで失敗しているように見えるため
再起動が行われているように見えます。
一方失敗ログでは、failed ping check. の次でping 導通が成功していますので、再起動が行われていません。
以上です。