ページ

2016年6月30日木曜日

電算機孝行ブログのお引っ越しのお知らせ

いつも電算機孝行ブログをご愛読いただき大変感謝しています。

この度、下記へ電算機孝行ブログが移転することとなりました。今後ともよろしくお願いします。
電算機孝行2
https://densankiblog.wordpress.com/

※ なお現在の Blogger によるブログ記事は、そのまま残した状態となります。
記事の中の多くに直接リンクしたものが数多く存在しており、リンク先が行方不明となってしまうことを防ぐためです。
玄箱のファームウェア(Debian)や Debian Linux のカーネル・モジュールなどのデータの保管には、今までどおり Google ドライブを使用致します。

経緯

かねてより WordPress によるブログ作成をしたいと思っていました。WordPress によるブログは、移植性の良さに定評があります。将来的に長くブログを続ける上でこの移植性の高さは大変重要なことだと考えていました。また、この移植性の高さは、自宅サーバにウェブサーバと WordPress をインストールすれば、自宅での保管も可能となります。そのためブログ業者などの外的要因(ブログ事業の廃止など)から開放されて、自分が望むまでブログを保管することも可能となります。このようなことから、いつかブログを WordPress へ移転したいと思っていました。

今回 WordPress.com へアカウントを取得して、現行の電算機孝行ブログのインポート処理を行ってみたところ、記事を移行することが無事できました。それもインポートできる記事の XML データの上限が 15MB のところ、記事の XML データが 13MB と上限に近い状態に達していたこともあり、今回が最後の移行のチャンスだと判断しました。

 Blogger は長く使用していたこともあり、大変愛着のあるブログでした。思い出と感謝でいっぱいです。

これからも 今までと同様に記事を掲載して参りますので、よろしくお願いします。

Livingston

Debian Firefox 47.0.1 へアップデート

mozilla.debian.net で配布している Debian 向けの最新の Firefox がアップデート(47.0 から 47.0.1 へ)しました。

Firefox 47.0.1 のクレジット表示


Debian LibreOffice のアップデート

Debian Jessie に LibreOffice のアップデートが到着しました。

LibreOffice のアップデート通知


2016年6月29日水曜日

Debian Jessie カーネル・アップデート

Debian Jessie へカーネルのアップデート(3.16.7-ckt25 から 3.16.7-ckt25+deb8u2 へ)が到着しました。

Debian Jessie のカーネルアップデート通知


弊ブログにて公開している無線LANアダプタのドライバ・モジュールを使用している読者さんは、モジュールの再インストールが必要です。一緒に公開しているドライバ・モジュールのアップデート・スクリプトの modules-update.sh を使って更新してください。

# cd (ドライバ・モジュールを展開したディレクトリ)
# ./modules-update.sh

Debian 用ドライバ保管庫
http://near-unix.blogspot.jp/p/debian.html
「カーネル・アップデート時の注意」をご覧ください。

2016年6月28日火曜日

HD-HGLAN へ Asterisk 11 をインストール

我が家では Asterisk 1.8 を FreeBSD で稼働している自宅サーバで運用しています。以前より Asterisk 11 へアップグレードしたいと思っていましたが、アップグレードに伴うトラブルを恐れてなかなかアップグレードに踏み切れないでいます。

そこで  Debian Jessie がインストールされた HD-HGLAN(玄箱 HG 相当)に Asterisk 11をインストールしたのち、自宅サーバで運用中の Asterisk 1.8 の設定ファイルを移植して動作するか確認してみました。

結論から先に述べますと、起動時にいくつかのエラーは発生しましたが、今までとほぼ同じように発信や着信ができました。

Debian Jessie 化した HD-HGLAN へ Asterisk をインストールしました。

Asterisk 11 のインストール

Debian Jessie の Asterisk の標準バージョンは 11.13.1 です。apt-get コマンドで簡単にインストール可能な状態となっています。弊ブログにて配布中の Debian Jessie のファームウェアでは、ネットワーク・ディスクとして機能するように Samba がインストールされています。しかしメモリの使用量が多いことから、この Samba を削除した後、Asterisk をインストールしました。
-- Samba の削除 --
# apt-get remove samba
# apt-get autoremove
-- Asterisk のインストール --
# apt-get update
# apt-get install asterisk

 インストールすると自動的に起動している Asterisk を停止させました。
-- Asterisk の停止 --
# service asterisk stop

Asterisk の設定

ます現状の Asterisk の設定ファイルをディレクトリごと保管しました。
-- 設定ファイルの保存 --
# cd /etc
# tar zcvf  asterisk-conf.tar.gz  asterisk/

自宅サーバで運用中の Asterisk 1.8 の設定ファイルのうち、次の三つの設定ファイルを HD-HGLAN へコピーしました。設定ファイルの移動には FTP を使用しました。
-- コピーした設定ファイル --
・sip.conf
・extensions.conf
・voicemail.conf

Asterisk 本体の設定ファイル(asterisk.conf)を編集しました。 無効化されていた以下の三行を有効化しました。有効化の方法は、行頭にあるコメントマーク " ; "  を削除します。
# vi /etc/asterisk/asterisk.conf

-- asterisk.conf の編集部分 --
languageprefix = yes ; Use the new sound prefix path syntax.
runuser = asterisk    ; The user to run as.
rungroup = asterisk  ; The group to run as.

