Armadilloフォーラム

吉田です。

お手数おかけします。

2台のSIMカードを入れ替えるとどうなりますでしょうか？
同じ Armadillo IoT ゲートウェイ G3L が通信断/再接続を繰り返しますでしょうか？

SIMを入れ替えても同じArmadillo IoT ゲートウェイ G3L で症状が発生する場合、
症状が発生している側で以下の情報を頂けますと、接続状況を確認出来る可能性があります。

(1) ModemManager のデバッグログを有効にした syslog
https://armadillo.atmark-techno.com/blog/750/2508
を参考に ModemManager のデバッグログを有効にした状態にし、
Armadillo を再起動した後、
接続・切断の事象が発生している時間帯の/var/log/syslogを添付下さい。

(2) # mmcli -m 0の結果
電話番号(Numbers)やimeiの値は伏せて頂いて構いません。
通信出来ているタイミングと、切断しているタイミングでとって頂けますと助かります。

(3) LTEモジュールのファームウェアバージョン
# els31-send-at ATI1
の結果をお願いします。

お世話になっております。
ゲートウェイの調査の情報取得を行っており、２つ質問がございます。

１．デバッグログが有効になっているかは、どこで判断出来るのでしょうか？
２．LTEバージョンが取得出来ない原因を教えて頂きたい。もしくは、他にリモートでLTEバージョン取得方法があれば教えて頂きたいです。

１に関して、
ご案内にありました　/etc/systemd/system/dbus-org.freedesktop.ModemManager1.service
をゲートウェイが現地設置済のため、ノードアイ経由でsedコマンドでご案内の通り、修正した結果が以下です。。

cat /etc/systemd/system/dbus-org.freedesktop.ModemManager1.service

[Unit]
Description=Modem Manager
After=syslog.target

[Service]
Type=dbus
BusName=org.freedesktop.ModemManager1
#ExecStart=/usr/sbin/ModemManager
ExecStart=/usr/sbin/ModemManager --log-level=DEBUG
StandardError=null
Restart=on-abort

[Install]
WantedBy=multi-user.target
Alias=dbus-org.freedesktop.ModemManager1.service

/etc/systemd/system/dbus-org.freedesktop.ModemManager1.service　を上記に修正後、rebootで再起動しています。

２に関して、
LTEバージョン取得するには、ATコマンドが必要。
ATコマンドにはModemManagerを停止する必要あり。
ゲートウェイが現地にあるためにModemManagerを停止すると、リモートでATコマンドを実行出来ないので、

ModemManagerの停止
↓
ATコマンド実行結果のログ保存
↓
ModemManager再開
という処理を行うスクリプトを作り、LTEバージョン取得を試みましたが上手くいかず、
リモートでのLTEバージョン取得に関してご教示頂けないでしょうか？

スクリプトの内容は下記です。
=============================================
#!/bin/bash

set -eu

trap catch ERR
trap finally EXIT

function catch {
echo "エラーが発生しました"
}

function finally {
echo "connection-recoverを開始中..."
echo "ModemManagerを開始中..."
service connection-recover start
service ModemManager start
echo "スクリプト終了"
}

echo "スクリプト開始"

echo "connection-recoverを停止しています..."
echo "ModemManagerを停止しています..."
service connection-recover stop
service ModemManager stop

echo "バージョン取得処理開始"
echo "-------------結果-------------"
expect <<- END_OF_SCRIPT
set timeout 5
spawn env LANG=C cu -l /dev/ttymxc6 -s 115200
expect "Connected."
send "ATI1\r"
expect {
"OK" {
send "~.\r"
exit 0
}
"ERROR" {
send "~.\r"
exit 1
}
}
END_OF_SCRIPT
echo "------------------------------"
echo "バージョン取得処理完了"
=============================================

・上記スクリプトの実行結果
spawn env LANG=C cu -l /dev/ttymxc6 -s 115200
cu: open (/dev/ttymxc6): Permission denied
cu: /dev/ttymxc6: Line in use

吉田です、ご対応ありがとうございます。

node-eyeのみで接続可能な状況ですね。

