いま振り返ってみると、 日経225 (日経平均株価) が最高値をつけたのは 1989年12月29日のことなので、 右肩上がりだったのは株を始めてわずかに 2年間で、 その後 20年間は右肩下がり、 しかも今現在は 1988年のスタート時点の半値以下に下がっている。 これでは長期投資では儲かるはずがないということにようやく気付いたが (遅すぎ! ^^;)、 かといって短期売買するほど相場に思い入れがあるわけではなく、 マーケット情報のウォッチに時間を費やすより、 コンピュータをいじっていたい性分なので、 株売買で儲けられないのは当然の成行。

ところが、 リーマンショックがまだ癒えない 2009年3月11日、 日経225 が今年 2番目の上げ幅 (3/11当時) を記録した。 別にマーケットをウォッチしていたわけではなく、 フツーに報道していたので多くの人が気に留めたはず。 この反騰を受けて報道では景気の先行きについて楽観的な見方を繰り返していたが、 「100年に一度」の世界恐慌が、 この程度の下げで V字回復するわけがないということくらい、 経済に疎い私だって分かる。 ということは株価を上げたいと考えている人が無理に買い上げているに違いない。

もちろん、テレビが率先して景気の先行きが暗いことを吹聴しては、 景気が余計に悪くなるのであえて楽観論のみ強調しているのだろうが、 甘い見通し報道を真に受けて投資したりすれば痛い目にあう、 ということは 20年間にわたって高い授業料を払って学んだところ。

株に関するブログなどをテキトーに拾い読みしてみると、 年度末である 3月に日経225 がある水準を下回ると、 金融機関などの決算上よろしくないことが起るらしく、 そのため誰かが株価を支えているということらしい。 真偽のほどは分からないが、 あまり健全とは言えない株価上昇だということだけは私にも分かる。

ムリヤリ買い上げた株価はいつかは下げるはずで、 しかもこれが決算対策ということであるなら、 4月に入れば上げた分が丸々下がる可能性が高い。 株価の上げ下げなんて、 当たるも八卦当たらぬも八卦の世界だと思っていたのだが、 今回ばかりは「無理な買い上げ」という原因がはっきりしているだけに、 ほぼ確実に下がりそうである。

というわけで、生まれて初めての空売り (からうり, 株を所有していないのに売る契約を結ぶこと) に挑戦してみることにした。 3月末に空売りするぞっと、 思った即その場で、 (普段利用している) ネット証券のサイトの信用取引方法の解説ページに目を通した。 ネットで申し込めば審査が行なわれ、 審査OK ならば数日後に取引開始できるらしい。 審査で落ちれば仕方がないが、 とりあえず申し込んでみるだけ申し込んでみようと、 これまたその場で申込みを終える。 これが 3/11 (水) 20:35 のこと。 大幅反発のニュースを知ってからここまで 1時間も経っていない (^^;)。

驚いたことに 3/13 (金) 03:45 には信用取引口座を開設可能とのメールが来ていた。 まだ 31時間しか経っていないのだが... こんなに早く済むとは、どんな審査なんだろうか？ 結局 3/14 (土) には取引可能状態になっていた。

次の問題は、 どの銘柄を空売りするか？ まず第一に、赤字企業であること。 大恐慌といえど儲かっている会社も中にはあるわけで、 そんな銘柄を空売りした後に株価が上がってしまっては目もあてられない。 むこう 1年くらいは赤字が続く予想が出ていながら、 株価が堅調に推移している不自然な会社を探すことにした。

第二に、日経225 算出の際の「みなし値」が高いこと。 日経225 は各銘柄を「50円換算」したときの株価を、 単純に合計して平均値を求めている。 だから「みなし値」が高いほど日経225 への影響度が高く、 日経225 をつり上げようとする人にとっては好都合となる。 ちなみに日経225 の騰落にどのくらい影響を与えたかを寄与額と呼ぶらしいが、 見なし値が高い銘柄ほど小幅の株価上昇で寄与額が大きくなる。 寄与額と株価変動額との比率を寄与率と呼び、 一般に値嵩株 (ねがさかぶ, 株価が高い株式) ほど寄与率が大きくなる。

また、 時価総額が大きい銘柄だと、 流通している株数も多いだろうから、 少々の資金では株価が動きにくいと思われる。 ということは日経225 をつり上げようとする人が狙うのは、 少ない資金でも値が飛びやすい銘柄なのだろう。 なので第三の条件として、 あまりに有名な超大企業は避けることにした。

ちなみに、 専門家ぶってエラソーに 「みなし値」 だの 「寄与率」 だの専門用語を振り回しているが、 土・日にネットサーフィン (死語) してニワカ仕込みで覚えた知識に過ぎない。 今まで信用取引をしたことがない全くの素人 (＝私) でも、 「空売りしよう」と思った直後に一夜漬けで勉強できるのが、 「知の高速道路」たるインターネットのいいところ。

まず「みなし値」が高い順に日経225 採用銘柄を並べてみる。 まずは上位 10銘柄。 もちろんいつの時点での株価を用いるかによって順位は入れ替わるが、 だいたいこんな感じ:

「利益予想」は来年 2010年度の予想額 (単位 百万円)。 大恐慌にも関わらず意外 (?) に黒字予想の企業が多い。 唯一赤字予想なのが、東京エレクトロン。 実はこれを調べるまで、 東京エレクトロン という会社が日経225 採用銘柄であることはおろか、 そもそも何をやってる会社かさえ知らなかった。 半導体製造装置の開発・製造会社らしい。 半導体製造というと不況業種というイメージを私は持っていたが、 実際あまり芳しくない業績のようだ。 そう簡単には黒字になったりはしないだろう。

ところが、 株価は 3/9 に 2875円の安値をつけた後、 一気に上昇している。 これはいかにも怪しい。 素人の私にも怪しさが伝わってくるくらいだから、 多くの人が怪しいと思ったのだろう。 空売りがどんどん膨らんで、 信用売残が信用買残の 10倍にも達している。 つまり多くの人が空売りを仕掛けているということだ。

ちなみに、 「みなし値」の 10位以降は以下のようになる。

以上 23社が、 日経225 に占める構成比 1% 以上の企業群。 1/225 = 0.4% なので、日経225 に与える影響は平均的銘柄の倍以上。 みなし値 1位のファーストリテイリング (ユニクロの会社) に至っては 構成比が 5% を超えていて、 みなし値最下位の企業群の 100倍以上の影響力を日経225 に対しておよぼしている。

構成比 1% 以上の企業のうち、 トヨタやソニーは超大企業なので除外すると、 赤字予想は東京エレクトロンの他は アドバンテスト と 富士フイルムHLDGS だけ。 いずれの株価も東京エレクトロンと同様、 3月上旬に安値をつけたあと一気に上昇していてとても怪しい。

というわけで、 狙いを 「東京エレクトロン」「アドバンテスト」「富士フイルムHLDGS」 に絞って、 しばらく株価をウォッチしてみることにした。 参考までに昨年 3月の株価を調べてみると、 東京エレクトロンは 2008年 3/26 に 6580円の高値をつけた後、 翌 3/27 に一気に下落している。 アドバンテストは 3/25 に高値をつけているが、 4月に入ってもあまり下落していないし、 富士フイルムHLDGSはむしろ 4月に入って上昇している。