日本語対応の音声ファイルをインストールしました。なお使用した日本語音声ファイルは VoIP-Info.jp Wiki のものです。バージョン 1.6 のものが最新のもののようで、Asterisk 11 でも使用出来ました。
# cd /var/lib/asterisk/sounds
# wget http://ftp.voip-info.jp/asterisk/sounds/1_6/asterisk-sound-jp_16_pre.tar.gz
# tar zxvf asterisk-sound-jp_16_pre.tar.gz

Asterisk 本体設定で "languageprefix = yes"  と設定していましたが、/var/lib/asterisk/sounds のディレクトリから音声ファイルを読み出してくれないようです。そこで英語の音声ファイルが格納されているディレクトリからソフトリンク(ln -s)を設定して、日本語対応の音声ファルを読み出せるようにしました。
# cd /usr/share/asterisk/sounds
# ln -s /var/lib/asterisk/sounds/ja  ja

今回は、日本語音声ファイルをインストールしたもの、音声の並びの不自然さを直すパッチは適応していません。英語的な?日本語です。

動作確認

以上で編集終了です。Asterisk を起動させました。
# service asterisk start

CLI モードへログインして、Asterisk の動作状況を確認しました。我が家では、起動時にエラーは発生するものの、発信、着信、通話ができました。
# asterisk -r

-- 外部へのレジスト状況の確認 --
*CLI> sip show registry

-- 各電話機との接続状況の確認 --
*CLI> sip show peers

-- 特定の電話機(201)との接続状況の確認 --
*CLI> sip show peer 201

余談

元々、自宅サーバ(FreeBSD)の Asterisk 1.8 の設定ファイルを丸ごとコピーして動作確認をしたところ、それなり?に動作していました。・・・がしかし、問題が多数発生しました(笑)。 FreeBSD と Debian とでは、各ディレクトリの配置がことなることから各種ファイルを見つけられずにエラーとなっていました。そのため、上記のように必要最小限度の設定ファイル(三つ)を移植しただけとしました。

アイコム VE-TA10 のファームウェア・アップグレード(2.00)

@nifty フォン-C の着信不良の問題の件で、ここ数日の間、自宅サーバの Asterisk やルータ(ホームゲートウェイ)を見直してきました。IP 電話で思い出したのが、このアイコム製の VE-TA10 です。あの 30 分経過すると着信不良となるテレホン・アダプタです。ファームウェアの最新バージョンを確認すると 2.00 となっていましたので、早速バージョンアップしました。

ファームウェアのアップグレードを行った VE-TA10 です。

アイコム VE-TA10 のファームウェア・アップグレード
http://near-unix.blogspot.jp/2015/10/ve-ta10.html

ファームウェアのバージョンアップ

VE-TA10 の IP アドレスを直接指定してブラウザで設定画面を開きます。そして [メンテナンス]-[ソフトウェアの更新] を選択して、最新のファームウェアの確認を行いました。現状は 1.80 でした。

現在のバージョンは 1.80 でした。

すでに 1.90 が存在していたようで、今回は 2.00 へのアップグレードでした。

新しい 2.00 のファームウェアの通知です。

そのまま [ソフトウェアを更新] でファームウェアをアップグレードしました。

ファームウェアの更新の様子です。

暫く放置すると自動的に再起動して、新しくなったファームウェアの設定画面を表示してくれました。

バージョン 2.00 となったファームウェアの設定画面です。


動作確認

以上でファームウェアのアップグレードは終了しました。

さて気になる 30 分後に VE-TA10 への着信ができなくなる問題は、相変わらず発生していました。このバージョン 2.00 のファームウェアでも SIP アカウントの再レジストの際に再度の暗号化されたアカウント設定が行われるようで、再レジストに失敗してしまいます。この VE-TA10 の問題というよりは、Asterisk の仕様の問題のようです。詳しくは以前調査した時の記事を参照してください。
アイコム VE-TA10 の30分で着信拒否の件
http://near-unix.blogspot.jp/2013/09/ve-ta10_20.html

2016年6月27日月曜日

@nifty フォン-C の着信不良(全面書き換え)

6月22日に @nifty フォン-C (050 の IP 電話)の着信不良について記述しておりましたが、その後、着信が安定的に行えるようになりましたので、全面的に書き換えを行うこととしました。
@nifty フォン-C の着信不良
http://near-unix.blogspot.jp/2016/06/nifty-c.html

症状

自宅サーバの Asterisk で管理している @nifty フォン-C の IP 電話へ着信が出来なくなっていました。外部から問題の IP 電話へ電話を掛けると何回かの呼び出しのあと、サービス不能として通話が切断されてしまいます。その後、一度 IP 電話側から外線へ電話を掛けた後、暫くの間は IP 電話への着信が可能となる状態でした。

なお @nifty フォン-C は OCN の業務を代行してもらっているサービスのようで、SIP サーバの IP アドレスは OCN のものです。

原因

着信不良となった原因は、@nifty フォン-C で指定している SIP サーバの移転(IP アドレスの変更)が原因でした。SIP サーバのホスト名は voip09.nifty.com と変更ありませんでしたが、指し示す IP が変更となっていました。

このため、フレッツ光回線で使用しているホームゲートウェイ※(PR-400NE)に設定してある IP パケットフィルタで新しい SIP サーバの SIP パケット(5060)を遮断していました。このため外部からの呼び出しに応答することが出来なくなっていました。
(※ホームゲートウェイ=ルータのことです)

対策

