帰って来たThinkpadX61

Thinkpad X61ワイヤレスLAN接続トラブルその後のその後。

修理センターに預けることにしたが、デバイスドライバ入れ替えておいてくれ、というオーダーは修理センターでは受けられないとの事。その変わり、「修理の際に技術担当から状況を連絡させます」という約束をいただいた。

ところが！

夏休みの帰省から自宅に戻ってみると、PC変換の不在票がポストに。徐に配送業者に連絡して、PCが返って来た。返って来たPCには「サービス報告書」なるものが添付されていた。

障害状況：間欠障害でリカバリー後でも無線接続が不安定。

修理内容：ご報告の無線LAN接続障害は長時間の無線LANネットワーク接続を行いましたが再現が出来ませんでした。障害記述から無線LANカードの交換を行いました。各種機能テストにて正常稼働を確認しております。

とまあ、いちばん避けたかった結果に。笑えねえよ。そうなるのが容易に想像できたから技術担当から連絡させろっつったのに。で、PC起動したら当り前のようにドライバはバージョンアップされないまま障害再現と。

最早半ギレでスマートセンターにTEL。状況を説明し、修理センターに再度問い合わせ。

一応履歴にそのような連絡をさせるという記載が残っていたようで、平謝りされる。

相当に頭に来ていたものの、接続障害が解決されないと謝られてもしょうがないので、スマートセンターに再度障害解決に付き合ってもらうことにした。こうなりゃトコトンですわ。

電話口でいろいろ確認してみたものの、やはり状況が改善しないため、先方から以下の提案が。

• Access Connectionsを使用しないで接続してみる
• Windows XP Service Pack3(SP3)を適用しない

いずれも報告例があるらしい。Access Connectionsを使用しないのであれば、ドライバのアップデートは不要のはずとの事。また、問題の切り分けとしても、Windowsがおかしいのか、ドライバがおかしいのか、Access Connectionsに異常があるのか判明しやすいとの事。まあこれは極めて合理的だわな。

という訳で、Windowsリカバリするところから再挑戦。おいおい。何度リカバリさせるんだ。。。もう手慣れたもんですわ（泣）。んで、Access Connectionsをアンインストール。

アンインストール後再起動して、コントロールパネルからアクセスポイント検索して、WEPキーを入力、、と。で、しばらく疎通観察してみたら、

接続速度の表示が断続的に変化して、

• 54.0Mbps / MACアドレスは親機のMACアドレスが表示→接続状態。
• 150.0Mbps / MACアドレスは00:00:00:00:00:00に表示→切断状態

が繰り返されることに。

がWindowsの接続でも再現！！なんなんだいったい。。。

で昨日はここまででタイムアップ。。しかも、今日（2008/8/10（日））は第2日曜日なのでスマートセンターはお休み。またも一週間塩漬け。いい加減にしてくれ。

ひとまずここまでのまとめ。

• 無線LANカード交換しても再現することから、HWのせいではない
• 他の無線LANクライアントでは再現しないことから、親機のせいである可能性は低い
• Access Connectionsは関係ない
• ドライバの更新は完了していないことから、バージョンが古いことに起因している可能性は否めない

ってことか。そろそろキツいな。。技術的にもそうだけど、手間がかかってしょうがない。

ていうかCardBus用無線子機買った方が早いかなー。。

DBIx::Class導入時Perlアップデート

CentOS5.1の環境にて、CatalystのためのO/RマッパーにDBIx::Class導入したとき、

WARNING: DBIx::Class::StartupCheck: This version of Perl is likely to exhibit
extremely slow performance for certain critical operations.
Please consider recompiling Perl.  For more information, see
https://bugzilla.redhat.com/show_bug.cgi?id=196836 and/or
http://lists.scsys.co.uk/pipermail/dbix-class/2007-October/005119.html.
You can suppress this message by setting DBIC_NO_WARN_BAD_PERL=1 in your
environment.

