Armadilloフォーラム

Armadiilo-IoT G3L 稼働中に真ん中のLEDランプが消灯

k.shiratori

2018年8月27日 21時05分

お世話になっております。

Armadillo-IoT G3Lを使用中、真ん中のLEDランプが消灯する現象が発生しました。電源投入時は点灯していましたが、連続稼働している中でいつの間にか消灯し、ネットワークに接続できなくなっていたようです。
そこで、以下について質問させてください。
・LEDランプの真ん中が、電源投入後途中で消灯してしまうのはどういったケースなのか
・ランプが消灯してしまった場合、再度ネットワークに接続するにはどういった対応が必要になるのか(LTEモジュールの再起動、など)
 → ArmadilloにはLTE再接続サービスがありますが、通信量削減の観点から現在無効化しております。LTE再接続サービスが有効化されていないと、自動で復旧する可能性がないかどうかも知りたいです。

なおこちらの都合で恐縮ですが、ログはすぐに回収できずご提示することができません。

端末情報:
 カーネルバージョン:
3.14.79-at15
 LTEモジュールファームバージョン確認結果:
Cinterion
ELS31-J
REVISION 4.3.2.1b
A-REVISION 4.3.3.0-30063
L-REVISION 3.7.6

以上です。
よろしくお願いいたします。

コメント

at_nakai

2018年8月28日 10時59分

nakaiです。

まず真ん中のLEDですが、
デフォルト状態のソフトウェアでは、「LTEのデータ接続中に点灯、切断で消灯」といった動作するように実装されています。
下記製品マニュアルに記載があります。
https://manual.atmark-techno.com/armadillo-iot-g3l/armadillo-iotg-g3l_p…

LTE再接続サービス(connection-recover)を無効化した場合には、自動で復旧しないケースがあります。
・LTEモジュールが意図せずにフリーズのような状態に陥った場合
 ・LTEモジュールの電源OFF/ONの実施が必要 (connection-recoverのwwan-force-restartに相当)
・電波状態が極度に悪い場合

上記にも一部記載しましたが、モジュールの初期化にはいくつかレベルがあります。
・LTEモジュールの電源OFF/ONによる再起動 (wwan-force-restart)
・LTEモジュールRFの無効化/有効化 (AT+CFUN=0/AT+CFUN=1)
・NetworkManagerのconnection初期化 など

記載された状態ですと、LTEモジュールの電源OFF/ONが該当しそうです。
wwan-force-restart
を試してみてください。

k.shiratori

2018年8月28日 16時15分

お世話になっております。

ご回答ありがとうございました。
追加で確認させてください。
> ・電波状態が極度に悪い場合
とありますが、これはどういったケースに該当するのでしょうか。
こちらの検証では、アンテナの着脱によるネットワークの切断、SIMの着脱によるネットワークの切断程度では、通信は自動で復旧しています。
切断している時間によって判断しているのでしょうか。
また、電波状態が極端に悪い場合から電波が回復すればLEDランプは再度点灯するのでしょうか。

今回はご指摘の通りLTEモジュールがフリーズもしくは落ちた状態だと予想しますが、LTEモジュールの再起動が必要になる状況の発生頻度について、わかるようであれば教えていただけないでしょうか。

よろしくお願いいたします。

at_nakai

2018年8月28日 16時17分

nakaiです。

>> ・電波状態が極度に悪い場合
>とありますが、これはどういったケースに該当するのでしょうか。

・キャリアのサービスエリアの境界付近への設置
・電波が遮断、混線するような環境
などでしょうか。

> 電波状態が極端に悪い場合から電波が回復すればLEDランプは再度点灯するのでしょうか。

LTEのデータ接続中の状態はソフトウェア(NetworkManager)で判断しているため、
ソフトウェアでデータ接続を確認できれば再点灯するように実装されています。
※ LTEモジュール直結のLEDではありません

> LTEモジュールの再起動が必要になる状況の発生頻度について、わかるようであれば教えていただけないでしょうか。

申し訳ありません。弊社でもなぜそのような状態に陥るのかを把握することができておりません。
そのため、発生頻度等、ご提示できる情報は今のところございません。

意図的に再現することができれば、調査は出来ると考えています。

k.shiratori

2018年8月29日 14時56分

お世話になっております。

内容承知いたしました。

現状ですと再接続サービスを停止させているためLTEモジュールが落ちたときに復帰する手段がないため、通信に失敗した場合はLTEモジュールの再起動を試みるなど、対策を検討したいと思います。

ご回答いただきありがとうございました。

k.shiratori

2018年9月13日 17時04分

お世話になっております。

本現象が発生した機体を回収し、ログを確認しました。
弊社が開発したアプリは正常に動作しており、LTE通信の部分がうまくいっていないことがわかっています。
また、通信エラー時にNetworkManagerの再起動(down/up)を実施していますが、通信は回復しておりませんでした。
障害発生前後のsyslogを添付しますので、LTEモジュールが落ちているのか、原因が特定できるかご確認いただけないでしょうか。

わかっていること:
・8/23 12:29:14時点ではデータ送信が成功している。
・8/24 12:29:20にデータ送信に失敗している。
・8/24 10:52:34にNetworkManagerでエラーが出ているように見える