ホームゲートウェイ(PR-400NE)の IP パケットフィルタを修正しました。
具体的には、以前 SIP サーバ(voip09.nifty.com)として指し示されていた IP アドレス210.227.109.253 から、新しい IP アドレス 153.146.170.168 へ変更しました。

単純に IP パケットフィルタを変更しただけでも良かったのですが、今後も若干の IP アドレスの変動(※2)があるかもしれないと予想して同じサブネット内の IP アドレス(153.146.170.0/255.255.255.0)から到着する SIP パケット(5060) を通過させるようにしました。

ホームゲートウェイ(PR-400NE)への設定例は次のとおりです。
エントリ番号 20 番(図中の赤枠部分)が今回追加で設定したパケットフィルタです。そしてエントリ番号 21 番は以前の古いパケットフィルタの設定です。万が一、何らかの理由で古い IP アドレスへ戻すかもしれないため、当面の間は古いパケットフィルタの設定も残しておくこととしました。

PR-400NE のパケットフィルタ設定
赤枠部分が新設した設定です。


※2 IP 電話の需要は減少しているようで、各プロバイダでの IP 電話の新規受付中止や廃止されていることから、今後 SIP サーバの統廃合が予想されるためです。

動作確認

Asterisk のモニタでレジスト状況を確認しました。そして実際に電話の発信・着信を一時間以上の間を開けながら何度か繰り返して行ってみました。問題なく発信と着信ができました。

# asterisk -r
*CLI> sip show registry

Host                                    dnsmgr Username       Refresh State                Reg.Time                
pr400ne:5060                            N      3                 3585 Registered           Mon, 27 Jun 2016 14:30:59
nifty-sip:5060                          N      0503456----@      3585 Registered           Mon, 27 Jun 2016 14:31:01
2SIP registrations.

なお古い SIP サーバでは qualify に対応して応答していましたが、新しい SIP サーバは qualify に対応していないようで、反応がありませんでした。qualify の設定は無効にした方が良いようです。

今後のこと

今回の SIP サーバの移転は IP 電話用のサーバ設備の更新(置き換え)だと思われます。今でも古い SIP サーバへレジストが可能で、さらに通話も可能ですが、いずれ古い SIP サーバは廃止されるものと思われます。

FreeBSD PHP 5.6.23 へのアップグレード

FreeBSD の ports へ PHP 5.6 のアップグレード(5.6.22 から 5.6.23 へ)が到着しました。

portmaster で関連の php-extensions も一気に更新しておきました。

php56-5.6.23 のビルドオプション


2016年6月24日金曜日

Buffalo HD-HGLAN(二台目)へ Debian Jessie をインストール

二台目の HD-HGLAN へ Debian Jessie をインストールしました。

Debian Jessie のインストールに成功した二台目の HD-HGLAN です。

シリアルコンソールの設置

インストールの前に HD-HGLAN のボード上のシリアルコンソールの端子へピンヘッダを予めハンダ付けしておきました。一台目の HD-HGLAN と同じ要領です。
Buffalo HD-HGLAN へシリアルコンソールの端子設置
http://near-unix.blogspot.jp/2016/06/buffalo-hd-hglan_20.html
Debian Jessie をインストール中の HD-HGLAN です。

u-boot 1.2.0 の書き込み

u-boot の書き込みは、玄箱 HG のファームウェアから出来ないことが確認されています。そこで一台目の HD-HGLAN と同様に純正ファームウェアのアップデートに起動コードを u-boot 1.2.0 に置き換えたもので書き換えを行いました。
Buffalo HD-HGLAN へ Debian Jessie をインストール
http://near-unix.blogspot.jp/2016/06/buffalo-hd-hglan-debian-jessie.html#u-boot

Debian Jessie のインストール

Debian Jessie のインストールも一台目の HD-HGLAN と同じ方法でインストールしました。
Buffalo HD-HGLAN へ Debian Jessie をインストール
http://near-unix.blogspot.jp/2016/06/buffalo-hd-hglan-debian-jessie.html#debian-jessie-install

動作確認

問題なく起動して動作しました。一台目の HD-HGLAN のときのように LAN ポートの障害はありませんでした。これで Debian Jessie 化した HD-HGLAN が二台となりました。


Buffalo HD-HGLAN(二台目)へ純正ファームウェアのインストール(失敗)

バッファロー製 HD-HGLAN(二台目)へメーカ純正ファームウェアのインストールを試みましたが、失敗しました。

二台目の HD-HGLAN も純正ファームウェアのインストールに失敗しました。

はじめに玄箱 HG のファームウェア

一度、メーカ純正のファームウェアのアップデート失敗していました。その後、ファームウェアのアップデートを受け付けない状況となっていました。一台目の HD-HGLAN の時のように EM モードへ移行していなかったことから、玄箱 HG のファームウェアがインストールされているハードディスクを取り付けてみました。するとこの玄箱 HG のファームウェアで起動することができました。

ここでフラッシュメモリのバックアップを取得しようとしました。しかしなぜか /dev/fl* へのアクセスができませんでした。また u-boot を書き込んでみようと試みましたが、書き込むことができませんでした。

メーカ純正ファームウェア(1.65)のインストール失敗

玄箱 HG のファームウェアからフラッシュメモリへアクセスできないことが判明したため、直接 Debian Jessie へ移行してしまうことを諦め、一旦メーカ純正のファームウェアをインストールすることとしました。