と散々言われた。おそらくワーニングのとおり環境変数にDBIC_NO_WARN_BAD_PERL=1をセットすればいいんだろうが、パフォーマンス悪くなるとかいうのが気になったのでググってみたらいろいろ出てきたのでメモ。

kazeburoさんやYappoさんが言ってたRed Hat系のディストリビューションのPerlのパッケージにはoverloadされたクラスをblessするとリファレンスを全て検索するパッチがあてられていて遅いので注意してねって感じですか。

hide-k.net#blog: CentOSでDBIC最新版を使うときの注意

要は、CentOSのRPM版Perl使用すると、余計なパッチが当たってしまっているので、以下のとおり除外したものを使え、とのこと。

FedoraがあてたPatch

• perl-5.8.8-U27509.patch
• perl-5.8.8-U27512.patch

が原因なのでspecファイルいじってrebuild

kazeburo : FC5 FC6でPerlが遅い問題

さらによく読み進めると結構深刻な問題なようで、use overload; してblessしたモジュールが覿面にパフォーマンス低下するようで。

とこのuse overload;って初見だったんだけど、Perlって演算子のオーバーロードができるんだね。

• http://search.cpan.org/~rgarcia/perl-5.10.0/lib/overload.pm
• http://perldoc.jp/docs/perl/5.6.1/overload.pod

…知らなかった。こんなのもあるのかー。

というわけで、CentOSの該当SRPMバラして、SPECファイル修正してPerlのRPMをリビルド。

 $ wget ftp://ftp.iij.ad.jp/pub/linux/centos/5/updates/SRPMS/perl-5.8.8-10.el5_2.3.src.rpm
 $ rpm -ivh perl-5.8.8-10.el5_2.3.src.rpm
 $ cd SPECS
 $ vim perl.spec

--- perl.spec.bak       2008-06-05 21:01:41.000000000 +0900
+++ perl.spec   2008-08-05 17:46:06.000000000 +0900
@@ -5,7 +5,7 @@
 %define multilib_64_archs x86_64 s390x ppc64 sparc64
 
 %define perlver    5.8.8
-%define perlrel    10%{?dist}.3
+%define perlrel    10%{?dist}.3nooverloadpatch
 %define perlepoch  4
 
 %{?!perl_debugging:    %define perl_debugging 0}
@@ -160,8 +160,8 @@
 Patch27116:    perl-5.8.8-U27116.patch
 Patch27391:     perl-5.8.8-U27391.patch
 Patch27426:    perl-5.8.8-U27426.patch
-Patch27509:     perl-5.8.8-U27509.patch
-Patch27512:     perl-5.8.8-U27512.patch
+#Patch27509:     perl-5.8.8-U27509.patch
+#Patch27512:     perl-5.8.8-U27512.patch
 Patch27604:     perl-5.8.8-U27604.patch
 Patch27605:     perl-5.8.8-U27605.patch
 Patch27914:     perl-5.8.8-U27914.patch
@@ -370,9 +370,9 @@
 
 %patch27426 -p1
 
-%patch27509 -p1
+#%patch27509 -p1
 
-%patch27512 -p1
+#%patch27512 -p1
 
 %patch27604 -p1

 $ rpmbuild -ba perl.spec

これで、RPMS/i386以下に

• perl-5.8.8-10.3nooverloadpatch.i386.rpm
• perl-debuginfo-5.8.8-10.3nooverloadpatch.i386.rpm
• perl-suidperl-5.8.8-10.3nooverloadpatch.i386.rpm

ができあがりー。

このうち

• perl-5.8.8-10.3nooverloadpatch.i386.rpm

をインストール。

 $ sudo rpm -Uvh perl-5.8.8-10.3nooverloadpatch.i386.rpm

2008/10/30追記：

CentOS5.2にしたらPerlのパッケージバージョンがperl-5.8.8-15.1にあがってた。。

ChangeLog読んだら、この周りの対応がされてたっぽい。

