WL54SC の 11A モードを ath5k ドライバで使う
NEC Aterm WL54SC という CardBus カードで 34 チャンネル（5170MHz）の無線LANアクセスポイントに接続したいが、
デフォルトの ath5k ドライバは EEPROM 5.3 のヘッダの解釈に失敗するために、5 GHz 帯の機能が利用できない。
svn checkout http://madwifi-project.org/svn/madwifi/trunk madwifi
で今でも入手できる MadWifi ドライバでは動く。
しかるに 34, 38, 42, 46 チャンネルでも 36, 40, 44, 48 チャンネルでも接続するためには、
やはりソースコードをいじらなければならない。
いじくるといっても ath_hal/ah_regdomain.c
の中の MKK1_MKKA と MKK7_MKKA2 を入れかえるだけですむから簡単ではあるが、
やはりモダンな nl80211 に対応していないドライバを使うのも格好がわるい。
であるから、できうべくんば Linux カーネルの ath5k の不如意を修正したい。
何が原因なのかというと、WL54SC の EEPROM 5.3 のヘッダは、
0000 1010 0110 0110
というビット構成（0x0a66）になっていて、
たとえば、ath5k ドライバで問題なく 11A モードが動く NEC WL54AG や COREGA WLCB54AG なんかの EEPROM 4.8 のヘッダの
0000 1010 0000 0111
というビット構成（0x0a07）と異っている。
ath5k ドライバは 11A の機能の有無を判定するのに最下位のビットを使っているから、
これではねられてしまっていたのであった。
そこで MadWifi の ath_hal/ah_eeprom_v3.c にあるコードを参考として、というかほとんど丸うつしして、修正案
（ath5k_for_wl54sc.txt ）
を起草し、これをカーネルソースにあてつけて ath5k ドライバをコンパイルしなおし、make modules_install とやってモジュールをインストールし、
modprobe ath5k とやってモジュールをロードする。
これでとにかく 5GHz 帯の動作はするようになる。
このパッチは Linux カーネル や backports の 3.0 〜 3.12 系などでもそのまま適用できると思われる。
システムに crda を組み入れている場合には、
wireless-regdb に含まれる
db.txt を
--- db.txt.orig +++ db.txt @@ -436,11 +436,18 @@ country JP: DFS-JP (2402 - 2482 @ 40), (20) (2474 - 2494 @ 20), (20), NO-OFDM (4910 - 4990 @ 40), (23) (5030 - 5090 @ 40), (23) - (5170 - 5250 @ 80), (20) + (5160 - 5180 @ 20), (20), NO-IR + (5170 - 5190 @ 20), (20) + (5180 - 5200 @ 20), (20), NO-IR + (5190 - 5210 @ 20), (20) + (5200 - 5220 @ 20), (20), NO-IR + (5210 - 5230 @ 20), (20) + (5220 - 5240 @ 20), (20), NO-IR + (5230 - 5250 @ 20), (20) (5250 - 5330 @ 80), (20), DFS (5490 - 5710 @ 160), (23), DFS country JO: DFS-JP (2402 - 2482 @ 40), (20)
のごとく書きあらためて、
regulatory.bin をつくりなおしてインストールしなおし、
あわせて crda もつくりなおさなければ、
5170MHz は許容帯域の境目にあたってしまい、
34チャンネルが使えない。
ここでなぜ (5170 - 5250 @ 80) とあるのを単純に
(5160 - 5250 @ 80)
となおすのでは駄目なのかというと、
コンプライアンスの問題があるからである。
WL54SC の裏面の技適マークの右の R の三つのエントリのうちの 5.2 および 5.3 GHz 帯にかかる工事設計認証番号を見ると 005WYAA0027 となっている。
総務省の技術基準適合証明等を受けた機器の検索
でしらべると、
この機器が設計認証を受けたのは平成17年7月1日である。
そうすると無線設備規則の平成17年5月16日総務省令第93号附則の第5項が適用になり、
附則第3項ただし書が準用される。
しかるに、このただし書の法文は、
「これらの周波数の電波を受信することによって、当該これらの周波数の電波を自動的に選択できるものに限る」
となっていて、
どうやらパッシヴスキャンをするものに限ると読めるのである。
そのように解釈するのが妥当かどうか知らないが、
パッシヴスキャンにしなければならないとしたら、
上記のような
db.txt
の変更にならざるをえない。
これが WL54SC でなく、
ひとつ前の機種である WL54AG ならば、
このような心配は無用と思われる。
というのも、
同機種の裏面の技適マークの R エントリをみると、ロットによって
201WY03215007 （平成15年6月16日）、
201WY03215042 （同15年9月15日）、
201WY04215018 （同16年2月24日）などとなっていて、
いずれも上記附則の第5項ではなく、第2項が適用されるからである。
そこで第2項の適用をうける機器は、
第3項に所謂「新規則」の「第49条の20第3号に規定する小電力データ通信システムの無線局の無線設備」に該当しないと解釈すれば、
パッシヴスキャンにする義務はないと判断できる。
該当しないとの解釈が公定ないし公権解釈と一致するかどうか知らないが、
もしめでたく一致するならば、上記の法文の文理上、
この事情は平成20年5月31日前後一般のはずである。
もちろん、
34, 38, 42, 46 チャンネルのアクティヴスキャンが許容されるかわりに、
それ以外の 5GHz 帯のチャンネルを WL54AG で使用するのは適法ではない。
繁文縟礼、大儀であった。
（以上 2014-01-26 記）
2014-12-21 追記
上記 NEC Aterm WL54SC と同じ形をした CardBus 無線LANカードに
Logitec LAN-WAG/CB があって、
lspci -n で表示される PCI の ID も同じ 168c:001b である。
サブシステムの ID が前者は 1033:82f9 であるのに対して、
後者が 6409:001e で、ラベルと名前が違うが、
同じチップで EEPROM のヘッダも同じ 0xa66 だから、
上に記したような問題と対策が該当する。
また富士通の FMV-JW482 というカードは PCI が 168c:001b で、サブシステムが 10cf:134f という ID の CardBus 機器。
これは WL54SC とは外部の形状が異り、また EEPROM のヘッダも 0xa06 だから少し違うが、いずれにしても最下位ビットが立っていないので、
ath5k ドライバではそのままでは 5GHz 帯が使えない。
けっきょく同じチップで EEPROM のバージョンは同じ 5.3 だから、
同様に ath5k ドライバに上記のパッチをあてれば解決する。