しかし一台目の HD-HGLAN と同じ症状でファームウェアのアップデートができませんでした。一台目の HD-HGLAN には LAN ポートの異常があったことから、これが原因だと判断していましたが、間違っていたようです。原因は、別のところにあるようです。
Buffalo HD-HGLAN にメーカ純正ファームウェアのインストール(失敗)
http://near-unix.blogspot.jp/2016/06/buffalo-hd-hglan_15.html

以上のことが判明したことから、一台目の HD-HGLAN と同じ手順で Debian Jessie をインストールしたいと思っています。

Buffalo HD-HGLAN (二台目)のハードディスク検査

二台目となるバッファローの HD-HGLAN のハードディスクを検査しました。

二台目の HD-HGLAN に搭載されていたのはサムスン製 SV1604N でした。

ハードディスクの検査

筐体を開いてハードディスクを取り出してみると、運悪くサムスン製のハードディスク(SV1604N, 160GB)でした(涙)。 早速ハードディスクの検査用のデスクトップ・パソコンへ接続して検査を行いました。

検査中のサムスン製 SV1604N の様子です。

HGST の DriveFitnessTest では「異常なし」として検査終了しました。

そして各セクタの様子を検査するために MHDD でも検査しました。すると二箇所のセクタで 500ms という危険値が検出されていました。その他 3.5 インチ・ディスクとしては遅めの 50ms のセクタも 4133 個も検出されました。

SAMSUNG SV1604N の MHDD の検査結果

ちなみに一台目の HD-HGLAN に搭載されていたウェスタンデジタルの WD2500BB では、500ms 以上の異常値を示すセクタは無く、さらに 50ms の遅めのセクタもたった 37 個しかありませんでした。同時期に製造されたと思われるハードディスクですが、これだけ性能に差が現れてしまっています。

WDC WD2500BB の MHDD の検査結果

ハードディスクの消去

Debian Jessie のインストールに備えて、ハードディスクを綺麗さっぱりとゼロフィルして初期化しました。


2016年6月23日木曜日

Buffalo HD-HGLAN 二台目を入手

二台目となるバッファローの NAS 製品 HD-HGLAN(HD-HG160LAN)をインターネット・オークションにて入手しました。

手前が今回入手した二台目の HD-HGLAN です。

経緯

二台続けて HD-HGLAN を入手した理由は、一台目の HD-HGLAN の異常で、もしかするとフラッシュメモリを JTAG にて書き換える必要があるかもしれないと考えて、オリジナルのフラッシュメモリのデータを入手することを前提として入手したものでした。しかし、その後一台目の HD-HGLAN は、フラッシュメモリの起動コード部分を U-boot 1.2.0 へ書き換えることに成功し、無事 Debian Jessie をインストールすることに成功していました。そのため、この二台目の HD-HGLAN は当初の目的を失ってしまいました(笑)。

上段が二台目の HD-HGLAN です。

ファームウェアのアップデート(失敗)

現状のファームウェアのバージョンは 1.02 でした。そこで 1.65 へアップデートを行ってみました。

何と!ファームウェアのアップデートに失敗してしまいました(涙)。 一体どうしたことでしょう!

結果、アップデート・ソフトウェアから HD-HGLAN が見つけられなくなってしまいました。

以前の 1.02 で起動します

アップデート・ソフトウェアから見つけられないのですが、何故か普通に起動をして動作していました。ブラウザから HD-HGLAN へアクセスすると設定画面へたどり着くことができました。NAS としての動作もしていました。

どうもハードディスク内のファームウェアの書き換えに失敗した模様ですが、以前のファームウェアがそのまま残っていることからシステムが起動したようです。ファームウェアのアップデートを制御する部分だけが動作していない模様です。

ファームウェアのアップデートに失敗しながらも起動しました。

ハードディスクの初期化予定

どうもハードディスクを消去して EM モードで起動させると、ファームウェアのインストールができるのではないかと考えています。明日以降に行ってみたいと思っています。

この HD-HGLAN は、背面のネジが残っていることと、筐体の爪に傷がないことから、まだ未開封の個体のようです。



2016年6月22日水曜日

FreeBSD に DEFAULT_VERSIONS+=ssl=openssl の警告

いつものように FreeBSD で構築している自宅サーバの ports を更新しようとしたところ次のような警告メッセージが表示されるようになりました。
/!\ WARNING /!\
You have security/openssl installed but do not have DEFAULT_VERSIONS+=ssl=openssl set in your make.conf

どうも SSL の標準値の設定を行うように促しているようです。設定先は /etc/make.conf です。

そこで設定を追加したところ、警告メッセージはなくなりました。
# vi /etc/make.conf

-- 最終行へ追加 --
DEFAULT_VERSIONS+=ssl=openssl


@nifty フォン-C の着信不良

注意:内容を全面的に記述しなおしました。次の記事を参照してください。
@nifty フォン-C の着信不良(全面書き換え)
http://near-unix.blogspot.jp/2016/06/nifty-c_27.html


我が家ではプロバイダとして使用している @nifty のサービスの一つの @nifty フォン-C (IP 電話)を使用しています。それも自宅サーバの中に設置してある Asterisk サーバから接続させていました。この IP 電話の番号へ着信が出来なくなっていました。何故か発信はできる状態でした。そして発信した直後だけは、着信が可能な状態となっています。

原因調査

Asterisk サーバを再起動させて @nifty フォン-C の SIP サーバ(我が家の場合 voip09.nifty.com)との接続状況を確認しました。
# asterisk -r
*CLI> sip show peers

