mkohei1122
2015年7月21日 13時58分
森と申します。
いつも、いろいろ拝見させていただきお世話になっております。
さて、当方では、Armadillo-IoTで不定期に取得されるデータを、3G(ドコモのMVNO)を使用し、
サーバーに定期的に転送するシステムを検討しております。使用ハードは、旧型モデルIOT、
カーネルは、v2.6.26-at25です。状況次第、順次、新カーネルは3.14-at、新モデルの置き換え
を考えております。
ところが、現状、ドコモのメンテナンス等の要因で、3G通信できないことございまして、
暫定的な対策をしておりますが、アドバイスをいただけたら幸いです。なお、ifplugdの監視は、
START_IFPLUGD=yとして、使用しております。
3G通信できないことは、いくつかの要因がございますが、下記が考えられると思っております。
通信不具合要因
(1)Armadillo-IoT起因
(a)ifplugd等が落ちる
(2)オリジナルの開発ソフト起因
(a)データ取得ソフトの不具合
(b)データ転送ソフトの不具合
⇒開発ソフトの問題（監視する等で対処。機会があれば別途議論させてください。）
(3)3Gモジュール起因
(a)3Gモジュールがハングアップ
(b)通信が切断され、ipが取れない。DNSが解決できない
(4)ドコモ要因
(a)圏外、障害
(b)パケット通信等が定期メンテナンス
⇒ドコモは、不定期で頻繁にメンテナンスしているようです。
https://www.nttdocomo.co.jp/info/construction/
例として、音声およびパケット通信が下記の時間帯で利用できないですようです。
7月23日(木曜) 午前1時～午前6時のうち 分～10分 全域
7月28日(火曜) 午前1時～午前5時のうち 5分程度 全域
(c)IP変更等
常時接続していると12時間に一回もしくは24時間に一回程度、一時切断され、
IPが変わる場合がある。
⇒サービス規定にありませんが、どの通信会社も、公平な利用のために、
一定期間通信で切断されるようです。
(5）MNVOプロバイダ要因
(a)障害
(b)定期メンテナンス
(6)転送サーバー要因
(a)障害
(b)定期メンテナンス
それぞれに対して、対策が必要と思われますが、最近起きた頻発する通信不具合として、
上記の、ドコモ要因（4)(b)または、MNVOプロバイダ要因(5)(a)(b)が発生し、それぞれの
外部要因が解消しても、通信できない、復活しない場合がございました。不具合発生後
ifdown usb0としても、usb0がlinkされていないと怒られましたので、可能性として、3G
モジュールに起因（(3)(a)または(b)）と考えております。
ifup usb0で再接続すると解消するので、cronでpingやcrulの外部応答を定期的に確認して、
落ちていたら、ifup usb0で再接続するといった対策をとっておりますが、この対策で
いいのか悩んでおります。
皆さまのアドバイスいただけたら幸いです。
なお、先月にも3G通信周りについてのトピックがありましたが、現時点で、
ご返答がないようです。
3Gモジュール切断について
https://armadillo.atmark-techno.com/forum/armadillo/1462
以上、よろしくお願いいたします。
コメント
at_kojiro.yamada
反応が遅くなってしまい申し訳ありません。
> > 上記の、ドコモ要因（4)(b)または、MNVOプロバイダ要因(5)(a)(b)が発生し、それぞれの
> > 外部要因が解消しても、通信できない、復活しない場合がございました。
上記の現象ですが、ifplugdによる再接続に失敗しているのだと思います。
再接続の処理は、/etc/ifplugd/ifplugd.actionに書かれています。
ifplugdは、interfaceの状態が変わった時に上記スクリプトを呼ぶのですが、
このスクリプトは、downになった時にifupを1度しか実行しません。
再接続が失敗すると、interfaceの状態が変化しないため、
interfaceがupして再度downするまで、再接続は行われません。
従って、
> ドコモ要因（4)(b)または、MNVOプロバイダ要因(5)(a)(b)が発生
のような場合、再接続に失敗して、
interface(usb0※)がdownしたままになってしまうことがあります。
※最新のatmark-distではumts0
> ・cronで、定期的に、inet addrが取れているかを監視
> ifconfig umts0 | grep "inet addr:"を実行し、IPがもらえて
> いなければ、ifup umts0 で3G再接続
ifplugdは、コマンドライン上で渡されたシェルスクリプトを実行することができるの
で、そのシェルスクリプト内に、
成功するまでifup usb0を一定間隔で繰り返す処理を書く
という方法もあります。
以下に手順を記載しますので、参考にしていただければと思います。
1. シェルスクリプト(/etc/config/ifup_loop.sh)を作成する
#!/bin/sh
IF=$1
ACTION=$2
case $ACTION in
down)
ifdown $IF
while [ 1 ]
do
ifup $IF
RET=$?
if [ $RET -eq 0 ]; then
exit 0
fi
sleep 2
done
;;
up)
ifup $IF
exit 0
;;
esac2. シェルスクリプトに実行権限を付与する
[Armadillo]# chmod +x /etc/config/ifup_loop.sh
3. /etc/config/interfacesを修正する
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
auto lo eth0
iface lo inet loopback
iface eth0 inet dhcp
iface umts0 inet dhcp
pre-up 3g-connect
post-up ifplugd -i umts0 -p -q -r /etc/config/ifup_loop.sh
pre-down ifplugd -i umts0 -k
post-down 3g-disconnect4. 変更を保存する
[Armadillo]# flatfsd -s
mkohei1122
森です。
返答ありがとうございました。
ご提示いただきましたスクリプトifup_loop.shを最新カーネルat3にて試させて
いただきました。下記のように行い3Gの再接続は確認できましたが、
再接続後、udhcpcプロセスがループしてしまっているようです。
(1) 3G接続
(2) 3G切断ー＞アンテナ取り外し（疑似的にDOCOMO、プロバイダダウン）
(3) ”sierra_net 2-1:1.7 umts0: No coverage, 0x00”のメッセージがくるまで待つ
”sierra_net 2-1:1.7 umts0: No coverage, 0x01”？
(4) アンテナ再接続 （疑似的にDOCOMO、プロバイダ回復）
(5) 3G再接続
→ root 0:00 udhcpc -R -n -t 8 -T 4 -p /var/run/udhcpc.umts0.pid -i um
がループしてしまう。
なお、スクリプトを拝見しますと2秒後とにループしておりますが、
3Gの不通期間が長くなった場合は、3Gモジュールが発熱するとうの
弊害はないのでしょうか。
以上です。
at_kojiro.yamada
> 再接続後、udhcpcプロセスがループしてしまっているようです。
ループ、とはどのような状況でしょうか？
ifupが成功すれば、psコマンドで
"udhcpc -R -n -t 8 -T 4 -p /var/run/udhcpc.umts0.pid -i um"
を確認できますが、このプロセスが複数存在するという意味でしょうか？
> なお、スクリプトを拝見しますと2秒後とにループしておりますが、
> 3Gの不通期間が長くなった場合は、3Gモジュールが発熱するとうの
> 弊害はないのでしょうか。
発熱はしますが、常温25℃での使用であれば問題ありません。
sleep時間が2秒というのは、今回の結果をすぐに確認するために設定した値です。
説明足らずで申し訳ありませんでした。
sleep時間は、5分などもっと長い間隔でも良いかと思います。
at_kojiro.yamada
反応が遅くなってしまい申し訳ありません。
> 再接続前後のコマンドの出力を添付いたします。
> プロセスが複数存在し、発生し続けてしまうようです。
psコマンドの結果を見ると
ifup_loop.shにより、ifup umts0が繰り返し実行され、全て失敗しているが、
起動されたumts0のudhcpcがそのまま残っている
ように見えます。
一旦、ifplugdを起動しないようにし、アンテナを外して圏外にした後で
以下のコマンドを実行してログをフォーラムに添付していただけないでしょうか？
[Armadillo]# ls /var/run/ [Armadillo]# cat /var/run/ifstate [Armadillo]# cat /var/run/udhcpc.umts0.pid [Armadillo]# ps [Armadillo]# ifdown umts0 [Armadillo]# echo $? [Armadillo]# ls /var/run/ [Armadillo]# cat /var/run/ifstate [Armadillo]# cat /var/run/udhcpc.umts0.pid [Armadillo]# ps [Armadillo]# ifup umts0 [Armadillo]# echo $? [Armadillo]# ls /var/run/ [Armadillo]# cat /var/run/ifstate [Armadillo]# cat /var/run/udhcpc.umts0.pid [Armadillo]# ps [Armadillo]# ifup umts0 [Armadillo]# echo $? [Armadillo]# ls /var/run/ [Armadillo]# cat /var/run/ifstate [Armadillo]# cat /var/run/udhcpc.umts0.pid [Armadillo]# ps
> なお、追加で失礼いたしますが、3Gが切断された場合の
> sierra_net 2-1:1.7 umts0: No coverage, 0x00
> sierra_net 2-1:1.7 umts0: No coverage, 0x01
> のエラー出力ですが、どんな意味になりますでしょうか。
パケット通信における圏外を意味します。
メッセージを出力しているのは
drivers/net/usb/sierra_net.c::sierra_net_parse_lsi()
です。
static int sierra_net_parse_lsi(struct usbnet *dev, char *data, int datalen)
{
struct sierra_net_data *priv = sierra_net_get_private(dev);
lsi_umts_t *lsi = (lsi_umts_t*)data;
:(省略)
/* Validate the coverage */
if (lsi->coverage == SIERRA_NET_COVERAGE_NONE
|| lsi->coverage == SIERRA_NET_COVERAGE_NOPACKET) {
deverr(dev, "No coverage, 0x%02x", lsi->coverage);
return 0;
}
:(省略)
}lsi->coverageに入る値の意味は
AirPrime UMTS MC Series CnS Referenceに記載されています。
0x00 No coverage
0x01 Circuit-switched available
(no packet-switched coverage)
■参考
AirPrime UMTS MC Series CnS Reference
http://source.sierrawireless.com/resources/airprime/minicard/2130602_ai…
mkohei1122
森です。
ご返答ありがとうございます。
下記の構成で、画面出力、ログメッセージをとりましたので、
ご確認いただければ幸いです。
＜構成＞
・ハード
・旧 Armadillo-IoT AG401-D00Z
3Gモジュール F/W Revision: P1_0_0_26AP R3750 CNSHZ-ED-XP0031 2014/12/12 17:29:37
プロバイダ：OCN モバイル ONE for Business（グローバルIP）
・新 Armadillo-IoT AG421-D00Z
3Gモジュール F/W Revision: RHL85xx.5.5.16.0.201505261641.x6250_2
プロバイダ：DTI ServersMan SIM LTE（プライベートIP）
・カーネル：linux-aiotg-std-v2.02.bin.gz
・ユーザーランド：romfs-aiotg-std-v2.03.img.gz
→アットマークテクノ様のサイトよりイメージをダウンロードして使用
・スクリプト
→”ifup_loop.sh”、”interfaces”を添付いたします。
＜確認実験＞
・再現性
・Interfaceにifup_loop.shを追加したところ、
旧IoTと新IoTの両方で、それぞれ挙動が違うところもございますが、
udhcpcの繰り返しが確認されました。アンテナの圏内/圏外、
再接続の成功/失敗に関わらず、再接続の動作で、udhcpcの繰り返し
されるようです。
・Interfaceの"auto"に"umts0"を追加するかどうかによっても挙動が
違うようですので、旧IOTのみそれぞれのログを添付いたします。
・旧IOT(auto lo eth0)
・旧IOT(auto lo eth0)_画面.txt
・旧IOT(auto lo eth0).log
→旧IOTで、interfaceのautoにumts0を付けない場合。
起動直後に、アンテナを外し、しばらくの時間ののち
再度アンテナを結線しております。
・旧IOT(auto lo eth0 umts0)
・旧IOT(auto lo eth0 umts0)_画面.txt
・旧IOT(auto lo eth0 umts0).log
→旧IOTで、interfaceのautoにumts0を付けた場合。
起動直後に、アンテナを外し、No coverageのメッセージがでて
ある程度時間がたってから、再度アンテナを結線しております。
最終的に、再接続できていません。
・旧IOT(auto lo eth0 umts0)
・旧IOT(auto lo eth0 umts0)_画面_2.txt
・旧IOT(auto lo eth0 umts0)_2.log
→旧IOT上記の別パターン。最終的に、再接続できて
いません。
・新IOT(auto lo eth0 umts0)
・新IOT(auto lo eth0 umts0).log
・新IOT(auto lo eth0 umts0)_画面.txt
→起動直後に、アンテナを外し、ある程度時間がたってから、
再度アンテナを結線しております。最終的に、再接続できて
いません。
不足な点がございましたらご指摘ください。
常時接続を前提としないケース場合は、自動再接続にたよらずに、アプリ自身が３G通信のたびに、
接続ON/OFFを繰り返した方が安全でしょうか。
以上、よろしくお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| log.zip |
at_kojiro.yamada
反応が遅くなってしまい申し訳ありません。
■udhcpcのプロセスが複数起動されてしまう問題について
ご不便おかけして大変申し訳ございません。
調査の結果、
ifplugdから実行されるスクリプト内部で直接ifdown,ifupを実行していること
が原因とわかりました。
問題発生時、以下のような現象が起きているようです。
1) 3G接続が切断される
2) ifplugdが、スクリプト(ifup_loop.sh)を実行する
3) スクリプトが、ifdownを実行する
4) スクリプトが、ifupを実行する
5) ifupが、pre-upに登録されたコマンドを実行する
6) ifupが、umts0をupする
- このとき、udhcpcのプロセスが1つ起動する
7) ifupが、post-upに登録されたコマンドを実行する(ifplugdを起動する)
8) umts0のifplugdが既に存在するため、ifplugdの起動は失敗する
9) post-upに登録されたコマンドが失敗したので、ifupはステートファイル
(/var/run/ifstate)を更新しない
- このとき、umts0がupしたままになり、ifup umts0を再度実行できる状
態になる
10) ifupが失敗する
11) スクリプトが、ifupを再度実行する
- 以降、5) ~ 10)を繰り返す
現在、上記現象の対策を検討中ですが、
暫定対策を記載いたしますのでお試しください。
ただし、アップデートで実施される対策とは異なる可能性があります。
■udhcpcのプロセスが複数起動されてしまう問題の対策(暫定)
暫定の対策方法を導入するスクリプト(create_files.sh)を添付いたします。
create_files.sh により
/etc/config/3g-monitor
/etc/config/ifplugd.action
/etc/config/3g-ifreup
が作成され、
/etc/config/interfaces
が書き換えられます。
書き換え前の/etc/config/interfacesは
/etc/config/interfaces.back
に上書きされます。
以下に導入の手順を記載します。
Armadilloを再起動した後、udhcpcのプロセスが複数起動されることがないか確
認してみてください。
1. create_files.shをArmadillo上に配置し実行、コンフィグ領域を保存する
[Armadillo]# sh create_files.sh [Armadillo]# flatfsd -s
2. Armadilloを再起動
[Armadillo]# reboot
> 常時接続を前提としないケース場合は、自動再接続にたよらずに、アプリ自身が３G通信のたびに、
> 接続ON/OFFを繰り返した方が安全でしょうか。
はい。
ifplugdで行っている自動再接続は、基地局との接続ができるだけですので、
実際に基地局の先にあるサーバーと通信ができるかどうかはわかりません。
結局のところ、サーバーからのレスポンスが返ってこない場合は
アプリ側で再接続(ifdown, ifup)を行ってしまう方がベターかと思います。
| ファイル | ファイルの説明 |
|---|---|
| create_files.sh | udhcpcのプロセスが複数起動されてしまう問題の暫定対策導入スクリプト |
y.nakamura
中村です。
この案件に少しかかわっていますので、コメントさせていただきます。
> 問題発生時、以下のような現象が起きているようです。
で説明されている1～11は追っていませんが...
> > 常時接続を前提としないケース場合は、自動再接続にたよらずに、アプリ自身が３G通信のたびに、
> > 接続ON/OFFを繰り返した方が安全でしょうか。
>
> はい。
常時接続での異常切断時の再接続に問題があるときき、
これを提案していました。
（それを確認するために、この質問になったものと思います）
このこととは別に、常時接続で
> 結局のところ、サーバーからのレスポンスが返ってこない場合は
> アプリ側で再接続(ifdown, ifup)を行ってしまう方がベターかと思います。
とするならば（何をもって異常と判断するか？という課題がありますが、
それはおいておいて・・・)、ifplugdは使わない方がいいですね。
で、必要なときだけ接続する話に戻って・・・
必要なときにだけ接続する方法の場合もifplugdは使わないので、
/ettc/config/interfasesの
post-up 3g-monitor start
pre-down 3g-monitor stop
は削除。
--
なかむら
mkohei1122
y.nakamura
中村です。
> ただ、切断すると毎回下記のメッセージがでますが、
> sierra_net 2-1:1.7 umts0: Link type unsupported: 0xff
> sierra_net 2-1:1.7 umts0: Invalid LSI
このメッセージは、カーネルソースdrivers/net/usb/sierra_net.cの
377行目あたり
/* Validate the link type */
if (lsi->link_type != SIERRA_NET_AS_LINK_TYPE_IPv4) {
netdev_err(dev->net, "Link type unsupported: 0x%02x\n",
lsi->link_type);
return -1;
}409行目あたり
if (link_up < 0) {
netdev_err(dev->net, "Invalid LSI\n");
return;
}で出しています。
netdev_errの部分をコメントにしてしまえば完全に消えます。
あるいは、netdev_xxxはマクロでprintkに置き換えられますので、
ログレベル(_errの部分)を変更すれば
コンソールには出なくなるかもしれません。
Armadilloの場合、どのレベルでコンソールに出なくなるのか
私は知りません。
一般的なLinuxの話としては、このあたりに説明がありあます。
http://www.itmedia.co.jp/enterprise/articles/0512/15/news008.html
この手のコンソールメッセージに対する私の考えですが、
どこかに設置した無人運転のときには、非常時のメンテナンス（
よほどどうしようもなくなったとき）以外はコンソールからログインして
使うことはないので、放置してます。
ちなみに、ネットワークのこのエラーの他に、コンソールに出るものとして、
たしか、ext3のSDカードmount/umount時に出ていたような気がします。
（出先なので、今、実機で確認できません）
--
なかむら
mkohei1122
at_ohsawa
障害の原因が、3G回線でIPレイヤが疎通している状態で、NW上のDHCPサーバー
のレスポンスが悪く、4秒間隔で8回リース要求を出してもIPアドレスがリース
されない。という場合には効果があります。
一つ前の Atmark Dst v20150918 のデフォルトの設定
(vendors/AtmarkTechno/Armadillo-IoTG-Std/config.busybox-1.20.2)では
タイムアウト4秒、リトライ8回( Atmark Dst v20150918以前は 3秒、3回)で
DHCPサーバーが応答しない場合、DHCPサーバーが存在しないものとして、
リンクローカルアドレス(169.254.0.0/16)を振っていましたが、これをバック
グランドで継続してリース要求するように変更しました。
mkohei1122
2015年8月6日 19時17分
森と申します。
自己レスいたしますと、3Gの再接続に関して、カーネル3.14でも
下記のような状況となっておりますが、正常なのでしょうか。
・ハード：旧 Armadillo-IoT AG401
・カーネル：v3.14-at2
イメージ：linux-aiotg-std-v2.01.bin.gz
・ユーザーランド：v20150727
イメージ：romfs-aiotg-std-v2.01.img.gz
⇒各イメージは、Atmarkのサポートページからダウンロード
・ネットワーク
・3G以外は未接続
・起動時に、3Gを自動接続するように、/etc/config/interfacesを編集
auto lo eth0 umts0
・状況
（1）ブート
（2）3Gの接続を確認
ifconfig umts0で、inet addr:を確認（IPがもらえている）
（3）3Gの外部アンテナのあえて外して、疑似的に3G圏外
(4) しばらくして、下記のメッセージ
・sierra_net 2-1:1.7 umts0: No coverage, 0x00
・sierra_net 2-1:1.7 umts0: No coverage, 0x01
(5)再び3Gの外部アンテナを接続
⇒時間が経過しても、3Gの再接続は行われない
ifconfig umts0で、確認しても、inet addr:が確認できない。
ここで対策として、下記のように3Gの再接続を行っておりますが、
問題点があれば、ご指摘、アドバイスいただければ幸いです。
・cronで、定期的に、inet addrが取れているかを監視
ifconfig umts0 | grep "inet addr:"を実行し、IPがもらえて
いなければ、ifup umts0 で3G再接続
・課題として、crondがそのものが落ちてしまった場合はどうするか
以上、よろしくお願いいたします。