空売り決行は 3月最終週、 特に 3/24 か 25 に狙いを定めた。

ところが 3/24 (火) は、 朝から学生さんを対象とした会社説明会を開催予定だった。 しかもその直後に KLab (株) の臨時株主総会が開催される。 これは人様の株なんか売ってないで、 自分の会社の心配をせよ、 という天の声なのか？ もちろん説明会も総会も参加しないわけにはいかず、 マーケットをウォッチするのは物理的に不可能だった。 よりによって会社説明会と臨時株主総会の日程にぶつかるとわ... (ついでに言うと、総会の後には某出版社の取材が入っていた)

仕方ないので会社説明会に出る前に、 指値で信用売り注文 (空売り) を出しておくことにした。 寄り付き状況を確認した後、 まず 9:09 に東京エレクトロンを 4030円の指値で注文を出したら、 いきなり 9:10 に約定してしまった。 初めての空売りがこんなにあっさり出来てしまうとわ... このまま株価が急騰するとマズイと思い、 すかさず 9:14 に 4180円の指値で追加注文を出す。 ところが株価は 4100円から下がりはじめた。 4180円になる気がしなかったので、 9:24 に 4090円の指値で注文を出した後、 会社説明会へ出る。

会社説明会の後、 ほとんど間をおかず (スーツに着替える時間だけでいっぱいいっぱい) 臨時株主総会。 総会が終わると後場ももうあとわずかである。 結局 4090円までは戻らず、 出来たのは 9:10 の 4030円の指値注文のみであった。 「お小遣いの範囲の売買」なので、 もちろん株数は最低売買単位である 100株だけ。 信用取引では際限のない損失拡大を防ぐことがなにより大事であるので、 売値より 1000円株価が上がってしまったら、 つまり損失が 10万円に達したら、 問答無用で損切り (ロスカット) しようと決めている。

翌 25日も指値空売り注文を出していたのだが、 株価は戻らず結局出来なかった。 マーケットの状況も気にはしていたのだが、 実は 25日の朝は HP ML115G5 (Athlon 1640B マシン) が 11750円 (送料・消費税込) で売られていたのを見つけてしまい、 衝動買いしてしまった。 劇安PC によってマーケットへの集中力が削がれてしまった感は否めない。 このマシンはサーバ仕様と言いつつ PCIe x16 スロットがあるので、 普通のデスクトップマシンとしても充分使える。 また ECC 無しメモリも使えるので安価なメモリを利用できる。 だから週末は秋葉へ行ってグラフィックボードとメモリを買おうなどと考え出すと、 マーケットのことなど、 もうどうでもよくなってしまう (^^;)。

東京エレクトロンはその後 3/27 に 4120円、 いったん下げた後 4/2 に急騰した。 なぜ 4 月に入っても上がり続けるのか？ (後で知ったが G20 期待だったらしい) と思いつつも、 ここで慌てて手仕舞するようでは信用取引をする意味がない。 いったん空売りを行なったからには、 ロスカット条件に達するまでは徹底して売り続ける必要がある。 4/2 に 4090円で、追加の空売りを行なった。

コンパクトカメラによる撮影だと色の再現性に難があるが (もちろん私の撮影スキルにも難あり ^^;)、 この青 (というか緑?) は 「天国」 (Lani) の名に恥じない美しさだと思う。

私は今まで米国では (2) レンタル携帯電話を使っていたのだが、 今回は二週間強ハワイ (オアフ島) に滞在するので、 (3) プリペイド SIM カードを購入することにした。 米国でプリペイド SIM カードが購入できるのは AT&T ストアだけ (T-Mobile などでは携帯電話ごと購入する必要がある) なので、 ホノルルに到着して (ホテルへ行く前に) まず立ち寄った Ala Moana Center (ショッピングモール) で、 at&t ストアを探した。

SIM カードを 2枚買って、 HTC P3600 と Motorola ZN200 に入れて使うつもり。 at&t Pay As You Go の Unlimited Talk プランだと、 一日 1ドルの固定料金だけで at&t携帯電話同士の通話が無制限に可能 (通話しない日は無料)。 at&t携帯電話以外との通話は、10セント/分。 $.25 per minute プランの場合は 25セント/分なので、 一日の通話が 4分以内に限られるならこちらを選んでもよい。

ところがモールマップ を見ても、 at&t ストアが見つからない。 google map で検索すると、 確かに at&t ストアが Ala Moana Center 内にあるように表示されるのだが... 仕方ないので携帯電話を扱っている RadioShack へ行って店員に聞いてみる。 すると Sears (モール西端にあるデパート) の中にあるとの答。 なるほど、だからモールマップには載っていないのか...

RadioShack を出て駐車場沿いに歩いて Sears へ。 Sears の入口から入るとすぐ at&t ストアが目に入った。 ところが先客が 4組ほどいて (iPhone を買っている人もいた)、 待てど暮らせど順番がまわってこない。 結局 1時間ほど待つ羽目になった。 私の後にはほとんど並ぶ人はなく、 開店直後は待っている客が多くて混む、 ということだったようだ。 開店時刻 (平日9:30, 土曜9:00, 日曜9:30) 前から並ぶか、 あるいは逆に遅い時間、例えばお昼頃に行けばよさそうだ。

ようやく順番がまわってきて、 携帯電話二台を示しながら、 これ用にプリペイド SIM カードを二枚欲しいと店員に言うと、 そういうお客は多いのだろう、 話はすぐ通じた。 店員が、この携帯電話はアンロックしてあるか？と確認してきた。 もちろんどちらの携帯電話も SIM ロックフリーである。 続いて ID (身分証明書) の提示を求められた。 空港から直接ここへ来たのでパスポートを持っている。 パスポートを提示すると、宿泊するホテルを聞かれた。 プリペイド SIM カードのユーザも住所を登録しておく必要があるらしい。

念のため一枚目のアクティベートが終わった段階で、 その SIM カードを HTC P3600 と Motorola ZN200 の両方に差してみると、 両方とも無事接続できて、HTC P3600 では 3G での接続を確認できた。

アクティベート (および SIM カードそのもの) は無料で、 最初に最低 $25 の通話料 (air time) を購入する必要がある。 ところが新規契約の場合は $10 のボーナスがつくので、 計 $35 ぶんの通話が可能。 at&t携帯電話同士の通話だけであれば一日 $1 しかかからないので、 一ヶ月の滞在までこれで用が足りてしまうし、 一週間程度の滞在でも (air time は余ってしまうが) レンタル携帯電話より安くつくように思う。

もちろん、 プリペイド SIM カードを利用する場合は、 あらかじめ携帯電話を購入しておく必要があるが、 HTC P3600 は 17,980円、 Motorola ZN200 は HK$899 (約 1万円) で購入したので、 何度かレンタル携帯電話を借りることを考えれば十分ペイする。 また、 アジアやヨーロッパでの使用を考えずに、 米国専用の携帯電話でよければもっと安く購入できる。

なお Unlimited Talk プランだと at&t 携帯電話以外への通話は 10セント/分かかるが、 at&t 携帯電話以外から着信した場合や、 トールフリー (無料通話, 1-800-XXX-XXXX など) へかけた場合も、 10セント/分かかるので注意が必要。 通話時間は 1分単位で切り上げて課金される。

