eiko-murata
2016年2月29日 19時59分
お世話になります。村田と申します。
運用中のIoT端末にて3G通信途絶が頻繁に発生しています。
最初に発生した際に、症状を確認した際に、
https://armadillo.atmark-techno.com/forum/armadillo/1783
↑の症状とほぼ同様の状況になっていたようなので、こちらを参考に、以下のような判断をして、3Gのリセットを行っています。
umts_live=`ifconfig umts0 | grep "inet addr"`
if [ "$umts_live" = "" ]
then
logger -t "checksys" "ERROR: umts0 No IP address"
ifup umts0
umts_live=`ifconfig umts0 | grep "inet addr"`
if [ "$umts_live" = "" ]
then
logger -t "checksys" "ERROR: ifup retry failed"
reset_3g
fi
fireset_3gでは、以下の処理を行っています。
reset_3g()
{
# RESET 3G module
logger -t "checksys" "Reset 3G module"
echo 1 > /sys/class/gpio/RESET_N_3G/value
sleep 1
echo 0 > /sys/class/gpio/RESET_N_3G/value
sleep 30
ifup umts0
}しかし、この対処をおこなった後も通信途絶が発生し、現場端末を確認したところ、上記のリセット対策が走ったログが残っていません。
それ以外にも全くそれらしきログは残っていない状況です。
また、定期的にAT+CSQコマンドを使用して電波状態をチェックしていますが、この操作では正常な値を示しているようです。
障害は約１日強経過したところで自然復旧していました（復旧時にはifpulgdが動作していますが、そこまではDown検出も行っていないように見えます)
全く別の原因（外部要因）であることも考えられますが、原因を絞り込むためにどんな情報を集めれば良いのかに悩んでいます。
端末が遠隔地に存在し、リアルタイムでの調査が困難なため有効な情報をログに書き残しておきたいのですが、解析に有効な情報として何を残しておけば良いか、ご指導いただけると幸いです。
よろしくお願いいたします。
コメント
eiko-murata
ご連絡ありがとうございます。
> > umts_live=`ifconfig umts0 | grep "inet addr"`
> ifconfigのステータスを見ても、通信切れを検出できないケースがあります。
>
> 例えば、Ethernetにて、Hubまで接続できていても、
> Hubから先のネットワークにてLANケーブルが抜けていた場合、
> ifconfigでは判断できないのと同じです。
>
> 10分に一度など、定期的にどこかにpingを実行し、失敗すればリカバリ、
> というような処理を入れるのがシンプルな対策と思います。
>
通信途絶自体はサーバへの不通で確認できています（サーバへのpingを定期的に行っています)が、この時何を検出することによって3Gモジュールをリセットすべきかどうかを判断すればよいでしょうか？
不通を確認した時点で、無条件にリセットをかける方法で問題ありませんか？
（現状は、念のためそのように変更しています)
>
> > また、定期的にAT+CSQコマンドを使用して電波状態をチェックしていますが、この操作では正常な値を示しているようです。
> 排他制御を意識しないと、元々入っている"3g-"で始まるスクリプトと
> AT+CSQを取得するプログラムがATコマンドの実行結果を奪い合う可能性があります。
>
> "/usr/bin/" 以下の "3g-"で始まるスクリプトを参考に、
> 電波状態をチェックするスクリプトを作成した、という事でしょうか？
>
排他制御は意識しておりませんでした。
これによって、3g-...コマンドが正常動作せず、このために不通になってしまう、というような悪影響は考えられますか？
> > reset_3g()
> 関数内に、apnの設定が記載されていませんが、
> apnの設定は/etc/config/interfaces にて行っていますでしょうか？
/etc/config/interfacesにて行っています。
不通状態を検出した際に、原因を特定したいのですが、どのような情報を集めると役にたつでしょうか？
以上、よろしくお願いいたします。
eiko-murata
少々勘違いをしておりました。
3G回線断が発生した場合、ifplugd等が自動検出してinterface自体がdownするか、IPアドレスがなくなるものと思い込んでいました。
回線断が発生してもintercae自体は正常なまま、ということですね。
例に出されたケース（HUBから先のケーブルが外れているというケース）では、ifupでは解決しないので、対処のしようがないと思いましたが、3G回線断の場合、通常はifup（/etc/config/interfacesでAPN設定）で解決することになるわけですね。
今回のケースでは、１日強経った頃に自然復旧していますが、これは、IPアドレスのリース期間が満了して再度アドレス取得が走った際にIPがなくなり、この時点でifplugdが断線検出して復旧処理に入った、と考えれば説明がつくということになりますか？（こちらの復旧処理は全く動作せず、ifplugdが復旧処理をおこなったログが出ています)
3G回線断(基地局不通)自体を検出する手段はなく、Pingが通らなくなったら、とりあえずifupをやってみる、それでもダメなら3Gモジュールのリセットを行う、という方法が適切な処理、ということになるでしょうか？
以上、半ば自己解決的ですが、問題あればご指摘ください。
at_koseki
2016年3月1日 19時15分
古関です。
> umts_live=`ifconfig umts0 | grep "inet addr"`
ifconfigのステータスを見ても、通信切れを検出できないケースがあります。
例えば、Ethernetにて、Hubまで接続できていても、
Hubから先のネットワークにてLANケーブルが抜けていた場合、
ifconfigでは判断できないのと同じです。
10分に一度など、定期的にどこかにpingを実行し、失敗すればリカバリ、
というような処理を入れるのがシンプルな対策と思います。
> また、定期的にAT+CSQコマンドを使用して電波状態をチェックしていますが、この操作では正常な値を示しているようです。
排他制御を意識しないと、元々入っている"3g-"で始まるスクリプトと
AT+CSQを取得するプログラムがATコマンドの実行結果を奪い合う可能性があります。
"/usr/bin/" 以下の "3g-"で始まるスクリプトを参考に、
電波状態をチェックするスクリプトを作成した、という事でしょうか？
> reset_3g()
関数内に、apnの設定が記載されていませんが、
apnの設定は/etc/config/interfaces にて行っていますでしょうか？
よろしくお願いします。