早速、いつものように portupgrade -a で関連する ports を含めて一斉に更新を行なっておきました。
我が家では動作上の問題は無いように感じられました。
 |
| php5-5.4.36 のビルド・オプション |
2014年12月30日火曜日
FreeBSD PHP 5.4.36 へアップグレード
年の瀬が押し迫った今日、FreeBSD の PHP のアップグレード（5.4.35 から 5.4.36 へ）が ports へ到着していました。
早速、いつものように portupgrade -a で関連する ports を含めて一斉に更新を行なっておきました。
我が家では動作上の問題は無いように感じられました。
早速、いつものように portupgrade -a で関連する ports を含めて一斉に更新を行なっておきました。
我が家では動作上の問題は無いように感じられました。
2014年12月25日木曜日
FreeBSD Asterisk 1.8.32.1_3 へアップデート
FreeBSD の ports へ Asterisk のアップデート（1.8.32.1_2 から 1.8.32.1_3 へ）が到着していました。
portupgrade で更新を行なっておきました。
portupgrade で更新を行なっておきました。
 |
| Asterisk 1.8.32.1_3 のビルド・オプション |
2014年12月24日水曜日
FreeBSD 9.3 p7 (ntpd, freebsd-update) アップデート
Debian Wheezy では、すでに NTPD の脆弱性問題に対するアップデートが到着していました。我が家では FreeBSD のサーバで家庭内 LAN 向けの NTPD が稼働しており、外部に公開はしておりませんが、とても気になる脆弱性でした。この NTPD の脆弱性問題について FreeBSD ではどうなるのか気になっていましたが、ようやく NTPD の対策アップデートが到着しました。また NTPD と一緒に freebsd-update のアップデートも到着していました。
この二つのアップデートは、ソースツリーの更新の後、共にユーザーランドの再構築（make buildworld）で対策可能となっています。カーネルの再構築は必要ありませんが、私はいつものように一緒に再構築を行なっておきました。詳しくは上記公式ウェブサイトを参照ください。
20141223: p7 FreeBSD-SA-14:31.ntp
FreeBSD-EN-14:13.freebsd-update
Fix multiple vulnerabilities in NTP suite. [SA-14:31]
https://www.freebsd.org/security/advisories/FreeBSD-SA-14:31.ntp.asc
Fix directory deletion issue in freebsd-update. [EN-14:13]
https://www.freebsd.org/security/advisories/FreeBSD-EN-14:13.freebsd-update.asc
この二つのアップデートは、ソースツリーの更新の後、共にユーザーランドの再構築（make buildworld）で対策可能となっています。カーネルの再構築は必要ありませんが、私はいつものように一緒に再構築を行なっておきました。詳しくは上記公式ウェブサイトを参照ください。
システム・ソースツリーの更新
# svn update /usr/src
Updating '/usr/src':
U /usr/src/contrib/ntp/ntpd/ntp_proto.c
U /usr/src/contrib/ntp/ntpd/ntp_control.c
U /usr/src/contrib/ntp/ntpd/ntp_crypto.c
U /usr/src/contrib/ntp/ntpd/ntp_config.c
U /usr/src/contrib/ntp/util/ntp-keygen.c
U /usr/src/usr.sbin/freebsd-update/freebsd-update.sh
U /usr/src/UPDATING
U /usr/src/sys/conf/newvers.sh
Updated to revision 276176.
システムの再構築（再ビルド）
# cd /usr/src
# make buildworld && make buildkernel KERNCONF=MYKERNEL
# make installkernel
# make installworld
# reboot
注意
NTPD のバージョンを確認してみましたが、最新の 4.2.8 ではなく、アップデートの前後でバージョン番号（4.2.4p8）の変更はなかったようです。しかし上記のソースツリーの更新で確かにパッチが対応しているので、セキュリティ上これで問題ないようです。# ntpd --version
ntpd - NTP daemon program - Ver. 4.2.4p8
参考 URL
Network Time Protocol daemon (ntpd) に複数の脆弱性
http://jvn.jp/vu/JVNVU96605606/
2014年12月23日火曜日
FreeBSD PKG 1.4.1 へアップデート
FreeBSD の ports へ PKG のアップデート（1.4.0 から 1.4.1 へ）が到着していました。
パッケージ管理で大切なソフトウェアなので、すぐに portupgrade で更新を行なっておきました。
パッケージ管理で大切なソフトウェアなので、すぐに portupgrade で更新を行なっておきました。
ports-mgmt/pkg (pkg-1.4.0 -> pkg-1.4.1)
2014年12月22日月曜日
PCi GW-NS300N 無線 LAN アダプタ
一つ前の記事のバッファロー WLI-CB-AMG54HP に引き続き、プラネックス社の IEEE 802.11n 対応の GW-NS300N 無線 LAN アダプタもインターネット・オークションで入手しました。
本機は IEEE 802.11 b/g/n 対応となっています。コントローラチップに Lalink RT2800 が使用されているようです。ドライバには rt2800pci が適用されていました。
我が家には以前入手したロジテック社の LAN-WN23/CB がありますが、こちらもコントローラチップに RT2800 が使用されていて、同様の仕様となっています。
今回入手した GW-NS300N の転送速度の計測の比較として、上記の LAN-WN23/CB を使用してみました。
実験方法は FTP 転送で転送速度の計測を行なってみました。使ったノートパソコンは ThinkPad R51e を使用して、OS に Debian Wheezy の Gnome3 デスクトップの環境です。無線LANアクセスポイントは、Linksys 社の WRT150N (DD-WRT v24-sp2) を使用しました。転送速度の比較用として、LAN-WN23/CB も併せて計測しました。計測は、およそ 100MB のファイルをダウンロードした転送速度を五回計測して、その平均値を求めました。
なお今回の計測において、同じ性能と思われた二機種の転送速度に差が出たため、最初に計測した GW-NS300N は、後に計測を行った LAN-WN23/CB の計測の後に、再計測を行なってみました。これは同じ条件で計測を行なっていましたが、目に見えない無線環境に急変があったのではないかと想像しての処置でしたが、結果として GW-NS300N の計測結果に差が生じることはありませんでした。どうも今回計測した二機種には性能差があるようです。
以下は転送速度の計測結果です。
この結果を見る限り LAN-WN23/CB の方が、GW-NS300N より転送速度が速くなっています。lspci コマンドで表示される内容はどちらも同じ内容の "05:00.0 Network controller: Ralink corp. RT2800 802.11n PCI" です。少なくともコントローラ・チップ以降の部分は同じ内容となっているものと思われます。アンテナや無線回路の部分に違いがあるのでしょうか？ また無線LANアクセスポイントへ接続するときも GW-NS300N がなかなか接続できない症状が発生することがありました。この症状も転送速度が遅いことと何か関連があるのでしょうか？ そして転送速度の大きな違いは、単純な個体差なのか？ 設計・製造上の違いからくるものなのかは不明です。個人的な感想としては、GW-NS300N はあまりお薦めできる無線 LAN アダプタではなさそうです。
最後に、GW-NS300N と LAN-WN23/CB ともに、無線LANアダプタを使用中に抜き去ると、カーネルがハングアップしてしまいます。ドライバに問題があるのでしょうか。
 |