この写真↑ は、橋の中間点から芝浦埠頭方向。 折り返してくる人々が反対車線に見える。 この時は歩いている人がまばらで歩きやすかったが、 お台場方向へ戻ったあたりで先が詰まってしまい、 満員電車並のすし詰め状態↓ になった。

こうなってくると、「ウォーキング」というよりはお祭り。

ニュース:
卓球の愛ちゃんも歩く！東京レインボーウオーク3月1日開催
レインボーブリッジでウオーキング大会－東京五輪招致に向けPR

そして、 エピソード記憶を持つ個体の中に、 あるとき突然変異によって自我の芽生えのようなものが生じた。 「自分」という自我意識が強くなればなるほど、 自分という存在が「かけがえのない」ものに思えるようになり、 自己を大事に思うようになる。 すなわち「死への恐怖」が生まれる。

「死」を忌避する個体の生存確率が高まるのは自明であり、 自我意識はどんどん強固なものへ (死がどんどん怖ろしいものへ) と進化し、 ついには自己同一性概念 (アイデンティティ) を獲得するに至り、 自身が「自由意思」を持っていると認識したりする。

幼虫から蛹、そして成体に至る過程において、 大量に予定された細胞の死 (programmed cell deathと言います) が起こるのですが、 芋虫から蝶、あるいはカブトムシというような、身体の形だけでなく、 なんと「神経系」に至るまで再構成されると聞いているからです。?!?!
...
成長の一ステップにおいて、 自分のこれまでの経験も何もかもが組み込まれた大きな系が再構成されるということで、
...
この幼虫とこの成虫は同じアイデンティティを持つ個体と呼べるものなのか

「虫の記憶はさなぎを経ても残るのか？」から引用

変態によって生存戦略が大きく変わる (例えば、地面を這う個体と、飛べる個体とでは、天敵を回避する戦略は全く異なる) ことを考えれば、 変態前のエピソード記憶は、 害になることはあっても益にはなるまい。 つまり、 エピソード記憶を忘れることが、 生存確率の向上につながる。

進化の過程で変態を行なう生物が生まれたとき、 もしかすると最初の変態生物は神経系の再構成までは行なわなかったのかもしれない。 そして、 あるとき突然変移によって神経系までも再構成する個体が生まれた。

変態前のエピソード記憶を引きずる個体は、 過去の経験が邪魔をして命を落とすこともある一方で、 変態によって記憶をリセットした個体は、 なまじ経験がないぶん有利となる。

あるいは、 神経系の再構成を完全には行なわず、 一部の神経組織が残る場合でも、 変態前のエピソード記憶を積極的に消去する個体の方が、 生存確率を高めることができるだろう。

どちらの場合も、 幼虫と成虫が同じアイデンティティを持つことによるメリットよりも、 エピソード記憶を引きずらず、 したがって同じアイデンティティを持たない (持てない) ことによるメリットの方が、 大きいだろう。 変態生物が自我の強化を行なうのは難しそうである。

OLEVIA X10A-1160 は、 SOTEC C101 と (キーボード配列や天板のデザインを除けば) 同等であるため、 以下の対策は SOTEC C101 に Ubuntu 等の GNU/Linux をインストールして使う場合も、 そのまま適用できるはず。

i8042 のバグ対策を行なってタッチパッドを認識させる

他のいくつかのノートPC (dynabook Satellite P10, Thinkpad R31, Lifebook P7010, Dell XPS M1530 など) と同じく、 OLEVIA X10A-1160 (確認していないが、おそらく SOTEC C101 も同様) のキーボード/マウス コントローラ i8042 互換チップにはバグがある。 OLEVIA X10A-1160 の場合、カーネル起動時に以下のようなログを出力する:

PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
i8042.c: Detected active multiplexing controller, rev 1.1.
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX0 port at 0x60,0x64 irq 12
serio: i8042 AUX1 port at 0x60,0x64 irq 12
serio: i8042 AUX2 port at 0x60,0x64 irq 12
serio: i8042 AUX3 port at 0x60,0x64 irq 12
	...(中略)...
input: PS/2 Generic Mouse as /devices/platform/i8042/serio4/input/input9
psmouse.c: Failed to enable mouse on isa0060/serio4

存在しないはずの外付けポート (AUX0～3) コントローラ (multiplexing controller) を認識してしまうようだ。 このため、 タッチパッド (SynPS/2 Synaptics TouchPad) が使えなくなってしまう。 この問題は、 カーネルパラメータに i8042.nomux=1 を追加することによって回避できる。 例えば GRUB の設定ファイル /boot/grub/menu.lst に、

title           Ubuntu 8.04.1, kernel 2.6.24-23-generic
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.24-23-generic root=UUID=(省略) ro quiet splash vga=789 i8042.nomux=1
initrd          /boot/initrd.img-2.6.24-23-generic
quiet

といった感じで 「i8042.nomux=1」 を追加すればよい。 Linux を再起動すると、

PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
	...(中略)...
Synaptics Touchpad, model: 1, fw: 5.10, id: 0x258eb1, caps: 0xa04711/0x0
input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input7

などと出力し、 無事 SynPS/2 Synaptics TouchPad が認識できた。

なお Linux は、 i8042 にバグを持つ PC で問題を回避できるよう、 PC のブラックリストを持っている。 すなわち linux/drivers/input/serio/i8042-x86ia64io.h で定義されている配列 i8042_dmi_nomux_table に PC の ID を登録しておくと、 該当する PC では自動的に i8042.nomux=1 が設定される仕掛けだが、 あいにく OLEVIA X10A-1160 は固有の ID を持っていないようだ:

# head /sys/class/dmi/id/{sys_vendor,product_*}
==> /sys/class/dmi/id/sys_vendor <==
 

==> /sys/class/dmi/id/product_name <==
 

==> /sys/class/dmi/id/product_serial <==
Not Applicable

==> /sys/class/dmi/id/product_version <==
Not Applicable

DMI のベンダ名、プロダクト名が共に空白になっている。

無線LAN ドライバ vntwusb をインストールする

OLEVIA X10A-1160 (確認していないが、おそらく SOTEC C101 も同様) は、 無線LAN チップとして VIA Technologies の VT6656 を使用している。 しかし残念ながらこのチップは、 現時点の Linux 標準カーネルではサポートしていない。 したがってドライバをインストールする必要がある。

まず VIA Technologies のサポートページ VT6656 WLAN Linux Driver Source から、 最新版のドライバ vt6656_wlan_linux_v118.zip (1/18 現在) をダウンロードする。 展開して make すれば、 VT6656 用のカーネルモジュール vntwusb.ko が作られる。

% wget http://www.viaarena.com/Driver/vt6656_wlan_linux_v118.zip
--10:19:24--  http://www.viaarena.com/Driver/vt6656_wlan_linux_v118.zip
           => `vt6656_wlan_linux_v118.zip'
Resolving www.viaarena.com... 74.54.151.131
Connecting to www.viaarena.com|74.54.151.131|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4,483,650 (4.3M) [application/x-zip-compressed]

    0K .......... .......... .......... .......... ..........  1%   68.92 KB/s
	...(中略)...

% unzip vt6656_wlan_linux_v118.zip
Archive:  vt6656_wlan_linux_v118.zip
   creating: VT6656_WLAN_Linux_V118/
   creating: VT6656_WLAN_Linux_V118/driver/
	...(中略)...
% cd VT6656_WLAN_Linux_V118/driver
VT6656_WLAN_Linux_V118/driver % make
make -C /lib/modules/2.6.24-23-generic/build SUBDIRS=/home/sengoku/VT6656_WLAN_Linux_V118/driver modules
make[1]: ディレクトリ `/usr/src/linux-headers-2.6.24-23-generic' に入ります
  CC [M]  /home/sengoku/VT6656_WLAN_Linux_V118/driver/main_usb.o
	...(中略)...
  LD [M]  /home/sengoku/VT6656_WLAN_Linux_V118/driver/vntwusb.ko
