Armadilloフォーラム

間欠起動でLTE接続ができない、電話番号が取得できない場合がある

takamura.eiji

2025年8月22日 17時32分

==========
製品型番:AG9130-C03D0
Debian/ABOSバージョン:v3.22.1-at.1
==========

添付ファイルの構成でコンテナアプリを起動しています。
A9E本体はCON3より間欠的に電源入力され、システム及びコンテナアプリが起動します。

起動直後にLTE接続と電話番号の取得を行う必要があるのですが、
何度も間欠起動していると時折接続状態が connected にならなかったり、電話番号が取得できないことがあります。

 ※電波状況は少なくとも70%以上はある環境
 ※閉域網の運用ということもありconnection-recoverは停止
 ※LTE接続状態の確認はnmcli deviceコマンド、電話番号の取得にmmcli -mコマンドを利用

その時の nmcliコマンドの結果はそもそもデバイス情報が返されなかったり、STATE 列が connecting のままと結果はさまざまです。
正しく取得できなかった際の救済処置として、REST API経由でwwan-force-restart や nmcli connection down/up をしていますが、
接続状態(connected)になったり、電話番号が取得できることがあるのですが、どうしてもダメな時があります。

間欠起動が関係あるかは判りませんが、何か情報はございますでしょうか?

また、救済処置としてwwan-force-restart や nmcli connection down/up をしておりますが
LTEインターフェイスの再起動やLTE再接続を促す方法として、奨励している手順などをご教示頂けないでしょうか?

コメント

at_dominique.m…

2025年8月22日 18時37分

takamura.eijiさん

お世話になっています、
マルティネです。

> STATE 列が connecting のままと結果はさまざまです。

確認ですが、今回試しているアプリケーションでコンテナ起動直後に mm 等の状態を確認してますでしょうか?
コンテナの起動は LTE の接続を待ってないので、しばらく待つ必要があります。
(A9E の場合は通常で数秒後で接続できてるはずですが、キャリアと場合によっては不定な時間がかかることがあります)

今のバージョンで APN/user/password の変更なければ連続再起動で接続できてる認識です。
待っても接続できなかった場合は、お手数ですが https://armadillo.atmark-techno.com/howto/mm-debug の手順通りに modemmanager のデバッグログを有効化してログを送っていただければ幸いです。

また、wwan-force-restart ですでに nmcli con up をしていますので別の方法で接続アップしない方がいいと思います。
wwan-force-restart で ModemManager を一旦サービスで止めてますが、その際に NetworkManager で gsm 接続を操作すると dbus が modemmanager を起動させてしまって次からの wwan-force-restart で modemmanager を停止できなくなる現象を昨日確認しました。
これも修正しますが、nmcli を利用しなければ問題ない認識なので、ひとまずそれでお願いします。

>  ※LTE接続状態の確認はnmcli deviceコマンド、電話番号の取得にmmcli -mコマンドを利用

今回の問題に関係ないですが、コンテナから nmcli/mmcli を直接に利用しないように推奨しています。
コンテナの更新と OS の更新は別で行っていて、バージョンが一致しない場合にエラーになる可能性があるからです。
abos-web の REST API で取得するとABOS側のコマンドを使ってますのでその問題はありません。
(networkmanager の情報も phone_numbers も取得できますが、足りない情報があれば追加を検討できます。また、custom API 経由でも対応できると思います)

よろしくお願いします

> 待っても接続できなかった場合は、お手数ですが https://armadillo.atmark-techno.com/howto/mm-debug の手順通りに modemmanager のデバッグログを有効化してログを送っていただければ幸いです。

ModemManagerのデバッグログを有効にした状態でログ取得しました。

 ※LTE 接続状態はホスト側の nmcli device で REST API(カスタムスクリプト)で取得
 ※電話番号は REST API(/api/wwan/phone_numbers)で取得

結果として3回問題が発生しましたので、それぞれの/var/log/messagesを添付させて頂きます。

・1.messages.tmp.h6w4EmOO9x.txt
発生時刻:02:20頃
LTE 接続状態: 最後まで connected になりませんでした
電話番号: 取得できて問題なし

