Armadilloフォーラム

LTE通信の再接続について

hhlin

2024年1月26日 18時58分

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

LTE通信に関して、nmcliコマンドを使用してLTEのコネクションを作成し、
connection-recoverサービスを起動しています。

現在の状況では、LTEの再接続は確認していますが、
復旧できないケースも多く発生しています。

connection-recoverサービスで復旧できない状況について、
他の対策などを教えていただけますでしょうか。

また、再接続を行うシステムログを確認したいと思いますが、保存先を教えていただけますか。

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

コメント

at_mitsuhiro.yoshida

2024年1月29日 15時33分

吉田です。

connection-recover が再接続を実施する状況では、接続が難しい状況になっていることが多いので
しばらくしないと復旧しないケースも多いです。

Cat.M1 モデルをご利用で、間欠動作ではなく連続動作での運用であれば、
製品マニュアル「LTE モデム EMS31-J 省電力などの設定 (Cat.M1 モデル)」
https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…
の suspend、psm、edrx の設定を disable にしていただきますと、
スリープ状態になる時間を減らすことが出来るので、ping 導通確認の失敗が減るかと思われます。

ログは、/var/log/message に保存されております。
LTE の再接続サービスは "connection-recover" や "wwan-force-restart" で検索ください。

製品マニュアルの「LTE 再接続サービス」に connection-recover の設定パラメーターを記載しております。
https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…
LTE モジュールを再起動した方が再接続が成功する可能性が高いのであれば、
WWAN_FORCE_RESTART_COUNT の値を小さくする手もあります。

吉田様

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

こちらの環境で、
① EMS31-J 省電力:設定なし
② LTE 再接続サービス:CHECK_INTERVAL_SEC(120)、WWAN_FORCE_RESTART_COUNT(10)
以上の設定で5日間ほど20台のA6EのLTE通信がほとんど接続不能状態になっておりました。

ログを回収し、EMS31-J 省電力の設定をdisableにし、LTE 再接続サービスのCHECK_INTERVAL_SECの設定値を60に変更し、WWAN_FORCE_RESTART_COUNTの設定値を1に変更しました。

現在発生している現象について、以下の3種類が確認されました。
① WWAN消灯、rebootコマンドで再起動したらLTE通信が復旧されました。ログは20240130_reboot_OK.txtをご参照ください。
② WWAN消灯、rebootコマンドで再起動してもLTE復旧せず、電源を入れ直しで復旧されました。ログは20240130_reboot_NG.txtをご参照ください。
③ WWAN点灯、ifconfigコマンドで確認したらIPは取得しておりますが、pingが通らなかったです。rebootコマンドで最後にシステムが停止してしまって、電源を入れ直さないと復旧できない状況でした。ログは20240130_ppp0.txtをご参照ください。

昨日新しい設定を導入してから24時間が経過し、8台A6EのLTE接続が断線している状況です。
ログの解析やアドバイスをいただければ幸いです。

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

ファイル ファイルの説明
20240130_ppp0.txt WWAN点灯、IPあり、接続不能、rebootコマンドでシステム停止
20230130_reboot_OK.txt WWAN消灯、IPなし、接続不能、rebootコマンドで復旧
20230130_reboot_NG.txt WWAN消灯、IPなし、接続不能、電源入れ直しで復旧

at_mitsuhiro.yoshida

2024年2月1日 10時07分

吉田です。

ログを確認したところ、実際に AT+COPS コマンドでオペレーターを取得できておらず
接続ができない状況が続いております。

Cat.M1 モデルですと再接続に時間がかかることがあるので、
チェック間隔を 60 秒にすると、接続処理中に接続処理を中断して再度接続しようとする動作を繰り返す可能性はあります。

吉田様

ご返事ありがとうございます。

添付したログファイルは、チェック間隔が 120 秒のA6Eのログです。
接続ができない状況が続いている問題について、何か解決策のご提案がございますでしょうか?

また、今朝SIMカード会社の障害通知があり、
Gatewayのオンライン状態を確認すると、
A6EはSIMカード通信障害が発生した時点で断線され、現在まで復旧できない状況です。
A6Eの隣にG3Lについては、同様に通信障害が発生した時点で断線され、通信が回復した際にG3Lの通信も同時に復旧されました。
このことから、A6EのLTE再接続処理に何か不具合があった可能性が考えられます。
解析していただけますでしょうか。

