y.nakamura
2015年12月24日 13時11分
中村です。
Armadillo-IoT(G2)で3Gの接続・切断を頻繁に行うと、
何時間か経過後に3Gでの通信ができなくなってしまいます。
どなたか、原因or解決方法をご存じではないでしょうか？
次のようなスクリプトで１分弱でループさせてテストをしています。
下のスクリプトの場合、接続にかかる時間にも依存しますが、
約５０秒で１回まわります。
実際の運用では１分ということはなく１０分とか３０分とかになりますが、
試験として短時間での接続・切断を繰り返しました。
試験用のスクリプト
#!/bin/sh ( while : do echo "======= ifup ======" ifup umts0 echo "======= ifup result = $? ======" ifconfig umts0 sleep 10 echo "======= ifdown ======" ifdown umts0 echo "======= ifdown result = $? ======" ifconfig umts0 sleep 30 done ) 2>&1 | logger -t 3g-test
syslogは、
syslogd -L -R 192.168.0.12
のようにして別のLinuxマシンに転送してます。
頻繁に接続と切断を繰り返しますので、次のようにして
ifplugdが起動しないようにしてあります。
auto lo eth0
iface lo inet loopback
iface eth0 inet dhcp
iface umts0 inet dhcp
pre-up 3g-connect
# post-up 3g-monitor start <--- ここ
# pre-down 3g-monitor stop <--- ここ
post-down 3g-disconnectテストした機体は何台かあり、どれでも同じ症状です。
そのうち１台は数日前に納品されたもので、
カーネルやユーザランドは何もいじっていません。
（変更箇所は、上に書いた/etc/config/interfacesだけ）
使用したSIMは、
- OCNのモバイルONE
- 旧DTI ServersMan SIM LTEC
で、どちらでも症状は同じです。
ちなみに、旧型のArmadillo-IoTでは、
何ヶ月かの稼働実績がありますが、
このような症状は発生していません。
以下、少し長くなりますが、症状を書いておきます。
正常時のifupの表示：
# ifup umts0 check APN/username/password success 3G connect udhcpc (v1.20.2) started Sending discover... Sending discover... Sending select for 100.71.158.207... Lease of 100.71.158.207 obtained, lease time 172800
正常時のifconfigの表示：
# ifconfig umts0
umts0 Link encap:Ethernet HWaddr 00:00:11:12:13:14
inet addr:100.71.158.207 Bcast:100.71.158.255 Mask:255.255.255.0
inet6 addr: fe80::200:11ff:fe12:1314/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1180 (1.1 KiB) TX bytes:12470 (12.1 KiB)ifupで接続できなくなったときのifup
# ifup umts0 check APN/username/password success 3G connect udhcpc (v1.20.2) started Sending discover... Sending discover... Sending discover... Sending discover... Sending discover... Sending discover... Sending discover... Sending discover... No lease, failing
一度この状態になると、復活しません。
ifupで接続できなくなったときのifconfig(引数無し)
# ifconfig(引数無し)
eth0 Link encap:Ethernet HWaddr 00:11:0C:18:27:55
inet addr:192.168.0.69 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::211:cff:fe18:2755/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7803 errors:0 dropped:61 overruns:0 frame:0
TX packets:7737 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1106566 (1.0 MiB) TX bytes:812762 (793.7 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:28 errors:0 dropped:0 overruns:0 frame:0
TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2108 (2.0 KiB) TX bytes:2108 (2.0 KiB)
umts0 Link encap:Ethernet HWaddr 00:00:11:12:13:14
inet6 addr: fe80::200:11ff:fe12:1314/64 Scope:Link <=== ★ここにIPv4がない
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1081 errors:0 dropped:0 overruns:0 frame:0
TX packets:10921 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:323824 (316.2 KiB) TX bytes:3113326 (2.9 MiB)このように、umts0にIPv4アドレスがありません。
この状態になったとき、ifdown umts0 も失敗します。
# ifdown umts0 ifdown: interface umts0 not configured
で、次のようにifconfigで落とすと・・・
この後のifconfig(引数無し)ではumts0は出てきません。
# ifconfig umts0 down
# ifconfig(引数無し)
eth0 Link encap:Ethernet HWaddr 00:11:0C:18:27:55
inet addr:192.168.0.69 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::211:cff:fe18:2755/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7944 errors:0 dropped:61 overruns:0 frame:0
TX packets:7737 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1128726 (1.0 MiB) TX bytes:812762 (793.7 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:28 errors:0 dropped:0 overruns:0 frame:0
TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2108 (2.0 KiB) TX bytes:2108 (2.0 KiB)引数でumts0を指定すると・・・
# ifconfig umts0
umts0 Link encap:Ethernet HWaddr 00:00:11:12:13:14
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:1081 errors:0 dropped:0 overruns:0 frame:0
TX packets:10953 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:323824 (316.2 KiB) TX bytes:3122303 (2.9 MiB)この状態でもう一度ifupしてみると・・・やっぱり失敗します。
tipコマンドでモデムにアクセスすると、問題はなさそうです。
# tip -l /dev/ttyATCMD -s 115200 Connected. at OK ati3 RHL85xx.5.5.16.0.201505261641.x6250_2 OK AT$CSQ $CSQ: 20,99,-5 OK
rebootで再起動すれば、復活できます。
（電源のOFF/ONは必要なし）
--
なかむら
コメント
y.nakamura
y.nakamura
中村です。
> > 昨晩から約１０分間隔で接続・切断を２４時間やってみました。
> > ifdownのあとのsleepを600秒です。
...
> そのまま動かし続けたところ、先ほど障害が発生しました。
> ４６時間です。
>
> この後、半分の５分でやってみます。
５分の場合、約24時間で障害が発生しました。
再起動からifupの実行回数をカウントしてみたところ、
269回目でNGです。
２分もやってみました。ifdownの後、sleep 100です。
約９時間でNG、回数は５分間隔の時と同じ269回目。
もう一度１分間隔のときのの回数を数えてみました。
これも269回目です。
ドライバか3Gモジュールのファームウェアに
何かありそうです。
この後30分間隔をやってみます。
もしこれも269回目でNGになるならば、
６日間くらいかかりますので報告は年明け３日頃です。
--
なかむら
at_koseki
中村様
古関です。
調査・再現試験、真にありがとうございます。
弊社でも症状を確認できました。
今のところ、3Gモジュール HL8548（ファームウェア）側の問題と見ています。
具体的には、ネットワーク接続するATコマンド "AT+XCEDATA" が
まともに動作できなくなっているようです。
（なぜ必ず269回目なのか、というのが良くわかっていませんが。。）
3Gモジュールメーカーと確認・解析を進め、
不具合ならばファームウェアのリリース、ワークアラウンドなりを出そうと考えています。
大変申し訳ありませんが、根本的な対策を行うまでは時間がかかりそうです。
進展ありましたら、報告させていただきます。
現在できる暫定的な対応としては、
この状態になった場合、3Gモジュールをリセットし、
3g-set-ap と ifupをやり直すしか見えていません。
（リセット後、接続できるところまでは確認しています。）
3Gモジュールのリセットの方法は２通りあります。
(1) ATコマンドでリセットする方法
ATコマンド "AT+CPOF" を実行する
(2) sysfsを利用して、3Gモジュールのリセット信号をアサートする方法
(※本来は3Gモジュールが固まり、ATコマンドすら実行できなくなった場合を想定した方法）
以下のようにコマンドを実行し、3Gモジュールをリセットする。
[armadillo ~]# echo 1 > /sys/class/gpio/RESET_N_3G/value
※100msec程度待つ
[armadillo ~]# echo 0 > /sys/class/gpio/RESET_N_3G/value
大変ご迷惑をおかけし、申し訳ありませんが、
よろしくお願いします。
y.nakamura
中村です。
古関さん、
再現調査、どうもありがとうございます。
回避方法だけでも年越しせずに済みそうです。
> 3Gモジュールメーカーと確認・解析を進め、
時間がかかりそうですね。
> 3g-set-ap と ifupをやり直すしか見えていません。
...
> (1) ATコマンドでリセットする方法
> ATコマンド "AT+CPOF" を実行する
ATコマンドが生きていることと、269回というのは
確実そうですので、当面は回数を数えて、
ある程度の回数(256とか)になったら、
このATコマンドでリセットする方法で回避と
しようと思います。
> 以下のようにコマンドを実行し、3Gモジュールをリセットする。
>
> [armadillo ~]# echo 1 > /sys/class/gpio/RESET_N_3G/value
> ※100msec程度待つ
> [armadillo ~]# echo 0 > /sys/class/gpio/RESET_N_3G/value
たぶんこちらは使わずに済むと思うのですが、
GPIOを使ったリセットのHighとLowはこれであってますか？
"RESET_N_3G"と"N"がついているので。
--
なかむら
y.nakamura
中村です。
みなさま、
あけましておめでとうございます。
今年もよろしくお願いいたします。
昨年暮れの
> この後30分間隔をやってみます。
> もしこれも269回目でNGになるならば、
> ６日間くらいかかりますので報告は年明け３日頃です。
昨日テストが終わりましたので、結果を報告しておきます。
予想通り、269回目でつながらなくなりました。
それから、古関さんのリカバリ方法に対して質問した
> GPIOを使ったリセットのHighとLowはこれであってますか？
> "RESET_N_3G"と"N"がついているので。
を試してみました。（６日間の試験が終わったので）
"1"を出力でリセットになりました。
--
なかむら
at_koseki
古関です。
> 3Gモジュールメーカーと確認・解析を進め、
> 不具合ならばファームウェアのリリース、ワークアラウンドなりを出そうと考えています。
> 大変申し訳ありませんが、根本的な対策を行うまでは時間がかかりそうです。
> 進展ありましたら、報告させていただきます。
状況報告です。
Armadillo-IoT以外の環境（WindowsPC）で同じ問題を再現できました。
ドライバー側の問題は薄そうです。
3Gモジュール HL8548のファームウェア不具合の方向でメーカー(Sierra社)解析中です。
ご迷惑おかけしますが、
今暫くお待ちいただけますようお願い申し上げます。
よろしくお願いします。
y.nakamura
at_koseki
古関です。
状況報告です。
3Gモジュール: HL8548のファームバグが原因であることが確定し、
修正版 テストファーム[※]がモジュールメーカー(Sierra社)からリリースされました。
[※] docomo IOTが未取得なテスト用ファームであり、弊社からお客さまへの再配布は出来ません。
テストファームで不具合が起こらないことは弊社で確認済みです。
この不具合修正が入った、再配布可能な、docomo IOT取得ファームのリリース日程はまだ未定ですが、
Sierra社 -> 弊社のリリースは最短でも2016/4となっております。
弊社で再度試験した後、変更通知とともに、ユーザーズサイトにアップロードする予定です。
詳しい日程が見えましたら、再度報告させていただきます。
よろしくお願いします。
y.nakamura
y.nakamura
at_koseki
中村様
古関です。
> > この不具合修正が入った、再配布可能な、docomo IOT取得ファームのリリース日程はまだ未定ですが、
> > Sierra社 -> 弊社のリリースは最短でも2016/4となっております。
>
> そろそろかなぁ？と思っているのですが、
> 状況はどうでしょうか？
> 「最短でも・・・」なので、もっと時間がかかる
> こともあるかとは思いますが。
申し訳ありません。
Sierra社側の都合によりリリースが遅れています。
詳しい日程が分かり次第、報告させていただきます。
ご迷惑をおかけしますが、よろしくお願いします。
y.nakamura
ma2013
at_koseki
古関です。
大変お待たせしました。
本不具合の修正ファームがSierra社よりリリースされました。
詳細は以下の変更通知を参照して下さい。
https://users.atmark-techno.com/change_notification/2016-010
よろしくお願いします。
y.nakamura
at_koseki
y.nakamura
y.nakamura
2015年12月25日 21時47分
中村です。
> 実際の運用では１分ということはなく１０分とか３０分とかになりますが、
> 試験として短時間での接続・切断を繰り返しました。
昨晩から約１０分間隔で接続・切断を２４時間やってみました。
ifdownのあとのsleepを600秒です。
今のところ、１０分間隔の場合は問題は発生してません。
--
なかむら