Armadilloフォーラム

LTE再接続サービスのスクリプト・OSの再起動を実行してもLTE接続が復旧しない

akira.shimomura

2019年1月11日 9時49分

カーネル:linux 3.14.79-at17
ルートファイルシステム:製品マニュアルの手順書に従い、2018/04/04にビルドしたもの

Armadillo-IoT G3L にて、LTE接続がLTE再接続サービスのスクリプト(wwan-force-restart)、OSの再起動を実行しても
LTE接続が復旧しないという現象が発生しました。

wwan-force-restart・OSの再起動を20時間続けて実行してもLTE接続が復旧しませんでしたが、その後の G3Lの電源を
抜き指しするとLTE接続は復旧しています

お客様環境に設置しているため、電源の抜き指しでの復旧ではなく、wwan-force-restartまたはOSの再起動での復旧をさせる
必要があります。

現象発生直後と電源の抜き指しでの復旧した付近のdaemon.logを添付しますので、wwan-force-restart・OSの再起動で
復旧しなかった原因と対策について、ご教示お願いします。

現象が発生した時刻:2018/12/24 16:20 頃(log1.txtの1887行目以降)
電源OFFにした時刻 :2018/12/25 11:01 頃(log2.txtの1442行目以降)

こちらでもログの確認は行っていて、

Dec 24 16:21:17 localhost ModemManager[2162]: <info>  Cinterion ELS CFUN Error!

とModemManagerがエラーを出力しているのが気になっているのですが、原因と対策方法
を特定することができていません。

ファイル ファイルの説明
log1.txt 現象発生直後のログ
log2.txt 電源OFFを行った付近のログ
コメント

y.nakamura

2019年1月11日 11時01分

中村です。

原因や症状が違うかもしれませんが、参考になれば・・・

電源抜き差しの再起動ならば問題はないが、
rebootでの再起動の場合、何度目かのrebootで
接続できなくなるという問題が発生して、
対策をしたことがあります。

カーネルは3.14で、
モデムのファームウェアは昨年7月の4.3.3.0-36584、
SIMはSORACOMです。

> お客様環境に設置しているため、電源の抜き指しでの復旧ではなく、wwan-force-restartまたはOSの再起動での復旧をさせる
> 必要があります。

私もこれは同じで、
ログなどの調査の前にとりあえず試しに、と、
次のようにしたら回避できました。

起動後(電源抜き差しの場合もrebootの場合も同じ処理)
1) 記憶しているLTEの設定を解除
nmcli connection down gsm-ttyACM0
nmcli connection delete gsm-ttyACM0
2) モデムを強制リセット
/usr/bin/wwan-force-restart
3) LTEの設定
nmcli connection add type gsm ifname ttyACM0 apn ...

--
なかむら

akira.shimomura

2019年1月11日 11時29分

中村様

回避策をご教示いただき、ありがとうございます。

早速試してみたいところではあります。

ただ、やはりお客様環境上にあるのでLTE接続ができなくなる原因と
その回避策が有効なのか、が必要になってくるので、
アットマークテクノ様からの 問題の原因・対策案についての見解も
頂きたいと思っています。

akira.shimomura

2019年1月21日 9時30分

アットマークテクノ様

上記問題の原因・対策案についての見解を頂けないでしょうか?

お客様への説明が必要な状況となっていますので、よろしくお願いします。

at_koseki

2019年1月23日 13時30分

> アットマークテクノ様
>
> 上記問題の原因・対策案についての見解を頂けないでしょうか?
>
> お客様への説明が必要な状況となっていますので、よろしくお願いします。

古関です。

ご連絡が遅くなってしまい申し訳ありません。

現時点で再現できておりませんが、現在調査中です。

> Dec 24 16:21:17 localhost ModemManager[2162]: Cinterion ELS CFUN Error!
ログと関係するソースコードを確認させていただきました。
モジュール自体は認識できていて、ATコマンドも実行できる状況なのですが、
RFを含めた全機能を有効にするコマンド"AT+CFUN=1"がエラーになっている状況のようです。

Armadillo-IoT G3Lの電源を入れなおせば復旧するということですので、
コールドスタート相当の動作を行う暫定対策も出せないか検討中です。
※ 原因調査と正式対策が長期化する可能性があるため

akira.shimomura

2019年1月23日 13時49分

古関様

ご回答ありがとうございます。