それとも他に必要な情報がありましたら、こちらで確認いたしますので、どうぞお知らせください。

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

> 吉田です。
>
> ログを確認したところ、実際に AT+COPS コマンドでオペレーターを取得できておらず
> 接続ができない状況が続いております。
>
> Cat.M1 モデルですと再接続に時間がかかることがあるので、
> チェック間隔を 60 秒にすると、接続処理中に接続処理を中断して再度接続しようとする動作を繰り返す可能性はあります。

at_mitsuhiro.yoshida

2024年2月2日 17時28分

吉田です。

情報のご連絡ありがとうございます。

A6E の Cat.M1 モデルに関して、2023年12月の製品アップデートにて、
https://armadillo.atmark-techno.com/news/20231226/software-update-aiota…
再接続処理が失敗するパターンの改善処理を追加しております。

ログから気付いたことがあれば別途ご連絡をいたします。

よろしくお願いします。

吉田様

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

情報ありがとうございます。
すみませんが、システムに既に入っているものに影響を与えず、製品アップデートのみを適用する方法についてはありますでしょうか?
よろしくお願いいたします。

> 吉田です。
>
> 情報のご連絡ありがとうございます。
>
> A6E の Cat.M1 モデルに関して、2023年12月の製品アップデートにて、
> https://armadillo.atmark-techno.com/news/20231226/software-update-aiota…
> 再接続処理が失敗するパターンの改善処理を追加しております。
>
> ログから気付いたことがあれば別途ご連絡をいたします。
>
> よろしくお願いします。

at_mitsuhiro.yoshida

2024年2月2日 18時12分

吉田です。

Armadillo Base OS(ABOS) の更新する手順としては、

ABOS Web が使える環境でしたら、ABOS の SWU イメージのアップデートが可能です。
https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…

または、USB メモリに ABOS の SWU ファイルを書き込むことでも実施できます。
https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…

Armadillo-IoT ゲートウェイ A6E の ABOS のファイルは以下に存在します。
https://armadillo.atmark-techno.com/resources/software/armadillo-iot-a6…

吉田様
お世話になっております。
OSを更新しましたが、LTE再接続の不具合はまだ発生しています。

状況としては、以下の3つのパターンが発生しています。
パターン①
IPアドレスは割り当て済みですが、インターネットに接続できない状態です。
/var/log/messagesのログを確認すると、次のようなエラーメッセージが繰り返し表示されています。
Feb 21 14:07:29 armadillo user.err aardvark-dns[0]: 3790 dns request got empty response

パターン②
/var/log/messagesに以下のメッセージが表示され、電源を入れ直したら通信が復旧されます。
Feb 18 22:52:14 armadillo daemon.err [1989]: [modem0] port ttyCommModem timed out 10 consecutive times, marking modem as invalid
Feb 18 22:52:14 armadillo daemon.info NetworkManager[1032]: [1708264334.7467] device (ttyCommModem): state change: prepare -> unmanaged (reason 'removed', sys-iface-state: 'removed')
Feb 18 22:52:14 armadillo daemon.info NetworkManager[1032]: [1708264334.7977] manager: NetworkManager state is now CONNECTED_LOCAL
Feb 18 22:52:14 armadillo daemon.warn [1989]: [modem0/bearer2] connection attempt #2232 failed: Couldn't validate update of profile '1': No AT port available to run command
Feb 18 22:52:14 armadillo daemon.info [1989]: [modem0/bearer2] connection #2232 finished: duration 0s
Feb 18 22:52:14 armadillo daemon.warn NetworkManager[1032]: [1708264334.8580] modem-broadband[ttyCommModem]: failed to disconnect modem: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Object does not exist at path g/org/freedesktop/ModemManager1/Modem/0 h
Feb 18 22:52:40 armadillo daemon.warn [1989]: [modem0/ttyCommModem/at] close blocked by driver for more than 7 seconds!
Feb 18 22:52:40 armadillo user.notice wwan-led: sim or modem not found or startup...

パターン③
/var/log/messages にLTE再接続のログが繰り返していますが、接続できませんでした。
特にキャリア側で通信障害が発生した場合、キャリア側が復旧されてもGatewayを再起動しないと再接続を行っても接続ができません。