* Thu Aug 28 2008 Marcela Maslanova <mmaslano@redhat.com> - 4:5.8.8-15.el5.1
- add upstream fix for bless/overload problem (changes 31996,32018,32019,
        32025) and perl-5.8.8-bug24254.patch. Without this patch had bless
        poor performance.
- Resolves: rhbz#460308

なので、そのままDBIx::Classで怒られなくなると思いきや、やっぱり怒られる。(T_T)

しょうがないので、関連するパッチを一切合財排除。

• Patch27509: perl-5.8.8-U27509.patch
• Patch27512: perl-5.8.8-U27512.patch
• Patch24254: perl-5.8.8-bug24254.patch
• Patch31996: perl-5.8.8-U31996.patch
• Patch32018: perl-5.8.8-U32018.patch
• Patch32019: perl-5.8.8-U32019.patch
• Patch32025: perl-5.8.8-U32025.patch

大元のパッチ（27509,27512）はupstream changesの組み込みということなのである程度意味があるんだろうが。。うーん…。

長距離ドライブで感じたこと。

今日から夏休みで東京から実家の福井まで帰省した。交通手段をちと悩んだんだけど７か月半の乳児がいることと、コストを抑える目的で自家用車で帰ることにした。

距離で約550km。原油高で車の使用を控える人が多いというが、通常の国産車の燃費を考えると、10km/lとしても、燃料にして55l。リッター単価185円としても片道10,175円。さらに高速道路もETC深夜割引を利用すると片道6,300円で家族で約16,500円。飛行機や鉄道を利用すると一人で片道14,000円近くかかることを考えると、まだまだリーズナブル。もちろん運転はしんどいけどね。。。

まだUターンラッシュの時期にはまだ早いことと、未明から運転したことで道路も渋滞もなくスムーズ。その道路を走ってていろいろ考えた。

まずこの原油高で、今年の渋滞は比較的酷くないのではないかと思う。さらに、現在の価格は突発的なものとしても、新興国の需要を考えると、トレンドとして長期的に値上がりするのは確実。

さらに若年層の非正規雇用が増えたり、少子高齢化が進むことで、こちらも長期的に収益力が低くなり、購買意欲が低くなることが容易に想像できる。

実際に乗用車の販売台数も既に厳しくなっている。

てことは新車市場も中古車市場も含めて必然的に価格も下落するはず。

「下取り時に高値で売れる」という理由で、海外の高級車を（がんばって？なのかどうかは分からないが）購入した友人がいるけれども、おそらくここ数年で全面的な価格の下落が予想できることを考えると、それほど高値で売れるとは限らないんじゃないかなぁ？

もちろん大衆車の市場と高級車市場でトレンドが異なる面はあるかもしれないけど。でも従来のように乗用車に資産価値を求めるのは危険なんじゃないかな？と思った。これからの時代、乗用車というものを考えるにあたり、あくまで小さい子供がいる家庭などに利便性を供与する消費財である、として割り切って考えるのがこれからの主流になっていくのではないかなぁ？と考えてみた。

Catalystでモバイルサイト開発に挑戦してみることにした。

• Catalyst初心者
• DBIx::Classは多少単独で使ったことがある
• HTML::Templateは使ったことあるけどTemplate::Toolkitは未経験
• Encode::JP::Mobileは大体理解した
• Ruby on Railsはがっつり開発したことはないが概念くらいは知ってる

という条件で、今月中くらいでモバイルサイトを開発してみることになった。果たしてできるのか？！

既存のオリジナルフレームワークはあるんだけど、どこかで一念発起してトレンドを吸収しておかないとね。

まるごとPerl! Vol.1

この本と、ITproの記事をテキスト代わりに、Catalyst::Manualを傍らにナメていけばそれなりに吸収できるかな。

と、思っていたら、この辺りの記事は古いのね。。