念の為 sip.conf の @nifty フォン-C の設定に "qualify=yes" を付加して、具体的に応答していることを確認してみたところ、応答がありませんでした。
nifty-sip/ABCDEFGH        153.146.---.---
5060     UNREACHABLE


パケットフィルタの設定変更

ここで @nifty フォン-C の SIP サーバの IP が変更になっていることに気づきました。以前は 210.227.109.--- でした。このため NTT から貸し出されているフレッツ光 ホームゲートウェイ PR-400NE のパケットフィルタの設定も変更しなければならないことに気づきました。
光ネクスト隼 PR-400NE の設定
http://near-unix.blogspot.jp/2013/03/pr-400ne.html

PR-400NE のパケットフィルタの設定を新しい IP アドレスに合わせて変更しました。そして接続状況を確認しました。・・・しかし接続できませんでした。訂正2016-06-26:接続できました。)

さらに PR-400NE のパケットフィルタを特定の IP アドレスの SIP パケット(5060)だけが通過できる状態から全ての IP アドレスからの SIP パケットが通過できるように変更しました。それでも接続できない状況に変わりありませんでした。

ドメイン名指定から IP アドレス直接設定へ

(注意:この IP アドレス直接指定はおすすめしません。voip09.nifty.com で接続できました。2016-06-26)
@nifty フォン-C の新旧の IP アドレスを whois コマンドや ping コマンドで調査してみると、まだ古い @nifty フォン-C の IP アドレスの SIP サーバは生きているようです。(注記:@nifty フォン-C と名前がついていますが OCN の IP 電話サービスを再利用しているようです。)

ドメイン名で指定された SIP サーバ(voip09.nifty.com)に問題があるのではないかと考えて、直接以前の SIP サーバへ接続できるように IP アドレスを sip.conf へ設定してみました。

-- sip.conf の @nifty フォン-C の設定部分 --
赤字の部分を ";" でコメント化
青字の部分を追加
[nifty-sip]
type=friend
secret=PASSWORD
defaultuser=ABCDEFGH
fromuser=05012345678
fromdomain=nifty.com
;host=voip09.nifty.com
host=210.227.---.---
context=nifty-in
dtmfmode=inband
canreinvite=no
insecure=port,invite
progressinband=no
qualify=yes

新しく設定した sip.conf を読み込ませて起動させました。すると SIP サーバと接続できました。応答もあります。そして @nifty フォン-C への着信も可能となりました。
# asterisk -r
*CLI> sip reload
*CLI> sip show peers

nifty-sip/ABCDEFGH        210.227.---.---
5060     OK (16 ms)

以上のことを確認した後、 PR-400NE で行っていたパケットフィルタの設定を元通りに特定の IP アドレス(210.227.---.---)の SIP パケット(5060)だけが通過できるように設定しました。

今後の事

IP アドレスの直接指定で着信出来ないという問題は回避することが出来ましたが、将来的にはドメイン名に戻したいと思っています。どうして SIP サーバが変更となり、接続(受信)出来ないのか? 今後どうなってしまうのか? 全く不明で不安です。

FreeBSD OpenSSL 1.0.2_14 へアップデート

FreeBSD の ports へ OpenSSL のアップデート(1.0.2_13 から 1.0.2_14 へ)が到着しました。

前回の openssl-1.0.2_13 は脆弱性の問題で一時的にインストールが停止されていましたが、その後、解除された模様でインストールされていました。今回の openssl-1.0.2_14 は、脆弱性の問題もなく、素直にインストールされました。

openssl-1.0.2_14 のビルドオプション


Buffalo HD-HGLAN へ Debian Jessie をインストール

メーカ純正ファームウェアのインストールに失敗していたバッファローの NAS 製品 HD-HGLAN へ Debian Jessie をインストールしました。

苦難を乗り越えて Debian Jessie のインストールに成功した HD-HGLAN です。

経緯

入手した HD-HGLAN は、何故かメーカ純正のファームウェアのインストールに失敗していました。原因は Debian Jessie をインストールしたことによって判明したのですが、LAN ポート付近の不良でした。具体的な場所については確定していません。HD-HGLAN に接続しているイーサネット・スイッチの LED ランプは正常に接続していると表示されていましたが、Debian Jessie を起動させると、接続しておらず DHCP による自動設定が出来ない状態でした。しかし LAN ケーブルを手に持っていろんな方向に向けて圧力をかけると LAN へ接続できる状態となるのです。どうも LAN ポート周辺の接触不良または一時的な断線が発生している模様です。これにより、正常な通信が出来なくてメーカ純正のファームウェアのアップデートに失敗していた模様です。
(2016-06-24 追記:LAN ポートの異常がファームウェアの失敗の原因ではないことが二台目の HD-HGLAN で判明しました。)
Buffalo HD-HGLAN にメーカ純正ファームウェアのインストール(失敗)
http://near-unix.blogspot.jp/2016/06/buffalo-hd-hglan_15.html

インストールの第一歩

では実際に Debian jessie をインストールした方法を紹介します。現状では、フラッシュメモリの中の起動ステータス部分(/dev/fl3)へ "NGNG"  が書き込まれており、常にフラッシュメモリの中のシステムが起動されるようになっています。このままでは、ハードディスクへいくら正常なシステムをインストールしたところで、このハードディスク内のシステムを起動させることができませんでした。そこで他の玄箱と同様に u-boot 1.2.0 をインストールすることとしました。