パターン③について、再現方法は以下の通りです。キャリアの管理画面で一旦SIMカードの利用を停止し、A6Eの通信停止を確認した後、SIMカードを再度利用開始する設定を行います。

最近キャリア側でメンテナンスや不具合が多発しており、その後A6Eを再起動しないと復旧できない状況に困っています。
この問題に対する解析と解決策をお願いいたします
何卒よろしくお願いいたします。

> 吉田です。
>
> Armadillo Base OS(ABOS) の更新する手順としては、
>
> ABOS Web が使える環境でしたら、ABOS の SWU イメージのアップデートが可能です。
> https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…
>
> または、USB メモリに ABOS の SWU ファイルを書き込むことでも実施できます。
> https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…
>
> Armadillo-IoT ゲートウェイ A6E の ABOS のファイルは以下に存在します。
> https://armadillo.atmark-techno.com/resources/software/armadillo-iot-a6…

at_mitsuhiro.yoshida

2024年2月29日 9時35分

吉田です。

お手数おかけします。状況詳細ありがとうございます。
内容確認いたします。

よろしくお願いします。

at_mitsuhiro.yoshida

2024年3月4日 17時44分

吉田です、情報ありがとうございます。

パターン① に関しては、
名前解決ができていない状況ですので、プロバイダーに確認いただけますでしょうか。

パターン② に関しては、
お手数ですが正常に接続している状況からこの状態になるまでのログが残っていましたらご提供いただけませんでしょうか。

パターン③ に関しては、
LTE モジュールの再起動 (wwan-force-restart)でも復帰しませんでしょうか?
復帰するようであれば、製品マニュアル「再接続サービス設定パラメーター」の
WWAN_FORCE_RESTART_COUNT を 2 など小さい数字に変更すると復帰が早くなるかと思われます。
https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…

よろしくお願いします。

吉田様

お世話になっております。ご返信ありがとうございます。

パターン①について、プロバイダー側の通信問題という認識でよろしいでしょうか。
パターン②について、ログを添付いたします。ご確認をお願いいたします。
パターン③について、WWAN_FORCE_RESTART_COUNTの設定は既に1で設定しておりますが、復帰しませんでした。LTEモジュールがリセットされたログの確認方法を教えていただけますでしょうか。

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

> 吉田です、情報ありがとうございます。
>
> パターン① に関しては、
> 名前解決ができていない状況ですので、プロバイダーに確認いただけますでしょうか。
>
> パターン② に関しては、
> お手数ですが正常に接続している状況からこの状態になるまでのログが残っていましたらご提供いただけませんでしょうか。
>
> パターン③ に関しては、
> LTE モジュールの再起動 (wwan-force-restart)でも復帰しませんでしょうか?
> 復帰するようであれば、製品マニュアル「再接続サービス設定パラメーター」の
> WWAN_FORCE_RESTART_COUNT を 2 など小さい数字に変更すると復帰が早くなるかと思われます。
> https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…
>
> よろしくお願いします。

ファイル ファイルの説明
A6E008-2402241352.txt パターン②ログ-1
A6E022-2402241357.txt パターン②ログ-2
A6E004-2402241419.txt パターン①ログ

at_mitsuhiro.yoshida

2024年3月6日 17時07分

吉田です。

情報ありがとうございます。

> パターン①について、プロバイダー側の通信問題という認識でよろしいでしょうか。

DNS に関しては、LTE 接続時に払い出されるので、
それがは以来出されていないのではないかと推測しております。

> パターン②について、ログを添付いたします。ご確認をお願いいたします。

再接続サービスで救えないルートに入っているようですので、
ワークアラウンドの追加を検討いたします。

> パターン③について、WWAN_FORCE_RESTART_COUNTの設定は既に1で設定しておりますが、復帰しませんでした。LTEモジュールがリセットされたログの確認方法を教えていただけますでしょうか。

重ね重ねお手数をおかけしますが、
③に関して再現が可能でしたらログを添付いただけますでしょうか。

吉田様

お世話になっております。
パターン③のログを添付いたします。
プロバイダ側が障害から復旧されて、A6E側がリトライしていても復帰されませんでした。
rebootコマンドでA6Eを再起動したら正常に接続できました。