Catalyst::Plugin は、現在では*基本的に*利用/開発が推奨されていません。おりしも、この記事が公開される数日前に
CatalystCon#1 が開催され、Catalyst::Plugin のあり方について周知しようという Perl Mongers の動きがあった中で、
このようなふるい記事がでたこともあって、タイミングが悪かったというところもあります。

＃ Perl がよくわからない人のために解説しておくと、2008年に gets(3) を使うサンプルコードが公開されたようなもの

そろそろ日経LinuxがDISられた理由について解説しておくか - TokuLog 改めB日記

えええ、じゃーまるで役に立たないの？

そのへんの事情は http://search.cpan.org/dist/Catalyst-Manual/lib/Catalyst/Manual/ExtendingCatalyst.pod#Plugins にのってるよ。

そろそろ日経LinuxがDISられた理由について解説しておくか - TokuLog 改めB日記

ふむふむ。という訳で該当箇所をよく読んでみよう。

The first thing to say about plugins is that if you're not sure if your module should be a plugin,
it probably shouldn't. It once was common to add features to Catalyst by writing plugins that provide
accessors to said functionality. As Catalyst grew more popular, it became obvious that this qualifies as bad practice.

By designing your module as a Catalyst plugin, every method you implement, import or inherit will be
available via your applications context object. A plugin pollutes the global namespace, and you should be
only doing that when you really need to.

Catalist::Manual::ExtendingCatalyst

なるほど。プラグインで公開すると、グローバルの名前空間に置かれるんだけど、Catalystがポピュラーになるにつれて衝突する可能性が高いから、本当に必要なときのみ使えってか。

その他にもBEST PRACTICE#Namespacesのあたりにも、

• Catalist::*の名前空間はコア拡張で使用してるから、可能ならCatalystX::*名前空間を使用しなさい
• モジュールのロードの際トラブルの元になるので、MyApp::Controller::Fooみたくモデルやコントローラー・ビューにベースクラスをMyAppディレクトリ以下に直接置かずに、MyApp::Base::Controller::* や MyApp::ControllerBase::* みたいな名前空間を使いなさい

とか書いてあるね。

でも逆を返せばこれらだけ気をつければ前述の本やITproの記事はそこそこ参考になりそうだ。

それにしても・・Ruby on Railsとかもそうだったけど、仕様の陳腐化が早いなぁ・・Railsは本まで出てるのに、今売ってるのじゃ既に古すぎたりするし。

社内でスキルの拙いメンバーに積極的に使わせて開発を進捗していくのはまだまだひと苦労もふた苦労もありそうだなーー。。。

Class::Delegateが便利だったのでメモ。

PerlのOOは必ずしもよくできてるとは言い難いけど、「使える範囲で十分に」書ける。これは決して悪いことじゃないし、Perlの良いところであり僕も好きな点なんだけど、コンストラクタについてはピンと来ない場合がある。

社内のフレームワークでHTML::Templateを継承していたクラスがあった。そのコンストラクタ内が以下のようになっていた。*1

package HogeHoge;

use base q/HTML::Template/;

sub new {
    my ($class, $filename) = @_;
    $class = ref($class) if ( ref($class) );

    # HTML::Templateのタグを変更.
    # 詳細は perldoc HTML::Templateでfilterを検索.
    my $filter = sub {
        # フィルタ関数
        # ...
    };

    # $pathを決定する
    # ...
  
    # HTML::Template生成.
    my $self ={};
    eval {
        $self = $class->SUPER::new(path             => $path,
                                  filename          => $filename,
                                  die_on_bad_params => 0,
                                  filter            => $filter,  
                                  loop_context_vars => 1);
    };

    if($@) {
        # エラー処理
        # ...
    }

    return bless $self, $class;
}

要は、

use HogeHoge;

my $template = HogeHoge->new('somepage.html');
$template->param(price => '19,800');
$template->output;

するのを想定してる設計。

それまではそれなりに動いていたんだけど、これだと気持ちが悪い。なぜなら、

        $self = $class->SUPER::new(path             => $path,
                                  filename          => $filename,
                                  die_on_bad_params => 0,
                                  filter            => $filter,  
                                  loop_context_vars => 1);