HD-HGLAN のフラッシュメモリ内のシステムは、起動したところでパスワードが不明なため、シリアルコンソールを接続していても一切の操作ができません。もちろんフラッシュメモリの内容を書き換えることもできません。

そこで HD-HGLAN のメーカ純正ファームウェアのアップデート・ソフトウェア(HD-HGLAN FWUpdate.exe)の特性を使って u-boot をインストールしました。

u-boot のインストール

それは、オプションに /force を設定してファームウェアのアップデートを実行させると、フラッシュメモリの中のシステム部分(/dev/fl1)と起動コード(/dev/fl2)を書き換えてくれることでした。

起動コードは、bootcode.bin という 38KB ほどのファイルになっています。これを u-boot 1.2.0 (u-boot-1.2.0-hg.flash.bin)に置き換えてメーカ純正のファームウェアのアップデート・ソフトウェアを /forece オプションを設定して実行させました。
DOS プロンプト上からの起動させます。

copy u-boot-1.2.0-hg.flash.bin  bootcode.bin
"HD-HGLAN FWUpdate.exe"  /force

通常のアップデートと同様にファームウェアのアップデートを更新しましたが、起動コード部分が書き換えられたために、HD-HGLAN からの反応が無くなってしまったようで、ファームウェアのアップデートが失敗してしまいます。

そこで電源を再投入してシリアルコンソールを観察していると u-boot による起動が開始されました。上記の bootcode.bin の置き換えで、起動コード部分をu-boot に書き換えてくれていました。

後は、u-boot のコンソールへログインした後、起動ステータスの部分を "OKOK" と書き換えました。書き換えは u-boot のコマンドを使用しました。
=> run writeok
=> boot

そのままハードディスク内の状況にもよりますが、ハードディスク内の第一パーティション(/dev/hda1)のシステムを起動させようとします。何もシステムをインストールしていなければ起動に失敗するはずです。

u-boot に書き換え成功した HD-HGLAN です。

Debian Jessie のインストール

ここで電源を切り、ハードディスクを取り出します。そしてハードディスクをパソコンへ接続して、パソコンから直接 玄箱用の Debian Jessie をインストールしました。インストール方法は過去の記事に詳細があります。第一パーティションへは、HD-HGLAN のファームウェアではなく、玄箱 HG 用のファームウェアをインストールしました。
玄人志向 玄箱 HG へ大容量ハードディスク向けインストール
http://near-unix.blogspot.jp/2016/03/hg_24.html

Debian Jessie のインストールが終わったハードディスクを HD-HGLAN へ接続して、起動させます。すぐに u-boot のコンソールへログインして、Debian Jessie の起動に必要な設定を行います。以下の記事の u-boot の設定部分を参照してください。
玄人志向 玄箱用 Debian Jessie 通常版(カーネル3.16 版)
http://near-unix.blogspot.jp/2016/01/debian-jessie-316.html

動作確認

再起動させて Debian Jessie が起動するか確認しました。

ここで初めて、上記に記した LAN ポートの不具合を発見しました。起動途中で DHCP による LAN の自動設定がタイムアウトで設定出来ないことを発見しました。その後、ハードディスクの第一パーティションへインストールしていた玄箱 HG 用のファームウェア(1.01)で起動し直してみましたが、同様に DHCP で IP の自動設定が出来ないことを確認しました。LAN ケーブル部分に圧力を加えると DHCP で IP の自動設定が行われることから、LAN ポート周辺の不具合が存在している模様です。

今後、LAN ポート周辺の再ハンダ付けなどを行ってみたいと思っています。

HD-HGLAN に搭載されていた RTL8110S-32 です。
RTL8169 と認識されて r8169 ドライバが使用されます。
HD-HGLAN の LAN ポートとパルストランス周辺の様子です。


 

2016年6月20日月曜日

Buffalo HD-HGLAN にメーカ純正ファームウェアのインストール(失敗)

ハードディスクのチェックや初期化の終わったバッファローの NAS 製品の HD-HGLAN へメーカ純正のファームウェアをインストールしようとしましたが、原因不明でインストールできませんでした。

ファームウェアをインストール中の HD-HGLAN

状況

ネット上を検索してみると HD-HGLAN のハードディスクを交換した後、ファームウェアを再インストールすることを紹介しているブログをいくつか発見しましたが、これらの記事のようにファームウェアをインストールすることができませんでした。

実際に行ったこと

1.単純に自宅 LAN に HD-HGLAN を接続して WindowsXP のパソコンより、メーカ指定の方法で単純にファームウェア(1.65)のインストールを試みました。途中で「ファームウェアの更新に失敗しました。」と表示されてインストールが中断されていまいました。この他、バージョン 1.69β と 1.42 で試みましたが、同様に成功しませんでした。もちろんファイアウォールを一時的に停止させており、通信上の障害は無かったものと思われます。
なお観察した雰囲気では、ファームウェアの転送を行った後、ファームウェアの解凍を行っている途中(全 LED が点滅し、ハードディスクがカタカタと動作している最中)にインストール動作が中断されている感じでした。

HD-HGLAN のファームウェアのインストール開始
バージョン 1.65 を EM モードでインストール
ファームウェアの更新に失敗しました。


2.クロスケーブルを使用して WindowsXP パソコンと HD-HGLAN を直接接続してファームウェアのインストールを試みましたが、上記と同様にインストールに失敗しました。HD-HGLAN の IP アドレスは初期設定のままの 192.168.11.150 で、WindowsXP パソコンの IP アドレスは 192.168.11.2 に手動設定していました。