| プラネックス GW-NS300N の外観です。 |
本機は IEEE 802.11 b/g/n 対応となっています。コントローラチップに Lalink RT2800 が使用されているようです。ドライバには rt2800pci が適用されていました。
我が家には以前入手したロジテック社の LAN-WN23/CB がありますが、こちらもコントローラチップに RT2800 が使用されていて、同様の仕様となっています。
今回入手した GW-NS300N の転送速度の計測の比較として、上記の LAN-WN23/CB を使用してみました。
実験方法は FTP 転送で転送速度の計測を行なってみました。使ったノートパソコンは ThinkPad R51e を使用して、OS に Debian Wheezy の Gnome3 デスクトップの環境です。無線LANアクセスポイントは、Linksys 社の WRT150N (DD-WRT v24-sp2) を使用しました。転送速度の比較用として、LAN-WN23/CB も併せて計測しました。計測は、およそ 100MB のファイルをダウンロードした転送速度を五回計測して、その平均値を求めました。
なお今回の計測において、同じ性能と思われた二機種の転送速度に差が出たため、最初に計測した GW-NS300N は、後に計測を行った LAN-WN23/CB の計測の後に、再計測を行なってみました。これは同じ条件で計測を行なっていましたが、目に見えない無線環境に急変があったのではないかと想像しての処置でしたが、結果として GW-NS300N の計測結果に差が生じることはありませんでした。どうも今回計測した二機種には性能差があるようです。
 |
| 転送速度を比較計測した二機種の無線LANアダプタです。 左が GW-NS300N 右が LAN-WN23/CB です。 |
以下は転送速度の計測結果です。
GW-NS300N : 4,116 KB/s (32,929 Kbps) 計測一回目
LAN-WN23/CB : 5,467 KB/s (43,739 Kbps)
GW-NS300N : 4,047 KB/s (32,377 Kbps) 計測二回目
 |
| 転送速度の計測データ |
この結果を見る限り LAN-WN23/CB の方が、GW-NS300N より転送速度が速くなっています。lspci コマンドで表示される内容はどちらも同じ内容の "05:00.0 Network controller: Ralink corp. RT2800 802.11n PCI" です。少なくともコントローラ・チップ以降の部分は同じ内容となっているものと思われます。アンテナや無線回路の部分に違いがあるのでしょうか？ また無線LANアクセスポイントへ接続するときも GW-NS300N がなかなか接続できない症状が発生することがありました。この症状も転送速度が遅いことと何か関連があるのでしょうか？ そして転送速度の大きな違いは、単純な個体差なのか？ 設計・製造上の違いからくるものなのかは不明です。個人的な感想としては、GW-NS300N はあまりお薦めできる無線 LAN アダプタではなさそうです。
最後に、GW-NS300N と LAN-WN23/CB ともに、無線LANアダプタを使用中に抜き去ると、カーネルがハングアップしてしまいます。ドライバに問題があるのでしょうか。
Buffalo WLI-CB-AMG54HP 無線 LAN アダプタ
インターネット・オークションにて、バッファロー社の無線 LAN アダプタの WLI-CB-AMG54HP を入手しました。
バッファロー社の無線LANアダプタのうち、ハイパワー仕様（HP）の無線LANアダプタはこれで WLI-CB-G54HP に引き続き、二個目の入手となります。
この WLI-CG-AMG54HP は、IEEE 802.11 a/b/g 仕様となっています。このためなのか？どうかは不明ですが、アンテナ部分が大きくなっています。下記の写真は比較写真です。以前入手していた WLI-CB-G54HP もアンテナ部分が大きい印象がありましたが、それよりも大きなアンテナに圧倒されてしまいます（笑）。この大きさのおかげで無線の到達距離も伸びるのでしょうか？なお使用しているコントローラ・チップは BCM4318 でした。ドライバは b43 が適用されました。
さて気になる転送速度ですが、いつものように FTP 転送で転送速度の計測を行なってみました。使ったノートパソコンは ThinkPad R51e を使用して、OS に Debian Wheezy の Gnome3 デスクトップの環境です。無線LANアクセスポイントは、Linksys 社の WRT150N (DD-WRT v24-sp2) を使用しました。転送速度の比較用として、WLI-CB-G54HP (BCM4318) と WLI-CB-G54 (BCM4306) も併せて計測しました。計測は、およそ 100MB のファイルをダウンロードした転送速度を五回計測して、その平均値を求めました。
以下は転送速度の計測結果です。
意外なほどに横並びの結果となりました（笑）。 アンテナ部分や無線回路部分の違いは、転送速度自体には影響を与えていないようでした。ただ無線LANの受信状況を示すインジケータを見る限り、アンテナのマークの本数が多い分だけ受信状況が WLI-AMG54HP は良好であったようです。単純に無線LANの到達距離を伸ばすことを目的として、本機を使用することには、効果があるようです。
 |
| バッファロー WLI-CB-AMG54HP |
バッファロー社の無線LANアダプタのうち、ハイパワー仕様（HP）の無線LANアダプタはこれで WLI-CB-G54HP に引き続き、二個目の入手となります。
この WLI-CG-AMG54HP は、IEEE 802.11 a/b/g 仕様となっています。このためなのか？どうかは不明ですが、アンテナ部分が大きくなっています。下記の写真は比較写真です。以前入手していた WLI-CB-G54HP もアンテナ部分が大きい印象がありましたが、それよりも大きなアンテナに圧倒されてしまいます（笑）。この大きさのおかげで無線の到達距離も伸びるのでしょうか？なお使用しているコントローラ・チップは BCM4318 でした。ドライバは b43 が適用されました。
 | |
| アンテナ部分の突出量の比較です。 上から WLI-CB-AMG54HP WLI-CB-G54HP WLI-CB-G54 |
さて気になる転送速度ですが、いつものように FTP 転送で転送速度の計測を行なってみました。使ったノートパソコンは ThinkPad R51e を使用して、OS に Debian Wheezy の Gnome3 デスクトップの環境です。無線LANアクセスポイントは、Linksys 社の WRT150N (DD-WRT v24-sp2) を使用しました。転送速度の比較用として、WLI-CB-G54HP (BCM4318) と WLI-CB-G54 (BCM4306) も併せて計測しました。計測は、およそ 100MB のファイルをダウンロードした転送速度を五回計測して、その平均値を求めました。
 |
