Armadilloフォーラム

Armadillo-IoT G3L のSIM電波が不安定

ayatsugu

2020年4月20日 13時55分

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

現在、複数台のArmadillo-IoT G3Lを利用しており、全く同じ場所に、ほぼ隣同士という状態で
2台設置しています。
同一キャリアのSIMカードで通信をさせているのですが、
1台 → まったく安定している
1台 → 1日に数回、SIM通信断→再疎通をすることがある(直近では、4/17~18で8回発生)
という状況となっています。

このような状況が発生していることから、1台のArmadillo-IoT G3Lが故障等が発生している可能性を
考えておりますが、どなたかこの辺りに知見のある方で故障によってこのような状況が起こる、
故障以外にこのような可能性が考えられるなどの情報があればたすかります。

故障の疑いがやはり強い、ということであれば交換等の対応ヲ進めたいと考えています。

もし、追加の情報など必用であれば取得します。


コメント

at_mitsuhiro.yoshida

2020年4月21日 10時39分

吉田です。

お手数おかけします。

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
の結果をお願いします。

ayatsugu

2020年4月21日 13時32分

吉田様

御連絡ありがとうございます。

すでに現地設置しているためSIMの交換や切断時のmmcliの結果は取得が難しいですが、
他の情報についてとれる範囲で取得してみます。
取得しましたらご連絡させてください。

何卒宜しくお願い致します。

k_nishida

2020年4月24日 10時55分

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

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

1に関して、
ご案内にありました /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で再起動しています。

2に関して、
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

k_nishida

2020年4月24日 17時38分

いきなりの投稿で説明が足りず、申し訳ございません。ユーザー:ayatsugu と同じチームの者です。 

at_mitsuhiro.yoshida

2020年4月24日 18時10分

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

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

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

コマンドが打てるのであれば、以下で確認が出来ます。
# 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 からダウンロードできるのであれば、
このフォーラムに添付頂ければ確認致します。

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

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

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

k_nishida

2020年4月30日 15時36分

1.デバックモードON
デバッグログ有効化への設定を検証環境で行っていましたが、
本番環境でゲートウェイを再起動させた場合に顧客データ損失のリスクがあるために、デバックモードへの変更は難しいです。

2.mmcli -m 0
通信出来ている時の結果
/org/freedesktop/ModemManager1/Modem/0 (device id '1c413defcc6aae4933eb515f066b4ddddc6158c2')
-------------------------
Hardware | manufacturer: 'Cinterion'
| model: 'ELS31-J'
| revision: 'REVISION 4.3.2.1b'
| supported: 'gsm-umts'
| current: 'gsm-umts'
| equipment id: '356778070426201'
-------------------------
System | device: '/sys/devices/soc0/soc/30800000.aips-bus/30b20000.usb/ci_hdrc.1/usb2/2-1'
| drivers: 'cdc_acm, cdc_ether'
| plugin: 'Cinterion ELS'
| primary port: 'ttyACM0'
| ports: 'ttyACM0 (at), usb1 (net)'
-------------------------
Numbers | own : '****'
-------------------------
Status | lock: 'none'
| unlock retries: 'unknown'
| state: 'connected'
| power state: 'on'
| access tech: 'lte'
| signal quality: '70' (recent)
-------------------------
Modes | supported: 'allowed: 2g; preferred: none'
| current: 'allowed: 2g; preferred: none'
-------------------------
Bands | supported: 'unknown'
| current: 'unknown'
-------------------------
IP | supported: 'ipv4, ipv6, ipv4v6'
-------------------------
3GPP | imei: '****'
| enabled locks: 'none'
| operator id: '44010'
| operator name: 'IIJ'
| subscription: 'unknown'
| registration: 'home'
-------------------------
SIM | path: '/org/freedesktop/ModemManager1/SIM/0'

-------------------------
Bearers | paths: '/org/freedesktop/ModemManager1/Bearer/0'

3.LTEバージョン情報取得結果

spawn env LANG=C cu -l /dev/ttymxc6 -s 115200
@Connected.
@5@55E@IQ5
ATI1

Cinterion
ELS31-J
REVISION 4.3.2.1b
A-REVISION 4.3.3.0-36584
L-REVISION 3.7.6

OK

>近い位置に配置した2台の Armadillo-IoT ゲートウェイ G3L のうち、
>1台だけが接続・切断を繰り返しているとのことですが、
>設置当初からその G3L は接続・切断を繰り返していましたでしょうか?
設置直後から起きていました。
3/30にゲートウェイを設置し、通信down,upが起きた期間は現在までに

3/30~4/2
4/5~4/7
4/9~4/12
4/17,18

以上の日付で起きています。

at_mitsuhiro.yoshida

2020年5月1日 14時46分

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

> 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
などを参考に今後の対応をご検討ください。

よろしくお願いします。

k_nishida

2020年5月15日 12時23分

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

①デバッグモード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と記載しております。

at_mitsuhiro.yoshida

2020年5月15日 17時30分

吉田です。

> ②に関して
> 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 するとデバッグモードで動作しております。

k_nishida

2020年5月18日 10時27分

現在、ゲートウェイが顧客の現場にあり、node-eye経由でしか操作できない状況です。
viでの編集は、node-eye経由では出来ないと思うのですが、
/etc/systemd/system/multi-user.target.wants/ModemManager.service
をnode-eye経由で編集して、デバッグモードを有効化に出来る方法があれば、ご教示頂けないでしょうか?

k_nishida

2020年6月2日 9時13分

node-eye経由でのデバッグモード有効化に関して、その後の進展などはございますでしょうか?

at_koseki

2020年6月2日 10時40分

古関です。

申し訳ありません。

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

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

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