tom5467_2016
2017年7月22日 9時26分
山口と申します。
ArmadilloーIoT G2で3Gに接続した状態で 使用しております。
TeraTermなどで接続していると
以下のようなログが時々表示されます。
これはどのようなプログラムが
どのような意味で出力しているのでしょうか。
よろしくお願いします。
-------------------------------------------------------------------------------------
[root@armadillo-iotg (ttymxc1) ~]# usb 2-1: USB disconnect, device number 11
cdc_ether 2-1:1.6 umts0: unregister 'cdc_ether' usb-ci_hdrc.1-1, CDC Ethernet Device
cdc_ether 2-1:1.8 umts1: unregister 'cdc_ether' usb-ci_hdrc.1-1, CDC Ethernet Device
cdc_ether 2-1:1.10 umts2: unregister 'cdc_ether' usb-ci_hdrc.1-1, CDC Ethernet Device
usb 2-1: new full-speed USB device number 12 using ci_hdrc
cdc_acm 2-1:1.0: This device cannot do calls on its own. It is not a modem.
cdc_acm 2-1:1.0: ttyACM0: USB ACM device
usb 2-1: USB disconnect, device number 12
usb 2-1: new full-speed USB device number 13 using ci_hdrc
usb 2-1: not running at top speed; connect to a high speed hub
usb 2-1: USB disconnect, device number 13
usb 2-1: new full-speed USB device number 14 using ci_hdrc
usb 2-1: not running at top speed; connect to a high speed hub
cdc_acm 2-1:1.0: This device cannot do calls on its own. It is not a modem.
cdc_acm 2-1:1.0: ttyACM0: USB ACM device
cdc_acm 2-1:1.2: This device cannot do calls on its own. It is not a modem.
cdc_acm 2-1:1.2: ttyACM1: USB ACM device
cdc_acm 2-1:1.4: This device cannot do calls on its own. It is not a modem.
cdc_acm 2-1:1.4: ttyACM2: USB ACM device
cdc_ether 2-1:1.6 eth1: register 'cdc_ether' at usb-ci_hdrc.1-1, CDC Ethernet Device, 00:00:11:12:13:14
cdc_ether 2-1:1.8 eth2: register 'cdc_ether' at usb-ci_hdrc.1-1, CDC Ethernet Device, 00:00:11:12:13:16
cdc_ether 2-1:1.10 eth3: register 'cdc_ether' at usb-ci_hdrc.1-1, CDC Ethernet Device, 00:00:11:12:13:18
-------------------------------------------------------------------------------------
コメント
ma2013
> 古関です。
>
> メッセージはカーネルが出しております。
> 現象としては、3Gモジュールの再起動によるunregister/registerが起きています。
>
> 回線側の要因等で3Gのデータ通信が切断した場合、
> モジュールを一度再起動、再接続をトライする仕組み(3g-recover)が入っており、
> その時のログが表示されているものと思われます。
>
> 3g-recoverによるモジュール再起動と再接続が行われた場合、
> "/var/log/messages"に "3g-recover-daemon :reset" と出力されます。
>
> もしくは高温で動作時に3Gモジュールがサーマルシャットダウン・復旧している可能性もあります。
>
> 使用環境が常温であればおそらく前者と思います。
>
> よろしくおねがいします。
MCSのマーです。
回線側の原因で通信が切断されることはあると思いますが
3g-recoverに任せば特にifdown umts0 ifup umts0を実行
しなくても充分と理解して宜しいでしょうか？
宜しくお願いいたします。
at_koseki
古関です。
> 回線側の原因で通信が切断されることはあると思いますが
> 3g-recoverに任せば特にifdown umts0 ifup umts0を実行
> しなくても充分と理解して宜しいでしょうか？
場合によります。
3g-recoverは、モジュールをリセットしながら再接続をトライし続けるので環境に問題がなければいつかは接続できます。
しかし、お客様が実装しているアプリケーションの状態を全く考慮せずに、再接続を実施しますので、
アプリケーションの実装によっては、3g-recoverによる再接続がされたとしても、データの取りこぼしが起こるかもしれません。
例えば、お客様が実装しているアプリケーションが3G経由で定期的にクラウドにデータをあげていて
データの取りこぼしをしたくないユースケースの場合、問題になるかもしれません。
このような場合は、アプリケーション内で再接続するなり、
通信ができない場合はバッファ・キャッシュに貯めておき、
接続が再開したら同期するなどの対策が必要です。
よろしくおねがいします。
ma2013
> 古関です。
>
> > 回線側の原因で通信が切断されることはあると思いますが
> > 3g-recoverに任せば特にifdown umts0 ifup umts0を実行
> > しなくても充分と理解して宜しいでしょうか？
>
> 場合によります。
>
> 3g-recoverは、モジュールをリセットしながら再接続をトライし続けるので環境に問題がなければいつかは接続できます。
> しかし、お客様が実装しているアプリケーションの状態を全く考慮せずに、再接続を実施しますので、
> アプリケーションの実装によっては、3g-recoverによる再接続がされたとしても、データの取りこぼしが起こるかもしれません。
>
> 例えば、お客様が実装しているアプリケーションが3G経由で定期的にクラウドにデータをあげていて
> データの取りこぼしをしたくないユースケースの場合、問題になるかもしれません。
>
> このような場合は、アプリケーション内で再接続するなり、
> 通信ができない場合はバッファ・キャッシュに貯めておき、
> 接続が再開したら同期するなどの対策が必要です。
>
> よろしくおねがいします。
MCSのマーです。
山口さんのご質問に割り込んで申し訳ありませんが
古関さんから結構貴重な情報をいただきありがとうございました。
弊社応用ではアプリ層で通信の確認を行っておりますので
3G（またはumts0）が復帰不可能の状態に陥らない限り，データの取りこぼしなどは発生しません。
そうなりますと，弊社の上記場合では3g-recoverに任せば充分と理解して宜しいでしょうか？
即ち，umts0は一定時間無効になっても，3g-recoverにより回復されますね。
また
3G（またはumts0）は無効になってしまった場合，3g-recoverは約どのぐらい時間内に検知可能でしょうか？
以上宜しくお願いいたします。
at_koseki
古関です。
> 弊社応用ではアプリ層で通信の確認を行っておりますので
> 3G（またはumts0）が復帰不可能の状態に陥らない限り，データの取りこぼしなどは発生しません。
>
> そうなりますと，弊社の上記場合では3g-recoverに任せば充分と理解して宜しいでしょうか？
アプリケージョンでやらないのであれば、3g-recoverに任せたほうが良いです。
3g-recoverを動作させた状態で、アプリケーション内でif up/downをすると
処理が競合するので、逆にアプリケーション内でやるなら、3g-recoverは止めてください。
> 即ち，umts0は一定時間無効になっても，3g-recoverにより回復されますね。
回線や接続環境によります。
3g-recoverは一定時間を開けながら接続のトライをし続けます。
また、御社のアプリケーションと3g-recoverを組み合わせて動作させた場合の、
データを取りこぼす、取りこぼさないまでは保障しかねますので、
十分なテストを行なってから運用いただければと思います。
> また
> 3G（またはumts0）は無効になってしまった場合，3g-recoverは約どのぐらい時間内に検知可能でしょうか？
デフォルトでは600秒です。
変更したい場合はAtmark Distの以下設定ファイルを変更して下さい。
vendors/AtmarkTechno/Armadillo-IoTG-Std/etc/3g-recover.conf
宜しくお願いいたします。
ma2013
tom5467_2016
古関様
山口です。
しばらく不在しており回答できず
申し訳ありませんでした。
※しかし、話しがかなり進んでいるようですが。
3g-recoverによるモジュール再起動と再接続の件は承知しました。
未だ、出先なので手元にArmadilloが無く
後ほど"/var/log/messages"を確認してみます。
ちなみに使用環境は常温です。
ところで今、問題になっているのはArmadillo-IoT G2ですが
Armadillo-IoT G1では
3Gで問題は起きていなかった様に感じます。
Armadillo-IoT G2の3Gモジュールで再起動と再接続が頻繁に起きてしまうのは
3Gモジュールのファームに関する問題が
まだ残っているためなのでしょうか。
3Gについて過去の質問も見てみましたが問題の整理がついていない状況です。
宜しくお願いします。
ma2013
at_koseki
古関です。
> Armadillo-IoT G2の3Gモジュールで再起動と再接続が頻繁に起きてしまうのは
> 3Gモジュールのファームに関する問題が
> まだ残っているためなのでしょうか。
> 3Gについて過去の質問も見てみましたが問題の整理がついていない状況です。
はい。
Armadillo-IoT G2搭載 3Gモジュール(HL8548)のファームウェアには不具合が残っております。
ファームウェア FW:5.5.16で、問題発生後モジュールをリセットするまでデータ接続ができなくなる不具合があり、
ワークアラウンドとして3Gモジュールのリセットを行なっています。
不具合の詳細は以下を参照してください。
http://armadillo.atmark-techno.com/howto/iotg-g2-3g-firm-summary
上記URLにも説明がありますが。
モジュールをリセットするまでデータ接続ができない不具合は
最新ファームウェア(FW:5.5.22)では修正されております。
しかし、最新ファームウェア(FW:5.5.22)では、DNSアクセスを行わない設定のSIMで
データ接続できないという別の不具合があります（閉域網の場合に多いです）。
現在、どちらの問題もFixされたファームウェアのリリースを
モジュールメーカーに要求しておりますが、リリースの目処はたっておりません。
よろしくおねがいします。
tom5467_2016
古関様
山口です。
3Gモジュール(HL8548)のファームウェアの不具合の承知しました。
特にDNSの件は気を付けておきます。
3g-recoverの動作について忘れておりました。
前に3g-recoverはpingを使用することを何かで知り
3g-recover.conf内のIPアドレスを削除した状態のままにしておりました。
おそらく3g-recoverがpingに失敗し頻繁に再接続を繰り返すような
動作になっていたのが今回、時々表示されるログ(メッセージ)だったように
思いますが如何でしょうか。
いずれにしても外部サーバーに pingする3g-recoverは使用できないので
3g-recoverはとめて アプリ側で再接続するようにします。
可能なら3g-recover.confにIPアドレスが設定されていなければ
何もしないというような仕様にすることは可能でしょうか。
現在rc_localで
3g-recover stop
を実行するようにし3g-recoverを止めて
連続運用を行っておりますが今のところ問題ありません。
もちろん送信データを一旦バッファーに格納し送信に失敗したら3Gの再接続 、
バッファーの再送を行うようにしております。
使われ方もよりますが
デフォルトで3g-recoverが動作していると逆に不具合になるような気もします。
如何でしょうか。
at_koseki
2017年7月25日 16時42分
古関です。
メッセージはカーネルが出しております。
現象としては、3Gモジュールの再起動によるunregister/registerが起きています。
回線側の要因等で3Gのデータ通信が切断した場合、
モジュールを一度再起動、再接続をトライする仕組み(3g-recover)が入っており、
その時のログが表示されているものと思われます。
3g-recoverによるモジュール再起動と再接続が行われた場合、
"/var/log/messages"に "3g-recover-daemon :reset" と出力されます。
もしくは高温で動作時に3Gモジュールがサーマルシャットダウン・復旧している可能性もあります。
使用環境が常温であればおそらく前者と思います。
よろしくおねがいします。