| 転送速度を計測した三種類の無線LANアダプタです。 左から WLI-CB-AMG54HP, WLI-CB-G54HP, WLI-CB-G54 |
以下は転送速度の計測結果です。
WLI-CB-AMG54HP : 2,272 KB/s (18.178 Kbps)
WLI-CB-G54HP : 2,143 KB/s (17.144 Kbps)
WLI-CB-G54 : 2,265 KB/s (18.127 Kbps)
 |
| 転送速度の計測データ |
意外なほどに横並びの結果となりました（笑）。 アンテナ部分や無線回路部分の違いは、転送速度自体には影響を与えていないようでした。ただ無線LANの受信状況を示すインジケータを見る限り、アンテナのマークの本数が多い分だけ受信状況が WLI-AMG54HP は良好であったようです。単純に無線LANの到達距離を伸ばすことを目的として、本機を使用することには、効果があるようです。
2014年12月18日木曜日
FreeBSD Perl 5.18.4_11 へアップデートと注意事項
FreeBSD の ports へ Perl 5.18.4_11 へのアップデートが到着していました。
アップデートは単純に portupgrade で更新を行なっておきました。ビルドとインストールした最後に次のセキュリティ警告が表示されていました。
さらに /usr/ports/UPDATING を確認してみると、Perl 5.** を使用しているユーザ宛に注意事項が届いていました。Perl 本体のアップグレードを行った時には、依存関係のある Perl のモジュールや ports の再ビルドが必要ですが、PKG を使ってバイナリ・アップグレードを行うときには、PKG がアップグレードを検出して再インストールしてくれるそうです。portupgrade や portmaster を使用している場合には、次のコマンド・スクリプトを実行することで、再ビルドの必要な ports を検出して、再ビルドができるそうです。PKG コマンドで再ビルドの必要な ports を検出して、portupgrade で再ビルドさせる手法のようです。詳しくは /usr/ports/UPDATING を確認してください。
Perl 5.18 ユーザは、次の方法で再ビルドすると時間の節約になるそうです。Perl 5.16 などの他のバージョンを使用している場合には、適宜変更が必要です。
アップデートは単純に portupgrade で更新を行なっておきました。ビルドとインストールした最後に次のセキュリティ警告が表示されていました。
Installing perl5-5.18.4_11...
===> SECURITY REPORT:
This port has installed the following files which may act as network servers and may therefore pose a remote security risk to the system.
/usr/local/lib/perl5/5.18/mach/CORE/libperl.so.5.18.4
さらに /usr/ports/UPDATING を確認してみると、Perl 5.** を使用しているユーザ宛に注意事項が届いていました。Perl 本体のアップグレードを行った時には、依存関係のある Perl のモジュールや ports の再ビルドが必要ですが、PKG を使ってバイナリ・アップグレードを行うときには、PKG がアップグレードを検出して再インストールしてくれるそうです。portupgrade や portmaster を使用している場合には、次のコマンド・スクリプトを実行することで、再ビルドの必要な ports を検出して、再ビルドができるそうです。PKG コマンドで再ビルドの必要な ports を検出して、portupgrade で再ビルドさせる手法のようです。詳しくは /usr/ports/UPDATING を確認してください。
20141217:
AFFECTS: users of lang/perl5.*
AUTHOR: mat@FreeBSD.org
Perl now links all .so it builds with libperl.so, it makes upgrading from one Perl major version to another way easier. For binary package users, it means pkg upgrade will detect the libperl.so.x.yy change, and reinstall the affected packages. For users using ports, it will save rebuild time as it's easier to detect what ports really need to be rebuilt.
Perl 5.18 ユーザは、次の方法で再ビルドすると時間の節約になるそうです。Perl 5.16 などの他のバージョンを使用している場合には、適宜変更が必要です。
Ports users are encouraged to rebuild ports that install files in SITE_ARCH.私個人としては、単純に portupgrade の "-r" オプションで Perl と依存関係のあるものを全て再ビルドしてしまう方が、後腐れなしで安心できるのではないかと思っています。今後もしばらくこの方法で処理する予定です。
If using Perl 5.18, run:
With portupgrade:
portupgrade -f `find /usr/local/lib/perl5/site_perl/mach/5.18 -name '*.so'|xargs pkg which -qo|sort -u`
With portmaster:
portmaster `find /usr/local/lib/perl5/site_perl/mach/5.18 -name '*.so'|xargs pkg which -qo|sort -u`
portupgrade -fr perl5
2014年12月17日水曜日
FreeBSD Subversion のアップグレード
FreeBSD の ports へ Subversion のアップグレード（1.8.10_3 から 1.8.11 へ）が到着していました。
いつものように portupgrade で更新をしておきました。カーネルのソースツリーの更新を Subversion で試してみましたが、問題なく動作しているようでした。ただし本日行われた「FreeBSD-SA-14:30.unbound」のセキュリティ・アップデートは、現在使用している FreeBSD 9.3 への適用ではないため、「更新なし」で終了しました。
いつものように portupgrade で更新をしておきました。カーネルのソースツリーの更新を Subversion で試してみましたが、問題なく動作しているようでした。ただし本日行われた「FreeBSD-SA-14:30.unbound」のセキュリティ・アップデートは、現在使用している FreeBSD 9.3 への適用ではないため、「更新なし」で終了しました。
devel/subversion (subversion-1.8.10_3 -> subversion-1.8.11)
2014年12月16日火曜日
FreeBSD Asterisk 1.8.32.1_2 へアップデート
FreeBSD の ports へ Asterisk 1.8.32.1_2 へのアップデートが到着していました。
いつものように portupgrade で更新を行なっておきました。
我が家では、動作上の問題はありませんでした。
いつものように portupgrade で更新を行なっておきました。
我が家では、動作上の問題はありませんでした。
 |