して返ってくるオブジェクトは、HTML::Templateの内部を知らない限りハッシュリファレンスかどうかは分からないので、HogeHogeクラスで新しいフィールドを追加しようとして

    $self->{logger} = $logger;

などとできない。もちろんやって動くかもしれないけど、そもそもHTML::Templateクラスはそんな使われ方は想定していないから、不慮の現象が起こらないとも限らないだろう。

そもそもHogeHogeクラスの設計として、HTML::Templateを継承するというのは不適切で、Has-aとするのが適切なんじゃないかしら？と思ったんだけど、HTML::Templateを継承しないで、HogeHogeクラスのフィールドとしてそのインスタンスを持つようにすると、既存のコードでHogeHogeクラスがHTML::Templateのサブクラスとして呼び出しているメソッド（param()とか）を逐一HogeHogeクラスで実装して、対応するHTML::Templateインスタンスにパスして透過的にアクセスできるようにしてやらなくちゃならない。また、現状呼び出されるメソッドが限定されていればよいけど、今後HogeHogeクラスを通してHTML::Templateの異なるメソッドを使用したかったら、逐一実装する必要がある*2。これはイケてない。

どちらかといえば委譲がすんなり行くのでは、ということでCPANを彷徨い歩いたら、ありました。

Class::Delegateモジュール。

Class::Delegate - easy-to-use implementation of object delegation.

Class::Delegateのpodより

詳細はpodに譲るとして、以下のような使い方ができるらしい。

#!/usr/bin/perl

# Class::Delegateのテスト

package My::Base;

sub new {
    my $class = shift;
    $class = ref($class) if ( ref($class) );
    return bless {}, $class;
}

sub a {
    print "My::Base#a called.\n";
}

sub b {
    print "My::Base#b called.\n";
}

package My::Delegated;

use base qw( Class::Delegate ); # My::Baseではなく、Class::Delegateを継承

sub new {
    my $class = shift;
    $class = ref($class) if ( ref($class) );

    my $base = new My::Base;
    my $self = { base => $base };
    bless $self, $class;

    $self->add_delegate($base); # My::Delegatedにないメソッドは$baseに委譲する

    return $self;
}

sub a {
    my $self = shift;
    my $base = $self->{base};
    print "My::Delegated#a called. \n";
}

# sub b is not defined.

package main;

my $d = new My::Delegated;
$d->a; # My::Delegated#aが呼ばれる
$d->b; # $dがDelegateしているMy::Base#bが呼ばれる

そして出力：

My::Delegated#a called. 
My::Base#b called.

メソッドaはMy::Delegateクラスで有しているので、そのまま呼び出されるけど、メソッドbはMy::Delegateに実装がないので、委譲しているMy::Baseのインスタンスのメソッドが呼ばれる。

という訳で、HogeHogeは以下のように書き換え。

package HogeHoge;

use HTML::Template;

use base qw( Class::Delegate );

sub new {
    my ($class, $filename) = @_;

    # HTML::Templateのタグを変更.
    # 詳細は perldoc HTML::Templateでfilterを検索.
    my $filter = sub {
        # フィルタ関数
        # ...
    };

    # $pathを決定する
    # ...
  
    # HTML::Template生成.
    my $template;
    eval {
        $template = HTML::Template->new(path              => $path,
                                        filename          => $filename,
                                        die_on_bad_params => 0,
                                        filter            => $filter,  
                                        loop_context_vars => 1);
    }

    if($@) {
        # エラー処理
        # ...
    }

    my $self = { template => $template };
    bless $self => $class;

    # HTML::Templateにデリゲートする
    # HTML::Templateのextendとはしていないことに注意:-)
    $self->add_delegate($template);

    return $self;
}

これでスッキリ！HogeHogeはハッシュリファレンスなのが分かっているので、HogeHogeのサブクラスを書くことだってすんなり。