3.ファームウェアの更新ソフトウェアの起動に /force のオプションの設定を行ってフラッシュメモリの起動部分の更新も強制的に行ってみましたが、どのバージョンもファームウェアのインストールに失敗しました。
DOS プロンプト上からの起動させます。

"HD-HGLAN FWUpdate.exe"  /force

4.ファームウェアに失敗したハードディスクを取り出して内容を確認してみると、次のようにパーティションが設定されていました。
/dev/hda1 : Linux(83) -- 未フォーマット
/dev/hda2 : Linux swap(82)
/dev/hda3 : Linux(83) -- フォーマット済み
/dev/hda4 : Linux(83) -- 未フォーマット
/dev/hda3 の中に /dev/hda1 へインストールするファームウェアの圧縮ファイル(tmpimage.tgz)が存在していました。 そこで未フォーマットの /dev/hda1 を ext3 フォーマットを行って、手動でファームウェアをインストールしました。
Debian Jessie が稼働しているマシンで接続して次のとおり操作 しました。

# mke2fs  -I 128  -j  /dev/sdb1
# mount /dev/sdb1 /mnt
# tar zxvf tmpimage.tgz  -C /mnt
# umount /mnt

しかしこの状態で HD-HGLAN へ接続しても EM モードからの復旧はできない状況でした。まだ /dev/fl3 へ "NGNG" が書き込まれている状況のようでした。

この状況で再度ファームウェアのインストールを試みましたが、やはりインストールに失敗しました。

お手上げ状態

現状では為すすべがありません。フラッシュメモリの起動コード部分がせめて u-boot 1.2.0 へ変更できればと思っています。メーカ純正のフラッシュメモリ内のファームウェア部分を修正することができる firmimgtool でなんとか出来ないものかと考えています。

この他、powerpc 向けの 20 pin JTAG にチャレンジすることも考慮する必要がありそうです。


Buffalo HD-HGLAN へシリアルコンソールの端子設置

先日、分解と掃除を行ったバッファローの NAS 製品の HD-HGLAN のボードへシリアルコンソールのピンヘッダを取り付けました。

現状の様子

玄箱 HG とほぼ同じプリント印刷基盤を使用しているようです。4ピンのヘッダパッドが用意されていました。他の玄箱と同様に入力保護用の抵抗器(R76)が取り除かれている状態でした。

HD-HGLAN のシリアルコンソール端子周辺の様子

ピンヘッダの取り付け

この R76 は、基本的にゼロオームの抵抗器を取り付けても大丈夫な部分ですが、手元にゼロオーム抵抗器がなかったことから 75 オームの抵抗器で代用しました。

また L 字型のピンヘッダを取り付けるときに障害となる C70 を避けるために、ピンヘッダの下に厚紙で作ったスペーサを挟み込んでピンヘッダをハンダ付けしました。

HD-HGLAN へピンヘッダを取り付ける直前の様子
HD-HGLAN へピンヘッダをハンダ付けしたところ

動作確認

GND, Rx, Tx の端子へシリアルケーブルを接続して動作確認を行いました。通信速度は 57600bps でした。問題なく動作していました。




2016年6月18日土曜日

Buffalo HD-HGLAN を入手

インターネット・オークションにて、バッファローの NAS 製品の HD-HGLAN (HD-HG250LAN)を入手しました。

今回入手した HD-HGLAN です。

すでに玄箱(初代)や玄箱 HG なども所有していますが、以前より気になっていた HD-HGLAN が安価で落札出来そうだったので入札しておいたところ、運良く落札することができました(笑)。

分解と掃除

筐体の表面を見てもそこそこ汚れている状態であったので、分解して掃除をすることとしました。

すでに以前の所有者さんが分解を行っていたようで、爪などに傷跡が残っていました。

筐体を開いた HD-HGLAN です。

各部を分解して、表面の汚れをブラシで掃除しました。

HD-HGLAN のボード表面です。
HD-HGLAN のボード裏面です。

冷却ファン(AD0412LX-G76)の汚れを掃除した後、玄箱シリーズでは定番作業となった回転軸へシリコングリスを塗布しておきました。竹串の先に少量のグリスをすくい取り、回転軸にある樹脂製の C リングの隙間から奥に押しこむようにして注入しました。これが細かな作業で、目が衰えてきた者にとって辛い作業です(笑)。

冷却ファンの回転軸へグリスを塗布しておきました。

そして電源ユニットの出力部にある電解コンデンサを確認してみましたが、まだ破裂しておらず、まだまだ使えそうでした。

HD-HGLAN に搭載されていた電源ユニットです。
電解コンデンサの破裂は見られませんでした。

設置されていたハードディスクはウェスタンデジタル(Western Digital)の WD2500BB-00GUC0 でした。設置されていたハードディスクの設定用ジャンパは、標準的な位置と異なったポジションに設定されていました。他にもバッファロー製品では、標準的な位置と異なるショートジャンパの設定をしているのを目撃しています。何らかの専用設定なのかもしれません。

HD-HGLAN に搭載されていたハードディスクの WD2500BB-00GUC0 です。
標準的な場所とは異なる位置にショートジャンパが設置されていました。

メーカ謹製の Data Life Guard Diagnostics で検査を行いました。検査では「異常なし」となりました。