make[1]: ディレクトリ `/usr/src/linux-headers-2.6.24-23-generic' から出ます

あとは、make install して modprobe vntwusb するだけ。

VT6656_WLAN_Linux_V118/driver % sudo make install
make -C /lib/modules/2.6.24-23-generic/build SUBDIRS=/home/sengoku/VT6656_WLAN_Linux_V118/driver modules
mkdir -p /lib/modules/2.6.24-23-generic/kernel/drivers/net
install -m 644 -o root vntwusb.ko /lib/modules/2.6.24-23-generic/kernel/drivers/net
/sbin/depmod -a || true
VT6656_WLAN_Linux_V118/driver % sudo modprobe vntwusb

ただし前もって、 カーネルモジュールを make するための環境を整えておく必要がある。 Ubuntu (というか debian) の場合であれば、 module-assistant パッケージと linux-headers パッケージをインストールしておけばよい。 あるいは、 上記 VT6656_WLAN_Linux_V118/driver ディレクトリを、 Linux カーネルソースにコピーしてカーネルを再構築してもよい。

私は、 Linux カーネルソースツリーに、 linux/drivers/net/wireless/vntwusb ディレクトリを作って、 VT6656_WLAN_Linux_V118/driver ディレクトリの内容をコピーし、 linux/drivers/net/wireless/Kconfig および linux/drivers/net/wireless/Makefile に以下のパッチをあてている。

--- linux-2.6.27.11.org/drivers/net/wireless/Kconfig	2008-10-10 07:13:53.000000000 +0900
+++ linux-2.6.27.11/drivers/net/wireless/Kconfig	2009-01-06 14:52:10.459276155 +0900
@@ -702,5 +702,6 @@
 source "drivers/net/wireless/b43legacy/Kconfig"
 source "drivers/net/wireless/zd1211rw/Kconfig"
 source "drivers/net/wireless/rt2x00/Kconfig"
+source "drivers/net/wireless/vntwusb/Kconfig"
 
 endmenu

diff -ur linux-2.6.27.11.org/drivers/net/wireless/Makefile linux-2.6.27.11/drivers/net/wireless/Makefile
--- linux-2.6.27.11.org/drivers/net/wireless/Makefile	2008-10-10 07:13:53.000000000 +0900
+++ linux-2.6.27.11/drivers/net/wireless/Makefile	2009-01-06 14:52:10.491275159 +0900
@@ -58,6 +58,7 @@
 
 obj-$(CONFIG_IWLWIFI)	+= iwlwifi/
 obj-$(CONFIG_RT2X00)	+= rt2x00/
+obj-$(CONFIG_VNTWUSB)	+= vntwusb/
 
 obj-$(CONFIG_P54_COMMON)	+= p54/
 

Ubuntu などのディストリビューションのアップデートに頼らずに、 カーネルのバージョンアップを行なっている場合は、 カーネルソースツリーに組み込んでおく方が、 ドライバ込みでカーネルを再構築できるので手間が省ける。

自宅の無線LAN を WPA2-EAP (WPA2 エンタープライズ) にして 1ヶ月になるが、 すこぶる快適。 アクセスポイントがエンタープライズモードに対応していなければいけないのと、 RADIUS サーバが必要である上、 EAP-TLS を用いる場合は SSL クライアント証明書を発行する 認証局 (CA) を作る必要まであるので、 自宅LAN での導入にはややハードルが高いが、 いったん導入してしまえば WPA/WPA2 パーソナルより手間がかからない。

WPA/WPA2 パーソナルだと、 秘密のパスワードを全ての無線LAN 端末で共有するので、 端末の台数が増えてくるとどんどん漏洩のリスクが高まる。

自宅LAN でそんなに端末があるのか？ という突っ込みが入りそうだが、 格安 NetBook や、 無線LAN 機能付スマートフォンなどを買っていると、 自宅LAN とはいえ、 「エンタープライズ」 的なニーズが出てくる。

WPA2 エンタープライズで認証方式として EAP-TLS を使うと、 無線LAN 端末にはそれぞれ個別の証明書をインポートしておくだけでよく、 万一その端末を紛失しても、 その端末の証明書を無効にするだけで済む。

EAP-TLS には対応機器/OS が多いというメリットもある。 無線LAN 端末として、 Windows VISTA, Windows XP, Ubuntu 8.04 LTS などを使ってみたが、 いずれもあっけないくらい簡単に接続できてしまった。 証明書さえインポートしておけば (Windows ならダブルクリックだけ)、 あとはパスワードを入力しなくてもいいぶん WPA/WPA2 パーソナルより設定が簡単。

既存の OS (Linux の場合はディストリビューション) で無線接続できるようになったので、 次は私が独自に構築した GNU/Linux (いわば my distribution) 上で WPA2 EAP-TLS 接続を試みた。

まず wpa_supplicant 0.5.11 をダウンロードしてコンパイル。 続いて設定ファイルである wpa_supplicant.conf を書く。

network={
	ssid="XXXXXXXXXX"
	key_mgmt=WPA-EAP
	eap=TLS
	identity="olevia"
	ca_cert="/usr/local/ssl/certs/GCD_Root_CA.pem"
	client_cert="/usr/local/ssl/certs/olevia.pem"
	private_key="/usr/local/ssl/private/olevia.pem"
	private_key_passwd=""
}

「ca_cert=」 「client_cert=」 「private_key=」 にそれぞれ CA の公開鍵、端末の公開鍵、端末の秘密鍵のファイル名を指定している。 で、wpa_supplicant を実行。

# wpa_supplicant -i eth1 -c /etc/wpa_supplicant.conf -d -D wext
Initializing interface 'eth1' conf '/etc/wpa_supplicant.conf' driver 'wext' ctrl_interface 'N/A' bridge 'N/A'
Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf'
Reading configuration file '/etc/wpa_supplicant.conf'
Priority group 0
   id=0 ssid='XXXXXXXXXX'
Initializing interface (2) 'eth1'
EAPOL: SUPP_PAE entering state DISCONNECTED
EAPOL: KEY_RX entering state NO_KEY_RECEIVE
EAPOL: SUPP_BE entering state INITIALIZE
EAP: EAP entering state DISABLED
	...(中略)...

wpa_supplicant はデバッグモード (-d オプション) にすると大量のログを出力するので動作を追いにくいが、 wpa_supplicant のプログラムは状態遷移機械 (オートマトン) として動作するよう書かれているので、 「EAP: EAP entering state」 の部分を追っていくとよい。 「DISABLED」 と出力されているのが、 その時点におけるオートマトンの状態。

状態遷移機械 (オートマトン) と言ってしまうと、 コンピュータ/プログラムは全てオートマトンなのであるが (^^;)、 プログラミングの方法として状態遷移機械 (state machine) と言うときは、 各状態に名前を付けて、 各状態ごとの動作を (switch 文や if ... else if ... 文などで) 分けて書く方法を指す。

状態には INITIALIZE, DISABLED, IDLE, RECEIVED, GET_METHOD, METHOD, SEND_RESPONSE, DISCARD, IDENTITY, NOTIFICATION, RETRANSMIT, SUCCESS, FAILURE の 13状態がある。 もちろん 「SUCCESS」 が受理状態。 SUCCESS 状態は、 アクセスポイントが接続を許可した状態を意味する。

ところが、ログを追っていくと、

EAP: EAP entering state RECEIVED
EAP: Received EAP-Success
EAP: EAP entering state FAILURE
CTRL-EVENT-EAP-FAILURE EAP authentication failed

FAILURE 状態 (非受理状態) に遷移している (*_*)。当然、接続できず。
その直前に 「Received EAP-Success」 と出ているにもかかわらず！

アクセスポイント側 (正確に言うと RADIUS サーバ) のログを調べてみると、 ちゃんと接続を許可している (EAP-Success を送っているのだから当然だが)。 一体これはどうしたことか？

私がコンパイルした wpa_supplicant に問題があるのかと思って、 この wpa_supplicant を、 既に接続できることが確認済みの Ubuntu 上にコピーして実行してみる。 「Received EAP-Success」 をログの中から探してみると、

EAP: EAP entering state RECEIVED
EAP: Received EAP-Success
EAP: EAP entering state SUCCESS
CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully

ちゃんと SUCCESS 状態に遷移しているし、接続もできた。
同一バイナリなのに、異なる環境 (ディストリビューション) だと、 どうして結果が異なるのか？

どのような可能性が考えられるだろうか？ 腕に覚えがあるかたは、 この続きを見ずに (といっても、既にタイトルでネタバレしてしまっているが ^^;) 原因を推測してみてはいかがだろうか？

Olevia X10A 10.1" notebook

物価が安い香港と言えど、HK$3000 以下の NetBook というと EeePC 701SDX あたりになってしまうわけで、 メモリ 1GB, HDD 160GB の Atom N270 で HK$2880 というのは興味深い。 その場で悩み込むこと数分間。 店員がべらべら説明を始めたが、広東語なので何も分からない (^^;)。

同等スペックの NetBook としては、 例えば acer Aspire One AOA150 がある。 メモリ 1GB, HDD 160GB, Atom N270, WSVGA, 無線LAN あたりは同等で、 違いは Aspire One AOA150 の方が若干小さく (画面サイズも 1インチほど小さい)、 LAN が 100Mbps (X10A は 1Gbps) で、 Webカメラの画素数が 30万画素 (X10A は 130万画素) である点など。 Aspire One AOA150 の最安値は 35000円くらい？

何より OS が Linux というのがいい。 香港版の Windows XP なんて広東語を喋れない私には無用であるわけで、 HK$600 くらいはする Windows XP ライセンスが付いた PC は避けたいところ。 一応 「Windows Compatible」 を謳っていて 「Designed for Microsoft WindowsXP」 シールも貼ってある。

買う一歩手前まで行ったのだが、最後の背中のひと押しが無かったのと、 妻がホテルで待っているというのがあって、 これから帰る旨を電話で伝えて、 後ろ髪を引かれつつお店を後にした。

ところが、

旅行前の準備で、 電脳街の場所を調べるのに苦労したので、 Google Maps での位置をまとめておく。 ついでに最寄駅の出口、道路の名前、ビルの名前も付記した。 駅の出口と道路の名前さえ覚えておけば探すのは難しくないはず。 「街」 「道」 がついているのが道路の名前で、 それぞれ「street」 「road」 の意味。 ちなみに 「站」 は 「駅」 の意味で、「大廈」 は 「ビル」。

「1樓」「1/F」は日本で言うところの「2階」のこと。 「2樓」「2/F」は「3階」。 つまりイギリスと同じ数え方。 「地下」 「G/F」 (Ground Floor) が、 日本で言うところの「1階」になる。 「地下」が「1階」なら、 日本で言うところの「地下1階」は一体何て言えばいいんだ？ という疑問が湧くが、 「第1層地庫」 「地庫1層」 「地庫一」 「地庫1樓」 「1/B」 (1st Basement) などと表現するらしい。

「數碼」(「數」は「数」の繁体字) は「デジタル」の意味。 深水埗站 D1 出口には、 數碼之源 Digital Hub と銘じたオブジェがある。

香港といえば (SIM ロック フリー) 携帯電話。 ホテルが旺角の近くなので、 まず先達廣場へ行ってみる。 携帯電話屋が多数集まっていることで有名な先達廣場だが、 安いのは Nokia 1208 (HK$200 くらい) などの 2バンド GSM (dual-band, 900/1800) 機ばかりで、 これだと 1900MHz 帯をサポートしていないので米国などで使えない。 4バンド GSM (quad-band, 850/900/1800/1900) 機だと結構高め (HK$1300～)。 安さを求めるなら先達廣場はあまり向いていないのではないか？ そもそも旺角の物価が (新界に比べると) 少々高め。

まあ、最近の為替レートだと HK$1 = 12円以下なので、 高いと言っても高々 15,000円程度ではあるのだが、 海外旅行中に通話専用として使う携帯電話としては安いに越したことはない (データ通信にも使う携帯電話としては HTC P3600 を既に持っているので)。

先達廣場を出て、西隣にあった家電量販店 國美電器 を覗いてみると、 Motorola ZN200 を HK$899 で売っていた。 期間限定のキャンペーン価格のようだ。 零細ショップより大手量販店の方が安くなるのは、 旺角も秋葉原も同じ、ということなのだろうか。 それまで見た 4バンド GSM 機の中では一番安かったので、 これに決めた (約 1万円)。

続いてプリペイド SIM カード Super Talk Stored Value SIM Card の Starter Pack HK$48 を、 PEOPLES Shop (China Mobile) で購入 (HK$43)。 2枚買って、Motorola ZN200 と HTC P3600 にそれぞれ入れた (2枚で約 1000円)。

たまたま登打士街 (Dundas st) を歩いているときに、 PEOPLES の看板が目に入ったので PEOPLES Shop で SIM カードを買ったが、 Distribution Channels によれば 7-Eleven などでも売っているらしい。 でも、忙しそうな 7-Eleven の店員に SIM カードのことをあれこれ尋ねて買うのは気が引けるのだが... その点、PEOPLES Shop は 「マル優」 マーク付なので安心かも。

通話料は繁忙時間帯 (12:00～20:59) で HK$0.12/分 (1.4円)、 それ以外の時間帯だと HK$0.05/分 (0.6円) であり、 香港の物価水準から考えても、えらく安い。 4日間の滞在では SIM カードの度数がほとんど減らず、 HK$40 以上が残ったままだった。

デフォルトで国際ローミングを行なう状態になっているようで、 日本に戻ってきてから香港の電話番号 010-852-XXXX-XXXX へかけたら、 ちゃんと HTC P3600 が鳴った。 SoftBank あるいは NTT DoCoMo のいずれの UMTS (Universal Mobile Telecommunications System) 網に接続していても着呼できた。 もちろん Motorola ZN200 は GSM 専用なので日本では使えない。

ただし、データ通信 (Mobile Data Service) は HK$0.04/KByte もするので、 ちょっと画像が多いページを閲覧したりすると、 SIM カードの度数が一瞬で無くなってしまう (1.2MB ダウンロードするだけで HK$48 になるから当然だが) ので、 少しでもデータ通信するなら Mobile Data Package (データ定額 HK$98/月) を利用すべき。 実は、 香港滞在の最終日に、 ごく短時間のアクセスのつもりで PC に HTC P3600 を接続して Web ブラウズしたのだが、 たまたまアクセスしたページに画像が沢山貼ってあった ;-( おかげで、 HK$40 以上残っていた SIM カードが、 そのページを表示しただけで無くなってしまった。

なお、 Mobile Data Service を利用するには、 へ電話をかけてサービスを有効に (activate) する。 私は利用しなかったが、 Mobile Data Package を利用するには、 Mobile Data Service を有効にした上で、 へ電話をかけて利用開始 (subscribe) すればよいらしい。

Mobile Data Package 利用中は、 30日経つたびに HK$98 が SIM カードから差し引かれるので、 利用しないときは、 へ電話をかけて Mobile Data Package を利用中止 (cancel) する。

Mobile Data Package を利用しなかった (できなかった) のは、 インターネット接続はホテルの無線LAN を利用すればよい、と考えていて、 携帯電話でのデータ通信に関して下調べを怠っていたから。 旅行前に、 滞在するホテル The City View (旧 YMCAインターナショナルハウス) は、 「部屋からインターネット接続できる (らしい)」との記述を見つけて安心していた:

部屋からインターネット接続出来る。（らしい）
以下、文面のコピー。

＜ブロードバンドインターネットアクセス＞

当ホテルでは、客室・ロビー・会議室・レストラン・ラウンジ内の どこからでも高速インターネットにアクセスできる 「ブロードバンド・インターネット接続サービス」がご利用いただけます。
お客様のご利用されるパソコンに、 ワイヤレスでのインターネット接続に必要な802.11b/Wi-Fiが搭載されていない場合、 専用アダプターもご用意いたしております。
詳しい内容については、 ホテルのビジネス・センターまでお問い合わせください。

※ご利用にあたっての重要なお知らせ※

「ブロードバンド・インターネット接続」サービスをご利用いただくにあたり、 以下の内容にご承認・ご同意下さるようお願い申し上げます。
インターネットを通じたメッセージの安全な送受信は100％保証することは出来ません。 インターネットによる通信では、 更新の中断や送信の遮断・ネットワークの繁忙状態による送信の遅れ、 誤ったデータの送信などのエラーが生じる可能性があります。
当ホテルおよびサービスプロバイダーは、 細心の注意を払って同サービスの提供に努めておりますが、 お客様が「ブロードバンド・インターネット接続」サービスを ご利用されることによって・もしくは利用出来ないことによって、 万が一、何らかの直接的・間接的な、 もしくは偶発的・必然的な損失やダメージ・負債・補償請求などの被害を被った場合、 当ホテルおよびプロバイダーは一切の責任を負いません。

YMCAインターナショナルハウス (現：ザ・シティビュー) 詳細 から引用

実際、部屋にはこの文面と同じ紙があった。 ところが、 この「ブロードバンドインターネットアクセス」に接続してみると、 Systech Telecom が提供している有料サービスだった。 それも香港の物価水準と比較すると法外に高い HK$100/日。 誰がこんなサービスを利用するんだ？ (泣く泣く利用したけど...) 「※ご利用にあたっての重要なお知らせ※」を書くなら、 真っ先に有料であることを書くべきではないのか？ ＞ ホテル

一ヶ月の携帯電話データ定額より、 一日の無線LAN の利用料の方が高いとわ... (*_*)
ちゃんと下調べして Mobile Data Service を利用すればよかった...

おまけ:

こういうのを見ると ↓ 香港の物価の安さを実感する。

EAP (社員支援プログラムではなくて、 拡張認証プロトコル) の認証方式には EAP-MD5, EAP-FAST, EAP-SKE, EAP-SRP, MS-CHAP, EAP-GTC, EAP-GTC, Cisco LEAP, EAP-TLS, EAP-TTLS, PEAP, EAP-MAKE, EAP-SIM などがあるが、 対応機器/ソフトウェアが多そうな EAP-TLS を使ってみることにした。 EAP-TLS とは、 TLS (Transport Layer Security) すなわち SSL (Secure Sockets Layer) のサーバ認証とクライアント認証を行なって、 RADIUS サーバと無線LAN 端末が相互に認証を行なう仕掛けである。

RADIUS サーバとしては、 free RADIUS 2.1.3 を使用した。 自前の認証局 でサーバ証明書とクライアント証明書を発行し、 それぞれ RADIUS サーバと無線LAN 端末 (Windows マシン) へインストールする (自分で発行する証明書だが、 認証する側が自分の管理下なので、 いわゆる「オレオレ証明書」ではない)。

まず radiusd をデバッグ モードで走らせてみる:

# radiusd -X
FreeRADIUS Version 2.1.3, for host i686-pc-linux-gnu, built on Dec  6 2008 at 17:50:58
Copyright (C) 1999-2008 The FreeRADIUS server project and contributors. 
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A 
PARTICULAR PURPOSE. 
You may redistribute copies of FreeRADIUS under the terms of the 
GNU General Public License v2. 
Starting - reading configuration files ...
including configuration file /usr/local/etc/raddb/radiusd.conf
including configuration file /usr/local/etc/raddb/clients.conf
including configuration file /usr/local/etc/raddb/eap.conf
group = radius
user = radius
including dictionary file /usr/local/etc/raddb/dictionary
	...(中略)...
Listening on authentication address * port 1812
Ready to process requests.

とりあえず動いているようだ。 Windows マシンからアクセスポイントへ接続してみると、 アクセスポイントを介して Windows マシンと RADIUS サーバ間で、 TLS サーバ/クライアント認証が行なわれ、 無事 WPA2 エンタープライズ モードで接続が完了した。

では、radiusd を daemontools 配下で動かそうと、 次のような /service/radius/run スクリプトを書いて動かしてみる:

#!/bin/sh
export PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
exec 2>&1
exec radiusd -fxxx

-x を指定して詳細なデバッグ情報を出力させるようにする。 daemontools 配下で動かす場合、 multilog プログラムがログをどんどんローテートしてくれるので、 通常運用でもデバッグ情報を出力させておける。 ログを標準出力 (stdout) へ出力させるため、 設定ファイル radiusd.conf において、 次のように指定しておく。

log {
	destination = stdout
}

これでログが /service/radius/log/main/current に書き出されるはず、 と思ったら何も出力されない... 何故に...?

radiusd(8) によれば、-X オプションは 「-sfxx -l stdout」 と等価らしい。 -s オプションは、 RADIUS サーバを単一スレッド/プロセスで走らせるための指定。 個人で使う分には単一スレッドでも構わないといえば構わないので、 ログを stdout に出力する目的で -X オプションを使ってしまっても構わないのだが、 せっかくだからともうちょっと追ってみることにした。

まず上記 run スクリプトにおいて 「-l stdout」 を指定してみる。 すると、/service/radius ディレクトリに stdout というファイルができて、 そこにログが出力された。 ダメだこりゃ。 -l オプションはマニュアルには記載されていないので、 -l に続く 「stdout」 をファイル名と見なすのも一つの「仕様」と言えなくもないが...

ソース radiusd.c を見てみると、 確かに -l オプションの処理では続く引数をファイル名としてしか扱っていない。 では設定ファイル radiusd.conf に指定した場合はどうかと、 mainconfig.c を見てみる。 「log { ... }」 の中で 「destination = stdout」 を指定すると、 mainconfig.radlog_dest に RADLOG_STDOUT が代入されるようだ。 ところが、mainconfig.radlog_fd を設定するコードがない。 これでは stdout にログが出力されるはずがない。

「-l stdout」 の件は百万歩譲って「仕様」でも構わないが、 mainconfig.radlog_dest に RADLOG_STDOUT を代入しておきながら mainconfig.radlog_fd に代入し忘れるのは、 仕様うんぬん以前にソースとして首尾一貫していないので、 明らかにバグである。

そこで以下のようなパッチをあてて、 mainconfig.radlog_dest が RADLOG_STDOUT あるいは RADLOG_STDERR のときは、 mainconfig.radlog_dest に STDOUT_FILENO あるいは STDERR_FILENO を それぞれ代入するようにしてみた。

--- src/main/mainconfig.c~	2008-12-06 01:37:56.000000000 +0900
+++ src/main/mainconfig.c	2008-12-06 16:16:27.455277946 +0900
@@ -738,6 +738,10 @@
 				cf_section_free(&cs);
 				return -1;
 			}
+		} else if (mainconfig.radlog_dest == RADLOG_STDOUT) {
+			mainconfig.radlog_fd = STDOUT_FILENO;
+		} else if (mainconfig.radlog_dest == RADLOG_STDERR) {
+			mainconfig.radlog_fd = STDERR_FILENO;
 		}
 	}
 

これで無事、 ログが stdout に出力され、 /service/radius/log/main/current に書き出されるようになった。

泊まったのはワイキキの安ホテル。 部屋はもちろんマウンテンビュー (つまり海が見えない側)。 一般に階数が高いほどいい部屋とされるが、 公衆無線LAN を使いたい場合は低層階のほうがいい。 もう少し上のランクのホテルだと、 各階に無線LAN のアクセスポイントが設置されていたり、 あるいは各部屋に LAN が敷設してあったりするが、 私が泊まったホテルだと無線LAN が使えるのは一階ロビーだけ。 部屋でインターネットにアクセスしたければ、 屋外で利用可能な公衆無線LAN を利用するしかない (もちろん電話でダイアルアップ接続する手も無くはないが、 あくまでそれは最後の手段)。

こういう場合、部屋が高層階だとやっかいである。 公衆無線LAN のアクセスポイントは、たいてい地上近辺に設置されているので、 階数が高いほど接続しにくくなるからだ。 今回は運悪く (フツーの意味では運良く) 最上階に近い 15階。 厳しいんじゃないかなぁと思いつつ、 ノートPC 内蔵の無線LAN 端末で接続を試みたら案の定、全く接続できず。 ラナイ (Lanai, ハワイ語で「ベランダ」) から身を乗り出して、 ノートPC を外に突き出して (落下注意!) みたのだがダメだった。

高層階だと当然遠くの街路まで見渡せるわけで、 やたらと沢山のアクセスポイントが見通し距離範囲に入ってくる。 が、こちらから出す電波が、 同じチャンネルで電波を出す機器に届かなければ衝突回避してもらえない (CSMA/CA, Carrier Sense Multiple Access/Collision Avoidance) わけで、 ノートPC 内蔵のアンテナではどうにも力不足である。

こんなこともあろうかと、 私は長期旅行には La Fonera+ を持っていくことにしている。 ノートPC 内蔵の無線LAN 端末と違って、 La Fonera+ には外部アンテナがあり、 また内蔵アンテナもあるので、 組合わせてダイバーシチ送信/受信が可能である。

La Fonera / La Fonera+ (FON ソーシャル ルータ) は、 本来は無線LAN アクセス ポイントなのであるが、 中身は普通の Linux マシンなので何でもアリである。 もちろん 無線LAN 端末として 使うこともできる。 まずは La Fonera+ をラナイの端ギリギリ (落下注意!) のところに置き、 ノートPC と Ether ケーブルでつなぐ。 ノートPC で試したときに比べてはるかに多くのアクセスポイントが見つかった (実に 49個!)。

無線LAN 端末としての La Fonera+ が見つけたアクセスポイントの一覧 (信号強度 dBm 順):

そもそも、なぜ init(8) を起動する前に /bin/sh を実行したいかというと、 ミニルート (initramfs) 上で 作業を行ないたいから。 initramfs の init (これは init(8) ではなくシェル・スクリプト) の中で、 BusyBox の /bin/sh (/bin/ash) を exec する (つまり PID=1) ことによって、 initramfs 上での作業を可能にする。

init(8) は、 GNU/Linux OS の全てのプロセスの親プロセスだが、 その万物の親すら生まれていない創世記以前に作業を行なえるメリットは数多い。 例えば、ルート・ファイル・システム (root file system) すらマウントしていない段階なので、 マウント後 (つまり init(8) 起動後) には実行不可能な操作 (xfs_repair などのファイルシステム修復操作とか) を行なうことができる。 しかもこのシェルはプロセスID が 1番なので、 このシェル環境上で root file system を「/」にマウントし、 続いて init(8) を exec すれば、 そのまま GNU/Linux OS を起動することができる。

root file system のメンテナンス等は、 別の起動ディスク (CD-ROM や USB メモリ等) からブートして行なうのが一般的だが、 CD-ROM ドライブや USB メモリを準備したり、 あるいは CD-ROM や USB メモリの抜き差しが必要になったりと、 なにかと面倒である。 メンテナンス用の起動パーティションを root file system とは別に用意する、 という方法も考えられるが、 メンテナンス専用のパーティションを維持管理するのが面倒くさい (普段使わないものほど陳腐化して、いざというとき役に立たない)。
initramfs だとハードディスクすら不要 (例えば PXE ブート) でメンテナンスが可能になるし、 普段 GNU/Linux OS 起動用として使ってる initramfs が、 そのまま非常用のメンテナンス環境になるため、 陳腐化する心配がない。
実は「突然死したハードディスクを復旧させる『お手軽パック』」は、 initramfs そのものだったりする。 しかも「復旧」用として作った initramfs というわけではなく、 私が普段 GNU/Linux OS を ブートするときに使っている initramfs と 全く同じものである (だからこそ ハードディスクの突然死問題 が勃発した直後にリリースできた)。

というわけで、 いいことづくめの initramfs シェル環境 (initramfs shell environment) なのだが、 「復旧お手軽パック」実行例 にもあるように、 init(8) 以前の段階で /bin/sh を実行すると

/bin/sh: can't access tty; job control turned off
#

と表示してジョブ制御がオフになってしまう。 つまりこのシェル環境では、 プログラムを実行中に control-C (^C) を押しても止める (正確にいうと SIGINT シグナルを送る) ことができない。

ジョブ制御 (^C などでシグナルを送ること) ができない状態に陥って 初めて沸き起こる制御端末 (controlling tty) に対する感謝の念なのであるが、 initramfs が役目を終えて init(8) が起動して (GNU/Linux OS がブートして) しまうと、 喉元過ぎればなんとやらで 「can't access tty」をなんとかしようという意欲は雲散霧消し、 そのままになっていた。

制御端末になれない initramfs シェル環境に対して何十回目かの悪態をついた後、 ようやく対策を立てるべく原因を調べてみることにした。

Linuxカーネル（ドライバ）のソースを読んでみたところ、 以下の端末デバイスは制御端末に成れないのです。 興味がある人は、ソース、 drivers/char/tty_io.cのtty_open()を見てみてください。

* /dev/console -- カーネルの起動時の端末。
* /dev/tty0 -- tty1～の「Linux Virtual Terminal」のうち、現在表示している物を示す。
* /dev/tty -- 現在使っている端末を示す。
* PTYのマスター側

Linux:制御端末 から引用

initramfs シェル環境で使っている端末は /dev/console だから制御端末になれない。 だから BusyBox には /dev/console という仮想的な端末ではなく、 本物のデバイスを探すための cttyhack というプログラムが付属している。 /bin/sh を実行する代わりに cttyhack /bin/sh を実行すれば ジョブ制御ができると BusyBox のマニュアルには書いてある。

...という解説は上に引用したページをはじめ、 WWW 上のあちらこちらのページで見かけるし、 私としても当然そんなことは先刻承知で、

/bin/sh: can't access tty; job control turned off
# tty
/dev/console
# cttyhack sh
sh: can't access tty; job control turned off
# tty
/dev/tty1
#

などと、確かに cttyhack の働きにより /dev/console ではなく /dev/tty1 を使うようになったものの、 相変わらず「can't access tty」エラーが出ているので困っているわけである。 cttyhack を使っているのにジョブ制御できないわけで、 cttyhack-- と思っていた。

前置きが長くなったが、ここからが本題である。

Aug 18 10:31:30 senri [144077.315932] tg3: eth0: Link is down.
Aug 18 10:33:57 senri [144201.921009] tg3: eth0: Link is up at 1000 Mbps, full duplex.
Aug 18 10:33:57 senri [144201.921228] tg3: eth0: Flow control is on for TX and on for RX.

Aug 18 10:31:30 asao [894103.906436] tg3: eth0: Link is down.
Aug 18 10:33:57 asao [894253.756472] tg3: eth0: Link is up at 1000 Mbps, full duplex.
Aug 18 10:33:57 asao [894253.756472] tg3: eth0: Flow control is on for TX and on for RX.

この日 8/18 はたまたま早朝から出張だった (帰宅したのは翌日 8/19 23:00 近く) ので link down に気付かなかった (もちろんヘルスチェックは行なっているが自宅なのでタイムアウトは長め)。 留守中、 link down 後しばらくたつと link up (正常状態に復旧)、 という繰り返しが何度も起きたようだ。 ログから down 時間を集計してみるとこんな感じ:

3 秒で復旧することもあれば、 20分以上落ちたままのこともあり規則性がないが、 いったん link down/up すると、 down/up を何度か短時間に繰り返す傾向がある。 また次第に down する頻度が上がり、 down している時間も長くなる傾向にあった。 複数のマシンで同時に link down することから、 ハブの故障だと判断できる。 ハブは、 コレガ製 1000BASE-T/100BASE-TX/10BASE-T 8ポート スイッチングHUB CG-SW08GTV2。 2005年11月9日に購入したものなので1年の保証期間は切れているものの、 まだ3年弱しか経過しておらず自宅LAN の中では比較的新しいハブである。

ちょっと壊れるのが早すぎなんじゃないかと思いつつ、 とりあえず余っていた 100Mbps スイッチング・ハブと置き換えて急場をしのぎつつ、 秋葉原に新しいハブを買いに行った。 買ったのは同じくコレガ製の、 1000BASE-T/100BASE-TX/10BASE-T 8ポート スイッチングハブ CG-SW08GTR。 T-Zone で 3742円だった。 8 port の gigabit が 4000円以下とは、 ずいぶん安くなったものだ (標準価格は 9975円)。

というわけで故障したハブを新しいハブで置き換えて一件落着なのであるが、 3年たたずに故障し、 しかも断続的に down するという症状が腑に落ちなかったので、 壊れた CG-SW08GTV2 の筐体を開けてみた。 すると...

iTCO_vendor_support: vendor-support=0
iTCO_wdt: Intel TCO WatchDog Timer Driver v1.02 (26-Jul-2007)
iTCO_wdt: failed to reset NO_REBOOT flag, reboot disabled by hardware
iTCO_wdt: No card detected

この「reboot disabled by hardware」とは何なのかを調べてみると、 Intel I/O Controller Hub 7 (ICH7) Family Datasheet の 78ページ、 Table 2-23. Functional Strap Definitions (Sheet 3 of 3) に、

と書いてある。 つまり ICH7 の SPKR 端子 (Ball# A19) はスピーカ出力なのであるが、 入力端子としても使われていて、 PWROK 入力端子 (Ball# AA4) の立ち上がりエッジ時 (すなわち電源投入時) において SPKR 端子が H レベルであれば、 「No Reboot」モードに固定される。

「No Reboot」モードというのは、 TCO タイマ (つまり Watchdog Timer) による再起動を行なわないモードで、 通常はソフトウェアでこのモードの設定/解除が可能なのであるが、 SPKR 端子によって「固定される」と No Reboot モードのまま変更できなくなる。

具体的には、 「No Reboot」モードの設定/解除は、 ICH7 の「NO REBOOT bit」に 1/0 を書込むことによって行ない、 逆にこの「NO REBOOT bit」を読むことによって現在のモードを確認できる。 Linux カーネルの drivers/watchdog/iTCO_wdt.c に、 このビットを解除し、解除できたか確認するコードがある:

static int iTCO_wdt_unset_NO_REBOOT_bit(void)
{
	...
	/* Unset the NO_REBOOT bit: this enables reboots */
	if (iTCO_wdt_private.iTCO_version == 2) {
		val32 = readl(iTCO_wdt_private.gcs);
		val32 &= 0xffffffdf;
		writel(val32, iTCO_wdt_private.gcs);

		val32 = readl(iTCO_wdt_private.gcs);
		if (val32 & 0x00000020)
			ret = -EIO;
	...
	return ret; /* returns: 0 = OK, -EIO = Error */
}

この iTCO_wdt_unset_NO_REBOOT_bit 関数は、 GCS (General Control and Status Register, オフセット 0x3410) のビット5 に 0 を書込むことによって No Reboot モードの解除を試み、 続いてこのビットを読んで正しく 0 に変わっているか確認し、 確認結果を返す。 つまりこの関数が正常に 0 を返せば、 ICH7 の Watchdog Timer が利用可能であることを示し、 -EIO を返せば、 (No Reboot モード固定なので) 利用不可能であることを示す。

というわけで、 DELL PowerEdge SC440 で Intel TCO Watchdog Timer が利用できない理由は、 電源投入時に SPKR 端子に電圧がかかってしまっていて、 No Reboot モード固定になっているためだろう。 SPKR 端子は内部的にプルダウン (20kΩ) されているので、 SPKR 端子につながっているスピーカを切り離せば SPKR 端子は L レベルになり、 Watchdog Timer が利用できるようになるはず。