ご確認のほどよろしくお願いいたします。

> 吉田です。
>
> 情報ありがとうございます。
>
> > パターン①について、プロバイダー側の通信問題という認識でよろしいでしょうか。
>
> DNS に関しては、LTE 接続時に払い出されるので、
> それがは以来出されていないのではないかと推測しております。
>
> > パターン②について、ログを添付いたします。ご確認をお願いいたします。
>
> 再接続サービスで救えないルートに入っているようですので、
> ワークアラウンドの追加を検討いたします。
>
> > パターン③について、WWAN_FORCE_RESTART_COUNTの設定は既に1で設定しておりますが、復帰しませんでした。LTEモジュールがリセットされたログの確認方法を教えていただけますでしょうか。
>
> 重ね重ねお手数をおかけしますが、
> ③に関して再現が可能でしたらログを添付いただけますでしょうか。

ファイル ファイルの説明
202402071520.txt

at_mitsuhiro.yoshida

2024年3月11日 15時42分

吉田です。

ログのご提供ありがとうございます。

パターン③もパターン②と同じく接続中状態から抜けたせずに再接続サービスが動かない状況となっており、
パターン②と同じワークアラウンドで対応できますので、3 月の製品アップデートにて対応いたします。

よろしくお願いします。

吉田様

お世話になっております。
A6EのOSをv3.19.1-at.3にアップグレードして、4月26日の午後から検証してみましたが、
ログによりますと、5月3日にLTEが停止してしまい、復旧されない状態です。
添付のログファイルをご確認ください。

また、OSのアップグレードについて、2月に手動でOSをアップグレードしました。
今回は、LANケーブルを差し込んだらOSが自動的にv3.19.1-at.3にアップグレードされたようです。
OSの自動的アップグレードは仕様でしょうか?停止方法について教えていただけますでしょうか。
ご確認のほど、よろしくお願いいたします。

> 吉田です。
>
> ログのご提供ありがとうございます。
>
> パターン③もパターン②と同じく接続中状態から抜けたせずに再接続サービスが動かない状況となっており、
> パターン②と同じワークアラウンドで対応できますので、3 月の製品アップデートにて対応いたします。
>
> よろしくお願いします。

ファイル ファイルの説明
messages.log
messages.0.log

at_mitsuhiro.yoshida

2024年5月8日 17時11分

吉田です。

ログの添付ありがとうございます。

ログの中で再接続サービス (connection-recover) のログが見つからなかったのですが、
稼働させていますでしょうか。

自動アップデートの停止に関しては、過去のフォーラムにありますとおり
https://armadillo.atmark-techno.com/forum/armadillo/16421

armadillo# persist_file -d /etc/runlevels/default/swupdate-url
armadillo# rc-service swupdate-url stop

を実行ください。

吉田様

ご返事ありがとうございます。設定内容を確認いたします。

OSの自動更新後、再接続サービス (connection-recover)を再度設定する必要があるでしょうか?

> 吉田です。
>
> ログの添付ありがとうございます。
>
> ログの中で再接続サービス (connection-recover) のログが見つからなかったのですが、
> 稼働させていますでしょうか。
>
> 自動アップデートの停止に関しては、過去のフォーラムにありますとおり
> https://armadillo.atmark-techno.com/forum/armadillo/16421
>
>

> armadillo# persist_file -d /etc/runlevels/default/swupdate-url
> armadillo# rc-service swupdate-url stop
> 

>
> を実行ください。

at_mitsuhiro.yoshida

2024年5月9日 16時47分

吉田です。

対象ファイルに persist_file を実行すると自動アップデート後も動作します。

armadillo:~# cp /etc/atmark/connection-recover.conf.example /etc/atmark/connection-recover.conf
/etc/atmark/connection-recover.conf を編集
armadillo:~# rc-update add connection-recover default
armadillo:~# persist_file /etc/atmark/connection-recover.conf
armadillo:~# persist_file /etc/runlevels/default/connection-recover

製品マニュアル「LTE 再接続サービスを有効にする」「LTE 再接続サービスの設定値を永続化する」も参照願います。
https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…
https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…

お手数ですが、よろしくお願いします。

吉田様

お世話になっております。嘉創株式会社の林です。

確認したところ、connection-recoverは started 状態となっておりますが、
armadillo:/var/log# rc-status | grep connection-recover
connection-recover [ started ]