| Asterisk 1.8.32.1_2 のビルド・オプション |
2014年12月15日月曜日
ThinkPad A20m (2628-11J) を入手
インターネット・オークションにて ThinkPad A20m (2628-11J) を入手しました。この機種のポイントは、液晶パネルの大きさが 12.1 インチの 800x640 という SVGA サイズのものが搭載されていることです。そのため、ベゼルの部分がとても広くなっています（笑）。
簡単に表面を掃除して、動作確認をしてみました。問題なく動作しているようでした。
嬉しいことにメモリが 512MB （256NBx2枚）ほど搭載されていました。どうも前の所有者さんが増設を行なっていたようです。チップセットに i440BX が使用されている機種のため、この 512MB が最大搭載量となります。memtest86+ にてメモリ試験を行いましたが、問題ありませんでした。
ハードディスクには 6GB のもの（IBM DARA-206000）が取り付けられていました。どうやら元々搭載されていたものがそのまま残っていたようです。DriveFitnessTest や MHDD で検査をしてみましたが、カランカランと時折音を立ててしまいますが、問題はないようです。
次に LAN カードが収納されている部分の蓋を開いてみると CMOS 用のボタン電池が見えてきました。写真のように交換をしたようで、以前のボタン電池の接点からもぎ取り、テープで固定する方法となっていました。この方法 の場合、マシンの発熱などでテープが緩んで接触不良となる場合があるため、今後銅箔テープによる方法に変更したいと思っています。
そして残念だったのは、左奥のヒンジカバーが破損していることでした。掃除を行う機会があれば修理をしたいと思っています。
この ThinkPad A20m は手にするまでは、外観が似ている ThinkPad A22m と同じ筐体だと思っていました。しかし比較してみると随分と違っていました。どうも向かって左側の部分が A22m の場合広くなっているようで、フロッピードライブが奥まった位置になっています。フロッピーディスクを挿入した時に飛び出してくるイジェクト・ボタンが筐体に守られるようになっています。どうも A22m で改良が加えられた結果のようです。
そしてキーボードの上部にあるスピーカーの部分も A20m ではプラスチックの一体形成だったものが、A22m では、金属板をプレス加工したものが取り付けられていて、ちっとした高級感？が感じられるものとなっていました。
どうも筐体を分解した形跡が見当たらないため、内部にはかなりホコリや汚れが溜まっているものと思われます。今後、分解掃除をしたいと思っています。
 |
| 今回入手した ThinkPad A20m (2628-11J) です。 大きな筐体に似合わない 12.1 インチの液晶が搭載されていました。 |
簡単に表面を掃除して、動作確認をしてみました。問題なく動作しているようでした。
嬉しいことにメモリが 512MB （256NBx2枚）ほど搭載されていました。どうも前の所有者さんが増設を行なっていたようです。チップセットに i440BX が使用されている機種のため、この 512MB が最大搭載量となります。memtest86+ にてメモリ試験を行いましたが、問題ありませんでした。
 |
| 両面 16 チップのメモリが二枚搭載されていました。 |
 |
| memtest86+ でメモリ試験中の様子です。 |
ハードディスクには 6GB のもの（IBM DARA-206000）が取り付けられていました。どうやら元々搭載されていたものがそのまま残っていたようです。DriveFitnessTest や MHDD で検査をしてみましたが、カランカランと時折音を立ててしまいますが、問題はないようです。
 |
| 搭載されていた 6GB のハードディスク（DARA-206000）です。 |
次に LAN カードが収納されている部分の蓋を開いてみると CMOS 用のボタン電池が見えてきました。写真のように交換をしたようで、以前のボタン電池の接点からもぎ取り、テープで固定する方法となっていました。この方法 の場合、マシンの発熱などでテープが緩んで接触不良となる場合があるため、今後銅箔テープによる方法に変更したいと思っています。
 |
| ボタン電池は交換されていました。 古い電池の電極部分を引き剥がして、そのまま電極を流用した形でした。 |
そして残念だったのは、左奥のヒンジカバーが破損していることでした。掃除を行う機会があれば修理をしたいと思っています。
 |
| 左奥のヒンジカバーは破損しているようです。 |
この ThinkPad A20m は手にするまでは、外観が似ている ThinkPad A22m と同じ筐体だと思っていました。しかし比較してみると随分と違っていました。どうも向かって左側の部分が A22m の場合広くなっているようで、フロッピードライブが奥まった位置になっています。フロッピーディスクを挿入した時に飛び出してくるイジェクト・ボタンが筐体に守られるようになっています。どうも A22m で改良が加えられた結果のようです。
 |
| 上が A20m で、下が A22m のフロッピードライブ付近の様子です。 A22m のキーボードの脇の幅が一段と広くなっていました。 |
そしてキーボードの上部にあるスピーカーの部分も A20m ではプラスチックの一体形成だったものが、A22m では、金属板をプレス加工したものが取り付けられていて、ちっとした高級感？が感じられるものとなっていました。
 |