CPANに乾杯！
類似のだとClass::Proxyてのもあるみたいだけど今回の状況はこっちの方がすんなり行くね。

*1:HogeHogeは仮名

*2:HogeHogeに対応するHTML::Templateのインスタンスを返すメソッドを設けるとかはナシね。

Thinkpad X61ワイヤレスLAN接続トラブルその後

d:id:orangevtr:20080731のつづき。

必要とされたコンポーネントを順にインストールしていったんだけど、Access Connectionsをインストールしたところで、再起動したら、「ようこそ」画面から「ユーザー名・パスワード直入力画面」にログイン画面が変更に。

ここでそんなこともあるのかな、となぜかそんなに疑問に思わないままワイヤレスLANドライバ（インテル ワイヤレスLAN）のインストールに進捗。時間は多少かかったものの、インストールされたようなので、再起動してみる。

ところが！「コントロールパネル＞システム」から、NICのデバイスドライバ（インテル Wireless WiFi Link 4965AG/4965AGN アダプタ）を確認してみたところ、更新されておらず、11.1.1.11のまま。

インテルワイヤレスLANのソフトウェアのみ空しくインストールされている。。起動してみても「11系のデバイスドライバはサポートしてないので12系つかってね」と言われる。そんなことわかっとるわ。。

はいここからが苦難の道のはじまりはじまり〜

まずデバイスドライバ削除してからインテルワイヤレスLANを再インストールしてみよっかな、と思い一旦インテルワイヤレスLANのソフトウェアを「プログラムの追加と削除」でアンインストールし、さらに「コントロールパネル＞システム」のデバイスドライバ一覧から、NICのデバイスドライバ（インテル Wireless WiFi Link 4965AG/4965AGN アダプタ）を削除して再起動。すると。。

Windowsが起動しない！！

ログイン前に、某DLL*1がないとかで、ログオンできない→再起動ボタンしかねーよっていう無限ループに。

ついにどうしようもないので、三たびスマートセンターに問い合わせ。

Windowsがイカれてる可能性があるので、いちどリカバリしてみたら？

という素敵なアドヴァイス。

いい加減呆れた＆疲れてきたんだけど、やむなしなので、ファイルバックアップしつつリカバリ作業。

んでWindows再セットアップして、Windows update入れ直して、再度Access ConnectionsおよびワイヤレスLANドライバ（インテル ワイヤレスLAN）をインストールチャレンジ！

だが・・やっぱりドライバのバージョンが据え置き＿|￣|○

もちろん、もとのトラブルも如何なく再現して、やっぱり断続的に切断される（うひゃ）

ここでさすがに萎えすぎてギブアップ。

翌日、半ギレで泣きながら（ウソ）、またもスマートセンターに問い合わせ。

しかし最早先方でも原因不明とのこと（ホントかよ）。

しょーがないので保証期間内修理という形でひきとってもらい、動作確認してもらえることに。いや当然アッチの環境じゃ再現しないというのも考えられるんだけどね…希望でデバイスドライバ入れ替えておいてくれとオーダー。

ちょうど今日お昼すぎ頃にドナドナされていきましたとさ。。
ホントに直るんかな？？

その後某所で手に入れた別のPC（しかもThinkpad X31）で試してみたところ、WEPキーのみ導入したところ54.0Mbpsですんなりつながり、断続的切断も再現せず。

やっぱドライバに何らか異常がある気がするんだけどね。。。
それにしても直るのかしら？？？

ていうかLenovoのは一般よりビジネスユース向けを想定しているとはいえ、エンジニアの端くれの僕でもこんなに苦労するというのに、普通のユーザーがこのサポートで満足するんかね・・・？

*1:名称失念…NETPLWIZ.DLL?IWPDGINA.DLLだった

ThinkpadX61のトラブルシューティングをログっておく

