3G/LTE 再接続サービスでのLTE通信の復旧について

y-matou

2020年8月21日 12時54分

いつもお世話になっております。

掲題の件、複数台のArmadillo-IoTゲートウェイG3 M1-Dモデル(AGX3142-D00Z)にてLTE通信を行うシステムを運用しております。
閉域網での運用の為、3G/LTE 再接続サービスのPINGを送信する宛先を疎通可能なサーバの宛先にしているのですが、
先日、PINGを送信する宛先のサーバが10日程度停止し、3G/LTE再接続サービス側で切断状態と判定される状態が続きました。
サーバの可動再開後、問題なく通信が復旧する見込みでしたが、復旧したのは複数台中1台のみでした。
その後、通信が復旧しなかった一部のArmadillo-IoT G3については直接電源の入り切りをしてもらい復旧しました。
複数台のAramadillo-IoT G3はほぼ同じ構成であり、同じ種類、契約内容のSIMを使用しており、通常時の通信状況についてもさほど差はありません。
messagesを確認したところ、復旧した方、復旧しなかった方のArmadillo-IoT G3の両方で疎通可能なサーバとの通信に複数回失敗後、
システムの再起動が実行されており、再起動後に復旧した方はLTE通信が再開され、復旧しなかった方はLTE通信の確立に失敗していました。
messagesを抜粋したファイルを添付致します。復旧した方、しなかった方の差について何かあれば教えて頂きたく思います。
また、このような現象を回避する方法がありましたら合わせて何かあれば教えて頂きたく思います。

Armadillo-IoT G3の構成は以下になります。
・Linuxカーネル： v4.9-at12 ※
・ブートローダー：v20
・使用LTE SIM：UNO SIM LTE microSIM (docomoの閉域網に接続)

※USBポートにUSB-シリアルとして認識するデバイスを接続して使用しているため、
　以下のブログの内容を元にデバイスツリーを変更し、
　システム起動後にUSB(CON7)の電源をONにするようにしています。
　https://armadillo.atmark-techno.com/blog/615/3882

ファイル	ファイルの説明
messages_復旧した方_抜粋.txt	LTE通信が復旧したArmadillo-IoT G3のmessagesの抜粋
messages_復旧しない方_抜粋.txt	LTE通信が復旧しないArmadillo-IoT G3のmessagesの抜粋

コメントを投稿するにはログインまたは登録をしてください

at_syunya.ohshio

2020年8月21日 16時49分

大塩です。

> messagesを確認したところ、復旧した方、復旧しなかった方のArmadillo-IoT G3の両方で疎通可能なサーバとの通信に複数回失敗後、
> システムの再起動が実行されており、再起動後に復旧した方はLTE通信が再開され、復旧しなかった方はLTE通信の確立に失敗していました。
> messagesを抜粋したファイルを添付致します。復旧した方、しなかった方の差について何かあれば教えて頂きたく思います。

復旧しない側のログを確認すると、error: ec25 connect wait timeout というログが確認できます。
こちらはEC25-Jを認識できない状態となっているため、発生しているログです。
こちらの状態は、確率で発生するため復旧するものとしないものが出ている状況であると思われます。

> また、このような現象を回避する方法がありましたら合わせて何かあれば教えて頂きたく思います。
>
> Armadillo-IoT G3の構成は以下になります。
> ・Linuxカーネル： v4.9-at12 ※
> ・ブートローダー：v20
> ・使用LTE SIM：UNO SIM LTE microSIM (docomoの閉域網に接続)
>
> ※USBポートにUSB-シリアルとして認識するデバイスを接続して使用しているため、
> 　以下のブログの内容を元にデバイスツリーを変更し、
> 　システム起動後にUSB(CON7)の電源をONにするようにしています。
> 　https://armadillo.atmark-techno.com/blog/615/3882

今回発生している状態につきましては、Linuxカーネルat13以降にて 3G/LTEモジュールのシャットダウン・リセットシーケンスを改善することで修正されています。
参考: 製品アップデートページ(2020年03月)
https://armadillo.atmark-techno.com/news/20200316/software-update-aiotg3

このため、ec25-utilsのバージョンを 1.1.0 に、Linuxカーネルのバージョンを at13 以降にアップデートし、動作を確認していただけますでしょうか。
以上です。

コメントを投稿するにはログインまたは登録をしてください

y-matou

2020年8月24日 8時54分

アットマークテクノ大塩様