前日のログにconnection-recover の動作が見つからなかったことは、どう確認すればよいのでしょうか?
よろしくお願いいたします。

> 吉田です。
>
> 対象ファイルに persist_file を実行すると自動アップデート後も動作します。
>
>

> armadillo:~# cp /etc/atmark/connection-recover.conf.example /etc/atmark/connection-recover.conf
> /etc/atmark/connection-recover.conf を編集
> armadillo:~# rc-update add connection-recover default
> armadillo:~# persist_file /etc/atmark/connection-recover.conf
> armadillo:~# persist_file /etc/runlevels/default/connection-recover
> 

>
> 製品マニュアル「LTE 再接続サービスを有効にする」「LTE 再接続サービスの設定値を永続化する」も参照願います。
> https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…
> https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…
>
> お手数ですが、よろしくお願いします。

at_mitsuhiro.yoshida

2024年5月21日 16時15分

吉田です。

回答遅くなりました。

NetworkManager の状態が connecting である状態が継続し、
2024 年 3 月のアップデート Armadillo Base OS (3.19.1-at.2)
https://armadillo.atmark-techno.com/news/20240326/software-update-aiota…
で atmark-wwan-utils (1.7.0) に追加したワークアラウンドにて
LTE モジュールを再起動して救済する想定でした。

いただいたログの始点の時点で再接続にトライしているループが開始しており、
その前の状況がわからず解析が難しいのが現状となります。

お手数ですが、状況確認のため connection-recover の設定ファイル
/etc/atmark/connection-recover.conf
を添付いただけますでしょうか。

> 確認したところ、connection-recoverは started 状態となっておりますが、
> armadillo:/var/log# rc-status | grep connection-recover
> connection-recover [ started ]
>
> 前日のログにconnection-recover の動作が見つからなかったことは、どう確認すればよいのでしょうか?
> よろしくお願いいたします。

吉田様

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

/etc/atmark/connection-recover.confが存在しないので、
/etc/atmark/connection-recover/gsm-ttyMux0_connection-recover.confの内容を送付いたします。
解析をお願いいたします。

armadillo:/var/log# cat /etc/atmark/connection-recover/gsm-ttyMux0_connection-recover.conf
#!/bin/sh

PRODUCT_NAME="Atmark Techno Armadillo-IoT Gateway A6E Cat.M1 Board"
CHECK_INTERVAL_SEC=120
PING_DEST_IP=8.8.8.8
DEVICE=ttyCommModem
TYPE=gsm
NETWORK_IF=ppp0
FORCE_REBOOT=FALSE
REBOOT_IF_SIM_NOT_FOUND=FALSE
WWAN_FORCE_RESTART_COUNT=1

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

> 吉田です。
>
> 回答遅くなりました。
>
> NetworkManager の状態が connecting である状態が継続し、
> 2024 年 3 月のアップデート Armadillo Base OS (3.19.1-at.2)
> https://armadillo.atmark-techno.com/news/20240326/software-update-aiota…
> で atmark-wwan-utils (1.7.0) に追加したワークアラウンドにて
> LTE モジュールを再起動して救済する想定でした。
>
> いただいたログの始点の時点で再接続にトライしているループが開始しており、
> その前の状況がわからず解析が難しいのが現状となります。
>
> お手数ですが、状況確認のため connection-recover の設定ファイル
> /etc/atmark/connection-recover.conf
> を添付いただけますでしょうか。
>
> > 確認したところ、connection-recoverは started 状態となっておりますが、
> > armadillo:/var/log# rc-status | grep connection-recover
> > connection-recover [ started ]
> >
> > 前日のログにconnection-recover の動作が見つからなかったことは、どう確認すればよいのでしょうか?
> > よろしくお願いいたします。

at_mitsuhiro.yoshida

2024年6月12日 9時47分

吉田です。

設定ファイルのご提供ありがとうございます。
特に進展はありませんが、現状を記載します。

Armadillo Base OS 3.19.1-at.3 にていただいた設定ファイルを適用し、
48 時間電波遮断袋で圏外の状況を作り出した後袋から取り出したところ、
connection-recover が稼働しており、LTE の接続が復旧することを確認いたしました。
電波遮断袋に入れている最中も、再接続をトライし続けておりました。

