2018/09/24

wpa_supplicantのデバッグ情報

元々Windows Vistaが入っていたdynabook SS SX/15AをNetBSD/i386に入れ換えて使っています。近所にある図書館が館内で無料のWi-Fiを提供しているので、繋ごうとしたらトラブルが続出しました。

この無料Wi-Fiは以前に繋げたことがあるので、 繋がる筈だとは思っています。ただし今年4月から方式を変えたようなので、ちょっと手間取りましたが、ともかく繋がることは間違いありません。ところが先週末に繋げようとしたら、うまくいきません。何が悪いのか不明だし、なにしろハードウェア自体に問題がある可能性も捨てきれないし、もしかしたらNetBSDでは何か一工夫要るのかもしれません。

そこで館内に掲示されている無料Wi-Fiのお知らせを見ると、8月末にSSIDを変えたようです。だから繋がらなかったのでしょう。Wi-Fiに接続するためのSSIDとパスフレーズは/etc/wpa_supplicant.confで指定しているので、変更しました。しかし繋がりません。今度は何が問題なのでしょうか。

この問題に限らず、何か障害が発生した時に問題個所を想定して、闇雲に設定を変えて様子を見るという方法で対処すると、不必要に解決までの時間がかかってしまう恐れがあります。上手く問題が解決できれば良いのですが、原因がはっきりしないままに、あれこれファイルを変更してリブートを繰り返したところで、無駄足を踏んでいる可能性が高いと思います。

 問題を把握するために/var/log/messagesを参照するのは基本中の基本かもしれませんが、特に情報は得られませんでした。/etc/rc.confでは「wpa_supplicant=YES」を指定しています。WPA_SUPPLICANT(8)を確認すると、デバッグ情報を出力することができるようです。出力先ファイル名を指定することもできるようなのでwpa_supplicant_flagsに「-d -f /var/log/wpa_supplicant.log」を追加しました。

かなり多くのデバッグ情報が出力されますが、次のような行が出ていました。
wpi0: WPA: 4-Way Handshake failed - pre-shared key may be incorrect
/etc/wpa_supplicant.confに追加した情報は/usr/sbin/wpa_passphraseで生成したのですが、入力ミスがあったのかもしれません。生成し直したら、繋がったようです。デバッグ情報のファイルに出力されていた状態遷移の状況を抽出すると、次のようになっていました。
wpi0: State: DISCONNECTED -> DISCONNECTED
wpi0: State: DISCONNECTED -> SCANNING
wpi0: State: SCANNING -> ASSOCIATING
wpi0: State: ASSOCIATING -> ASSOCIATED
wpi0: State: ASSOCIATED -> 4WAY_HANDSHAKE
wpi0: State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE
wpi0: State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE
wpi0: State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE
wpi0: State: 4WAY_HANDSHAKE -> DISCONNECTED
wpi0: State: DISCONNECTED -> SCANNING
wpi0: State: SCANNING -> DISCONNECTED
wpi0: State: DISCONNECTED -> DISCONNECTED
wpi0: State: DISCONNECTED -> SCANNING
wpi0: State: SCANNING -> ASSOCIATING
wpi0: State: ASSOCIATING -> ASSOCIATED
wpi0: State: ASSOCIATED -> 4WAY_HANDSHAKE
wpi0: State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE
wpi0: State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE
wpi0: State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE
wpi0: State: 4WAY_HANDSHAKE -> DISCONNECTED
wpi0: State: DISCONNECTED -> SCANNING
wpi0: State: SCANNING -> DISCONNECTED
wpi0: State: DISCONNECTED -> DISCONNECTED
wpi0: State: DISCONNECTED -> SCANNING
wpi0: State: SCANNING -> DISCONNECTED
wpi0: State: DISCONNECTED -> DISCONNECTED
wpi0: State: DISCONNECTED -> SCANNING
wpi0: State: SCANNING -> ASSOCIATING
wpi0: State: ASSOCIATING -> ASSOCIATED
wpi0: State: ASSOCIATED -> 4WAY_HANDSHAKE
wpi0: State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE
wpi0: State: 4WAY_HANDSHAKE -> GROUP_HANDSHAKE
wpi0: State: GROUP_HANDSHAKE -> GROUP_HANDSHAKE
wpi0: State: GROUP_HANDSHAKE -> COMPLETED
接続完了するまでの間に何回か「DISCONNECTED」という状態が出てくるのが不安ですが、ともかく接続できました。やれやれ解決かと思いきや、せっかく接続できたのに、すぐに接続が切れてしまいます。しかも次のような、不穏なメッセージが残っています。
wpi0: fatal firmware error
もしかすると無線LANインターフェイスが故障しているのかもしれません。何分にも旧いマシンですので、その可能性は否定できません。もしそうだとすれば、パーツを交換すれば綺麗に直ると思いますが、パーツが手に入るか不明だし、修理に出すとしても手間賃だけでも安いPCが買えるくらいになってしまいそうです。

USBポートに挿す無線LANの子機を買うという手段もあるかもしれません。NetBSDで使えるか否か不明ですが、例えば「TP-Link WIFI 無線LAN 子機 11n/11g/b デュアルモード対応モデル TL-WN725N」のようなものです。

しかし内心気になっているのが、本当に無線LANインターフェイスが故障しているだろうか?ということです。上述したメッセージが出力されているのは事実ですが、これは本当に無線LANインターフェイスが故障の実態を表していると信じて良いのだろうか、若干疑っているということです。NetBSDのバグではなかろうかと考えているということです。

このように考えてしまう理由は、つい最近までサウンド機能が動かなかったのに、カーネルのバージョンを上げたら、音が鳴るようになったという経験をしているからです。現在使用中のカーネルは次の通りです。
NetBSD dynabook 8.99.24 NetBSD 8.99.24 (GENERIC) #0: Mon Aug 20 01:47:02 JST 2018  root@dynabook:/usr/src/sys/arch/i386/compile/obj/GENERIC i386
このPCにNetBSD/i386を入れた時のカーネルは7.0でしたが、そのときはサウンド関係が全滅でした。ブート時のメッセージを見ると、それらしきハードウェアは検出しようとしていますが、何やらエラーが出て、結局音が出ませんでした。ところがカーネルを更新したら、何の問題もなくブート時にハードウェアが認識されたという経験をしているのです。

無線LANも同じような話ではないかと思うこともあります。NetBSDのカーネルのソースコードは全て参照できるわけですから、問題があれば調査できるはずだ、というのは「原理的には」その通りです。しかしサウンド不具合のときもソースを参照しましたが、素人がちょっと見たらすぐに原因が判明するような単純な話ではありません。それなりの経験がないと、なかなか手に負えない問題です。

すぐに問題が解決できるとは考えていませんが、なんとか技術力向上を目指しつつ、対策を考えてみようと思います。



0 件のコメント:

コメントを投稿