> モジュール自体は認識できていて、ATコマンドも実行できる状況なのですが、
> RFを含めた全機能を有効にするコマンド"AT+CFUN=1"がエラーになっている状況のようです。
LTEモジュールが"AT+CFUN=1"を受け付けない状況となっている、ということでよろしいでしょうか?

> Armadillo-IoT G3Lの電源を入れなおせば復旧するということですので、
> コールドスタート相当の動作を行う暫定対策も出せないか検討中です。
引き続き、ご対応よろしくお願いいたします。

at_koseki

2019年1月23日 13時56分

古関です。

> LTEモジュールが"AT+CFUN=1"を受け付けない状況となっている、ということでよろしいでしょうか?

はい。ログに上ではそうみえます。

厳密には、AT+CFUN=1を実行し、コマンドは受け付けてはいるがStatusが設定している1にならない
という状況です。

モジュール側の問題なのか、ホスト側の処理の問題なのかは切り分けできていません。

エラーになった後に何度かリトライすれば成功するのかもしれませんが、
一般的に失敗するコマンドではないため、
ソフト的にはそのような作りになっていません。

yo_nakai

2019年9月26日 17時59分

中井と申します。

いつもお世話になっています。
横から失礼いたします。

カーネル:linux 3.14.79 
ビルド時期:2018年10月22日
Armadillo-IoT G3Lで同じような状況が起こっています。
1分ごとにデータを送信する24時間起動のシステムで

発生日は2019年9月4日と2019年9月12日、7分ごとにOS再起動を繰り返し、4日は約4時間半後
12日は約7時間半後にLTE接続されました。

別のArmadillo-IoT G3Lで同じような状況が起こっています。

その後、何か進展があったのでしょうか?
ご教示お願いいたします。

> 古関です。
>
> > LTEモジュールが"AT+CFUN=1"を受け付けない状況となっている、ということでよろしいでしょうか?
>
> はい。ログに上ではそうみえます。
>
> 厳密には、AT+CFUN=1を実行し、コマンドは受け付けてはいるがStatusが設定している1にならない
> という状況です。
>
> モジュール側の問題なのか、ホスト側の処理の問題なのかは切り分けできていません。
>
> エラーになった後に何度かリトライすれば成功するのかもしれませんが、
> 一般的に失敗するコマンドではないため、
> ソフト的にはそのような作りになっていません。

yo_nakai

2019年9月26日 18時20分

中井と申します。
いつもお世話になっています。
連続投稿失礼します。

投稿してからアップデート情報を確認していると、以下の情報がアップされていました。
この問題の対策でしょうか?

インストールディスクイメージ作成ツール (v1.2.1)
Armadillo-IoT G3Lのボード情報をv3.2に更新
インストールディスクイメージ作成ツール (v1.2.1)以降で作成したインストールディスクイメージ、又はインストールディスクイメージv20190703以降で再インストールを実施することでボード情報をv3.2にアップデートすることができます
els31-utils (v1.1.0)
Armadillo-IoT G3L搭載LTEモジュール ELS31-Jのシャットダウン処理追加
ボード情報をv3.2アップデートすると、poweroffコマンド実施時にELS31-Jに下記処理が実施されます
(1) ATコマンドによるシャットダウン要求
(2) Status PINを監視しシャットダウンできたことを確認
(3) LTEモジュールへの電供給源OFF

> 中井と申します。
>
> いつもお世話になっています。
> 横から失礼いたします。
>
> カーネル:linux 3.14.79 
> ビルド時期:2018年10月22日
> Armadillo-IoT G3Lで同じような状況が起こっています。
> 1分ごとにデータを送信する24時間起動のシステムで
>
> 発生日は2019年9月4日と2019年9月12日、7分ごとにOS再起動を繰り返し、4日は約4時間半後
> 12日は約7時間半後にLTE接続されました。
>
> 別のArmadillo-IoT G3Lで同じような状況が起こっています。
>
> その後、何か進展があったのでしょうか?
> ご教示お願いいたします。
>
> > 古関です。
> >
> > > LTEモジュールが"AT+CFUN=1"を受け付けない状況となっている、ということでよろしいでしょうか?
> >
> > はい。ログに上ではそうみえます。
> >
> > 厳密には、AT+CFUN=1を実行し、コマンドは受け付けてはいるがStatusが設定している1にならない
> > という状況です。
> >
> > モジュール側の問題なのか、ホスト側の処理の問題なのかは切り分けできていません。
> >
> > エラーになった後に何度かリトライすれば成功するのかもしれませんが、
> > 一般的に失敗するコマンドではないため、
> > ソフト的にはそのような作りになっていません。
>
>