| 左が A22m で、右が A20m のスピーカー・グリルの様子です。 |
どうも筐体を分解した形跡が見当たらないため、内部にはかなりホコリや汚れが溜まっているものと思われます。今後、分解掃除をしたいと思っています。
2014年12月12日金曜日
Linux 用 Flashplayer がアップデート
今朝 Iceweasel ( Firefox ) で各ウェブサイトを閲覧していたところ、Flashplayer を使用しているサイトにて Flashplayer を阻止する（ブロックする）表示が現れました。Iceweasel の機能として Flashplayer の実行を阻止して、バージョンが古いと表示されるようになっているようです。
そこで Flashplayer のバージョンテストのサイトでバージョンを確認してみたところ、新しいバージョン（11,2,202,425）が登場していました。
早速新しいバージョンの Flashplayer をインストールしました。方法は新規に Flashplayer をインストールした時に表示されるのですが、メモをしていないと忘れてしまいます（笑）。以下の方法でアップデートが可能です。
アップデートが終了したら、Iceweasel を再起動させて、バージョンテストを行なって確認してください。
そこで Flashplayer のバージョンテストのサイトでバージョンを確認してみたところ、新しいバージョン（11,2,202,425）が登場していました。
http://www.adobe.com/jp/software/flash/about/
早速新しいバージョンの Flashplayer をインストールしました。方法は新規に Flashplayer をインストールした時に表示されるのですが、メモをしていないと忘れてしまいます（笑）。以下の方法でアップデートが可能です。
# update-flashplugin-nonfree --install
アップデートが終了したら、Iceweasel を再起動させて、バージョンテストを行なって確認してください。
# update-flashplugin-nonfree --install
--2014-12-12 09:14:37-- http://fpdownload.macromedia.com/get/flashplayer/pdc/11.2.202.425/install_flash_player_11_linux.i386.tar.gz
fpdownload.macromedia.com (fpdownload.macromedia.com) をDNSに問いあわせています... 23.207.114.70
fpdownload.macromedia.com (fpdownload.macromedia.com)|23.207.114.70|:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 6926590 (6.6M) [application/x-gzip]
`/tmp/flashplugin-nonfree.D7LSoreV0j/install_flash_player_11_linux.i386.tar.gz' に保存中
0K .......... .......... .......... .......... .......... 0% 1.01M 6s
50K .......... .......... .......... .......... .......... 1% 1.98M 5s
100K .......... .......... .......... .......... .......... 2% 2.47M 4s
↓↓↓6700K .......... .......... .......... .......... .......... 99% 2.18M 0s
6750K .......... .... 100% 3.66M=3.2s
2014-12-12 09:14:40 (2.07 MB/s) - `/tmp/flashplugin-nonfree.D7LSoreV0j/install_flash_player_11_linux.i386.tar.gz' へ保存完了 [6926590/6926590]
already exists: /usr/bin/flash-player-properties
already exists: /usr/share/applications/flash-player-properties.desktop
already exists: /usr/share/icons/hicolor/16x16/apps/flash-player-properties.png
already exists: /usr/share/icons/hicolor/22x22/apps/flash-player-properties.png
already exists: /usr/share/icons/hicolor/24x24/apps/flash-player-properties.png
already exists: /usr/share/icons/hicolor/32x32/apps/flash-player-properties.png
already exists: /usr/share/icons/hicolor/48x48/apps/flash-player-properties.png
already exists: /usr/share/pixmaps/flash-player-properties.png
2014年12月11日木曜日
Debian Wheezy に Icedove のアップデート
Debian Wheezy にメールクライアントの Icedove (Thunderbird) のアップデート（31.3.0）が到着していました。初期値では SSLv3 を無効化する対策が施されているようです。ただしセキュリティ上 危険ですが、必要があれば SSLv3 を有効化することも可能のようです。
その他 Xorg 関係のアップデートも一緒に行われました。
icedove (31.3.0-1~deb7u1) stable-security; urgency=low
Due to the BEAST vulnerability Icedove does not support SSLv3 encrypted connections by default any longer.
However you can still reactivate SSLv3 as described in README.Debian.
その他 Xorg 関係のアップデートも一緒に行われました。
FreeBSD 9.3 p6 アップデート
FreeBSD のシステムにセキュリティ・アップデート（p6）が到着していました。
私が使用している FreeBSD 9.3 では二点のアップデートとなりました。先日 Debian Wheezy でも BIND のアップデートがありましたが、この Debian のものと同じセキュリティ対策を行った模様です。
その他のバージョンでは、以下のアップデートもあるようです。
以上のアップデートでは、ユーザーランドの再ビルドを求めています。私の場合は、再ビルドの必要性はありませんがカーネルも合わせて再ビルドするようにしています。
# svn update /usr/src
Updating '/usr/src':
U /usr/src/UPDATING
U /usr/src/sys/conf/newvers.sh
U /usr/src/contrib/file/readelf.c
U /usr/src/contrib/file/elfclass.h
U /usr/src/contrib/file/softmagic.c
U /usr/src/contrib/bind9/lib/isccfg/namedconf.c
U /usr/src/contrib/bind9/lib/dns/include/dns/adb.h
U /usr/src/contrib/bind9/lib/dns/include/dns/resolver.h
U /usr/src/contrib/bind9/lib/dns/adb.c
U /usr/src/contrib/bind9/lib/dns/resolver.c
U /usr/src/contrib/bind9/bin/named/server.c
U /usr/src/contrib/bind9/bin/named/query.c
U /usr/src/contrib/bind9/bin/named/config.c
U /usr/src/contrib/bind9/CHANGES
Updated to revision 275693.
私が使用している FreeBSD 9.3 では二点のアップデートとなりました。先日 Debian Wheezy でも BIND のアップデートがありましたが、この Debian のものと同じセキュリティ対策を行った模様です。
20141210: p6 FreeBSD-SA-14:28.file
FreeBSD-SA-14:29.bind
Fix multiple vulnerabilities in file(1) and libmagic(3). [SA-14:28]
Fix BIND remote denial of service vulnerability. [SA-14:29]
FreeBSD-SA-14:28.file
https://www.freebsd.org/security/advisories/FreeBSD-SA-14:28.file.asc
FreeBSD-SA-14:29.bind
https://www.freebsd.org/security/advisories/FreeBSD-SA-14:29.bind.asc
その他のバージョンでは、以下のアップデートもあるようです。
FreeBSD-SA-14:27.stdio
https://www.freebsd.org/security/advisories/FreeBSD-SA-14:27.stdio.asc
以上のアップデートでは、ユーザーランドの再ビルドを求めています。私の場合は、再ビルドの必要性はありませんがカーネルも合わせて再ビルドするようにしています。
# cd /usr/src
# make buildworld && make buildkernel KERNCONF=MYKERNEL
# make installkernel
# make installworld
# make reboot
2014年12月10日水曜日
FreeBSD PKG 1.4.0 へアップグレード
FreeBSD の ports へパッケージ管理ソフトウェアの pkg のアップグレード（1.3.8_3 から 1.4.0 へ）が到着していました。
ここしばらく動きのなかった pkg の更新ですが、何か新しい機能を装備してのアップグレードのようです。
ここしばらく動きのなかった pkg の更新ですが、何か新しい機能を装備してのアップグレードのようです。
2014年12月9日火曜日
Debian Wheezy で カーネルと BIND のアップデート
Debian Wheezy にカーネルのアップデートと BIND のアップデートが到着していました。
アップデート・マネージャで通知を受けて、そのままアップデートを行いました。
カーネルも大切ですが、ネット上の名前の解決に必要不可欠な BIND の更新も是非行なっておきましょう。
アップデート・マネージャで通知を受けて、そのままアップデートを行いました。
カーネルも大切ですが、ネット上の名前の解決に必要不可欠な BIND の更新も是非行なっておきましょう。
YAMAHA RT56v を入手しました
ヤマハ社の VoIP 対応 ブロードバンド・ルータである RT56v をインターネット・オークションにて入手しました。
RT56v は、VoIP サーバの Asterisk に接続することができる ATA （アナログ・テレホン・アダプタ）機能を有しています。それもアナログ電話機が三台まで接続できるのです。ルータとしては、すでに時代遅れ機種ですが、この ATA 機能を目的として入手してきたわけです。
早速、入手した RT56v を家庭内の LAN へ接続した後、自宅サーバの Asterisk へ登録してみました。もちろんの事ですが、ちゃんと通話ができました。私が所有しているヤマハ製の他機種のルータ（RT57i と RTA55i）と同様に設定することができました。同じメーカの製品群なので、ユーザ・インターフェースがほぼ同じ設計となっていることに好感がもてました。
Asterisk 経由の VoIP 通信の通話音質は良好でした。ただ WAN 端子側で Asterisk サーバに接続していると、パケット・フィルタリングの処理の関係で、データの通信量が多い時には音声の遅延が発生することがありました。ただし RTA55i の時のように音声自体が途切れ途切れな感じに劣化することはありませんでした。この RT56v を ATA （アナログ・テレホン・アダプタ）として使用する人は、Asterisk サーバを LAN 端子側で通信するように設定する方が好ましいと思います。もちろん私のように単純に ATA 機能しか使用しない人にとっては、VoIP で使用するパケット通信量は限られていますので、WAN 端子側でも LAN 端子側でも通話に問題が出るとは思われません。
この RT56v の実力を知りたくて、通信転送速度を計測してみました。いつも行なっている無線 LAN アダプタの通信転送速度の計測と同じ手法で行いました。WAN 端子側から LAN 端子側へ FTP 転送でデータをダウンロードして、その通信転送速度を計測するものです。およそ 100MB のファイルを5回ダウンロードしてその平均値を求めました。参考として同じヤマハ社の RT57i と RTA55i を同じ環境で測定して比較してみました。結果は下記のとおりです。
RT56v は RTA55i とほぼ同じ通信転送速度となっていました。RT56v も RTA55i も2002年の発売だそうですので、同じ世代の設計ということなのでしょうか？ それに比較して、2003年に発売された RT57i は、さすがに高速化されたものとなっていました。
これでヤマハ社の VoIP 対応ルータのコレクションがまた一つ増えました（笑）。今後、RTA54i や RT58i を入手したいと思っています。
 |