おそらく、以前いただいたログの状況になる前に connection-recover がなんらかの理由で
稼働しなくなったと思われるのですが、それを現状捕まえられておりません。

以下のように添削しました。ご確認ください。

吉田様

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

OS:3.19.1-at.3にて再度A6Eを電波遮断袋に入れて確認いたしましたところ、LTE通信が断線され、袋から取り出しても接続ができませんでした。ログファイルを添付いたします。

rebootコマンドでA6Eを再起動してもLTE通信の復旧ができず、一度電源を抜いて再起動したところ、LTE通信が復旧しました。この現象について、LTEモジュールに不具合があり、電源を切らないと復旧できないという認識でよろしいでしょうか。

ご確認をお願いいたします。

ファイル ファイルの説明
messages_20240701.log
messages.0_20240701.log

at_mitsuhiro.yoshida

2024年7月2日 15時02分

吉田です。

検証ありがとうございます。
2024年6月の製品アップデートにて
https://armadillo.atmark-techno.com/news/20240626/update-aiota6e

LTE 再接続サービス (connection-recover) の稼働状況を確認するためのログを追加しました。
お手数ですが、Armadillo Base OS 3.19.2-at.5 へアップデートし、
/var/log/connection-recover.log 及び /var/log/connection-recover.log.1 の
出力を確認いただけますでしょうか。

吉田様

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

BASE_OSを3.19.2-at.5へ更新し、connection-recover.logを添付いたしました。
ご確認のほどよろしくお願いいたします。

> 吉田です。
>
> 検証ありがとうございます。
> 2024年6月の製品アップデートにて
> https://armadillo.atmark-techno.com/news/20240626/update-aiota6e
>
> LTE 再接続サービス (connection-recover) の稼働状況を確認するためのログを追加しました。
> お手数ですが、Armadillo Base OS 3.19.2-at.5 へアップデートし、
> /var/log/connection-recover.log 及び /var/log/connection-recover.log.1 の
> 出力を確認いただけますでしょうか。

ファイル ファイルの説明
connection-recover.20240716.log
messages.20240716.log
connection-recover.0.20240716.log
messages.0.20240716.log

at_mitsuhiro.yoshida

2024年7月16日 16時16分

吉田です、情報ありがとうございます。

以下のコマンド結果を添付いただけますでしょうか。

armadillo:~# nmcli -f NAME connection

ここに gsm-ttyCommModem が存在しないと LTE に対してコネクションの設定が存在しない=LTE を使用していない、
と判定し LTE 再接続サービスは何もしない状況となります。

こちらで、以下の設定ファイルにて base_os 3.19.2-at.5 上で稼働させた場合に LTE 再接続サービスが正常に動作することを確認しております。

armadillo:~# cat /etc/atmark/connection-recover/gsm-ttyMux0_connection-recover.conf
#!/bin/sh
 
PRODUCT_NAME="Atmark Techno Armadillo-IoT Gateway A6E Cat.M1 Board"
CHECK_INTERVAL_SEC=120
PING_DEST_IP=8.8.8.8
DEVICE=ttyCommModem
TYPE=gsm
NETWORK_IF=ppp0
FORCE_REBOOT=FALSE
REBOOT_IF_SIM_NOT_FOUND=FALSE
WWAN_FORCE_RESTART_COUNT=1

吉田様

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

LTE接続中のnmcli connectionの出力です。

NAME                UUID                                  TYPE      DEVICE
lte-connection      b490f2e2-9d12-4be9-8827-0a7202ca4ba5  gsm       ttyCommModem
lo                  607e3325-0cb0-4b22-b52a-650e7ee07e83  loopback  lo
Wired connection 1  f2ca0041-7cdb-3950-9f92-6a7529be886e  ethernet  --
Wired connection 2  569a25ba-2ba7-382e-9c06-a1c8621270c0  ethernet  --
lte-connection      e2eb77a6-a9c2-4134-8e99-6cefe653736c  gsm       --

LTE接続中のnmcli deviceの出力です。

DEVICE        TYPE      STATE                   CONNECTION
ttyCommModem  gsm       connected               lte-connection
lo            loopback  connected (externally)  lo
eth0          ethernet  unavailable             --
ppp0          ppp       unmanaged               --

