asao.satoshi
2018年4月9日 12時05分
お世話になっております。浅尾と申します。
Armadillo-loT G3Lに、ASAHIネットの固定IP付きSIM（NTTドコモ系）を取り付けております。
マニュアルを元に、nmcliを使用してLTEコネクションを作成しインタネットに接続しております。
さて、LTE再接続サービス（connection-recover）についてですが、
このサービスは、LTEコネクションが無効の場合のみ、
LTEコネクションを再起動し、LTEコネクションを有効化させるサービスと認識しておりますが、
LTEのコネクションが有効の場合であっても、LTEコネクションを再起動しているようです。
そのため、社内PCからArmadilloに対して定期的にSFTPでファイルを取得しているのですが、
LTEコネクションの再起動のタイミングが重なると失敗してしまいます。
LTEコネクションが無効の場合のみ
LTEコネクションを再起動するようには出来ないでしょうか。
なお、Armadilloから手動で8.8.8.8へpingを打ち続けていても
LTE再接続サービスによるLTEコネクションの再起動が実施されていることは
確認しております。
コメント
asao.satoshi
大塩様
お世話になっております。浅尾です。
ご回答ありがとうございます。
また言葉の定義があいまいで申し訳ありません。
改めて質問させて頂きます。
> 上記のフローから、「LTEコネクションが有効でping通信に失敗した場合はLTEコネクション再接続」という処理が存在しているため、
>
LTE再接続サービスの動作については、説明書を読んでおりましたので
ping通信の失敗も考慮していることは理解しております。
私としても行いたいのは、「LTEコネクションが無効、またはping通信エラー時に、LTEコネクションを有効にする」です。
加えて言えば、「ping通信成功時にLTEコネクションを再接続しないで欲しい」となります。
フローを見る限り、行いたい事はLTEコネクション再起動サービスと同じ内容と思っております。
動作の確認として、有線LANからSSHで接続しrootユーザーで8.8.8.8にpingを打ち続けておりました。
ping 8.8.8.8
pingの結果は
64 bytes from 8.8.8.8: icmp_seq=106 ttl=59 time=41.7 ms 64 bytes from 8.8.8.8: icmp_seq=107 ttl=59 time=39.8 ms 64 bytes from 8.8.8.8: icmp_seq=108 ttl=59 time=37.8 ms
といった内容ですので、問題なく通信できているものと思います。
上記の状態で、2分に1回の頻度でping通信がエラーとなります。
64 bytes from 8.8.8.8: icmp_seq=322 ttl=59 time=37.9 ms ping: sendmsg: Network is unreachable （中略 上記と同じ内容が24回発生） ping: sendmsg: Network is unreachable From 192.168.15.1 icmp_seq=349 Destination Net Unreachable From 192.168.15.1 icmp_seq=350 Destination Net Unreachable From 192.168.15.1 icmp_seq=351 Destination Net Unreachable 64 bytes from 8.8.8.8: icmp_seq=355 ttl=59 time=44.3 ms （中略 上記と同じ内容が7回発生） 64 bytes from 8.8.8.8: icmp_seq=363 ttl=59 time=28.6 ms ping: sendmsg: Network is unreachable （中略 上記と同じ内容が21回発生） ping: sendmsg: Network is unreachable 64 bytes from 8.8.8.8: icmp_seq=387 ttl=59 time=32.2 ms 64 bytes from 8.8.8.8: icmp_seq=388 ttl=59 time=30.6 ms
以降、次のconnection-recoverまでping通信は成功します。
syslogを見ると、「connection-recover: exec wwan-force-restart」と出ているので
connection-recoverによる再起動が起きているものと推察しております。
実際、connection-recoverを停止すると、2分に1回の頻度で発生していたping通信エラーが起こりません。
設定に不備があるものと思っておりますが、
何をお知らせすれば良いのか、ご教示いただけると幸いです。
私の行いたいことが「LTE再接続サービス」では無いのであれば、
手作りすることにいたします。
y.nakamura
中村です。
横から失礼します。
先日、再接続サービスの別の問題がありソースを見ていたいので、
本件のやりとりも気になっています。
> 私としても行いたいのは、「LTEコネクションが無効、またはping通信エラー時に、LTEコネクションを有効にする」です。
これが再接続サービスの仕様だと、私は思っています。
> 加えて言えば、「ping通信成功時にLTEコネクションを再接続しないで欲しい」となります。
これもそうあってほしいですね。
というか、そうなるのが仕様だと思っています。
connection-recoverdのソースを見る限りでは。
気になるところとして・・・
pingが成功しているとき、手動で
nmcli -f DEVICE,STATE device
を実行すると、どういう結果になりますか？
これは/usr/bin/connection-recoverdの初めのあたりにある
get_connection_status()の処理と同じものです。
再接続サービスを停止させて、/usr/bin/connection-recoverd
がやっているのと同じことを手作業で１つずつ試してみると
何かわかるかもしれません。
--
なかむら
asao.satoshi
中村様
横からありがとうございます。
仕様についてご理解頂きありがとうございます。
> pingが成功しているとき、手動で
> nmcli -f DEVICE,STATE device
> を実行すると、どういう結果になりますか？
下記となります。
root@armadillo:~# nmcli -f DEVICE,STATE device デバイス 状態 eth0 接続済み ttyACM0 接続済み wlan0 切断済み usb0 利用不可 gre0 管理無し gretap0 管理無し ip6gre0 管理無し ip6tnl0 管理無し tunl0 管理無し lo 管理無し sit0 管理無し ip6_vti0 管理無し
「ttyACM0 接続済み」ですので、LTEコネクションは有効だと思っています。
> 再接続サービスを停止させて、/usr/bin/connection-recoverd
> がやっているのと同じことを手作業で１つずつ試してみると
> 何かわかるかもしれません。
>
サービスの内容（コード）についてご教示ありがとうございます。
少し中身を解析してみたいと思います。
asao.satoshi
原因が分かりましたので記載します。
弊社のarmadilloについてですが、
日本語パッケージを導入し、言語を日本語に変更していたことが
原因でした。
中村様からご提案いただいた「nmcli -f DEVICE,STATE device」の結果と、
大塩様の定義を見直しして判明しました。
・nmcli -f DEVICE,STATE deviceの結果
root@armadillo:~# nmcli -f DEVICE,STATE device | grep "ttyACM0" ttyACM0 接続済み
・定義
-------------------------------------------------
「nmcli device」コマンドで表示される情報のうち、対象デバイスの[STATE]が
・[connected]ならば「LTEコネクション有効」
・[disconnected]ならば「LTEコネクション無効」
とします。
-------------------------------------------------
確かに、対象デバイスの[STATUS]は[connected]ではありませんでした。
/usr/bin/connection-recoverの、下記行を修正することで
ひとまず2分毎のLTEコネクション再接続は無くなりました。
・135行目 変更前：*disconnected*|*failed*|*unknown*|"*connection failed*") 変更後：*disconnected*|*failed*|*unknown*|"*connection failed*"|*"切断済み"* ) ・140行目 変更前：*connected*) 変更後：*connected*|*"接続済み"* ) ・146行目 変更前：*deactivating*|*unmanaged*|*unavailable*|*connecting*) 変更後：*deactivating*|*unmanaged*|*unavailable*|*connecting*|*"接続中"* )
Linuxには明るくないのですが、ステータスのチェックは文字列で行うことが一般的なのでしょうか。
コード値でチェックできれば良いのにと思いましたが、本件の場合は難しいのかなとも感じました。
（nmcli device show ttyACM0 で、状態が100（接続済み）と出ますが、
項目が「GENERAL.状態:」と日本語があるため言語に依存する箇所が多いため）
y.nakamura
中村です。
浅尾さんの解決したとの投稿と私のLANG=Cの話とで、
投稿のタイミングのズレで入れ違ってしまいました。
原因が分かって解決できたようですが、
> 変更後：*disconnected*|*failed*|*unknown*|"*connection failed*"|*"切断済み"* )
で対策するのではなく、
サービスなどは英語(ASCII)環境で動作するように
OSの設定をした方がいいと思います。
> Linuxには明るくないのですが、ステータスのチェックは文字列で行うことが一般的なのでしょうか。
> コード値でチェックできれば良いのにと思いましたが、本件の場合は難しいのかなとも感じました。
終了コード検査もありますが、
出力の文字列検査することも少なくないと思います。
--
なかむら
asao.satoshi
中村様
お世話になっております。浅尾です。
丁寧な解説ありがとうございます。
> 変更後：*disconnected*|*failed*|*unknown*|"*connection failed*"|*"切断済み"* )
ご指摘の通り、良くない対応だと思っております。
問題の切り分け、および暫定的な対応としました。
（そもそも上記では、disconnected以外の対応が出来ていない）
>サービスなどは英語(ASCII)環境で動作するように
>OSの設定をした方がいいと思います。
承知しました。
どのような方法が一般的なのか調査していたところ、
下記フォーラムに解決方法が記載されていましたので
同様に行ってみました。
https://armadillo.atmark-techno.com/forum/armadillo/3070
・対応方法（先ほどの暫定対応は戻した上で）
/lib/systemd/system/connection-recover.serviceをviで編集。
Environment="LANG=C"を、ExecStartの直前に記載する。
[Service]部分の変更後の内容を下記に記載します。
[Service] Type=forking Environment="LANG=C" ExecStart=/usr/bin/connection-recover start ExecStop=/usr/bin/connection-recover stop
connection-recoverのサービス再起動（およびdaemonのreload）を実行後、
正常に動作するようになりました。
また、Armadillo再起動後も想定の動きとなっておりましたので
併せてご連絡します。
問題の解決にご尽力頂きありがとうございます。
y.nakamura
中村です。
> 下記となります。
ありがとうございます。
>
> root@armadillo:~# nmcli -f DEVICE,STATE device > デバイス 状態 > eth0 接続済み > ttyACM0 接続済み > wlan0 切断済み ... >
> 「ttyACM0 接続済み」ですので、LTEコネクションは有効だと思っています。
すみません。ログイン端末から実行の場合はLANGの指定が必要でした。
LANG=C nmcli -f DEVICE,STATE device
とやると、たぶん「接続済み」のところは「connected」に
なっていると思います。
/usr/bin/connection-recoverdはこの"connected"を見てますので。
--
なかむら
at_syunya.ohshio
2018年4月10日 16時21分
大塩です。
「LTEコネクション有効・無効」の定義について、認識違いを防ぐため次の内容と定義して回答致します。
-------------------------------------------------
「nmcli device」コマンドで表示される情報のうち、対象デバイスの[STATE]が
・[connected]ならば「LTEコネクション有効」
・[disconnected]ならば「LTEコネクション無効」
とします。
-------------------------------------------------
> さて、LTE再接続サービス（connection-recover）についてですが、
> このサービスは、LTEコネクションが無効の場合のみ、
> LTEコネクションを再起動し、LTEコネクションを有効化させるサービスと認識しておりますが、
> LTEのコネクションが有効の場合であっても、LTEコネクションを再起動しているようです。
LTEコネクションが有効でも、再起動を行う場合があります。
LTE再接続サービスは次のフローをループしています。
上記のフローから、「LTEコネクションが有効でping通信に失敗した場合は再起動」という処理が存在しているため、
LTEコネクション無効時だけではなく有効時でも再起動する場合があります。
LTE再接続サービスの仕様については「Armadillo-IoTゲートウェイG3L製品マニュアル 7.2.6.8.1 サービスの仕様」を参考にしてください。
> LTEコネクションが無効の場合のみ
> LTEコネクションを再起動するようには出来ないでしょうか。
上記処理を「LTE再接続サービス」のみで実装することは難しいです。
「LTE再接続サービスを無効にし、通信失敗時に手動で再起動を行う」方法が確実かと思われます。
LTE再接続サービスの停止については「Armadillo-IoTゲートウェイG3L製品マニュアル 7.2.6.8.3 停止・開始」を参考にしてください。
以上です。