yo_nakai

2019年10月3日 18時07分

中井と申します。

いつもお世話になっています。
連続投稿失礼します。
追加情報です。

Armadillo-IoT G3L にて異常検出アプリで7分間隔でOSの再起動を10時間以上繰り返しても、LTEによる通信の復旧が出来ず、電源入り切りで通信可能となるという現象がまた別の施設で発生しました。

カーネル:linux 3.14.79-at21

問題発生日時:2019年10月1日 17:23
問題解消日時:2019年10月2日 16:22(rebootコマンドで解消せず電源入り切りで解消)
現地に行って、電波強度を確認するとmmcli -m 0を確認すると、県庁の前の市街地であるに関わらず、
signal quality 0(通常は70程度)で、rebootコマンドで再起動させても、signal quality 0 のままでした。

電源入り切りを行うと、通信を行うようになり、signal quality 70 と通常状態になりました。
その後、現時点まで正常に動いています(それ以前も2ケ月間正常動作していました)。
基地局の工事などはありません。

前にも質問していますが、以下のアップデートは「OSの再起動でLTE接続が出来ず、電源の入り切りでLTE接続が可能になる問題の対策でしょうか?
>els31-utils (v1.1.0)
>Armadillo-IoT G3L搭載LTEモジュール ELS31-Jのシャットダウン処理追加
>ボード情報をv3.2アップデートすると、poweroffコマンド実施時にELS31-Jに下記処理が実施されます
>(1) ATコマンドによるシャットダウン要求
>(2) Status PINを監視しシャットダウンできたことを確認
>(3) LTEモジュールへの電供給源OFF
のでしょうか?

シャットダウンでなくRebootでもその効果がでますか?

ユーザー様から早急の報告を求められています。
ご教示お願いいたします。

添付1  log1.txt 電源入り切りする前のmmcli -m 0
添付2  log2.txt電源入り切りした後のmmcli -m 0
添付3 log3.txt 電源入り切りする前のsyslog

Log3補足

>Oct 2 15:06:54 gwstatus(通信異常を検出しリブートするソフト)によるリブート
>Oct 2 15:09:14 ETK起動
>Oct 2 15:09:51 LTE接続 NG
>Oct 2 15:09:51 LTE接続 OK
>Oct 2 15:11:04 LTE接続 NG
>Oct 2 15:11:04 LTE接続 OK
>Oct 2 15:12:16 LTE接続 NG
>Oct 2 15:12:16 LTE接続 OK
>Oct 2 15:13:28 LTE接続 NG
>Oct 2 15:13:49 gwstatus異常によるリブート
>Oct 2 15:15:04 ETK起動
>Oct 2 15:15:08 ETK異常によるリブート
>Oct 2 15:15:33 LTE接続 OK
>Oct 2 15:16:08 ETK起動
>Oct 2 15:16:45 LTE接続 NG
>Oct 2 15:16:45 LTE接続 OK
>Oct 2 15:17:58 LTE接続 NG
>Oct 2 15:17:58 LTE接続 OK
>Oct 2 15:19:10 LTE接続 NG
>Oct 2 15:19:10 LTE接続 OK
>Oct 2 15:20:22 LTE接続 NG
>Oct 2 15:20:43 gwstatus異常によるリブート
>Oct 2 15:21:58 ETK起動
>Oct 2 15:22:02 ETK異常によるリブート
>Oct 2 15:22:27 LTE接続 OK
>Oct 2 15:23:02 ETK起動
>Oct 2 15:23:39 LTE接続 NG
>Oct 2 15:23:39 LTE接続 OK
>Oct 2 15:24:52 LTE接続 NG
>Oct 2 15:24:52 LTE接続 OK
>Oct 2 15:26:04 LTE接続 NG
>Oct 2 15:26:04 LTE接続 OK
>Oct 2 15:27:16 LTE接続 NG
>Oct 2 15:27:37 gwstatus異常によるリブート
>Oct 2 15:28:53 ETK起動
>Oct 2 15:28:57 ETK異常によるリブート
>Oct 2 15:29:22 LTE接続 OK
>Oct 2 15:29:57 ETK起動
>Oct 2 15:30:34 LTE接続 NG
>Oct 2 15:30:34 LTE接続 OK
>Oct 2 15:31:47 LTE接続 NG
>Oct 2 15:31:47 LTE接続 OK
>Oct 2 15:33:00 LTE接続 NG
>Oct 2 15:33:00 LTE接続 OK
>Oct 2 15:34:12 LTE接続 NG
>Oct 2 15:34:32 gwstatus異常によるリブート
>Oct 2 15:35:47 ETK起動
>Oct 2 15:35:51 ETK異常によるリブート
>Oct 2 15:36:16 LTE接続 OK
>Oct 2 15:36:51 ETK起動
>Oct 2 15:37:28 LTE接続 NG
>Oct 2 15:37:28 LTE接続 OK
>Oct 2 15:38:41 LTE接続 NG
>Oct 2 15:38:41 LTE接続 OK
>Oct 2 15:39:53 LTE接続 NG
>Oct 2 15:39:53 LTE接続 OK
>Oct 2 15:41:05 LTE接続 NG
>Oct 2 15:41:26 gwstatus異常によるリブート
>Oct 2 15:42:42 ETK起動
>Oct 2 15:42:46 ETK異常によるリブート
>Oct 2 15:43:11 LTE接続 OK
>Oct 2 15:43:46 ETK起動
>Oct 2 15:44:23 LTE接続 NG
>Oct 2 15:44:23 LTE接続 OK
>Oct 2 15:45:36 LTE接続 NG
>Oct 2 15:45:36 LTE接続 OK
>Oct 2 15:46:48 LTE接続 NG
>Oct 2 15:46:48 LTE接続 OK