> １．デバッグログが有効になっているかは、どこで判断出来るのでしょうか？

コマンドが打てるのであれば、以下で確認が出来ます。
# ps x | grep ModemManager
$ ps ax | grep ModemManager
で以下のように、ModemManagerの後ろに「--log-level=DEBUG」が付与されて起動していることが確認出来ます。
859 ? Ssl 0:00 /usr/sbin/ModemManager --log-level=DEBUG
4400 ttymxc4 S+ 0:00 grep ModemManager

または、/var/log/syslog を Armadillo-IoT ゲートウェイ G3L からダウンロードできるのであれば、
このフォーラムに添付頂ければ確認致します。

> ２．LTEバージョンが取得出来ない原因を教えて頂きたい。
> もしくは、他にリモートでLTEバージョン取得方法があれば教えて頂きたいです。

エラーを見る限りroot権限がない状態で実行している為と思われます。

最初のお問い合わせに戻りますが、
近い位置に配置した2台の Armadillo-IoT ゲートウェイ G3L のうち、
1台だけが接続・切断を繰り返しているとのことですが、
設置当初からその G3L は接続・切断を繰り返していましたでしょうか？

吉田です。情報ありがとうございます。

> 2. mmcli -m 0
> 3. LTEバージョン情報取得結果

特に問題はないように見受けられます。

> 設置直後から起きていました。
> 3/30にゲートウェイを設置し、通信down,upが起きた期間は現在までに
> 3/30～4/02
> 4/05～4/07
> 4/09～4/12
> 4/17,18
> 以上の日付で起きています。

とのことですが、4/17,18以外はどの程度の頻度で発生していますでしょうか？
ご利用になられているのがIIJのSIMということですので、
1日に1～数回程度の再接続が発生することはあります。

デバッグログなどを確認出来ないとのことですので、出来そうな対処としては、
以下のフォーラムを参考に、
https://armadillo.atmark-techno.com/forum/armadillo/3533
LTEモジュール(ELS31-J)を工場リセットを試して頂くことは可能でしょうか？
※ モデムマネージャーを停止・再起動する必要がある為、一旦通信は途絶えます。

----------------------------------------------
root@armadillo:~# systemctl stop connection-recover.service
root@armadillo:~# service ModemManager stop

cu -l /dev/ttyACM0 -s 115200

AT&F
OK

AT^SCFG="MEopMode/Factory","all"
OK

AT+CFUN=1,1
OK

^SHUTDOWN
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
cdc_acm 2-1:1.2: failed to set dtr/rts
cu: Got hangup signal

Disconnected.

(モジュールがリブートするとcuが勝手に終了する)
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:70:06:22
----------------------------------------------

停止したModemManagerと再接続サービスの再起動を行います。
root@armadillo:~# service ModemManager start
root@armadillo:~# systemctl start connection-recover.service

上記の様にリモートで出来ることを記載はしておりますが、
客先で使用を始めてから一か月以上経過しているとのことですので、
出来れば現場で別のSIMを挿してみるなどの確認をして頂き、
それでも事象が変化がなく、運用に支障があるのでしたら、

故障かなと思ったら(Armadillo-IoT ゲートウェイ G3L)
https://armadillo.atmark-techno.com/faq/troubleshooting-aiotg3l
Armadillo-IoT G3L: LTEモジュールで通信ができないときには？
https://armadillo.atmark-techno.com/faq/aiotg-g3l-lte-doesnt-work
などを参考に今後の対応をご検討ください。

よろしくお願いします。

回答が遅くなり、大変申し訳ございません。

①デバッグモードONに関して
②4/17,18以外はどの程度の頻度で発生していますでしょうか？

①に関して、
デバッグモード有効化スクリプト(Debug_Mode_On.sh)を実行し、有効化にならない原因をご教示頂けないでしょうか？

また、実行順序としては
　
.serviceファイルの書き換え⇒設定ファイルを再読み込み⇒connection-recover＆ModemManager停止⇒connection-recover＆ModemManager再開

という流れで合っていますでしょうか？

