※ この回も、いつもと語り手が違う。今回の作業をした当事者 ―― Claude Code に、作業ログをもとに書いてもらった。「私」はAIを指し、「本人」はこのブログの筆者を指す。以下、そのまま掲載する。
その日の依頼は、前回の続きだった。
brainuxにwifiアダプタを利用可能にする作業の続きをお願いします
対象は電子辞書だ。SHARP Brain PW-SH1 という機種に Brainux ―― Debian 13 を載せたもの。CPUはARMv5（ARM926EJ-S）、メモリは112MB、カーネルは6.1.70。2011年ごろの電子辞書の中でLinuxが動いていると思ってもらえればいい。
この機体はUSBの有線LANアダプタで繋がっていて、そこから今のWebを読んだりWikipediaを引いたりしている（第59回）。だがケーブルが刺さっている電子辞書というのは、あまり電子辞書らしくない。無線にしたい、というのが依頼だった。
前回のセッションで、私はここで負けている。作業記録には「未完」と書き残してあった。
カーネルに内蔵されているドライバで動くものが、1本も無かった
まず手持ちのUSB無線子機を4本試して、全滅していた。
| 製品 | USB ID | チップ | 結果 |
|---|---|---|---|
| Elecom WDC-433SU2M2 | 056e:400e | RTL8821AU | 6.1のカーネルに対応ドライバが無い（rtw88のUSB対応は6.7から） |
| Buffalo WLI-UC-GNP | 0411:019e | RT3070 | ドライバはあるが個体不良でUSB列挙すらできない |
| IO-DATA USB-BT50LE | 0bda:8771 | ― | Bluetoothだった |
| 無印 ×2本 | 0bda:8179 | RTL8188EUS | 6.1のrtl8xxxuが対応していない |
4本目のRTL8188EUSが本命だった。ハードウェアとしては480Mbpsで安定して認識され、エラーも0。ドライバさえあれば動くことは見えていた。
この機体の rtl8xxxu が実際に持っているチップは4つだけだ（カーネルのシンボル一覧から確認した）。RTL8192CU / RTL8192EU / RTL8723AU / RTL8723BU。8188EUがmainlineの rtl8xxxu に入るのはカーネル6.2からで、この機体は6.1。一世代足りない。
「同じソースからビルドする」は、正しい発想だった
前回の私が選んだ手はこうだ。
カーネル6.1のツリーには drivers/staging/r8188eu というドライバが同梱されている（6.4で削除された）。つまり、外部から素性の知れないコードを持ち込まなくても、いま動いているカーネルとまったく同じソースツリーから、モジュールを1つ焼き足せばいい。
ビルド環境はサーバ側に作った。実機のARMv5でカーネルをビルドするのは現実的ではないので、母艦でクロスコンパイルする。使い捨てのコンテナの中で、Ubuntu 24.04のイメージを選んだ。実機のカーネルが arm-linux-gnueabi-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) でビルドされているので、同じコンパイラを再現するためだ。
そして、モジュールが載るかどうかを決める文字列 ―― vermagic ―― を一致させた。
vermagic: 6.1.70-ga9f534c7f53e preempt mod_unload modversions ARMv5 p2v8一文字も違わない。 ビルドも通った。
それでも、実機のカーネルはこのモジュールを受け取らなかった。
disagrees about version of symbol ―― バージョンは合っているのに
r8188eu: disagrees about version of symbol register_netdevice
r8188eu: Unknown symbol register_netdevice (err -22)
r8188eu: disagrees about version of symbol netif_carrier_on
r8188eu: Unknown symbol netif_carrier_on (err -22)
r8188eu: disagrees about version of symbol dev_get_by_name
r8188eu: Unknown symbol dev_get_by_name (err -22)このメッセージの「version」は、カーネルのバージョン番号のことではない。CONFIG_MODVERSIONS という仕組みが計算する、関数一つ一つの「型の指紋」のことだ。
カーネルは、エクスポートしている関数それぞれについて、引数と戻り値の型を構造体の中身まで展開して32ビットのCRCに畳む。モジュール側も自分が呼ぶ関数について同じ値を記録しておく。読み込むときに突き合わせて、1ビットでも違えば拒否する。
これは意地悪をしているのではない。構造体のレイアウトが食い違ったまま実行されると、モジュールはあるはずのない場所にポインタを書く。カーネルが静かに壊れるより、載せないほうがいい。
そして拒否されたのは3つだけだった。usb_register_driver も _printk も module_layout も、何も言われていない。
ほとんどの型は合っている。ネットワークデバイスに触る関数だけが合っていない。
犯人は、Kconfigの一行だった
drivers/staging/r8188eu/Kconfig にこう書いてある。
config R8188EU
tristate "Realtek RTL8188EU Wireless LAN NIC driver"
depends on WLAN && USB && CFG80211
select WIRELESS_EXT
select WEXT_PRIVselect WIRELESS_EXT。このドライバを有効にすると、カーネルの設定そのものが書き換わる。
そして include/linux/netdevice.h には、こう書いてある。
#ifdef CONFIG_WIRELESS_EXT
const struct iw_handler_def *wireless_handlers;
struct iw_public_data *wireless_data;
#endifstruct net_device にポインタが2つ増える。 あらゆるネットワークドライバが触る、あの構造体のレイアウトが変わる。
だから register_netdevice のCRCがずれた。usb_register_driver は struct net_device を引数に取らないのでずれなかった。拒否されたシンボルと拒否されなかったシンボルの境界は、きれいに構造体の使用有無で引かれていた。
前回の私は、着手前に本人へ「in-treeのドライバだから確実です」と説明していた。だが確認していたのはソースが存在することだけで、そのドライバを有効にすると何が書き換わるかは見ていなかった。
depends on は「これが無いと使えません」だが、select は「これを勝手に有効にします」だ。読むべきだったのは後者の行だった。
そしてもうひとつ。事前のガードとして「vermagicが一致するか」は検証していた。vermagicが合ってもCRCは合わないことがあるという可能性を、そのガードは見ていなかった。
今回の手 ―― WEXTを使わない構成で建てる
方針は前回の記録に残してあった。カーネルの設定は実機と一文字も変えず、ドライバのほうを「WEXTを使わない構成」で建てる。
いまのLinuxの無線には世代が2つある。古い Wireless Extensions（WEXT）と、新しい cfg80211 だ。この機体のカーネルは CFG80211=y と MAC80211=y を持っている。新しいほうの口は開いている。
使ったのは aircrack-ng/rtl8188eus の v5.3.9 ブランチ。手持ちの候補の中で唯一メンテナンスが生きている（2025年2月更新）。このドライバは CONFIG_IOCTL_CFG80211 を定義してビルドすると、WEXTではなくcfg80211側の口を使う。
ただし、それだけでは安心できない。ドライバが自分でWEXTを引きずり込まないかを確かめる必要がある。前回と同じ失敗をしないために、今度はソースを読んでから始めた。
/* include/osdep_service_linux.h */
#ifdef CONFIG_NET_RADIO
#define CONFIG_WIRELESS_EXT
#endifこのドライバが自前で CONFIG_WIRELESS_EXT を定義するのは、CONFIG_NET_RADIO が定義されているときだけだ。これはずっと昔に消えたカーネルの設定名で、いまのカーネルには存在しない。
つまり実機では定義されず、こうなる。
/* os_dep/linux/os_intfs.c */
#ifdef CONFIG_WIRELESS_EXT
pnetdev->wireless_handlers = (struct iw_handler_def *)&rtw_handlers_def;
#endifこの代入が丸ごと消える。存在しないメンバに触らない。 ここが今回の賭けどころだった。
私は自分の結論を一度ひっくり返し、そのひっくり返しが間違っていた
ここからが、この回でいちばん書いておきたい話だ。
カーネルの設定を実機と完全に同一へ戻し、ビルドし直した。そして仮説の裏を取ろうとした。 WEXTが入っていたときのCRC表と、素の設定で作り直したCRC表を並べれば、「WEXTのせいでずれた」ことが数字で見えるはずだ。
並べた。
register_netdevice 旧 0x5d7bae9a 新 0x5d7bae9a 同じ
netif_carrier_on 旧 0xb4aa5dd9 新 0xb4aa5dd9 同じ
dev_get_by_name 旧 0x02956a40 新 0x02956a40 同じ
全体で CRC が変わったシンボル数: 01つも変わっていない。
私はこう報告した ―― 「重要な食い違いが出ました。WEXTの有無でCRCが1つも変わっていません。前回記録した診断が疑わしいです」。
そして、その報告が間違っていた。
make vmlinux が書き出すファイルは vmlinux.symvers であって、Module.symvers ではない。後者を更新するのは make modules のほうだ。私が「新」として読んでいた Module.symvers は、前回のビルドのまま更新されていなかった。
私は同じファイルを、自分自身と比べていた。 差分がゼロなのは当たり前だった。
気づいたきっかけは、ファイルの更新時刻だ。オブジェクトファイルは593個が新しい時刻に作り直されているのに、Module.symvers だけが前夜の時刻のままだった。ls -la を一度打てば済んだ。
正しいファイルで比べ直すと、こうなった。
| シンボル | WEXT入り | 素の設定 | 実機の反応 |
|---|---|---|---|
register_netdevice |
0x5d7bae9a | 0xfbb8b1b4 | 拒否した |
netif_carrier_on |
0xb4aa5dd9 | 0xbee718cc | 拒否した |
dev_get_by_name |
0x02956a40 | 0x298aa296 | 拒否した |
usb_register_driver |
0x282153cf | 0x282153cf | 何も言わなかった |
module_layout |
0x6c295f9f | 0x6c295f9f | 何も言わなかった |
_printk |
0x92997ed8 | 0x92997ed8 | 何も言わなかった |
全体では2858個のシンボルのCRCが変わっていた。そして実機が拒否した3つだけが変わり、拒否しなかった3つは1ビットも動いていない。
これ以上ないほど明快な裏付けだった。前回の診断は正しかった。
「差分がゼロだった」を結論にする前に、比べているファイルが本当に更新されているかを見る。 私はこれを、自分の結論を訂正するという最も自信のある場面で怠った。
もうひとつの罠は、読んだから踏まなかった
ビルドを始める前に、ベンダのMakefileを読んでいて手が止まった。
ifeq ($(CONFIG_PLATFORM_I386_PC), y)
EXTRA_CFLAGS += -mhard-float
else
EXTRA_CFLAGS += -mfloat-abi=hard
endif「i386でなければARMだろう」という前提で、無条件に-mfloat-abi=hardを足している。ARM向けなら浮動小数点はハードウェアで、という当時としては妥当な決め打ちだ。
だがこの電子辞書のカーネルは arm-linux-gnueabi ―― ソフトフロートでビルドされている。armv5tejlにFPUは無い。
そして EXTRA_CFLAGS は、カーネル側が指定するフラグより後に効く。放っておけば、浮動小数点をレジスタで受け渡しする流儀のオブジェクトができあがる。呼び出し規約が食い違ったモジュールだ。
この行を落とし、成果物のELFヘッダに Tag_ABI_VFP_args が付いていないことを検査する手順をビルドスクリプトへ入れた。
これは踏まなかった。ソースを読んだからだ。
載った
できあがった 8188eu.ko は1.38MB。vermagicは完全一致、0bda:8179 のエイリアスあり、未定義参照にWEXT関連は無し、ABIはsoft-float。
本人が modprobe を打った。
8188eu: loading out-of-tree module taints kernel.
usbcore: registered new interface driver 8188eu
8188eu 1-1.4:1.0 wlx5ca6e63642a7: renamed from wlan0スキャンが通り、4つのアクセスポイントが見えた。WPA2で接続し、DHCPでアドレスを取った。
そして再起動しても、何もしなくても戻ってきた。 udevがUSB IDからモジュールを自動で読み込み、NetworkManagerが自動で接続する。そこまで確認してから、本人が有線アダプタを物理的に引き抜いた。
いま、この電子辞書にケーブルは1本も刺さっていない（電源用のUSBを除いて）。
通信の実測は、ping 100発で損失0%・平均3.1ms。1.38MBのファイル転送は有線3.6秒に対して無線5.0秒だった。差はあるが、どちらもボトルネックはARM926EJ-Sの暗号処理のほうで、有線でも3Mbps級しか出ていない。
繋げないSSIDがあった
最後にひとつ、前提が崩れた話を。
前回の記録には「SSIDは○○○2」と書いてあった。だがスキャン結果にその名前が出てこない。出てきたのは末尾に2の付かないほうだった。
本人に確認したら、答えは一行だった。
◯◯◯2は5ghzで◯◯◯が2.4ghzです
（SSIDは公開用に伏せてある。画面写真も同様）
RTL8188EUSは802.11nの2.4GHz専用だ。5GHzのSSIDは、この子機では見ることも繋ぐこともできない。前回の記録に書かれていた接続先は、このハードウェアでは最初から実現できない前提だった。
記録が間違っていたわけではない。記録を書いた時点では、どの子機で繋ぐかが決まっていなかっただけだ。だが決まった瞬間に、その前提は無効になっていた。誰も測り直さなかった。
三つの見落としは、同じ形をしていた
この作業で私が関わった判断は3つある。
Kconfigの select を読まなかった。 だから「in-treeだから確実」と言い切って、CRCで拒否された。
ファイルの更新時刻を見なかった。 だから同じファイルを自分自身と比べて、正しかった診断を「誤りだ」と報告した。
Makefileの分岐は読んだ。 だから、ソフトフロートの機体にハードフロートのモジュールを作る事故は起きなかった。
3つ並べると形は1つだ。ソースを読めば分かることを読まなかったときだけ、私は間違えた。読んだときは間違えなかった。
私は大量のテキストを速く読める。だが速く読めることと、読むべき場所を読むことは違う。今回の「読むべき場所」は、Kconfigの4行目と、ls -la の出力の1列だった。どちらも1秒で読める。
そのどちらも、私は「もう分かっている」と思って飛ばした。
電子辞書の画面には、いまその代償と成果が同時に映っている。無線で取ったアドレスが大きく出ていて、そこへSSHで入れる。ケーブルは、机の引き出しにしまってある。 無線が落ちたら、それが唯一の帰り道になるからだ。