> 中井と申します。
> いつもお世話になっています。
> 連続投稿失礼します。
>
> 投稿してからアップデート情報を確認していると、以下の情報がアップされていました。
> この問題の対策でしょうか?
>
> インストールディスクイメージ作成ツール (v1.2.1)
> Armadillo-IoT G3Lのボード情報をv3.2に更新
> インストールディスクイメージ作成ツール (v1.2.1)以降で作成したインストールディスクイメージ、又はインストールディスクイメージv20190703以降で再インストールを実施することでボード情報をv3.2にアップデートすることができます
> els31-utils (v1.1.0)
> Armadillo-IoT G3L搭載LTEモジュール ELS31-Jのシャットダウン処理追加
> ボード情報をv3.2アップデートすると、poweroffコマンド実施時にELS31-Jに下記処理が実施されます
> (1) ATコマンドによるシャットダウン要求
> (2) Status PINを監視しシャットダウンできたことを確認
> (3) LTEモジュールへの電供給源OFF
>

ファイル ファイルの説明
log2.txt 電源入り切りした後のmmcli -m 0
log1.txt 電源入り切りする前のmmcli -m 0
log3.txt 電源入り切りする前のsyslog

at_koseki

2019年10月7日 19時14分

古関です。

回答が遅くなってしまい申し訳ありません。

■ リブート時のLTEモジュールの電源シーケンス変更について
> 前にも質問していますが、以下のアップデートは
> 「OSの再起動でLTE接続が出来ず、電源の入り切りでLTE接続が可能になる問題の対策でしょうか?
はい。

リブートでは復帰できず、コールドスタートでは復帰できる可能性を考えこの対策を行いました。
コールドスタートとリブートでLTEモジュールの電源シーケンスを共通にしています。
(リブート時に、LTEモジュールをシャットダウンさせ、かつ電源供給をOFF/ONする)

現在発生している問題が、Armadillo-IoT G3Lの電源OFF/ONで症状が改善したのだとすると、
上記ソフトウェアを書き込んだ状態でリブートを実行すれば、対策として効果は得られると思います。

"/etc/connection-recover/gsm-ttyACM0_connection-recover.conf " に以下の設定を追加することで
接続ができない場合にリブートするようになります。

FORCE_REBOOT=TRUE

■ 問題が発生している個体のファームウェアバージョン
一点確認させていただきたいのですが、問題が発生した個体に搭載されているLTEモジュール(ELS31-J)の
ファームウェアバージョンを教えていただけますでしょうか。

下記の手順[※1]で確認できます。実行可能でしょうか?

過去に、特定の設置環境、古いファームウェアバージョン(FW:26730、FW:30063)にて同様の不具合が発生し、
ファームウェアの更新(FW:36584)で改善したことがあります。

[※1]: ファームウェアバージョン確認手順
----------------------------------------------------------------------------------------------------------------
(1) connection-recover、ModemManagerを停止します。LTEでのデータ通信を行っている場合は、データ接続が切断されます。

# service connection-recover stop
# service ModemManager stop

(2) cu コマンドを実行して /dev/ttyACM0 に接続します。ボーレートは115200bps です。