ご回答頂きありがとうございます。
ec25-utilsを1.1.0、とLinuカーネルのバージョンを at13 以降にアップデートして動作確認を行う旨、了解致しました。
現地で動作しているイメージを確認したところ、ec25-utilsのバージョンは1.1.0となっていましたので、
ユーザーランドはこのままで、カーネルのみをat13以降に更新すれば改善されるとの認識ですがよろしいでしょうか？
> いつもお世話になっております。
>
> 掲題の件、複数台のArmadillo-IoTゲートウェイG3 M1-Dモデル(AGX3142-D00Z)にてLTE通信を行うシステムを運用しております。
> 閉域網での運用の為、3G/LTE 再接続サービスのPINGを送信する宛先を疎通可能なサーバの宛先にしているのですが、
> 先日、PINGを送信する宛先のサーバが10日程度停止し、3G/LTE再接続サービス側で切断状態と判定される状態が続きました。
> サーバの可動再開後、問題なく通信が復旧する見込みでしたが、復旧したのは複数台中1台のみでした。
> その後、通信が復旧しなかった一部のArmadillo-IoT G3については直接電源の入り切りをしてもらい復旧しました。
> 複数台のAramadillo-IoT G3はほぼ同じ構成であり、同じ種類、契約内容のSIMを使用しており、通常時の通信状況についてもさほど差はありません。
> messagesを確認したところ、復旧した方、復旧しなかった方のArmadillo-IoT G3の両方で疎通可能なサーバとの通信に複数回失敗後、
> システムの再起動が実行されており、再起動後に復旧した方はLTE通信が再開され、復旧しなかった方はLTE通信の確立に失敗していました。
> messagesを抜粋したファイルを添付致します。復旧した方、しなかった方の差について何かあれば教えて頂きたく思います。
> また、このような現象を回避する方法がありましたら合わせて何かあれば教えて頂きたく思います。
>
> Armadillo-IoT G3の構成は以下になります。
> ・Linuxカーネル： v4.9-at12 ※
> ・ブートローダー：v20
> ・使用LTE SIM：UNO SIM LTE microSIM (docomoの閉域網に接続)
>
> ※USBポートにUSB-シリアルとして認識するデバイスを接続して使用しているため、
> 　以下のブログの内容を元にデバイスツリーを変更し、
> 　システム起動後にUSB(CON7)の電源をONにするようにしています。
> 　https://armadillo.atmark-techno.com/blog/615/3882
>

コメントを投稿するにはログインまたは登録をしてください

at_syunya.ohshio

2020年8月24日 10時18分

大塩です。

> ご回答頂きありがとうございます。
> ec25-utilsを1.1.0、とLinuカーネルのバージョンを at13 以降にアップデートして動作確認を行う旨、了解致しました。
> 現地で動作しているイメージを確認したところ、ec25-utilsのバージョンは1.1.0となっていましたので、
> ユーザーランドはこのままで、カーネルのみをat13以降に更新すれば改善されるとの認識ですがよろしいでしょうか？

上記認識で問題ありません。
ec25-utils 1.1.0 とカーネル at13 以降が揃うことで、改善の動作が行われる仕様となっています。
以上です。

コメントを投稿するにはログインまたは登録をしてください

y-matou

2020年9月7日 16時35分

先日、ご回答頂いた内容を元にLinuxのカーネルバージョンをat12からat14に変更しましたが、
再起動すると稀にLTE通信の確立に失敗する端末がありましたので再度質問させて頂きたい事項がございます。

1.USBポートにUSB-シリアルとして認識するデバイスを接続して使用しているため、デバイスツリーを変更し、
USB（CON7）の電源（CON7_USB_VBUS）をGPIOで制御し、USBポートの電源を遅延させて入れています。
タイミングとしてはNetworkManagerが起動後に起動するサービス内でUSBポートの電源を入れるようにしています。
上記ではLTEモジュールがUSBデバイスとして認識された後のタイミングとして不適切でしょうか？
LTEモジュールがUSBデバイスとして認識された後に起動されるサービスがあれば教えて頂きたく思います。

2.3G/LTE 再接続サービスの設定内にFORCE_REBOOTというものがありますが、項目名からすると失敗時に強制的に
　リブートをかけるような設定だと思われます。この設定の仕様と想定される使用用途を教えて頂きたく思います。
　※遠隔地に設置してあり、LTE通信ができなくなった場合に手動で電源の入り切りが難しいため、最悪、システム再起動してでも復旧するのであれば設定しておきたいと考えています。

3.上記の問題とは別にLTEモジュールの認識が他に比べて遅い端末があることがわかりました。1ヶ月半程度に設置した時点では
他と変わりなく使用できていたのですが、他の端末が起動からttyUSB3を認識するまで7秒程度のところ、
該当の端末では12秒程度となっております。その為、USBポートにUSB-シリアルとして認識するデバイスを接続していると
必ずLTE通信の確立に失敗してしまいます。ログを添付します。ログから何か原因等わかりますでしょうか？