今年の5月に購入したThinkpad X61(767366J)がずっとトラブルを抱えていて調子が悪かったのを、昨日ちょうど休みだったのでトラブルシューティングしようとしたときのログを書いておこう。いろいろと厄介なことになりそうなヨカンもするのであとで役に立つかもしれないし…

トラブル1：AwaySch

シャットダウンしようとすると、AwaySchがいつも応答待ちのまま、終了できないというトラブル。

ぐぐってみたら同様な症状の人がいた。

AwaySchはメンテナンス・マネージャーの常駐タスクなので、以下のページの
「−Symantec AntiVirus またはバックグラウンド・プログラム・マネージャーを起動すると、IPSSVC.EXE による SYMANTEC 改変対策警告が表示される。」
には該当しなかったが、導入してみた。解凍して、C:driversWINAWAYTASKsetup.exeを
手動で実行しなければ導入できない。恐らく、プログラムを上書きインストールしたもの
と思われるが、最初に述べた問題は解決した。

ユニフォーム姿三四郎::レノボ（lenovo）ThinkPad X60とX61『AwaySch.exeが応答しない』

こちらではこれでは解決せず・・スマートセンターに問い合わせてみたところ、メンテナンス・マネージャーをインストールしなおせとのこと。

どうも上書きインストールではダメのようで、

• コントロールパネルからアンインストール（再起動）
• サポートサイトからダウンロード、解凍＆インストール（再起動）

したら、再現しなくなった。

同じバージョンでいいから一旦アンインストール＋再インストールがミソらしい。

トラブル２：ワイヤレスLANトラブル

自宅で無線LAN親機としてBUFFALOのWZR2-G300Nを導入して、AOSSでThinkpadを接続していたんだけど、どうにも調子が悪い。症状としては、AOSSで登録した親機と違うアクセスポイント（近所：チャンネルも異なる）に一定時間ごとに接続しにいこうとして、断続的にコネクションが切れる。

最初は親機のせいかと思い、BUFFALOのサポートセンターに問い合わせたものの、AOSSをやめて、普通のWEPキー認証にしても改善されない。ここでどうも子機（Thinkpad）のせいではないかという話になり、再びスマートセンターに問い合わせ。

BUFFALOの接続ツールではなく、Thinkpad付属のAccess Connectionsを使用して、WEPキー認証で接続に修正。

ここまでは２ヶ月くらい前に対処した話で、これで使用していたものの、新たな症状に見舞われた。

接続速度の表示が断続的に変化して、

• 54.0Mbps / MACアドレスは親機のMACアドレスが表示→接続状態。
• 150.0Mbps / MACアドレスは00:00:00:00:00:00に表示→切断状態

が繰り返されることに。

HTTPなんかの接続なら正直ちょっと遅いかな、というくらいなんだけど、リモートデスクトップやPoderosaで端末接続してると使い物にならないレベル。

しばらくダマシダマシ使っていたんだけど、ちょうど昨日直してしまえーということで、問い合わせ。

問い合わせると、無線LANのデバイスドライバの最新版がつい最近リリースされたとのこと。

まずはこれに入れ替えてみないか、という提案を受け、インストールしてみたがうまくインストールされない。

再度問い合わせたら、リリースノートをよく読むと、いくつかのコンポーネントをアップデートする必要があるとのこと・・

−MSXML 6.0 Parser またはそれ以降
−Windows Installer 3.14 またはそれ以降
−ThinkVantage Access Connections (Windows XP/2000)バージョン 5.0 またはそれ以降
−ThinkPad 省電力ドライバー (Windows 98 SE/Me/2000/XP/Vista ACPIモード)バージョン 1.45 またはそれ以降
−ホットキー機能 (Windows Vista/XP/2000)バージョン 2.08.2008 またはそれ以降

めんどくせーー！

なんでデバイスドライバアップデートするのに依存コンポーネントとかあんだよ。

しかたがないから端から順にインストールしていくことに。しかしここはまだヒドイ目になるまだまだ入り口だった。。（つづく）