| 今回入手した YAMAHA RT56v です。 |
 |
| RT56v の背面の様子です。 |
RT56v は、VoIP サーバの Asterisk に接続することができる ATA （アナログ・テレホン・アダプタ）機能を有しています。それもアナログ電話機が三台まで接続できるのです。ルータとしては、すでに時代遅れ機種ですが、この ATA 機能を目的として入手してきたわけです。
 |
| RT56v の背面の端子の様子です。 アナログ電話機が三台まで接続できる特徴があります。 |
早速、入手した RT56v を家庭内の LAN へ接続した後、自宅サーバの Asterisk へ登録してみました。もちろんの事ですが、ちゃんと通話ができました。私が所有しているヤマハ製の他機種のルータ（RT57i と RTA55i）と同様に設定することができました。同じメーカの製品群なので、ユーザ・インターフェースがほぼ同じ設計となっていることに好感がもてました。
Asterisk 経由の VoIP 通信の通話音質は良好でした。ただ WAN 端子側で Asterisk サーバに接続していると、パケット・フィルタリングの処理の関係で、データの通信量が多い時には音声の遅延が発生することがありました。ただし RTA55i の時のように音声自体が途切れ途切れな感じに劣化することはありませんでした。この RT56v を ATA （アナログ・テレホン・アダプタ）として使用する人は、Asterisk サーバを LAN 端子側で通信するように設定する方が好ましいと思います。もちろん私のように単純に ATA 機能しか使用しない人にとっては、VoIP で使用するパケット通信量は限られていますので、WAN 端子側でも LAN 端子側でも通話に問題が出るとは思われません。
この RT56v の実力を知りたくて、通信転送速度を計測してみました。いつも行なっている無線 LAN アダプタの通信転送速度の計測と同じ手法で行いました。WAN 端子側から LAN 端子側へ FTP 転送でデータをダウンロードして、その通信転送速度を計測するものです。およそ 100MB のファイルを5回ダウンロードしてその平均値を求めました。参考として同じヤマハ社の RT57i と RTA55i を同じ環境で測定して比較してみました。結果は下記のとおりです。
 |