/etc/atmark/connection-recover/gsm-ttyMux0_connection-recover.confファイルの内容は一緒です。

ご確認のほどよろしくお願いいたします。

> 吉田です、情報ありがとうございます。
>
> 以下のコマンド結果を添付いただけますでしょうか。
>
>

> armadillo:~# nmcli -f NAME connection
> 

>
> ここに gsm-ttyCommModem が存在しないと LTE に対してコネクションの設定が存在しない=LTE を使用していない、
> と判定し LTE 再接続サービスは何もしない状況となります。
>
> こちらで、以下の設定ファイルにて base_os 3.19.2-at.5 上で稼働させた場合に LTE 再接続サービスが正常に動作することを確認しております。
>
>

> armadillo:~# cat /etc/atmark/connection-recover/gsm-ttyMux0_connection-recover.conf
> #!/bin/sh
> 
> PRODUCT_NAME="Atmark Techno Armadillo-IoT Gateway A6E Cat.M1 Board"
> CHECK_INTERVAL_SEC=120
> PING_DEST_IP=8.8.8.8
> DEVICE=ttyCommModem
> TYPE=gsm
> NETWORK_IF=ppp0
> FORCE_REBOOT=FALSE
> REBOOT_IF_SIM_NOT_FOUND=FALSE
> WWAN_FORCE_RESTART_COUNT=1
> 

at_mitsuhiro.yoshida

2024年7月17日 16時34分

LTE 再接続サービスはコネクション名 gsm-ttyCommModem が存在する状態で稼働しますので、

お手数ですが、コネクション名 lte-connection を削除し、

armadillo:~# nmcli connection delete lte-connection

製品マニュアル「LTE のコネクションの作成」
https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…
に記載の通り設定してもらえますでしょうか。

armadillo:~# nmcli connection add type gsm ifname ttyCommModem apn [ご利用のプランのAPN] user [ご利用のプランのユーザー名] password [ご利用のプランのパスワード]

吉田様

コネクション名をgsm-ttyCommModemに変更し、7月にリリースされたbase_os 3.20.2-at.1で検証を行いました。
LTE再接続サービスの動作は確認できましたが、LTE通信の回復ができませんでした。

具体的な状況としては、WANの緑LEDがずっと点滅し続けており、rebootコマンドで再起動してもLTE通信が回復しませんでした。
しかし、一度電源を抜いてしばらく放置し、再度電源を入れることでLTE通信が回復しました。
このことから、おそらくLTE通信モジュールに問題が発生してしまい、電源を切らない限り復旧できない状態だと推測されます。

ログファイルを添付いたしますので、ご確認いただけますと幸いです。
よろしくお願いいたします。

> LTE 再接続サービスはコネクション名 gsm-ttyCommModem が存在する状態で稼働しますので、
>
> お手数ですが、コネクション名 lte-connection を削除し、
>
>

> armadillo:~# nmcli connection delete lte-connection
> 

>
> 製品マニュアル「LTE のコネクションの作成」
> https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…
> に記載の通り設定してもらえますでしょうか。
>
>

> armadillo:~# nmcli connection add type gsm ifname ttyCommModem apn [ご利用のプランのAPN] user [ご利用のプランのユーザー名] password [ご利用のプランのパスワード]
> 
ファイル ファイルの説明
A6E-log-base_os 3.20.2-at.1-20240828.zip

at_mitsuhiro.yoshida

2024年8月29日 13時46分

吉田です。

ログのご提供ありがとうございます。
確かに回復する気配が無いですね。

> しかし、一度電源を抜いてしばらく放置し、再度電源を入れることでLTE通信が回復しました。
どの程度の間隔を開けたのか教えてもらえますでしょうか。

吉田様

お世話になっております。
確実な時間間隔は不明ですが、電源を抜いてから2〜3秒後すぐ電源を入れた場合、通信は回復しませんでした。
電源を抜いて1分ほど放置した後、再度電源を入れると通信は回復しました。

ご確認をお願いいたします。

> 吉田です。
>
> ログのご提供ありがとうございます。
> 確かに回復する気配が無いですね。
>
> > しかし、一度電源を抜いてしばらく放置し、再度電源を入れることでLTE通信が回復しました。
> どの程度の間隔を開けたのか教えてもらえますでしょうか。