本来であれば、このようにUSBデバイスを使用する場合は、3G/LTE のネットワークデバイス名に ttyCommModemを利用する方法で運用するべきだとは思うのですが、システムを構築したのが対応ソフトウェアがリリースされる前で、
modemmanagerとatmark-x1-baseのバージョン条件を満たしておらず、閉域網での運用の為、インターネット接続しての更新も難しいことからどうにかLTE通信でトラブルが発生した際に自動で復旧できるようにしたいと考えています。

ファイル	ファイルの説明
messages_通常の端末.txt
messages_LTE認識遅い端末.txt

コメントを投稿するにはログインまたは登録をしてください

at_syunya.ohshio

2020年9月8日 11時14分

大塩です。

ご確認ありがとうございます。
以下、質問に回答致します。

> 1.USBポートにUSB-シリアルとして認識するデバイスを接続して使用しているため、デバイスツリーを変更し、
> USB（CON7）の電源（CON7_USB_VBUS）をGPIOで制御し、USBポートの電源を遅延させて入れています。
> タイミングとしてはNetworkManagerが起動後に起動するサービス内でUSBポートの電源を入れるようにしています。
> 上記ではLTEモジュールがUSBデバイスとして認識された後のタイミングとして不適切でしょうか？
> LTEモジュールがUSBデバイスとして認識された後に起動されるサービスがあれば教えて頂きたく思います。

お客様が想定されているのは「EC25-JをUSBデバイスとして認識→USB(CON7)の電源投入」とのことであるため、
「NetworkManagerが起動後に起動するサービス内」で以下のようなスクリプトを追加してはどうでしょうか。

EC25_VIDPID="2c7c:0125"
TIMEOUT=90
 
wait_ec25_wakeup()
{
    for ((i=0; i < $TIMEOUT; i++)); do
        lsusb | grep $EC25_VIDPID -q
        if [ $? -eq 0 ]; then
            echo "found EC25"
            break;
        fi
        echo -n "."
        sleep 1
    done
}

簡単な確認の結果、問題なく動作しています。
お客様の想定しているタイミングより早い場合は、EC25-J認識後にwaitを入れる等の調整をしてください。

> 2.3G/LTE 再接続サービスの設定内にFORCE_REBOOTというものがありますが、項目名からすると失敗時に強制的に
> 　リブートをかけるような設定だと思われます。この設定の仕様と想定される使用用途を教えて頂きたく思います。
> 　※遠隔地に設置してあり、LTE通信ができなくなった場合に手動で電源の入り切りが難しいため、最悪、システム再起動してでも復旧するのであれば設定しておきたいと考えています。

「/etc/connection-recover/gsm-ttyUSB2_connection-recover.conf」の FORCE_REBOOT を TRUE 指定すると再起動します。
他スクリプト等から強制的にrebootさせたい場合などで使用可能です。
作成されたアプリケーションに、復旧手段の1つとして組み込むと良いと思われます。
また、閉域網運用であるとのことであるため、同ファイルのPING_DIST_IPをお客様の閉域網内で ping 導通可能な IP アドレスに変更してください。
ネットワークコネクションの接続確認は、ping が通るか否かで行っているため、上記作業を行う必要があります。

> 3.上記の問題とは別にLTEモジュールの認識が他に比べて遅い端末があることがわかりました。1ヶ月半程度に設置した時点では
> 他と変わりなく使用できていたのですが、他の端末が起動からttyUSB3を認識するまで7秒程度のところ、
> 該当の端末では12秒程度となっております。その為、USBポートにUSB-シリアルとして認識するデバイスを接続していると
> 必ずLTE通信の確立に失敗してしまいます。ログを添付します。ログから何か原因等わかりますでしょうか？

起動時間については、起動したタイミングの機体のコンディション等でも変化するため
確実に「EC25-JをUSBデバイスとして認識→USB(CON7)の電源投入」とする場合は、
1つ目のご質問にてお答えした方法をお試しいただけますでしょうか。

以上です。

コメントを投稿するにはログインまたは登録をしてください

y-matou

2020年9月24日 8時26分

アットマークテクノ大塩様

返事が遅くなり申し訳ございません。
ご回答頂きありがとうございます。
回答頂いた内容を元に対策を行おうかと思います。

コメントを投稿するにはログインまたは登録をしてください

Armadilloフォーラム

3G/LTE 再接続サービスでのLTE通信の復旧について

製品

コメント