また、対策についてご教授いただきたい次第です。
LTE通信に失敗した場合、アプリ側でNetworkManagerの再起動を試しているのですが回復していないため、LTEモジュールの再起動を実施するようにアプリ改修を検討しています。
LTE通信に失敗した場合はLTEモジュール再起動(wwan-force-restartの実行)を実施しようと思っているのですが、通信失敗時毎回LTEモジュール再起動するようにしても問題はないでしょうか。
また、NetworkManagerの再起動は今まで通り実施した方がよいのか、LTEモジュール再起動をすればNetworkManagerの再起動は必要ないものなのかを教えていただきたいです。
LTEモジュール再起動でも通信が回復しない場合は、何回か通信を試した後にOSリブートまで実施するように考えています。

以上です。
よろしくお願いいたします。

ファイル ファイルの説明
障害発生前後のシスログ.txt

at_koseki

2018年9月13日 17時35分

古関です。

> Aug 24 10:52:35 armadillo nm-dispatcher: Dispatching action 'down' for ttyACM0
> Aug 24 10:52:47 armadillo kernel: usb 2-1: new high-speed USB device number 3 using ci_hdrc
> Aug 24 10:52:47 armadillo kernel: cdc_ether 2-1:1.0 usb1: register 'cdc_ether' at usb-ci_hdrc.1-1, CDC Ethernet Device, 02:80:79:95:74:20
> Aug 24 10:52:47 armadillo kernel: cdc_acm 2-1:1.2: This device cannot do calls on its own. It is not a modem.
> Aug 24 10:52:47 armadillo kernel: cdc_acm 2-1:1.2: ttyACM1: USB ACM device

原因はわかりませんが、突然LTEモジュールが切断・再認識しています。
このとき、ModemManager側がリソース(モデムポート)を開放できず、ttyACM0という名前を掴みっぱなしになり、
モデムポート名が ttyACM0 -> ttyACM1 に変化しています。

NetworkManagerのコネクション設定は"ttyACM0"を前提にしているので
データ接続に行かない状態になっているものと思います。

ModemManagerを一旦止めて、
モジュールを再起動すればttyACM0が割り当てられデータ接続可能になると思います。
※ wwan-force-restartをすると上記の処理が行われ再接続されるはずです。

なお、LTEモジュールのファーム30063以前では、
突然モジュールがリブートする不具合があり、ファーム36584で修正されています。
もし、30063以前をご利用であればアップデートすることを推奨します。
https://users.atmark-techno.com/change_notification/2018-009

> LTE通信に失敗した場合はLTEモジュール再起動(wwan-force-restartの実行)を実施しようと思っているのですが、
> 通信失敗時毎回LTEモジュール再起動するようにしても問題はないでしょうか。
はい。どうしても通信できない場合は、LTEモジュールを再起動し、
再接続を試みたほうが良いです。

> また、NetworkManagerの再起動は今まで通り実施した方がよいのか、
> LTEモジュール再起動をすればNetworkManagerの再起動は必要ないものなのかを教えていただきたいです。
NetworkManagerの再起動は不要です。

> LTEモジュール再起動でも通信が回復しない場合は、何回か通信を試した後にOSリブートまで実施するように考えています。
これも実施したほうが良いと思います。

今回は、自前のアプリ側に再接続処理を入れるとのことですが、
再接続サービスでも、デフォルトでは無効なのですが、リブートする処理が入っています。

「/etc/connection-recover/gsm-ttyACM0_connection-recover.conf」
で以下を設定を変更することで有効になります。
FORCE_REBOOT=TRUE

k.shiratori

2018年9月13日 20時29分

お世話になっております。

迅速なご確認ありがとうございました。
ご確認いただいた内容から、弊社アプリケーションの仕様を検討させていただきたいと思います。

追加の質問なのですが、はじめの現象に立ち返ると、LEDの真ん中のランプが消灯していることからLTEモジュールがなんらかの影響によって停止していると想定していたのですが、ログ解析の結果から、この状況になった場合はLEDの真ん中のランプが消灯してしまう、という理解でよろしいのでしょうか?

at_koseki

2018年9月14日 11時45分

古関です。

> 追加の質問なのですが、はじめの現象に立ち返ると、LEDの真ん中のランプが消灯していることからLTEモジュールがなんらかの影響によって停止していると想定していたのですが、
> ログ解析の結果から、この状況になった場合はLEDの真ん中のランプが消灯してしまう、という理解でよろしいのでしょうか?

はい。

usb1(LTEモジュールのcdc-etherデバイス)がdownすると
LED3を消す仕組みになっています。

操作は以下のスクリプトでやっています。
/etc/NetworkManager/dispatcher.d/99updownLED

k.shiratori

2018年9月19日 10時05分

お世話になっております。

> usb1(LTEモジュールのcdc-etherデバイス)がdownすると
> LED3を消す仕組みになっています。
>
> 操作は以下のスクリプトでやっています。
> /etc/NetworkManager/dispatcher.d/99updownLED

ご回答ありがとうございました。
上記承知いたしました。

いただいた情報を元に、アプリ側で対応を入れたいと思います。

よろしくお願いいたします。