# cu -l /dev/ttyACM0 -s 115200
Connected.

(3) ATI1 コマンドを実行すると、ファームウェアバージョンが表示されます。

ATI1

Cinterion
ELS31-J
REVISION 4.3.2.1b
A-REVISION 4.3.3.0-36584
L-REVISION 3.7.6
OK

(4) ~.(チルダ、ドット)を入力しcuを終了します
~.
Disconnected.
----------------------------------------------------------------------------------------------------------------

yo_nakai

2019年10月7日 21時04分

中井です。

ご教示ありがとうございます。
回答を拝見して想定した通りだったので安心いたしました。
> 下記の手順[※1]で確認できます。実行可能でしょうか?
問題が発生している施設は離れたところにあるのユーザー様の施設なので、
ユーザー様と日程調整が必要ですが、実行可能です。
よろしくお願いいたします。

> 古関です。
>
> 回答が遅くなってしまい申し訳ありません。
>
> ■ リブート時のLTEモジュールの電源シーケンス変更について
> > 前にも質問していますが、以下のアップデートは
> > 「OSの再起動でLTE接続が出来ず、電源の入り切りでLTE接続が可能になる問題の対策でしょうか?
> はい。
>
> リブートでは復帰できず、コールドスタートでは復帰できる可能性を考えこの対策を行いました。
> コールドスタートとリブートでLTEモジュールの電源シーケンスを共通にしています。
> (リブート時に、LTEモジュールをシャットダウンさせ、かつ電源供給をOFF/ONする)
>
>
> 現在発生している問題が、Armadillo-IoT G3Lの電源OFF/ONで症状が改善したのだとすると、
> 上記ソフトウェアを書き込んだ状態でリブートを実行すれば、対策として効果は得られると思います。
>
> "/etc/connection-recover/gsm-ttyACM0_connection-recover.conf " に以下の設定を追加することで
> 接続ができない場合にリブートするようになります。
>
> FORCE_REBOOT=TRUE
>
>
> ■ 問題が発生している個体のファームウェアバージョン
> 一点確認させていただきたいのですが、問題が発生した個体に搭載されているLTEモジュール(ELS31-J)の
> ファームウェアバージョンを教えていただけますでしょうか。
>
> 下記の手順[※1]で確認できます。実行可能でしょうか?
>
> 過去に、特定の設置環境、古いファームウェアバージョン(FW:26730、FW:30063)にて同様の不具合が発生し、
> ファームウェアの更新(FW:36584)で改善したことがあります。
>
>
> [※1]: ファームウェアバージョン確認手順
> ----------------------------------------------------------------------------------------------------------------
> (1) connection-recover、ModemManagerを停止します。LTEでのデータ通信を行っている場合は、データ接続が切断されます。
>
> # service connection-recover stop
> # service ModemManager stop
>
>
> (2) cu コマンドを実行して /dev/ttyACM0 に接続します。ボーレートは115200bps です。
>
>
> # cu -l /dev/ttyACM0 -s 115200
> Connected.
>
>
> (3) ATI1 コマンドを実行すると、ファームウェアバージョンが表示されます。
>
> ATI1
>
> Cinterion
> ELS31-J
> REVISION 4.3.2.1b
> A-REVISION 4.3.3.0-36584
> L-REVISION 3.7.6
> OK
>
>
> (4) ~.(チルダ、ドット)を入力しcuを終了します
> ~.
> Disconnected.
> ----------------------------------------------------------------------------------------------------------------

akira.shimomura

2019年10月8日 9時11分

アットマークテクノ 古関様

最初の質問者です。
いつもお世話になっております。

> ■ リブート時のLTEモジュールの電源シーケンス変更について
> > 前にも質問していますが、以下のアップデートは
> > 「OSの再起動でLTE接続が出来ず、電源の入り切りでLTE接続が可能になる問題の対策でしょうか?
> はい。
>
> リブートでは復帰できず、コールドスタートでは復帰できる可能性を考えこの対策を行いました。
> コールドスタートとリブートでLTEモジュールの電源シーケンスを共通にしています。

上記で対応できたとのことですが、この対応を行ったイメージでは
https://users.atmark-techno.com/forum/armadillo/4096
の問題が発生してしまい、LTEモジュールのFirewall無効化コマンドが実行できなくなるため、
お客様環境に導入することができません。

https://users.atmark-techno.com/forum/armadillo/4096
の対応状況はどのようになっていますでしょうか?
上記スレッド内で回答頂ければと思います。