| 通信転送速度を計測した三機種です。 左から RT56v, RT57i RTA55i です。 |
★ 通信転送速度の計測結果 ★
RT56v 1,031 KB/s ( 8,250 Kbps)
RT57i 11,322 KB/s (90,579 Kbps)
RTA55i 1,020 KB/s ( 8,165 Kbps)
測定条件：ルータの初期化を行い、特段のパケットフィルタリング処理などを行わず、WAN 側を自宅内 LAN へ DHCP 接続した上で、LAN 側に通信転送速度の計測用のパソコンを接続しました。
RT56v は RTA55i とほぼ同じ通信転送速度となっていました。RT56v も RTA55i も2002年の発売だそうですので、同じ世代の設計ということなのでしょうか？ それに比較して、2003年に発売された RT57i は、さすがに高速化されたものとなっていました。
これでヤマハ社の VoIP 対応ルータのコレクションがまた一つ増えました（笑）。今後、RTA54i や RT58i を入手したいと思っています。
2014年12月4日木曜日
Debian Iceweasel が 34.0 へアップグレード
すでに Windows 版では 34.0 へアップグレードしていた Firefox ですが、少し遅れること mozilla.debian.net のリポジトリ（Debian 向けの最新 Firefox）にも Iceweasel 34.0 が到着しました。
アップデート・マネージャでの通知で知り、そのままアップグレードを行いました。
新しい Iceweasel には OpenSSL 問題などへの対応がなされているそうで、より安心して使えるブラウザとなったようです。
アップデート・マネージャでの通知で知り、そのままアップグレードを行いました。
新しい Iceweasel には OpenSSL 問題などへの対応がなされているそうで、より安心して使えるブラウザとなったようです。
2014年12月3日水曜日
FreeBSD の Bash, Perl, OpenVPN がアップデート
今日は FreeBSD の ports へ重要ないくつかのアップデートが到着していました。
まだまだ Perl 5.18 は安定していないのかアップデートでした。そして Bash も久しぶりのアップデートでした。そして OpenVPN もアップデートがありました。以下は本日行ったアップデートの内容です。
まだまだ Perl 5.18 は安定していないのかアップデートでした。そして Bash も久しぶりのアップデートでした。そして OpenVPN もアップデートがありました。以下は本日行ったアップデートの内容です。
+ lang/perl5.18 (perl5-5.18.4_9 -> perl5-5.18.4_10)
+ shells/bash (bash-4.3.30 -> bash-4.3.30_1)
+ security/openvpn (openvpn-2.3.5_1 -> openvpn-2.3.6_1)
+ graphics/libexif (libexif-0.6.21_2 -> libexif-0.6.21_3)
2014年12月2日火曜日
WLAH-G54 のモデル名の変更
復活した WLAH-G54 ですが、ステータスのページのモデル欄には、今まであった WLAH-G54 ではなく、" Broadcom 3/0x042f/42/0x10/0x10 " という変な名前に切り替わっていました。どうも nvram の一部分の消去に伴うものと思われました。
そこで、このモデル名を再設定してみました。
WLAH-G54 へ telnet か ssh でログインした後、次のコマンドでモデル名の設定ができました。
名前の変更の確認は次のコマンドでできます。
[2014-12-03 訂正]
上記の方法では本体の電源を切るとモデル名が元に戻ってしまいます。
どうも上記の変な名前は、TomatoAnon Code （トマトアノン・コード）というものらしいのです。このコードからモデル名を限定して表記するようになっているらしく、コード表に無いものは TomatoAnon Code が直接表示される模様です。詳しくは参考 URL を参照してください。
そこで、このモデル名を再設定してみました。
WLAH-G54 へ telnet か ssh でログインした後、次のコマンドでモデル名の設定ができました。
# nvram set t_model_name="Buffalo WLAH-G54"
# nvram commit
名前の変更の確認は次のコマンドでできます。
# nvram get t_model_name動作には関係のない部分ですが、設定のページを開くたびに目に飛び込んでくるものですので、こうして変更しておくと気分的に気持ちのよいものです。
Buffalo WLAH-G54
[2014-12-03 訂正]
上記の方法では本体の電源を切るとモデル名が元に戻ってしまいます。
どうも上記の変な名前は、TomatoAnon Code （トマトアノン・コード）というものらしいのです。このコードからモデル名を限定して表記するようになっているらしく、コード表に無いものは TomatoAnon Code が直接表示される模様です。詳しくは参考 URL を参照してください。
Understanding " Tomatoanon"
http://www.linksysinfo.org/index.php?threads/understanding-tomatoanon.69043/
Buffalo WLAH-G54 が Shibby 版 Tomato ファームウェアで復活
本当に読者さんには感謝しています！
当ブログの掲示板へ WLAH-G54 が起動不良になったことへの対策を読者さんが投稿してくださり、これをヒントにして WLAH-G54 が復活しました。それも起動できないと思っていた Shibby 版の Tomato ファームウェアで立ち上がりました。
掲示板への投稿ではシリアルコンソールのつなぎ方が示されていました。それも画像つきです。これを参考にしてシリアル接続のためのピンヘッダなどを取り付けました。そして USB 接続のシリアルケーブル（PL2303HX）をパソコンと接続して WLAH-G54 と通信することに成功しました。
以下の写真は WLAH-G54 の分解とシリアル接続のための加工の様子です。
シリアルコンソールへの接続ソフトウェアは、パソコンのシステムが Debian であったため、cu で行いました。この辺のことは以前の fon2405 の投稿記事へ記述した方法と一緒です。
接続して電源を投入すると文字化けした表示が流れて行く状態でした。初期値の 9600 bps から順番に変化させて、ようやく発見した接続速度は 115,200 bps でした。Debian の仮想端末上から次のコマンドで接続しました。
そしてシリアルコンソール上に表示されたのは PMON という BIOS でした。ネット上を検索してみると PMON のマニュアルが存在していました。"h" でヘルプが表示され、各コマンドの取り扱いが示されます。ただし WLAH-G54 に搭載されていた PMON はバッファローでカスタマイズされたものでした。コマンドの数が少なく、そして "melco" というコマンドが追加されていました。
"set" コマンドで、現在登録されている変数と数値が表示されます。この "set" コマンドを実行すると仮想端末の初期値で設定していた 512 行を超える変数が流れて行きました。そこで 1024 行にしてみましたが、まだ全部表示することが出来ず、さらに 2048 行に設定してようやく全貌を見ることができました。結局 1778 行の変数が存在していました。
この中から ipaddr の文字列を持つ変数を探しだしては、 IP アドレスをメモしておきました。かつて DD-WRT で使用していた時に設定していた IP アドレス類を次々に発見することができました。どうも lan_ipaddr （192.168.*.*）へ稼働中の IP アドレスが記録され、ini_ipaddr （1.1.1.1)へ TFTP の IP アドレスが記録されているようでした。
しかし現在設定されている lan_ipaddr や ini_ipaddr の値で TFTP 経由でファームウェアを読みこませることが出来ないのは確認済みで、さらに今回も同様に TFTP でファームウェアを送り込むことができませんでした。そこで先程メモしていた IP アドレスで次々と TFTP でファームウェアを読みこませようとしましたが、どれも成功しませんでした。
ここでお手上げ状態となってしまいました。
そこで再度起動直後に表示されるメッセージを詳しく観察してみると、一番最後に表示される案内に目が留まりました。それは・・・ " failed to retrieve os dl addr " というものです。これをキーワードにしてネット上を検索してみると、バッファローの WZR-RS-G54 の事例を発見しました。
この参考ページにはマザーボードの画像もあり、それが WLAH-G54 と同じもので、部品の搭載の仕方が異なっているだけのものでした。そして上記の " failed to retrieve os dl addr "のキーワード部分には、解決のためのヒントがありました。どうも nvram に記録されている変数の一部が衝突を起こしているようで、問題となる部分の内容を消去する （nvErase） と解決するとありました。早速実行してみました。
コマンド実行と共にシリアルコンソール上をメモリ消去している案内が流れて行きました。終了したところで WLAH-G54 を再起動させてみました。
すると今までとは違った内容がシリアルコンソール上に表示されました。このシリアルコンソール上に 192.168.1.1 の IP アドレスが表示されていたこともあり、パソコン上からブラウザで 192.168.1.1 へアクセスしてみたところ、何と！ Shibby 版の Tomato ファームウェアへアクセスすることができました。書き換えが失敗していたと思っていた Shibby 版の Tomato ファームウェアですが、ちゃんと書き換えが成功しており、ちゃんと動作していました。なおログイン・パスワードなどは DD-WRT 時代に設定していたものが残っていました。
WLAH-G54 上で動作している Shibby 版 Tomato ファームウェアですが、DIAG の LED ランプが赤色に点灯したままなど、きっちりと正常に動作しているのかまだ不明な状態です。これから動作確認などを行ってみたいと思っています。
当ブログの掲示板へ WLAH-G54 が起動不良になったことへの対策を読者さんが投稿してくださり、これをヒントにして WLAH-G54 が復活しました。それも起動できないと思っていた Shibby 版の Tomato ファームウェアで立ち上がりました。
 |
| 起動不良となっていた バッファロー WLAH-G54 です。 |
Buffalo WLAH-G54 が起動不良へ
http://near-unix.blogspot.jp/2014/07/buffalo-wlah-g54.html
掲示板への投稿ではシリアルコンソールのつなぎ方が示されていました。それも画像つきです。これを参考にしてシリアル接続のためのピンヘッダなどを取り付けました。そして USB 接続のシリアルケーブル（PL2303HX）をパソコンと接続して WLAH-G54 と通信することに成功しました。
以下の写真は WLAH-G54 の分解とシリアル接続のための加工の様子です。
 |
