LTE通信異常の原因、異常復帰の方法について

yuto.tsukada

2021年5月18日 20時40分

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

本件につきまして2点質問がございます。
　
〇一日に数回サーバーから正常レスポンスがこない場合があり、
　その根本の原因を調査しております。
　通信異常ということは理解しましたが、なぜ異常が発生するのかを
　お教えいただけますでしょうか。

　＜背景＞
　pythonのrequestモジュールを使用しHTTPリクエストを行っています。
　しかし正常レスポンスでない場合は、requestモジュールから以下内容が返ってきます。
　　HTTPConnectionPool(host='xxxxxxxxxxxxx', port=80): Max retries exceeded with url: xxx/xxxx/xxxxxxxxx
　　(Caused by　NewConnectionError(':
　　Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',))
　またその際のsyslogを添付いたします。（May 15 22:00:55～あたりです。）
　22:00:59頃にHTTPリクエストをした際、上記内容が返ってきました。

〇上記レスポンスが返ってきた場合、以下のような処理を行い、異常復帰を試みています。
　しかし時々、下記処理を行った後も、異常復帰が完了せずLTE未接続の状態が続くことがあります。
　この原因はなぜでしょうか。また効果的な異常復帰方法があれば、お教えいただけますでしょうか。

　＜異常復帰処理＞
　１．LTE接続異常とみなしNetworkManagerとModemManagerをリスタート。
　　　subprocess.check_output('systemctl restart ModemManager.service', shell=True)
　　　subprocess.check_output('systemctl restart NetworkManager', shell=True)
　２．自動接続する環境を設定。
　　　subprocess.check_output('nmcli connection modify sora_prod autoconnect no',shell=True)
　３．LTE接続済みになるまで待つ。
　　　subprocess.check_output('nmcli device | grep gsm',shell=True)　定期的に実行
　　　　→　'connected' で接続済みとしています。

お手数ではございますが、ご回答のほどよろしくお願いいたします。

ファイル	ファイルの説明
syslog.zip

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

at_syunya.ohshio

2021年5月20日 16時35分

大塩です。

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

> 〇一日に数回サーバーから正常レスポンスがこない場合があり、
> 　その根本の原因を調査しております。
> 　通信異常ということは理解しましたが、なぜ異常が発生するのかを
> 　お教えいただけますでしょうか。

LTEが不通となる要因は、基本的に圏外または通信状態が悪い状況となります。
また、契約している事業者によっては 24時間程度で LTE の切断・接続を実施することがあります。

> 〇上記レスポンスが返ってきた場合、以下のような処理を行い、異常復帰を試みています。
> 　しかし時々、下記処理を行った後も、異常復帰が完了せずLTE未接続の状態が続くことがあります。
> 　この原因はなぜでしょうか。また効果的な異常復帰方法があれば、お教えいただけますでしょうか。

標準イメージでは、再接続サービスを実装しております。
仕様などは以下を参照願います。
https://manual.atmark-techno.com/armadillo-iot-g3l/armadillo-iotg-g3l_p…

・ LTE が不通になることは想定していただいた上で再送処理を実装し、LTE の再接続の頻度を下げると良いと思われます。
　再接続の頻度が早すぎる場合、再接続処理中の状態を通信異常と見なしてしまう恐れがあります。
・サービスの再起動は、 ModemManager だけでも良いかと思われます。
・ wwan-force-restart を実行することで通信モデムの再起動も実施できます。

以下も参考にしていただければと思います。

「ドコモネットワーク接続ガイドライン (IoT機器編)」
https://www.nttdocomo.co.jp/biz/binary/pdf/support/utilization/module/g…

以上です。

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

yuto.tsukada

2021年5月21日 19時19分

ご回答ありがとうございます。
回答に対して、追加の質問があります。

> LTEが不通となる要因は、基本的に圏外または通信状態が悪い状況となります。
> また、契約している事業者によっては 24時間程度で LTE の切断・接続を実施することがあります。
>
> 標準イメージでは、再接続サービスを実装しております。
> 仕様などは以下を参照願います。
> https://manual.atmark-techno.com/armadillo-iot-g3l/armadillo-iotg-g3l_p…
>
上記サービスに関連して、requestモジュールによるHTTPリクエストを行った際、下記エラーが発生し、LTEは接続済みの状態でした。
（LTE接続済みの確認は、定期的に、subprocess.check_output('nmcli device | grep gsm',shell=True)を実行し、gsmの状態を確認しています。）
　　HTTPConnectionPool(host='xxxxxxxxxxxxx', port=80): Max retries exceeded with url: xxx/xxxx/xxxxxxxxx
　　(Caused by　NewConnectionError(':
　　Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',))
LTEは接続済み、つまり上記サービスによるpingが通っていることを踏まえると、通信状態が悪いことが関係していないように思えたのですが、この認識はまちがっているのでしょうか。

> ・ LTE が不通になることは想定していただいた上で再送処理を実装し、LTE の再接続の頻度を下げると良いと思われます。
再送処理を実装するにあたり、再送処理の間隔（最初のHTTPリクエスト送信～次のHTTPリクエスト送信までの時間）、再送回数(LTE再接続を実施するまで)の目安を教えていただけますでしょうか。
参考までに、正常レスポンス受信した際は、HTTPリクエスト送信からHTTPレスポンス受信までの時間は約2秒くらいです。
また、お客様が受付操作完了後にHTTPリクエストを送信する機能を実装しておりますので、時間はなるべく短くしたい思いがあります。

> 　再接続の頻度が早すぎる場合、再接続処理中の状態を通信異常と見なしてしまう恐れがあります。
恐れ入りますが、この回答の意味が理解できませんでした。
アプリでは上記LTE接続済みの確認を定期的に行い、接続済み以外の状態ではHTTPリクエストは行わない仕様となっております。

> ・サービスの再起動は、 ModemManager だけでも良いかと思われます。
> ・ wwan-force-restart を実行することで通信モデムの再起動も実施できます。
ModemManagerだけrestartとのこと、承知しました。
また、LTE再接続をするにあたり、wwan-force-restartの実行を行うと、LTEモジュール、ModemManagerともにrestartするので、
LTE再接続は、wwan-force-restartのみ行えばよいという認識でよろしいでしょうか。

> 以下も参考にしていただければと思います。
>
> 「ドコモネットワーク接続ガイドライン (IoT機器編)」
> https://www.nttdocomo.co.jp/biz/binary/pdf/support/utilization/module/g…
上記資料ありがとうございます。

お忙しいところ大変恐れ入りますが、ご回答のほどよろしくお願いいたします。

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

at_syunya.ohshio

2021年5月25日 18時16分

大塩です。
以下にそれぞれ回答いたします。

> 上記サービスに関連して、requestモジュールによるHTTPリクエストを行った際、下記エラーが発生し、LTEは接続済みの状態でした。
> （LTE接続済みの確認は、定期的に、subprocess.check_output('nmcli device | grep gsm',shell=True)を実行し、gsmの状態を確認しています。）
> 　　HTTPConnectionPool(host='xxxxxxxxxxxxx', port=80): Max retries exceeded with url: xxx/xxxx/xxxxxxxxx
> 　　(Caused by　NewConnectionError(':
> 　　Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',))
> LTEは接続済み、つまり上記サービスによるpingが通っていることを踏まえると、通信状態が悪いことが関係していないように思えたのですが、この認識はまちがっているのでしょうか。

まず、subprocess.check_output('nmcli device | grep gsm',shell=True) は
「nmcli device | grep gsm の結果が返ってきたらOKとするコマンド」と認識しております。
この条件ですと、nmcli device | grep gsm の結果が以下の場合でもOKとなってしまいます。

ttyUSB2  gsm       connecting (getting IP configuration)  gsm-ttyUSB2

よって、必ずしもpingが通っていると言い切れないと思われます。
これについては条件の判定に、「STATE が connected である」も追加すると良いと思います。

> 再送処理を実装するにあたり、再送処理の間隔（最初のHTTPリクエスト送信～次のHTTPリクエスト送信までの時間）、再送回数(LTE再接続を実施するまで)の目安を教えていただけますでしょうか。
> 参考までに、正常レスポンス受信した際は、HTTPリクエスト送信からHTTPレスポンス受信までの時間は約2秒くらいです。
> また、お客様が受付操作完了後にHTTPリクエストを送信する機能を実装しておりますので、時間はなるべく短くしたい思いがあります。

ご利用になる環境等によって数値は変化するため、目安をご提案することは難しいです。
お客様が作成されているシステムを、実際の環境にて動作確認していただき、許容可能な再送処理の間隔と再送回数を導き出すのが良いです。

> 恐れ入りますが、この回答の意味が理解できませんでした。
> アプリでは上記LTE接続済みの確認を定期的に行い、接続済み以外の状態ではHTTPリクエストは行わない仕様となっております。
>

説明が不十分であり、申し訳ありません。
ここでの説明は、LTEコネクションの接続、切断のことを説明しております。
例えばLTE再接続サービス稼働中に、コネクションの接続を行っても
必ず false となるためコネクションの接続タイミングは見極めた方が良い、との説明でした。

> ModemManagerだけrestartとのこと、承知しました。
> また、LTE再接続をするにあたり、wwan-force-restartの実行を行うと、LTEモジュール、ModemManagerともにrestartするので、
> LTE再接続は、wwan-force-restartのみ行えばよいという認識でよろしいでしょうか。

上記認識で問題ないと思います。

以上です。
宜しくお願い致します。

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

yuto.tsukada

2021年5月28日 14時36分

大塩様
お世話になっております。

ご回答ありがとうございます。
再度、質問がございます。

> > 上記サービスに関連して、requestモジュールによるHTTPリクエストを行った際、下記エラーが発生し、LTEは接続済みの状態でした。
> > （LTE接続済みの確認は、定期的に、subprocess.check_output('nmcli device | grep gsm',shell=True)を実行し、gsmの状態を確認しています。）
> > 　　HTTPConnectionPool(host='xxxxxxxxxxxxx', port=80): Max retries exceeded with url: xxx/xxxx/xxxxxxxxx
> > 　　(Caused by　NewConnectionError(':
> > 　　Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',))
> > LTEは接続済み、つまり上記サービスによるpingが通っていることを踏まえると、通信状態が悪いことが関係していないように思えたのですが、この認識はまちがっているのでしょうか。
>
> まず、subprocess.check_output('nmcli device | grep gsm',shell=True) は
> 「nmcli device | grep gsm の結果が返ってきたらOKとするコマンド」と認識しております。
> この条件ですと、nmcli device | grep gsm の結果が以下の場合でもOKとなってしまいます。
>

> ttyUSB2  gsm       connecting (getting IP configuration)  gsm-ttyUSB2
>

> よって、必ずしもpingが通っていると言い切れないと思われます。
> これについては条件の判定に、「STATE が connected である」も追加すると良いと思います。
>
説明不足で申し訳ございません。
アプリでは「nmcli device | grep gsm」の結果が ' connected ' or '接続済み' であれば、LTEは接続済みと判断しております。
このことを踏まえたうえで、再度上記の質問に対してご回答いただけますでしょうか。

> ご利用になる環境等によって数値は変化するため、目安をご提案することは難しいです。
> お客様が作成されているシステムを、実際の環境にて動作確認していただき、許容可能な再送処理の間隔と再送回数を導き出すのが良いです。
>
承知しました。再送処理および再送回数は通信試験を行った上で、適切なパラメータを検討いたします。

> 説明が不十分であり、申し訳ありません。
> ここでの説明は、LTEコネクションの接続、切断のことを説明しております。
> 例えばLTE再接続サービス稼働中に、コネクションの接続を行っても
> 必ず false となるためコネクションの接続タイミングは見極めた方が良い、との説明でした。
>
アプリで再接続を試みる際は、LTE再接続サービスを停止する必要があるということでしょうか。
また停止する必要がない場合は、LTE再接続サービス稼働中のどのタイミングであれば、アプリ側で再接続処理を行ってもよいのかをお教えいただけますでしょうか。

また、アプリ側の再接続処理について、現在下記の処理を検討しております。
　１．subprocess.check_output('nmcli connection modify sora_prod autoconnect no',shell=True)
　２．subprocess.check_output('nmcli connection modify sora_develop autoconnect yes',shell=True)
　３．subprocess.check_output('wwan-force-restart', shell=True)
１と２は再接続の際、デフォルトの接続先とアプリでの接続先設定が異なっていた場合、実行いたします。
再接続処理の手順として、１～３の順序で行うことは正しいかをお教えいただけますでしょうか。

以上
お手数をおかけしますが、ご回答のほどよろしくお願いいたします。

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

at_syunya.ohshio

2021年5月28日 18時07分

大塩です。

> 説明不足で申し訳ございません。
> アプリでは「nmcli device | grep gsm」の結果が ' connected ' or '接続済み' であれば、LTEは接続済みと判断しております。
> このことを踏まえたうえで、再度上記の質問に対してご回答いただけますでしょうか。

nmcli device の結果が connected であっても、通信経路上の問題などで ping 導通や https の接続が出来ないことはあり得ます。

> アプリで再接続を試みる際は、LTE再接続サービスを停止する必要があるということでしょうか。
> また停止する必要がない場合は、LTE再接続サービス稼働中のどのタイミングであれば、アプリ側で再接続処理を行ってもよいのかをお教えいただけますでしょうか。

標準イメージの再接続サービスとお客様独自で実装された再接続処理とで
何らかの競合が発生する可能性がありますので、停止された方が良いかと思います。

> また、アプリ側の再接続処理について、現在下記の処理を検討しております。
> 　１．subprocess.check_output('nmcli connection modify sora_prod autoconnect no',shell=True)
> 　２．subprocess.check_output('nmcli connection modify sora_develop autoconnect yes',shell=True)
> 　３．subprocess.check_output('wwan-force-restart', shell=True)
> １と２は再接続の際、デフォルトの接続先とアプリでの接続先設定が異なっていた場合、実行いたします。
> 再接続処理の手順として、１～３の順序で行うことは正しいかをお教えいただけますでしょうか。

ご参考までに、標準イメージでの再接続処理を記載します。
上述の通り、nmcli device で connected になっていても通信経路上の問題などでping が通らない可能性はあります。
それらの可能性も踏まえて標準イメージの再接続サービスでは、ping での導通確認を実施しております。
ping 導通確認の周期は、以前ご紹介した製品マニュアルのLTE再接続サービス項目をご確認ください。
このping が一定回数(デフォルトで2回)失敗した場合、wwan-force-restart が実行されるという処理になっております。

記載いただいた内容の手順は、実際に動作確認を行い、正しいか否かを判別していただくのが良いと思います。

以上です。

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

yuto.tsukada

2021年6月2日 11時22分

大塩様

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

ご回答ありがとうございました。
下記、標準イメージの再接続サービスを使用する旨理解いたしました。
アプリでの再接続処理は行わない方針といたします。

追加で標準イメージの再接続サービスについて、2点質問がございます。

＜質問事項＞
・以下症状の原因について、お教えいただけますでしょうか。
・SIM側でセッションの切断を行った際、デバイス側でセッションの再接続をしているとのお話をSORACOMから伺ったのですが、
　セッションの再接続も標準イメージの再接続サービスが行っているとの認識でよろしいでしょうか。

標準イメージの再接続サービスを利用していた際、以下の症状が発生しました。

＜症状＞
１時間程度、HTTPリクエストに対する応答がない。（アプリで10分毎HTTPリクエストを送信するも、いずれも以下のログ。（python requests使用））
HTTPConnectionPool(host='xxxxxxxxx', port=80): Max retries exceeded with url: /xx/xx/xx/xx
(Caused by NewConnectionError(' urllib3.connection.HTTPConnection object at 0x76070d30 :
Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',))

＜状況＞
「nmcli device | grep gsm」の結果は、connected
１時間経過後は、HTTPリクエストに対するHTTPレスポンス有り（HTTPステータスコード：200）
（１時間無通信状態が続くと、SIM側でセッションの切断を行う。）

標準イメージの再接続サービスが稼働していれば、wwan-force-restartが実行されると予想していたのですが、
それらしきログがsyslogにはありませんでした。
その際のsyslogを添付いたします。

お忙しいところ恐縮ですが、ご回答のほどよろしくお願いいたします。

> 大塩です。
>
> > 説明不足で申し訳ございません。
> > アプリでは「nmcli device | grep gsm」の結果が ' connected ' or '接続済み' であれば、LTEは接続済みと判断しております。
> > このことを踏まえたうえで、再度上記の質問に対してご回答いただけますでしょうか。
>
> nmcli device の結果が connected であっても、通信経路上の問題などで ping 導通や https の接続が出来ないことはあり得ます。
>
> > アプリで再接続を試みる際は、LTE再接続サービスを停止する必要があるということでしょうか。
> > また停止する必要がない場合は、LTE再接続サービス稼働中のどのタイミングであれば、アプリ側で再接続処理を行ってもよいのかをお教えいただけますでしょうか。
>
> 標準イメージの再接続サービスとお客様独自で実装された再接続処理とで
> 何らかの競合が発生する可能性がありますので、停止された方が良いかと思います。
>
> > また、アプリ側の再接続処理について、現在下記の処理を検討しております。
> > 　１．subprocess.check_output('nmcli connection modify sora_prod autoconnect no',shell=True)
> > 　２．subprocess.check_output('nmcli connection modify sora_develop autoconnect yes',shell=True)
> > 　３．subprocess.check_output('wwan-force-restart', shell=True)
> > １と２は再接続の際、デフォルトの接続先とアプリでの接続先設定が異なっていた場合、実行いたします。
> > 再接続処理の手順として、１～３の順序で行うことは正しいかをお教えいただけますでしょうか。
>
> ご参考までに、標準イメージでの再接続処理を記載します。
> 上述の通り、nmcli device で connected になっていても通信経路上の問題などでping が通らない可能性はあります。
> それらの可能性も踏まえて標準イメージの再接続サービスでは、ping での導通確認を実施しております。
> ping 導通確認の周期は、以前ご紹介した製品マニュアルのLTE再接続サービス項目をご確認ください。
> このping が一定回数(デフォルトで2回)失敗した場合、wwan-force-restart が実行されるという処理になっております。
>
> 記載いただいた内容の手順は、実際に動作確認を行い、正しいか否かを判別していただくのが良いと思います。
>
> 以上です。

ファイル	ファイルの説明
syslog.zip	通信不可の時間帯は、2月6日 14:30頃～15:25頃となります。

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

at_syunya.ohshio

2021年6月3日 11時45分

大塩です。

質問事項に回答いたします。
> ・SIM側でセッションの切断を行った際、デバイス側でセッションの再接続をしているとのお話をSORACOMから伺ったのですが、
> 　セッションの再接続も標準イメージの再接続サービスが行っているとの認識でよろしいでしょうか。

SORACOM様の「セッション」とは、こちらでいう「コネクション」と思われます。
LTEコネクションの確立は、標準イメージであればNetworkManagerや再接続サービスで行われます。

> ・以下症状の原因について、お教えいただけますでしょうか。
> 標準イメージの再接続サービスを利用していた際、以下の症状が発生しました。
>
> ＜症状＞
> １時間程度、HTTPリクエストに対する応答がない。（アプリで10分毎HTTPリクエストを送信するも、いずれも以下のログ。（python requests使用））
> HTTPConnectionPool(host='xxxxxxxxx', port=80): Max retries exceeded with url: /xx/xx/xx/xx
> (Caused by NewConnectionError(' urllib3.connection.HTTPConnection object at 0x76070d30 :
> Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',))
>
> ＜状況＞
> 「nmcli device | grep gsm」の結果は、connected
> １時間経過後は、HTTPリクエストに対するHTTPレスポンス有り（HTTPステータスコード：200）
> （１時間無通信状態が続くと、SIM側でセッションの切断を行う。）
>
> 標準イメージの再接続サービスが稼働していれば、wwan-force-restartが実行されると予想していたのですが、
> それらしきログがsyslogにはありませんでした。
> その際のsyslogを添付いたします。

送付いただいたログを確認しました。
仰る通り、wwan-force-restart が実行されていないため、必ずしもLTE接続が原因とは限らないと思われます。
ping は通っているがサーバーまでの名前解決が上手く行っていないか、サーバーまでの経路で何か発生しているなどの要因かと思われます。

以上です。

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

yuto.tsukada

2021年6月4日 10時29分

大塩様

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

ご回答のほどありがとうございました。

> 送付いただいたログを確認しました。
> 仰る通り、wwan-force-restart が実行されていないため、必ずしもLTE接続が原因とは限らないと思われます。
> ping は通っているがサーバーまでの名前解決が上手く行っていないか、サーバーまでの経路で何か発生しているなどの要因かと思われます。

この件に関しまして、サーバーまでの名前解決の部分を重点的に調査いたします。

また調査後に質問させていただくことがあるかもしれません。
その際は、引き続きよろしくお願いいたします。

> 大塩です。
>
> 質問事項に回答いたします。
> > ・SIM側でセッションの切断を行った際、デバイス側でセッションの再接続をしているとのお話をSORACOMから伺ったのですが、
> > 　セッションの再接続も標準イメージの再接続サービスが行っているとの認識でよろしいでしょうか。
>
> SORACOM様の「セッション」とは、こちらでいう「コネクション」と思われます。
> LTEコネクションの確立は、標準イメージであればNetworkManagerや再接続サービスで行われます。
>
> > ・以下症状の原因について、お教えいただけますでしょうか。
> > 標準イメージの再接続サービスを利用していた際、以下の症状が発生しました。
> >
> > ＜症状＞
> > １時間程度、HTTPリクエストに対する応答がない。（アプリで10分毎HTTPリクエストを送信するも、いずれも以下のログ。（python requests使用））
> > HTTPConnectionPool(host='xxxxxxxxx', port=80): Max retries exceeded with url: /xx/xx/xx/xx
> > (Caused by NewConnectionError(' urllib3.connection.HTTPConnection object at 0x76070d30 :
> > Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',))
> >
> > ＜状況＞
> > 「nmcli device | grep gsm」の結果は、connected
> > １時間経過後は、HTTPリクエストに対するHTTPレスポンス有り（HTTPステータスコード：200）
> > （１時間無通信状態が続くと、SIM側でセッションの切断を行う。）
> >
> > 標準イメージの再接続サービスが稼働していれば、wwan-force-restartが実行されると予想していたのですが、
> > それらしきログがsyslogにはありませんでした。
> > その際のsyslogを添付いたします。
>
> 送付いただいたログを確認しました。
> 仰る通り、wwan-force-restart が実行されていないため、必ずしもLTE接続が原因とは限らないと思われます。
> ping は通っているがサーバーまでの名前解決が上手く行っていないか、サーバーまでの経路で何か発生しているなどの要因かと思われます。
>
> 以上です。

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

yuto.tsukada

2021年6月7日 14時25分

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

上記の件調査したところ、LTE再接続サービスについて
お聞きしたいことが出てきましたので質問させていただきます。
＜質問＞
１．コネクション名を「gsm-ttyCommModem」以外にするとLTE再接続サービスは機能しないのでしょうか。
２．１に関連して、コネクション名を任意の名前にし、LTE再接続サービスを機能させる方法をお教えいただけますでしょうか。

＜質問の背景＞
現在以下の設定で運用しております。
・ネットワークデバイス名は「ttyCommModem」。
・コネクションファイルは複数。（コネクションごとにdnsを変更したいため。）
・設定ファイル
/etc/connection-recover/gsm-ttyACM0_connection-recover.conf

PRODUCT_NAME="Armadillo-X1L","Armadillo-IoT Gateway G3 D2 Board","Atmark-Techno
Armadillo-IoT Gateway G3 D2(AGX3031-E00Z) Board"
PING_DEST_IP=pong.soracom.io
DEVICE=ttyACM0
TYPE=gsm
NETWORK_IF=usb1
FORCE_REBOOT=FALSE
SYMLINKDEVICE=ttyCommModem
SYMLINK_MM_PARAM=cinterion-els31-symlink

・コネクションファイル設定
/etc/NetworkManager/system-connections/sora_prod

[connection]
id=sora_prod
#uuid=0a564ae8-7d51-4fd7-b183-16547e988cb8
type=gsm
interface-name=ttyCommModem
permissions=
autoconnect=true
...

LTE再接続サービスのスクリプトを確認したところ、以下の部分の終了ステータスが 1 となっているため、
pingによる疎通確認の処理までたどりつけていません。

active_connection_exist() {
        nmcli -f NAME connection | sed -e 's/ *$//' | grep -x -q ${CONNECTION}
        ...
}

これは、${CONNECTION}に、${TYPE}-${DEVICE}の文字列（gsm-ttyCommModem）が入っており、
コネクション名（sora_prod）と異なっていることが原因かと思われます。

背景の部分が長文になってしまい、申し訳ございません。

お手数をおかけしますが、ご回答の程よろしくお願いいたします。

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

at_syunya.ohshio

2021年6月9日 18時04分

大塩です。

> 上記の件調査したところ、LTE再接続サービスについて
> お聞きしたいことが出てきましたので質問させていただきます。
> ＜質問＞
> １．コネクション名を「gsm-ttyCommModem」以外にするとLTE再接続サービスは機能しないのでしょうか。
> ２．１に関連して、コネクション名を任意の名前にし、LTE再接続サービスを機能させる方法をお教えいただけますでしょうか。
>

LTE再接続サービスは、G3Lの場合以下にのみ対応しております。
・symlink.conf で ttyCommModem の使用を宣言している場合は gsm-ttyCommModem
・上記でない場合は gsm-ttyACM0
そのため、任意のコネクション名にしている場合はLTE再接続サービスは動作しません。

以上です。

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

yuto.tsukada

2021年6月10日 11時32分

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

ご回答ありがとうございます。

> LTE再接続サービスは、G3Lの場合以下にのみ対応しております。
> ・symlink.conf で ttyCommModem の使用を宣言している場合は gsm-ttyCommModem
> ・上記でない場合は gsm-ttyACM0
> そのため、任意のコネクション名にしている場合はLTE再接続サービスは動作しません。
>
上記、LTE再接続サービスについて理解いたしました。
スクリプトを書き換えるか、コネクション名を変更するか、検討いたします。

引き続き、よろしくお願いいたします。

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

Armadilloフォーラム

LTE通信異常の原因、異常復帰の方法について

製品

コメント