asao.satoshi
2018年6月28日 11時21分
浅尾と申します。
armadillo-G3Lを野外でボックスに入れて使用しております。
LTE接続が切れることがあります。
LAN経由でのデータ取得は出来ているため、armadillo自体は生きているようです。
現地に行ってarmadilloを再起動すると直りますが、再起動前にLAN経由のsshで接続し、
nmcliによるコネクション再起動は出来ませんでした。
(nmcli c にて、コネクションのデバイス設定が消えてなくなっているような感じです。
再接続サービスでは「ttyACM0」のデバイスを使用したコネクションを見つけることが出来ず復帰できないようです。)
(以前、その状態でmmcliを見ると、電波強度が0%になっていたのが気になりました。)
端末が遠隔地に置きっ放しにしてあることもあり、
LTE再接続サービスによる再接続が効かない場合に
再起動するバッチ処理を作成したところ、昨日17時頃に再起動され
LTE接続も復活しました。
(具体的には、8.8.8.8へpingを行い続け、12回連続で通らない状態が続いた場合に再起動するバッチ処理です
pingコマンドと次のpingコマンドは、10秒の間隔を空けています。)
実は購入した端末のうち3台で発生している状況で、
原因についてご教示いただきたく思います。
syslogを添付しますので、恐れ入りますが調査をお願いできないでしょうか。
なおModemManagerのデバッグログは出力するようにはしております。
また原因特定のために必要な情報があれば、ご連絡をお願いします。
コメント
y.nakamura
中村です。
> 原因についてご教示いただきたく思います。
> syslogを添付しますので、恐れ入りますが調査をお願いできないでしょうか。
「原因について」とありますが、何の原因でしょうか?
LTEが切れる原因ですか?
再接続サービスが期待どおりに動かない理由ですか?
それとも他のことですか?
再接続サービスのことの場合・・・
添付されたsyslogを見たところでは、再接続サービスに関係するログは
何もないようなので、再接続サービスの問題の原因を調べるならば、
再接続サービスのスクリプトに適当なログ出力を追加するなどして
調べるのが近道かと思います。
ちなみに過去に、
G3Lで再接続サービスが機能しなくなるという問題がありました。
https://armadillo.atmark-techno.com/forum/armadillo/3049#comment-5155
--
なかむら
y.nakamura
asao.satoshi
浅尾です。
言葉が足らず申し訳ありません。
調査して欲しい原因は、突然、「LTE再接続サービスが効かないLTE接続不能な状況になってしまう事」についてです。
もう少し言えば、nmcliで作成したコネクション設定から、デバイス情報が消えてしまう現象の原因、です。
LTE接続不能で、かつLTE再接続サービスでも再接続されないとき、「nmcli c」を打つと下記のようになります。
名前 UUID タイプ デバイス gsm-drone 51f78145-80fc-4e65-ad97-5c3927da56d6 gsm -- eth0 4b28a36f-7472-45c4-9088-c9ebf7e0fc2c 802-3-ethernet eth0 有線接続 2 51e958eb-4e54-4050-ab8d-140981c68450 802-3-ethernet --
LTE再接続サービスでも再接続されるとき、つまり正常時は下記のようになります。
名前 UUID タイプ デバイス gsm-drone 51f78145-80fc-4e65-ad97-5c3927da56d6 gsm ttyACM0 eth0 4b28a36f-7472-45c4-9088-c9ebf7e0fc2c 802-3-ethernet eth0 有線接続 2 c924b7cc-7105-41e1-ae0c-3d20741010d2 802-3-ethernet --
「gsm-drone」がLTEコネクション設定となりますが、
遠隔地に取り付け、突然LTE接続不能になった際に、上記のような現象となります。
LTE再接続のプログラムを読み解くと、
デバイス名に「ttyACM0」が存在しなくなるため、LTE再接続サービスでは、
接続不能になっているコネクションを引き当てることが出来ず、
LTE再接続が行われていないものと推察しております。
ですので、まずは、nmcliで作成したコネクション設定から、なぜデバイス情報が消えてしまうのか、
を知ることで、本現象が解決できるのではないかと思っている次第です。
そのために、ModemManagerのデバッグログを出力したsyslogを添付した次第です。
asao.satoshi
浅尾です。
連投すみません。
現地端末にて、LTE接続不能になった際のnmcli、mmcliの状況を調査しておりました。
デバイス情報が消えてしまう件については、
デバイス名が「ttyACM0 → ttyACM1」に変わってしまっているためのようです。
LTE接続不能時のnmcli d の結果
nmcli d デバイス タイプ 状態 接続 eth0 ethernet 接続済み eth0 ttyACM1 gsm 切断済み -- wlan0 wifi 切断済み -- usb0 ethernet 利用不可 -- gre0 gre 管理無し -- gretap0 gretap 管理無し -- ip6gre0 ip6gre 管理無し -- ip6tnl0 ip6tnl 管理無し -- tunl0 ipip 管理無し -- lo loopback 管理無し -- sit0 sit 管理無し -- ip6_vti0 vti6 管理無し --
LTE接続コネクションは、ttyACM0で作成していますので
「ttyACM0 → ttyACM1」に変わってしまうと、
確かにLTE接続コネクションのデバイスが不明になってしまいますね。
なぜ変更してしまうのでしょうか。
また、ttyACM0に固定することは可能なのでしょうか。
中村様にご教示いただいたページと、過去ログを参照しようと思います。
y.nakamura
中村です。
G3Lを使い始めたころ、LTEのコネクション名をgsm-ttyACM0とは
異なるものに変更しようとしたことがあります。
そのあと、いろいろ調べていくと、
/etc/connection-recover/gsm-ttyACM0_connection-recover.conf
に設定されている
DEVICE=ttyACM0
TYPE=gsm
以外にすると再接続サービスが動かなくなりそうでしたので、
コネクション名はgsm-ttyACM0として使うようにしました。
gsm-ttyACM0_connection-recover.confの中身を(ファイル名も適切に)
自分の設定に合わせてもいいのかもしれませんが・・・
--
なかむら
asao.satoshi
浅尾です。
運用中に突然、ttyACM0->ttyACM1に名前が変更してしまうため、
名前を固定したいと思っておりますが、方法がよく分かりません。
ご教示いただけないでしょうか。
/etc/udev/rules.d/ に設定内容を記述したファイルを追加すれば良さそうなのですが、
設定に必要なデバイスを識別する情報の調べ方がよく分かりません。
udevadm info -a -n /dev/ttyACM0 コマンドを打ちましたが、どれが該当する情報なのか・・・。
Udevadm info starts with the device specified by the devpath and then walks up the chain of parent devices. It prints for every device found, all possible attributes in the udev rules key format. A rule to match, can be composed by the attributes of the device and the attributes from one single parent device. looking at device '/devices/soc/30800000.aips-bus/30b20000.usb/ci_hdrc.1/usb2/2-1/2-1:1.2/tty/ttyACM0': KERNEL=="ttyACM0" SUBSYSTEM=="tty" DRIVER=="" looking at parent device '/devices/soc/30800000.aips-bus/30b20000.usb/ci_hdrc.1/usb2/2-1/2-1:1.2': KERNELS=="2-1:1.2" SUBSYSTEMS=="usb" DRIVERS=="cdc_acm" ATTRS{bInterfaceClass}=="02" ATTRS{iad_bFunctionClass}=="02" ATTRS{bmCapabilities}=="2" ATTRS{iad_bFirstInterface}=="02" ATTRS{bInterfaceSubClass}=="02" ATTRS{bInterfaceProtocol}=="01" ATTRS{bNumEndpoints}=="01" ATTRS{iad_bFunctionSubClass}=="02" ATTRS{iad_bFunctionProtocol}=="01" ATTRS{supports_autosuspend}=="1" ATTRS{iad_bInterfaceCount}=="02" ATTRS{bAlternateSetting}==" 0" ATTRS{bInterfaceNumber}=="02" ATTRS{interface}=="CDC Abstract Control Model (ACM)" looking at parent device '/devices/soc/30800000.aips-bus/30b20000.usb/ci_hdrc.1/usb2/2-1': KERNELS=="2-1" SUBSYSTEMS=="usb" DRIVERS=="usb" ATTRS{bDeviceSubClass}=="02" ATTRS{bDeviceProtocol}=="01" ATTRS{devpath}=="1" ATTRS{idVendor}=="1e2d" ATTRS{speed}=="480" ATTRS{bNumInterfaces}==" 4" ATTRS{bConfigurationValue}=="1" ATTRS{bMaxPacketSize0}=="64" ATTRS{busnum}=="2" ATTRS{devnum}=="2" ATTRS{configuration}=="SQN Multifunction Composite Gadget" ATTRS{bMaxPower}=="300mA" ATTRS{authorized}=="1" ATTRS{bmAttributes}=="a0" ATTRS{bNumConfigurations}=="1" ATTRS{maxchild}=="0" ATTRS{bcdDevice}=="0307" ATTRS{avoid_reset_quirk}=="0" ATTRS{quirks}=="0x0" ATTRS{serial}=="105302708002" ATTRS{version}==" 2.00" ATTRS{urbnum}=="4439" ATTRS{ltm_capable}=="no" ATTRS{manufacturer}=="Sequans Communications" ATTRS{removable}=="unknown" ATTRS{idProduct}=="00a0" ATTRS{bDeviceClass}=="ef" ATTRS{product}=="SQN" looking at parent device '/devices/soc/30800000.aips-bus/30b20000.usb/ci_hdrc.1/usb2': KERNELS=="usb2" SUBSYSTEMS=="usb" DRIVERS=="usb" ATTRS{bDeviceSubClass}=="00" ATTRS{bDeviceProtocol}=="01" ATTRS{devpath}=="0" ATTRS{idVendor}=="1d6b" ATTRS{speed}=="480" ATTRS{bNumInterfaces}==" 1" ATTRS{bConfigurationValue}=="1" ATTRS{bMaxPacketSize0}=="64" ATTRS{authorized_default}=="1" ATTRS{busnum}=="2" ATTRS{devnum}=="1" ATTRS{configuration}=="" ATTRS{bMaxPower}=="0mA" ATTRS{authorized}=="1" ATTRS{bmAttributes}=="e0" ATTRS{bNumConfigurations}=="1" ATTRS{maxchild}=="1" ATTRS{bcdDevice}=="0314" ATTRS{avoid_reset_quirk}=="0" ATTRS{quirks}=="0x0" ATTRS{serial}=="ci_hdrc.1" ATTRS{version}==" 2.00" ATTRS{urbnum}=="22" ATTRS{ltm_capable}=="no" ATTRS{manufacturer}=="Linux 3.14.79-at17 ehci_hcd" ATTRS{removable}=="unknown" ATTRS{idProduct}=="0002" ATTRS{bDeviceClass}=="09" ATTRS{product}=="EHCI Host Controller" looking at parent device '/devices/soc/30800000.aips-bus/30b20000.usb/ci_hdrc.1': KERNELS=="ci_hdrc.1" SUBSYSTEMS=="platform" DRIVERS=="ci_hdrc" ATTRS{uframe_periodic_max}=="0" looking at parent device '/devices/soc/30800000.aips-bus/30b20000.usb': KERNELS=="30b20000.usb" SUBSYSTEMS=="platform" DRIVERS=="imx_usb" looking at parent device '/devices/soc/30800000.aips-bus': KERNELS=="30800000.aips-bus" SUBSYSTEMS=="platform" DRIVERS=="" looking at parent device '/devices/soc': KERNELS=="soc" SUBSYSTEMS=="platform" DRIVERS==""
y.nakamura
y.nakamura
中村です。
> ttyACM0以外(ttyACM1など)になることは想定されていないようなので、
とは書きましたが、
CDC_ACMなデバイスを複数接続すれば変わることはあるわけで、
何か実験するのに手ごろなものはないかと探してみたところ、
Arduino UNO がttyACMになってくれました。
Arduino UNO をG3Lにつないで起動すると、
# lsusb Bus 002 Device 003: ID 1e2d:00a0 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 2341:0001 Arduino SA Uno (CDC ACM) Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub # dmesg | grep ACM [ 2.727315] cdc_acm 1-1:1.0: ttyACM0: USB ACM device [ 3.358175] cdc_acm 2-1:1.2: ttyACM1: USB ACM device # ls -l /dev/ttyACM* crw-rw---- 1 root dialout 166, 0 7月 19 02:06 /dev/ttyACM0 crw-rw---- 1 root dialout 166, 1 7月 19 02:40 /dev/ttyACM1 # LANG=C nmcli d DEVICE TYPE STATE CONNECTION eth0 ethernet connected ethernet-eth0 ttyACM1 gsm disconnected -- wlan0 wifi disconnected -- usb0 ethernet unavailable -- ...(以下省略)...
と、LTEモデムがttyACM1になりました。
1e2d:00a0がLTEモデム、2341:0001がArduinoなので、
例えば次のようなルールを書いて固定できるといいのですが、
udevの"NAME"でデバイス名の変更はできません。
# LTE modem 1e2d:00a0 KERNEL=="ttyACM*", SUBSYSTEMS=="usb", ATTRS{idVendor}=="1e2d", ATTRS{idProduct}=="00a0", NAME="ttyACM0" # 2341:0001 Arduino SA Uno (CDC ACM) KERNEL=="ttyACM*", SUBSYSTEMS=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="0001", NAME="ttyACM1"
udev(7)のmanに次の記述があります。
NAME
The name to use for a network interface. See systemd.link(5) for a higher-level mechanism for setting the interface
name. The name of a device node cannot be changed by udev, only additional symlinks can be created.
どうしますかねぇ・・・
シンボリックリンクを作って、その名前でコネクションを作って、
再接続サービスもその名前を使うように変更するくらいしか、
今のところ思いつきません。
--
なかむら
y.nakamura
中村です。
自己レスです。
> どうしますかねぇ・・・
>
> シンボリックリンクを作って、その名前でコネクションを作って、
もしかしたら、いい加減なことを書いたかもしれません。
NetworkManagerとかModemManagerとかよくわかってないのですけど、
nmcli device で1列目(DEVICE)のところに表示されるデバイス名は
どこからひっぱってきているのでしょう?
eth0とかwlan0とか、ttyACM0以外のものは ifconfig -a で表示されるものと
同じみたいなのですけど、ttyACM0はどこから?
それから・・・
# grep -R ttyACM /etc/*
したら、/etc/connection-recover/の下のconfファイルの他に、
/etc/NetworkManager/dispatcher.d/99updownLEDの中にも
"ttyACM0"が埋め込まれてました。
また、/usr/の下の
/usr/bin/wwan-force-restart
/usr/bin/pds6j-read-conf
/usr/bin/pds6j-write-conf
/usr/bin/pds6j-rm-conf
にも。
--
なかむら
asao.satoshi
浅尾です。
中村様、いろいろとご教示ありがとうございます。
参考にさせていただきます。
> ttyACM0以外(ttyACM1など)になることは想定されていないようなので、
> 固定する方法といよりも、なぜttyACM1になってしまうのかの
> 原因を突き止めた方がいいと思います。
おっしゃる通りなのですが、原因究明の方法についても分から無い状況です。
しかしながら、今月だけでも、ある1台の端末で5回起こっておりますので、
現在は対処療法として、ping応答が2分間不能だった場合に
Armadilloの再起動を行うバッチを回して凌いでいる状況です。
y.nakamura
中村です。
私の昨晩の実験ではArduinoをつなぐことでttyACM1になりましたが、
そういったものが接続されておらず、最初はttyACM0だったものが
動作中にttyACM1に変わってしまうということだとすると、
何等かの原因でLTEモデムをリセットしたときに、
それまでのttyACM0がカーネルから削除される前に
リセット再起動したモデムが認識されて、
そのときにttyACM1になってしまう、というようなことが
原因なのではないのか、と推測できます。
最初にアップしていただいたsyslogを見直してみました。
Jun 27 16:54:02 armadillo ModemManager[2251]: <debug> (ttyACM0): <-- '<CR><LF>^EXIT: D-OfGetStat: : 0<CR><LF><CR><LF>^EXIT: M_T-fr 428:ts 84059<CR><LF>' Jun 27 16:54:02 armadillo kernel: usb 2-1: USB disconnect, device number 2 Jun 27 16:54:02 armadillo kernel: cdc_ether 2-1:1.0 usb1: unregister 'cdc_ether' usb-ci_hdrc.1-1, CDC Ethernet Device ... Jun 27 16:54:15 armadillo kernel: usb 2-1: new high-speed USB device number 3 using ci_hdrc Jun 27 16:54:15 armadillo kernel: cdc_ether 2-1:1.0 usb1: register 'cdc_ether' at usb-ci_hdrc.1-1, CDC Ethernet Device, 02:80:70:02:56:20 Jun 27 16:54:15 armadillo kernel: cdc_acm 2-1:1.2: This device cannot do calls on its own. It is not a modem. Jun 27 16:54:15 armadillo kernel: cdc_acm 2-1:1.2: ttyACM1: USB ACM device
このあたりが手がかりになるかもしれません。
--
なかむら
y.nakamura
中村です。
同じ原因かどうかはわかりませんが、ttyACM1になる現象を再現できました。
再現性は100%です。
先に私の環境を書いておきます。
Armadillo起動時にはLTEは何も設定されていない状態です。
(overlayfsで起動し、LTEを使うときだけコネクションを作ってます)
有線LANのコネクション名はデフォルトとは異り、ethernet-eth0にしています。
LTEモデムのファームウェアは最新にしてあります。
再起動時にusb1とusb0が逆になってしまう問題の対策はしてあります。
G3Lを起動してrootでログインしたあとの画面をそのままコピペしておきます。
少し長くなりますが正確に伝えるために、見易さのために改行やメモを
適当に挿入する以外は、そのまま張り付けておきます。
Debian GNU/Linux 8 armadillo ttymxc4 armadillo login: root Password: Last login: Thu Jul 19 01:59:54 JST 2018 on ttymxc4 Linux armadillo 3.14.79-at19 #6 SMP PREEMPT Wed Jan 24 06:30:57 JST 2018 armv7l The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@armadillo:~# IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready root@armadillo:~# LANG=C nmcli d DEVICE TYPE STATE CONNECTION eth0 ethernet connected ethernet-eth0 ttyACM0 gsm disconnected -- wlan0 wifi disconnected -- usb0 ethernet unavailable -- gre0 gre unmanaged -- gretap0 gretap unmanaged -- ip6gre0 ip6gre unmanaged -- ip6tnl0 ip6tnl unmanaged -- tunl0 ipip unmanaged -- lo loopback unmanaged -- sit0 sit unmanaged -- ip6_vti0 vti6 unmanaged -- (LTEモデムをリセットする) root@armadillo:~# echo 1 > /sys/devices/extboard-devices:els31-cold-reset/reset usb 2-1: USB disconnect, device number 2 cdc_ether 2-1:1.0 usb1: unregister 'cdc_ether' usb-ci_hdrc.1-1, CDC Ethernet Device (この状態で10数秒放置すると、次のメッセージが表示される) root@armadillo:~# usb 2-1: new high-speed USB device number 3 using ci_hdrc cdc_ether 2-1:1.0 usb1: register 'cdc_ether' at usb-ci_hdrc.1-1, CDC Ethernet Device, 02:80:79:97:85:40 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 (少し待ってから) root@armadillo:~# LANG=C nmcli d DEVICE TYPE STATE CONNECTION eth0 ethernet connected ethernet-eth0 ttyACM1 gsm disconnected -- wlan0 wifi disconnected -- usb0 ethernet unavailable -- gre0 gre unmanaged -- gretap0 gretap unmanaged -- ip6gre0 ip6gre unmanaged -- ip6tnl0 ip6tnl unmanaged -- tunl0 ipip unmanaged -- lo loopback unmanaged -- sit0 sit unmanaged -- ip6_vti0 vti6 unmanaged --
再接続サービスが使っているLTEモデムをリセットするコマンド(スクリプト)
/usr/bin/wwan-force-restartでLTEモデムをリセットした場合には問題はありません。
このスクリプトでも
echo 1 > /sys/devices/extboard-devices:els31-cold-reset/reset
をやっていますが、その前後でModemManagerサービスをstop/startしていてます。
その部分を引用しておきます。
G3L_ELS31_RESTART="/sys/devices/extboard-devices:els31-cold-reset/reset" ... g3l_wwan_force_restart() { if [ -e $G3L_ELS31_RESTART ]; then put_log "start force restart els31" service ModemManager stop send-at /dev/ttyACM0 AT^SMSO echo 1 > $G3L_ELS31_RESTART wait_g3l_els31_disconnect wait_g3l_els31_connect service ModemManager start put_log "end force restart els31" return 0 else put_log "error: $G3L_ELS31_RESTART is not found" exit 1 fi }
--
なかむら
at_koseki
古関です。
回答に時間がかかってしまい申し訳ありません。
> Jun 27 16:54:02 armadillo ModemManager[2251]: (ttyACM0): <-- '^SHUTDOWN'
> Jun 27 16:54:02 armadillo ModemManager[2251]: (ttyACM0): <-- '^EXIT: Assertion failed^EXIT: File: rfcAdderReg.c@1574'
> ・・・省略・・・
> Jun 27 16:54:02 armadillo ModemManager[2251]: (ttyACM0): <-- '^EXIT: Lpm Error Counter: : 0^EXIT: Lpm Msg L1 Counter: : 30278'
> Jun 27 16:54:02 armadillo ModemManager[2251]: (ttyACM0): <-- '^EXIT: Lpm Msg EE Counter: : 30278'
> Jun 27 16:54:02 armadillo ModemManager[2251]: (ttyACM0): <-- '^EXIT: D-OfGetStat: : 0^EXIT: M_T-fr 428:ts 84059'
通信環境、基地局等の相性によって、まれに発生することがあるLTEモジュールのファームウェア側の問題と推測しています。
LTEモジュールが異常動作して、上記のログを出した後、
突然リブートして、USBデバイスとしてdisconnect、再度connectしているようです。
あからさまに、backtraceのようなログをモジュールが出しているため、
モジュールメーカーにログを送付し問い合わせ中です。
■ 新ファームウェアでの再現性
本現象ですが、先ほどPCNを公開いたしました、ELS31-J新ファームウェアで問題が修正されている可能性があります。
https://users.atmark-techno.com/change_notification/2018-009
PCN中記載 変更点:「動作中、偶発的にLTEモジュール自体がシャットダウン、または、リブートすることがある不具合を修正」が該当?
お手数をおかけしますが、新ファームウェアで再現性を見ていただけますと幸いです。
もし、新ファームウェアでもこの問題が改善しない場合
すぐには原因判明、修正ファームウェアのリリースがされない可能性があります。
それまでは運用[※1] でカバーする必要がありそうです。
■ デバイス名が/dev/ttyACM0 -> /dev/ttyACM1に変わる理由
デバイス名が/dev/ttyACM0 -> /dev/ttyACM1になってしまうのは、中村様の推測と同意見で、
突然モジュールがリブートしUSB disconnect/connectが発生したため、
ModemManager、又はカーネルがリソースを開放できず、/dev/ttyACM0が開放されず、
/dev/ttyACM1が割り当てられたと考えています。
※ udevで固定しても、使用済みの名前なので割り当てられないはずです
中村様も記載していますが、ModemManagerが起動している状態で、
モジュールをリブートさせれば同様の現象は再現できます。
・LTEでテータ接続・通信をする
・以下のコマンドを実行する(通信中に横から強制的にモジュールリブートさせる)
# send-at /dev/ttymxc6 at+cfun=1,1 ※ こちらの方が安全です。。
または、
# echo 1 > /sys/devices/extboard-devices:els31-cold-reset/reset
/dev/ttyACM1に変化した場合、以下のコマンドを実施すれば/dev/ttyACM0に戻らないでしょうか?
# wwan-force-restart
※ この中で、ModemManagerの停止、モジュールのリブート、ModemManagerの再開を行っています。
ModemManagerの停止することで、/dev/ttyACM0が開放され
その後、モジュールのリブートすることで、再度/dev/ttyACM0が割り当てられます
■ 再接続サービスの動作
弊社で擬似的に問題を再現させた場合は、/dev/ttyACM0 -> /dev/ttyACM1に
なった場合でもしばらく待てば再接続サービスで wwan-force-restartされ、再接続される状況です。
そちらで本現象が再現した場合は、しばらくまっても再接続されない状況でしょうか?
LTEモジュールのリブートの仕方によってはwwan-force-restartでリソース開放されない場合があるのかもしれません。
この場合、Armadillo本体をリブート[※1]したほうが無難と思います。
[※1]
"/etc/connection-recover/gsm-ttyACM0_connection-recover.conf"の
FORCE_REBOOT=FALSE をTRUEにすることで再接続サービスからのリブートが可能です。
ご迷惑をおかけしますが、よろしくお願いいたします。
y.nakamura
中村です。
先ほどG3Lのモデムファームウェアのアップデート通知(メール)があり、
不具合の内容を読んで、「お!これかな?」と思っていたところでした。
// LTEモデムのファームウェア更新は終わらせました
> /dev/ttyACM1に変化した場合、以下のコマンドを実施すれば/dev/ttyACM0に戻らないでしょうか?
> # wwan-force-restart
> ※ この中で、ModemManagerの停止、モジュールのリブート、ModemManagerの再開を行っています。
> ModemManagerの停止することで、/dev/ttyACM0が開放され
> その後、モジュールのリブートすることで、再度/dev/ttyACM0が割り当てられます
>
> ■ 再接続サービスの動作
> 弊社で擬似的に問題を再現させた場合は、/dev/ttyACM0 -> /dev/ttyACM1に
> なった場合でもしばらく待てば再接続サービスで wwan-force-restartされ、再接続される状況です。
> そちらで本現象が再現した場合は、しばらくまっても再接続されない状況でしょうか?
質問者の浅尾さんはコネクション名をgsm-droneに変更しているようです。
これが原因で再接続サービスが機能していないのではないでしょうか?
以下は、このスレッドでの2018/07/02の私自身の投稿からの引用です。
>> G3Lを使い始めたころ、LTEのコネクション名をgsm-ttyACM0とは
>> 異なるものに変更しようとしたことがあります。
>> そのあと、いろいろ調べていくと、
>> /etc/connection-recover/gsm-ttyACM0_connection-recover.conf
>> に設定されている
>> DEVICE=ttyACM0
>> TYPE=gsm
>> 以外にすると再接続サービスが動かなくなりそうでしたので、
>> コネクション名はgsm-ttyACM0として使うようにしました。
>> gsm-ttyACM0_connection-recover.confの中身を(ファイル名も適切に)
>> 自分の設定に合わせてもいいのかもしれませんが・・・
--
なかむら
asao.satoshi
古関様、中村様
浅尾です。
ご回答、ならびにご協力ありがとうございます。
ファームウェアのアップデートを試してみたいと思います。
> [※1]
> "/etc/connection-recover/gsm-ttyACM0_connection-recover.conf"の
> FORCE_REBOOT=FALSE をTRUEにすることで再接続サービスからのリブートが可能です。
自前でリブートするバッチを作成しましたが、connection-recoverで可能であれば
こちらを使用するようにしたいと思います。
> 弊社で擬似的に問題を再現させた場合は、/dev/ttyACM0 -> /dev/ttyACM1に
> なった場合でもしばらく待てば再接続サービスで wwan-force-restartされ、再接続される状況です。
> そちらで本現象が再現した場合は、しばらくまっても再接続されない状況でしょうか?
再接続はされませんでした。
> 質問者の浅尾さんはコネクション名をgsm-droneに変更しているようです。
> これが原因で再接続サービスが機能していないのではないでしょうか?
設定ファイルを自分でリネームしたか、コネクション作成時に自動で作成されていたのかは
覚えておりませんが、gsm-drone_connection-recover.conf の名前で設定ファイルがあります。
ttyACM0がttyACM1に変わっていなければ、コネクション再接続は動作しておりました。
asao.satoshi
2018年6月29日 13時23分
失礼いたしました。
syslog(抜粋)がアップロードされていませんでしたのでアップしました。