Armadilloフォーラム

> 大塩です。
>
> > 掲題の件、複数台のArmadillo-IoT G3にてLTE通信を行うシステムを運用しております。
> > 閉域網での運用の為、3G/LTE 再接続サービスのPINGの送信先は到達可能なサーバのアドレスにしています。
> > 先日、PINGを送信する宛先のサーバの再起動があり、一時的にPINGが到達しなくなった為、
> > 3G/LTE再接続サービス側で切断状態と判断され、再接続処理が実行されましたが、
> > その際に、1台だけLTE通信が復旧しないものがありました。
> >
> > 遠隔地にある為、現在もLTE通信が停止している状態なのですが、
> > 昨年の12月にPING送信先のサーバが停止した際にも今回LTE通信が復旧しない端末で同様の現象が発生しました。
> >
> > Armadillo-IoT G3の構成は以下になります。
> > ・モデル： Armadillo-IoTゲートウェイG3 M1-Dモデル(AGX3142-D00Z)
> > ・Linuxカーネル： v4.9-at14 ※
> > ・ブートローダー：v20
> > ・使用LTE SIM：UNO SIM LTE microSIM (docomoの閉域網に接続)
> > 　CON1に"Armadillo-IoT 絶縁RS485 アドオンモジュール RS02"に装着しその先に温湿度センサを接続
> > 　USBポートにはオムロンの環境センサ"2JCIE-BU01"を接続
> >
> > ※以下のブログの内容を元にデバイスツリーを変更し、USBポートの電源を制御できるようにしたものを使用
> > 　https://armadillo.atmark-techno.com/blog/615/3882
> >
> > 昨年12月に発生した際のログを確認したところ、LTEモジュールの再起動を行う"wwan-force-restart"が実行され
> > NetworkManagerにてLTEのコネクションを無効化させていることろまでは記録されていましたが、
> > 以降のログは記録されていませんでした。
> > また、復旧前に3G/LTE 再接続サービスの状態を読み出したところ、以下のように"send-at"でLTEモジュールの
> > 電源を切るコマンド"AT+QPOWD"を送信するプロセスがCGroup内にあった為、何等かの要因で"send-at"で"AT+QPOWD"を
> > 送信する際にフリーズしてしまったと推測しています。
> > --------------------------------------------------------------------------------------------------------
> > # service connection-recover status
> > 　● connection-recover.service - Connection Recover
> > 　 Loaded: loaded (/lib/systemd/system/connection-recover.service; enabled; vendor preset: enabled)
> > 　 Active: active (running) since Fri 2016-11-04 02:16:49 JST; 5 years 3 months ago
> > 　 Process: 1491 ExecStart=/usr/bin/connection-recover start (code=exited, status=0/SUCCESS)
> > 　 Main PID: 1665 (connection-reco)
> > 　 CGroup: /system.slice/connection-recover.service
> > 　 ├─ 888 /bin/bash /usr/bin/wwan-force-restart
> > 　 ├─ 923 expect /usr/bin/send-at /dev/ttymxc6 AT+QPOWD
> > 　 └─1665 /bin/bash /usr/bin/connection-recoverd
> > --------------------------------------------------------------------------------------------------------
> >
> > "send-at"がフリーズしてしまう原因に心当たりはございますでしょうか？
> > また、このような現象が発生した場合に、自動で復旧できるよう"ip"コマンドでネットワークインターフェース"ppp0"が
> > ない場合にOSの再起動を実行するシェルスクリプトを作成し、cronで1時間に1回実行しようかと考えていますが、
> > この対策は適切でしょうか？
>
> ご報告頂いた現象につきましては、「3G/LTE再接続サービス(connection-recover)使用時、極稀に停止してしまう現象」のようにみえます。
> これは、過去の製品アップデートにて atmark-x1-base のアップデートで対応済みとなっています。
> ■アップデートページ
> https://armadillo.atmark-techno.com/news/20210428/software-update-aiotg3
>
> お手数ですが、ご利用中のatmark-x1-base のバージョンをご確認いただけますでしょうか。
>

> # dpkg -l | grep "atmark-x1-base"
> 

>
> 遠隔地に機器があるとのことであるため、上記が難しければご利用になったユーザーランドのバージョンをご確認いただけますでしょうか。
>
> 以上です。

早々にご回答頂きありがとうございます。
手元に同等の環境のArmadilloがある為、"atmark-x1-base"のバージョンを確認したところ、
2.3.2-1でした。

-------------------------------------------------------------------------------------------------------------------------------
$ dpkg -l | grep "atmark-x1-base"
ii atmark-x1-base 2.3.2-1 armhf Atmark Techno X1 platform base software
-------------------------------------------------------------------------------------------------------------------------------

> ご報告頂いた現象につきましては、「3G/LTE再接続サービス(connection-recover)使用時、極稀に停止してしまう現象」のようにみえます。
> これは、過去の製品アップデートにて atmark-x1-base のアップデートで対応済みとなっています。

こちらについてですが、リンク先を確認しましたところ、atmark-x1-base (2.4.3-1)のアップデート内容は以下のようになっていました。
"connection-recover による再接続時、極稀に nmcli connection up コマンドで停止してしまう現象の対応"

今回の現象ですが、wwan-force-restart内でArmadillo-IoT G3 M1モデル向けのLTEモジュール再起動処理
"g3_m1_wwan_force_restart"が呼ばれた際に、"# Power off and disconnect"とコメントが入っている処理の内、
"send-at /dev/ttymxc6 AT+QPOWD"でフリーズしているように思われます。
"nmcli connection up"コマンドについては、その先の"# Power on and connect"以降で実行されている為、
上記のアップデートで対応された内容とは違うのではないかと考えています。

また、"atmark-x1-base"をアップデートする場合、閉域網で運用している端末の為、事前に別のArmadilloでパッケージのダウンロードのみしておき、
ダウンロードしたパッケージを利用してアップデートすることになると思います。
修正されたバージョン"2.4.3-1"のパッケージは見つからず、最新の"3.1.3-1"しかダウンロードできないようです。
古いバージョン"2.3.2-1"からいきなり最新の"3.1.3-1"にアップデートしても問題ないでしょうか？