| WLAH-G54 の筐体を開いてマザーボードを取り出したところです。 発熱の大きなチップの熱を放熱する工夫がされていました。 |
 |
| マザーボードの裏側の様子です。 ピンヘッダのハンダ付けはこちらがわから行うために取り外しました。 |
 |
| 加工前のシリアル接続部分の様子です。 IC8 に TTL-RS232C のレベル変換のチップを搭載すれば RS232C で送受信ができるようになります。 しかしここでは、直接 TTL レベルで信号のやり取りをします。 |
 |
| IC8 の #7-#8 と #11-#12-#13 をハンダブリッジで接続します。 そして信号を取り出すピンヘッダも取り付けました。 左から GND, NC, Rx, Tx となります。 |
 |
| シリアル-USB 変換IC の PL2303HX が搭載されたケーブルをピンヘッダへ接続したところです。 |
 |
| マザーボードの Tx には、ケーブルの Rx を マザーボードの Rx には、ケーブルの Tx を マザーボードの GND には、ケーブルの GND を接続します。 |
シリアルコンソールへの接続ソフトウェアは、パソコンのシステムが Debian であったため、cu で行いました。この辺のことは以前の fon2405 の投稿記事へ記述した方法と一緒です。
FON2405E へ改造ファームウェアを導入
http://near-unix.blogspot.jp/2014/09/fon2405e.html
接続して電源を投入すると文字化けした表示が流れて行く状態でした。初期値の 9600 bps から順番に変化させて、ようやく発見した接続速度は 115,200 bps でした。Debian の仮想端末上から次のコマンドで接続しました。
# cu -l /dev/ttyUSB0 -s 115200
そしてシリアルコンソール上に表示されたのは PMON という BIOS でした。ネット上を検索してみると PMON のマニュアルが存在していました。"h" でヘルプが表示され、各コマンドの取り扱いが示されます。ただし WLAH-G54 に搭載されていた PMON はバッファローでカスタマイズされたものでした。コマンドの数が少なく、そして "melco" というコマンドが追加されていました。
pmonシリアルコンソール上に表示された内容は次のとおりです。長いので一部分だけ抜粋です。
http://www.mbernstein.de/agenda/pmon.htm
Connected.
Flash type "TC58FVM6T2AFT65 8Mx8 TopB"
Main(bc7f8000) NVRAM is good
Sub(bc7e8000) NVRAM is good
** There is a difference in Main and Sub.
dst=bc7e8000 src=bc7f8000 len=32768
Erase of block 0x007e0000-0x007f0000 done
Writing 0x8000 bytes to flash @0xbc7e8000 ...
↓
PMON 3.51.5.0-MEL1.0_005
failed to retrieve os dl addr
PMON>
"set" コマンドで、現在登録されている変数と数値が表示されます。この "set" コマンドを実行すると仮想端末の初期値で設定していた 512 行を超える変数が流れて行きました。そこで 1024 行にしてみましたが、まだ全部表示することが出来ず、さらに 2048 行に設定してようやく全貌を見ることができました。結局 1778 行の変数が存在していました。
この中から ipaddr の文字列を持つ変数を探しだしては、 IP アドレスをメモしておきました。かつて DD-WRT で使用していた時に設定していた IP アドレス類を次々に発見することができました。どうも lan_ipaddr （192.168.*.*）へ稼働中の IP アドレスが記録され、ini_ipaddr （1.1.1.1)へ TFTP の IP アドレスが記録されているようでした。
しかし現在設定されている lan_ipaddr や ini_ipaddr の値で TFTP 経由でファームウェアを読みこませることが出来ないのは確認済みで、さらに今回も同様に TFTP でファームウェアを送り込むことができませんでした。そこで先程メモしていた IP アドレスで次々と TFTP でファームウェアを読みこませようとしましたが、どれも成功しませんでした。
ここでお手上げ状態となってしまいました。
そこで再度起動直後に表示されるメッセージを詳しく観察してみると、一番最後に表示される案内に目が留まりました。それは・・・ " failed to retrieve os dl addr " というものです。これをキーワードにしてネット上を検索してみると、バッファローの WZR-RS-G54 の事例を発見しました。
WZR-RS-G54 Bricked/DeBricked via serial console
http://www.dd-wrt.com/phpBB2/viewtopic.php?t=11279
この参考ページにはマザーボードの画像もあり、それが WLAH-G54 と同じもので、部品の搭載の仕方が異なっているだけのものでした。そして上記の " failed to retrieve os dl addr "のキーワード部分には、解決のためのヒントがありました。どうも nvram に記録されている変数の一部が衝突を起こしているようで、問題となる部分の内容を消去する （nvErase） と解決するとありました。早速実行してみました。
Buffalo WHR-G54S reverted to defaults automatically
http://www.dd-wrt.com/phpBB2/viewtopic.php?p=24604
PMON> nvErase 0xbc7e0000 0x20000
Erase of block 0x007e0000-0x007f0000 done
Erase of block 0x007f0000-0x007f2000 done
Erase of block 0x007f2000-0x007f4000 done
Erase of block 0x007f4000-0x007f6000 done
Erase of block 0x007f6000-0x007f8000 done
Erase of block 0x007f8000-0x007fa000 done
Erase of block 0x007fa000-0x007fc000 done
Erase of block 0x007fc000-0x007fe000 done
Erase of block 0x007fe000-0x00800000 done
コマンド実行と共にシリアルコンソール上をメモリ消去している案内が流れて行きました。終了したところで WLAH-G54 を再起動させてみました。
すると今までとは違った内容がシリアルコンソール上に表示されました。このシリアルコンソール上に 192.168.1.1 の IP アドレスが表示されていたこともあり、パソコン上からブラウザで 192.168.1.1 へアクセスしてみたところ、何と！ Shibby 版の Tomato ファームウェアへアクセスすることができました。書き換えが失敗していたと思っていた Shibby 版の Tomato ファームウェアですが、ちゃんと書き換えが成功しており、ちゃんと動作していました。なおログイン・パスワードなどは DD-WRT 時代に設定していたものが残っていました。
 |
| TFTP 経由でファームウェアの流し込みを行なっていた様子です。 TFTP での流し込みは成功しませんでした。 |
 |
| WLAH-G54 上で動作している Shibby 版 Tomato ファームウェアの設定画面です。 |