・2.messages.tmp.4LxBhhAKiS.txt
発生時刻:04:10頃
LTE 接続状態: connected で問題なし
電話番号: 取得できませんでした

・3.messages.tmp.zEeHu0SmIw.txt
発生時刻:09:10頃
LTE 接続状態: connected で問題なし
電話番号: 取得できませんでした

どのファイルも
「A9E起動→LTE 接続状態確認→電話番号確認→シャットダウン」
を繰り返しており、最後のA9E起動ログ以降が障害箇所のログになっていると思います。

なお、下記のアドバイスは未実施の状態でログ取得しています
> wwan-force-restart ですでに nmcli con up をしていますので別の方法で接続アップしない方がいいと思います。

お忙しいところ申し訳ありませんが、ご確認の程、宜しくお願い致します。

ファイル ファイルの説明
1.messages.tmp_.h6w4EmOO9x.txt
2.messages.tmp_.4LxBhhAKiS.txt
3.messages.tmp_.zEeHu0SmIw.txt

at_dominique.m…

2025年8月26日 13時32分

マルティネです

> ModemManagerのデバッグログを有効にした状態でログ取得しました。

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

> ・1.messages.tmp.h6w4EmOO9x.txt
> 発生時刻:02:20頃
> LTE 接続状態: 最後まで connected になりませんでした
> 電話番号: 取得できて問題なし

このメッセージが気になりますね:

Jan  1 09:00:21 armadillo daemon.warn NetworkManager[1308]: <warn>  [21.7569] modem-broadband[ttyCommModem]: failed to connect 'gsm-ttyCommModem': Connection requested both IPv4 and IPv6 but dual-stack addressing is unsupported by the modem.

正常に接続する時は ipv4 と ipv6 両方をもらってますのでモデムは対応してますが、何かのタイミングの問題で NetworkManager が諦めて接続を中止にしているように見えますね…
弊社で連続試験を行ったテストは IPv4 しかサポートしない SIM で行っていたので申し訳ございません。

引き続き確認しますが、 ひとまず ipv6 を利用しない場合は NM 接続に ipv6.method disabled を設定すれば発生しなくなる可能性が高いです。
dual stack SIM でこちらで再び確認します。

> ・2.messages.tmp.4LxBhhAKiS.txt
> ・3.messages.tmp.zEeHu0SmIw.txt

こちらの2つは同じ問題で、モデムからの返事がないそうです:

Jan  1 09:00:17 armadillo daemon.debug [1965]: <dbg> [000000017.427253] [modem0/ttyCommModem/at] --> 'AT+CNUM<CR>'
Jan  1 09:00:21 armadillo daemon.debug [1965]: <dbg> [000000021.001129] [modem0] couldn't load list of own numbers: Serial command timed out

ソフトウェアでリトライ等でどうにかなるかもしれませんが、ファームウェアの問題の可能性が高いのでメーカーと問い合わせしようと思います。
そこで2つお願いしたいことがあります:
① 現在利用中のファームウェアのバージョンを確認していただけますか?

send-at /dev/ttyLP1 AT+SIMCOMATI echo sim7672

② お差し支えなければ、先週新しいバージョンをリリースしたばかりですので更新して引き続き確認していただければ助かります(最新のバージョンで再現できると報告できるとスムースに話が進むため)
https://armadillo.atmark-techno.com/resources/software/partner-solution… の手順で更新できると思います。

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

at_dominique.m…

2025年8月26日 14時11分

マルティネです。

連続ですみません。

> 弊社で連続試験を行ったテストは IPv4 しかサポートしない SIM で行っていたので申し訳ございません。
> 引き続き確認しますが、 ひとまず ipv6 を利用しない場合は NM 接続に ipv6.method disabled を設定すれば発生しなくなる可能性が高いです。
dual stack SIM でこちらで再び確認します。

こちらは訂正します。別の試験で dualstack も利用していました。
また、ログを再び確認したところこのエラーの原因もわかりました:

Jan  1 09:00:14 armadillo daemon.debug [2007]: <dbg> [000000014.612216] [modem0] loading supported IP families...
Jan  1 09:00:14 armadillo daemon.debug [2007]: <dbg> [000000014.613818] [modem0] couldn't load supported IP families: Unknown error