DLGDIAG で WD2500 の検査を終了したところです。

しかしデータを念の為に消去を行ってみたところ、250GB のハードディスクなのに12 時間以上も時間が掛かりました。 何となくですが、どこかに異常がある感じがします。もう少しハードディスクの検査を継続してみたいと思います。

DLGDIAG で WD2500 を消去しているところです。

最後にかなり汚れていた筐体のプラスチック部品を水洗いました。レンジ周り用のアルカリ洗剤を使用してしっかり洗浄しました。

プラスチック筐体の内側は、プラスチック特有の汚れが付着していました。
レンジ周り用のアルカリ洗剤をふりかけて暫く放置した後、洗浄しました。

この後は、シリアルコンソール用のピンヘッダの取り付けなどを行った後、Debian Jessie をインストールする予定です。

2016年6月16日木曜日

Buffalo WLI2-TX1-G54 の分解と無線 LAN カードの取り外し

昨日 NVRAM へポート設定に誤った値を書き込んだため、文鎮化してしまった バッファローのイーサネット・コンバータの WLI2-TX1-G54 を分解しました。

文鎮化してしまった WLI2-TX1-です。

Buffalo WLI2-TX1-G54 が文鎮化(レンガ化)
http://near-unix.blogspot.jp/2016/06/buffalo-wli-tx1-g54.html

経緯

このブログの掲示板へ有益な情報を多く提供してくださる SSS さんより、LAN ポートのアクセスが出来なくなったときに、試して欲しい脱出方法として、WLI2-TX1-G54 の内部にある無線 LAN カード(Mini-PCI)を取り外す方法が紹介されていました。
WLI-TX1-G54の文鎮化の記事について
http://livingston.bbs.coocan.jp/?m=listthread&t_id=23

これは無線 LAN カードがなくなることにより Linux システムが自動的にポート番号を割り振り直してしまう特徴を活かして、新たに振り直されたポート番号によって運が良ければ通信が出来なくなっている状態から脱出できるかもしれないというものでした。

もう文鎮化してしまっているので、一度は試してもよい方法だと考えて試してみることとしました。

WLI2-TX1-G54 の分解

以前にも同様の筐体を分解したことがあるため、分解作業は順調に行うことができました。

頭頂部のカラー部品を取り外しました。分解を参考にする読者さんは爪の位置をよく観察して分解してください。

頭頂部のカラー部品を取り外したところ

前面部品を取り外しました。頭頂部の爪を外した後、左右の側面の爪を外して、最後に底部の爪を外す要領で取り外しました。

前面部品を取り外したところ

左右に筐体を分割しました。これも頭頂部にある二箇所の爪を外した後、底部の一箇所の爪を筐体を上下にずらすような形で爪を外しました。最後に背面部分の二箇所の爪を外しました。

筐体を左右に分割したところ

内部に収まっているボードやアンテナ類を取り外しました。

筐体からボードを取り外したところ

無線 LAN カードの取り外し

ハンダ付けで固定されている無線 LAN カードをハンダゴテを使って取り外しました。

ボードから無線 LAN カードを取り外したところ

動作確認

WLI2-TX1-G54 の無線 LAN カードを取り外して、LAN ポートへパソコンからケーブルを接続しました。WLI2-TX1-G54 の LAN ポートにはどのような IP アドレスが設定されているのか不明のため、パソコン側には arp コマンドを使って IP アドレスを 192.168.1.1 へ設定しておきました。
-- arp コマンドの設定例 --
# arp -s 192.168.1.1 00:11:22:33:44:55

現状の DD-WRT v23 SP2 がインストールされている状態では、LAN ポートの反応はありませんでした。そして家庭内 LAN へ接続しなおして、DHCP による IP アドレスをしてもらう状態にしてみましたが、IP アドレスが DHCP サーバから配給された気配はありませんでした。

どうも無線 LAN カードを取り外しても適切なポート番号が割り振られなかったもようです。

TFTP による流し込み

この無線 LAN カードを取り外した状態で TFTP によるファームウェアの流しこみができるか確認してみました。運良くこの TFTP による流し込みは生きているようです。そこで Openwrt Backfire 10.03.1 をインストールしてみました。

OpenWrt で動作確認

OpenWrt がインストールされた状態で、再度上記ように WLI2-TX1-G54 の LAN ポートの確認を行ってみましたが、反応はありませんでした。

OpenWrt 上でハードリセット

そして DD-WRT の時には失敗した 30/30/30 ハードリセットを この OpenWrt 上でも行ってみました。DD-WRT の時には、リセットボタンを押していても LED ランプは無反応でしたが、OpenWrt では反応がありました。これはハードリセットにより NVRAM を消去してくれた可能性がありました。

再起動させて動作確認を行ってみましたが、OpenWrt では元々動作しているのか不明でした(笑)。

再度 DD-WRT のインストール

そこで TFTP によるファームウェアの流し込みによって DD-WRT v23 SP2 を再度インストールし直しました。そして無線 LAN カードを取り付けて DD-WRT の SSID が発射されていないかを確認しました。しかし待てど暮らせど DD-WRT の SSID を発見することができませんでした。OpenWrt 上でのハードリセットは失敗だったようです。

DD-WRT を再度インストールして無線 LAN 通信が可能となっているかどうかを確認しました。

いくつかこの文鎮化した状況を脱出するための方法を掲示板上にいくつかアドバイスして頂いておりますので、今後これらを確かめてみたいと思っています。