デバッグモードを有効化にするために、GW再起動ではなく、ModemManager再起動で出来るということで
リモートでスクリプト実行によるデバッグモード有効化を試みました。
スクリプトはエラーなく実行されているのですが、
スクリプト実行後に # ps x | grep ModemManager、$ ps ax | grep ModemManager
のコマンドで確認しても、--log-level=DEBUGが付与されていません。

実行コマンドは下記です。※企業情報が含まれるため、一部****で変更しております。
sudo bash /home/****/src/Debug_Mode_On.sh >> /var/log/Debug_Mode_On_sh.log 2>&1

==================Debug_Mode_On.sh ここから=================================
#!/bin/bash

set -eu

trap catch ERR
trap finally EXIT

#エラー時の処理
function catch {
echo "エラーが発生しました、.serviceファイルをバックアップに切り替えます。"
rm /etc/systemd/system/dbus-org.freedesktop.ModemManager1.service
cp -a /home/****/tmp/dbus-org.freedesktop.ModemManager1_bk.service /etc/systemd/system/dbus-org.freedesktop.ModemManager1.service
echo ".serviceファイルをバックアップに切り替えたので、設定ファイルを再読み込みします。"
systemctl daemon-reload
echo "connection-recoverを開始中..."
echo "ModemManagerを開始中..."
service connection-recover start
service ModemManager start
echo "connection-recover&ModemManager 再開"
}

function finally {
echo "スクリプト終了"
}

echo "スクリプト開始"
mkdir /home/****/tmp/
cp -a /etc/systemd/system/dbus-org.freedesktop.ModemManager1.service /home/****/tmp/dbus-org.freedesktop.ModemManager1_bk.service
sed -i 's/ExecStart/#ExecStart/' /etc/systemd/system/dbus-org.freedesktop.ModemManager1.service
sed -i '8aExecStart=/usr/sbin/ModemManager --log-level=DEBUG' /etc/systemd/system/dbus-org.freedesktop.ModemManager1.service
systemctl daemon-reload
echo "connection-recoverを停止しています..."
echo "ModemManagerを停止しています..."
service connection-recover stop
service ModemManager stop

echo "connection-recover&ModemManager 停止"
echo "------------------------------"

echo "connection-recoverを開始中..."
echo "ModemManagerを開始中..."
service connection-recover start
service ModemManager start
echo "connection-recover&ModemManager 再開"
=================ここまで==================================

②に関して
4/19 ～　今まで頻発していたメインダイニングのGW通信DOWNが起きていませんでしたが、
5/12 に5分間の通信DOWNが発生し、その後は現在まで通信Downは起きていません。
※通信DownはノードアイのHeartbeatによる切断通知を通信Downと記載しております。

吉田です。

> ②に関して
> 4/19 ～　今まで頻発していたメインダイニングのGW通信DOWNが起きていませんでしたが、
> 5/12 に5分間の通信DOWNが発生し、その後は現在まで通信Downは起きていません。
> ※通信DownはノードアイのHeartbeatによる切断通知を通信Downと記載しております。

この程度の通信断であれば、通常起こりえる範囲かと思われます。

> ①に関して、
> デバッグモード有効化スクリプト(Debug_Mode_On.sh)を実行し、有効化にならない原因をご教示頂けないでしょうか？

vi で編集し reboot コマンドで Armadillo の再起動をした際には正常に動作することを確認出来ております。

記されたように sed で編集した場合は、同様にデバッグモードでは動作致しませんでした。
その後、 vi で
/etc/systemd/system/multi-user.target.wants/ModemManager.service
の内容も編集し reboot するとデバッグモードで動作しております。

古関です。

申し訳ありません。

node-eye経由でArmadillo-IoT G3L内の任意のファイルを編集/ファイルの中身を確認する機能は標準ではありません。
特に、/etc/ 配下のファイルの編集はセキュリティホールやシステム停止につながりうるため
標準対応していない状況です。

現地に設置してしまった個体のデバッグログに関しては、一度回収して確認する必要があります。

node-eyeを使ってリモートで上記の対応を行う場合、
カスタムのモジュールを作成、設置前に仕込んでおく必要があります。
https://manual.atmark-techno.com/node-eye/device-management_aiotg3l_ja-…