なので、 ipv6 を無効化したところまた発生すると思います。

ところで、このでの失敗はリクエストを送る前に来ていて、他のところのメッセージも気になりました:

Jan  1 09:00:14 armadillo daemon.debug [2007]: <dbg> [000000014.614796] [modem0/ttyCommModem/at] --> 'AT+CFUN?<CR>'
Jan  1 09:00:15 armadillo authpriv.info : abos-web-admin ran command /etc/atmark/abos_web/customize_rest/wggw_api.sh get_lte_firmver as root from /
Jan  1 09:00:15 armadillo daemon.debug [2007]: <dbg> [000000015.905865] [modem0/ttyCommModem/at] <-- '<CR><LF>Manufacturer: SIMCOM INCORPORATED<CR><LF>Model: SIM7672G-MNGV<CR><LF>Revision: 2388B0
1SIM767XM5A_M<CR><LF>SIM767XM5_B01V02_250409<CR><LF>IMEI: 865031061366794<CR><LF><CR><LF>OK<CR><LF>'

wggw_api で ttyCommModem に直接に send-at を利用していますでしょうか?(この返事は AT+SIMCOMATI への返事です)
ModemManager を起動してからでは ttyCommModem を利用すると違うリクエストの返事を受信したり、エラーの原因になります。
send-at を利用する場合は必ず ttyLP1 を利用してください。

ttyCommModem を同時に利用している場合はナンバーのエラーも説明できますので、一旦返事を待ちます。

よろしくお願いします

マルティネさん
回答ありがとうございました。

> wggw_api で ttyCommModem に直接に send-at を利用していますでしょうか?(この返事は AT+SIMCOMATI への返事です)

現状は下記フォーラムのNITZ問題への暫定対処の為、LTE ファームウェアのバージョンを読み出して時刻同期方法を変えてます。
https://armadillo.atmark-techno.com/forum/armadillo/25914

その際にREST API カスタムスクリプト経由で以下のコマンドを実行しています。

send-at /dev/ttyCommModem AT+SIMCOMATI echo sim7672

※修正版ModemManagerもリリースされNITZ問題が解決されるなら、この暫定対処は外す予定です

> ModemManager を起動してからでは ttyCommModem を利用すると違うリクエストの返事を受信したり、エラーの原因になります。
> send-at を利用する場合は必ず ttyLP1 を利用してください。

8/22リリースの「2388B03SIM767XM5A_M」を適用していない状況ですと、
下記コマンド(/dev/ttyLP1利用)では結果が返されませんでした。

# send-at /dev/ttyLP1 AT+SIMCOMATI echo sim7672
※何も出力が得られないで終了

下記コマンド(/dev/ttyCommModem利用)であれば結果が返されました。

# send-at /dev/ttyCommModem AT+SIMCOMATI echo sim7672
Manufacturer: SIMCOM INCORPORATED
Model: SIM7672G-MNGV
Revision: 2388B01SIM767XM5A_M
SIM767XM5_B01V02_250409
IMEI: 865031061366794
OK

なお、「2388B03SIM767XM5A_M」を適用したところ/dev/ttyLP1で正常に応答がありました。

at_dominique.m…

2025年8月26日 15時30分

マルティネです。

> > wggw_api で ttyCommModem に直接に send-at を利用していますでしょうか?(この返事は AT+SIMCOMATI への返事です)
>
> 現状は下記フォーラムのNITZ問題への暫定対処の為、LTE ファームウェアのバージョンを読み出して時刻同期方法を変えてます。
> https://armadillo.atmark-techno.com/forum/armadillo/25914

了解しました。
モデムの revision だけでしたら、mmcli -m 0 | grep revision などでも取得できると思いますが、それを代用してみていただけますか

> 8/22リリースの「2388B03SIM767XM5A_M」を適用していない状況ですと、
> 下記コマンド(/dev/ttyLP1利用)では結果が返されませんでした。

> # send-at /dev/ttyLP1 AT+SIMCOMATI echo sim7672
> ※何も出力が得られないで終了

こちらの動作は更新で変わった認識がないので、タイミングの違いかもしれません。
バージョンの確認以外に必要でしたらもう少し確認しますので言ってください

よろしくお願いします