あり

よくパソコンのメモリとかの裏に「パリティ有」とか書いてあったりします。
昔から聞いたことがあった単語だったのですが、まあいいやと思っていたのですが、
最近それを知る機会があったので、せっかくなのでメモしておきます。

まずWikpediaの記載によると、

パリティビット(parity bit)は、コンピュータと通信において、与えられた二進数に対して全体の奇偶性を保つために与えられる一桁の二進数(つまり 0 か 1)である。パリティビットは最も単純な誤り検出符号である。

もうこの時点で意味がわかんない。「奇遇性」ってヒマがあれば追ってみるけど別にいいやと思っちゃいますね普通。

パリティチェックの基本については、以下ページがすごく参考になりました。
通信基本用語 – 誤り制御 | LINEEYE
http://www.lineeye.co.jp/html/term_ayamari.html
エラー制御
http://www.asahi-net.or.jp/~ax2s-kmtn/error.html

まずこれは、あるデータを通信する場合に、そのデータが正常なものなのかをやんわりと検証するためのものです。
送信側は知っていても、受信側は受信するだけで、それが正しいのかどうかはわかりません。

なので、送信するデータを元に、明白な計算結果を一緒につけてあげるのがパリティビットの役割です。

たとえば、「A」も文字コードは10進数で「65」で、1バイトで表現できます。
これを2進数に変換すると「01000001」になります。

パリティビットのルールは、送信側と受信側で決めておくことが出来ますが、たとえばパリティビットは偶数です、と決めたとすると、
上記の「01000001」の中の1の数が偶数であれば、最後に「0」を付与して送信します。
（パリティビットは奇数です、と決めた場合は、パリティビットを合わせた1の数が奇数になるように送信側で調整します。）

受信側は、010000001と「0」をあわせて受信しており、1の数がちゃんと偶数であればOKとします。
途中、通信状態によりどこかのビットが反転（0が1、1が0）になった場合には全体として偶数にならないのでエラーを検出できます。
ただし、この場合はたまたま2つのビットが反転した場合にはエラー検出できません。
全体として奇数か偶数かしかわからないので。これを垂直パリティ方式と言います。
これがWikpediaの「奇遇性」と言うことなんだろうな。

そこで、1キャラクタだけではなく、ある単位でパリティビットを与えて、それがどうなのかを計算する方法があります。
それが水平パリティ方式と言うことになります。

たとえば、「ABCD」と言うデータがあったとしたら、これを2進数にしてリストすると、
A:01000001
B:01000010
C:01000011
D:01000100

となります。これの垂直パリティビットは、偶数パリティの場合は「0010」になりますが、これのタテのパリティビットも算出して送ります。
これをBlockCheckCharacter(BCC）と言うそうですが、以下のようになります。

A:01000001 0
B:01000010 0
C:01000011 1
D:01000100 0
————–
00000100 1

これで、垂直パリティと組み合わせると、多少はエラー検出率があげることが出来ます。
ただ、これはほんとに低レイヤーの処理の話ですなぁ。

EclipseのSubversionクライアントのプラグインのsubversiveを入れるときに、
その接続に必要なSVN Connectorsを選択する必要があります。

これは結局どれを選べば良いのか？というかどんな違いがあるのか？
過去の経験や公式ページの説明などをまとめておきたいと思います。

まずは、subversiveのドキュメントに以下が書いてあります。
Eclipse Subversive – Documentation
http://www.eclipse.org/subversive/documentation/faq.php#connectors

What are the differences between SVN Connectors and which one to choose?
JavaHL is a native client implementation (so it needs a binaries to work (dll on Windows, so on Unix and so on). It is developed by tigris with Subversion itself as a Java binding for subversion.
Pros:
There is always a new version of this client with the new version of Subversion
Cons:
To work with SSH protocol you need to create a tunnel manually
There is no interface to configure proxy server settings
It’s almost impossible to get to work together JavaHL 1.5.x and 1.6.x clients, cause Java class loader can not use binaries with the same names in two plug-ins.
Because of native binaries usage any crash in the library makes Eclipse to crash either.

SVNKit is a pure Java implementation of the client (reverse engineered one), so it can be run on any OS with JRE installed.
Pros:
You do not need to find the binaries for you OS to get it to work
There is an interface for configuring proxy server settings
The work with SSH is incapsulated inside the client
It will never crash your Eclipse IDE instance
Cons:
It’s new versions are released always some time after Subversion release
Sometimes it inherits bugs from the native code while adopting it
The first versions (BETAs and RCs) are sometimes very unstable

It’s only for you to choose which connector to use.

Google翻訳でページをそのまま翻訳してみたらやはり厳しい結果（笑）になったので、雰囲気で意訳してみます。

選択するSVN Connectorsにはどのような違いがありますか？

JavaHLは、実行環境に依存した実装です。（Windowsではdll、Unixではso）。tigris社でのSubversionに関連する開発は、これで行われています。

■長所

• このクライアントの新しいバージョンは、常にSubversionの最新バージョンに対応しています。

■短所

• SSHプロトコルを使用する場合、自前でトンネルを作成する必要があります。

• Proxyサーバーを使用する場合の設定が出来ない。
• JavaHL1.5.xと1.6.xをJavaクラスローダーは同じ名前で実行することがまず出来ません。
• ネイティブライブラリの一部クラッシュがEclipse全体に影響を与えます。

SVNKitはPure Javaで実装されたクライアントで、JREさえインストールされていればOSを問わず動作させることが出来ます。

■長所

• OSのネイティブライブラリを意識する必要がありません。

• Proxy Serverの設定を行うインターフェイスがあります。
• SSHの動作はクライアント処理に内包されています。
• クラッシュした際でも、Eclipseに影響がありません。

■短所

• SVNKitの最新バージョンは、Subversionリリースのしばらく後にリリースされます。

• ネイティブコードからバグを引き継いでしまうことがあります。
• 最初のバージョン（BETA, RC）は非常に不安定です。

この説明だけを見ると、ネイティブのJavaHLが安定していればそれを使用したほうが良さそうですね。
パフォーマンスにも多少影響がありそうだし・・・。
ただ、以前JavaHLのConnectorとTortoiseSVNを併用していたときに、Subversionの管理ファイルのバージョンかなんかが一致しなくて、TortoiseSVNのバージョンを落としたりして対応したような気がします。
（まあそれは、SVNKitでも同じか・・・）

JavaHLの場合は、ProxyやSSHが設定できないとのことですが、そうだったっけな？
手元での環境で、SVNのConnectorをJavaHLにして確認してみると、リポジトリ追加の際の「SSH」のタブが設定できない・・・。
ただ使わないので別にいいや。Proxyの設定はどこに効いてくるのすらわかりませんでした。
今までJavaHLはなんとなく使用を避けてたのですが、これからちょっと使ってみます。

Lavie MにCentOSを入れて使ってみるの続編です。

CentOS5.4を使って普通に使えるとこまでは行きましたが、このLavie Mには無線LANインターフェイスが付いている模様。
これを何とか使ってもうちょっと快適に使いたいことろです。

Linuxで無線LANを使うには
を参考にさせて頂きました。

環境は
・CentOS5.4（3.9からアップグレード)
・NEC Lavie M LM700/7
・無線LANルーター親機 Bufferlo AirStation WHR-G

まず付いている無線LANインターフェイスはなんなのかを調べたい。これは、GUIの「システム」-「管理」-「ネットワーク」で調べられるけど、コマンドではどう調べるのかも押さえておきたい。

コンピュータに接続されているハードウェア（OSが認識できている）は以下コマンドで調べられます。

# lspci

で、ずらずらリスト出力されるのですが、一番下に

02:09.0 Ethernet controller: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01)

と出ているので、Atheros AR5001X+というのが無線LAN用のハードウェアだと分かります。

そして、このハードウェアを使用するためのドライバがあるはずですが、それは以下の場所を見てみます。
もっといい方法があるかも？

# ls /lib/modules/2.6.18-164.el5/kernel/drivers/net/wireless

すると、「ath5k」というモジュールがあるのがわかります。
このへんは感覚なのですが、「Atheros AR5001X+」と紐づけるにはまず
5k　→　5000で、
athが会社名
なのでそれっぽいな、という判別方法しかないのですが、もっといい判別方法ないのかなぁ？

これのドライバはどこに読み込まれているのか？読み込まれているモジュールを取得するには、以下コマンドを使います。

# lsmod

これでath5kが読み込まれているのが確認出来ました。
というか、これは確認方法で、既にここまでは何もしなくても出来ていました。

全く勘違い編

最初は、iwconfigというコマンドを軸にいろいろ以下のようなことをやっていたが、これはあんまり意味がなかった。

無線LANデバイスをデスクトップのGUIの設定ツール（システム-管理-ネットワーク）から起動すると

Error for wireless request "Set Mode" (8B06):
Set failed on deice wlan0: invalid argument
Error for wireless request "Set requency"(8B04):
 invalid argument "自動".

と出て失敗してます。
これの設定ファイルである、/etc/sysconfig/networks-scripts/ifcfg-wlan0を見てみると

CHANNEL=自動

とか書いてありました。確かにGUIの設定で「自動」って選択項目があったので、それをそのまま設定してくれちゃってたのかもしれませんが、
普通、ドライバに渡すパラメータが日本語というのはまだまだないんじゃないかと。
ここをコメントアウトして、再度起動してみると

Error for wireless request "Set requency"(8B04):
 invalid argument "自動".

の方のエラーが消えたので、SetModeで失敗している原因ぽい「MODE=Auto」
をコメントにしたら、とりあえず起動のエラーは消えました。

というか、GUIの「ワイヤレスデバイス設定」のモードを「自動」にするとどうもおかしくなるので「管理」にしたら
この辺のifcfg-wlan0の記述がおかしなのも直ったみたいです。
この状態で、以下コマンドをやってみると、親機が見えているようでした。

# iwlist wlan0 scanning
 Cell 02 - Address: (親機MACアドレス)
             ESSID: （SSID）
　　　　　　　　：

見えているのであとちょっとだ！と思っていたのですが、ここからiwconfig系のことを何やってもだめ。
どうやっても、

Error for wireless request "Set requency"(8B04):
 invalid argument "自動".

が出てしまい、うまく起動できないのです。

解決編

じゃあ、まず基本的なところから確認しようと思い、親機をブラウザ設定画面で確認しました。
親機の現在の設定はAOSS(AirStation One-Touch Secure Systemの略らしい)を使用しており、この暗号化レベルがいくつか並んでいます。
・WPA-PSK-AES
・WPA-PSK-TKIP
・WEP128
・WEP64

これの「WPA-PSK-AES」のところに（現在使用中）となっているので、これを使っているのだろうと想像しました。
WPAというのは、従来のWEPという規格の改良版ということなので、これはこのままでよさそうです。

WPAとは 【Wi-Fi Protected Access】 – 意味/解説/説明/定義 ： IT用語辞典

ところで、このWPAでLinuxを無線LANクライアントにする場合、どうがんばっても先ほどのiwconfigなどを使ってもだめなようです。
そこで、wpa_supplicantというツールを使用するとつなぐことができると言うことを聞いたのでやってみました。

参考ページ：
wpa_supplicant
YANO’s digital garage – madwifiとwpa_supplicant
ごえごえの Linux 備忘録: CentOS+INSPIRON 700m 無線(WPA-PSK)設定

まずwpa_supplicantはyumで普通にインストール出来た。

# yum install wpa_supplicant

続いて、このwpa_supplicantの設定をします。
まずは、wpa_supplicantファイルを確認します。
とはいっても、今回インターフェイスやドライバーに特に変わったことはやっていないのでそのままでよいと思います。

# vi /etc/sysconfig/wpa_supplicant
　　：
INTERFACES="-i wlan0"
　　：
DRIVERS="-D wext"
　　：

次に、/etc/wpa_supplicant/wpa_supplicant.confです。

# vi /etc/wpa_supplicant/wpa_supplicant.conf
network={
     ssid="（設定されているSSID）"
     proto=WPA
     pairwise=CCMP
     group=CCMP
     psk=(パスフレーズ)
}

(設定されているSSID)は、AirStationの設定画面に設定されているSSIDを設定します。
(パスフレーズ)も、同じ欄にある「暗号化キー」をそのまま入れればいいのかなと思ったらやはり駄目で、
これをクライアント側で暗号化？するために、wpa_passphraseというツールを使います。
ためしに、SSIDをAAA、パスフレーズをAAAAAAAAでやると以下のように出力されます。

# wpa_passphrase AAA AAAAAAAA
network={
    ssid="AAA"
    #psk="AAAAAAAA"
    psk=2f2681c2d3d2d8d1e・・・

これを先ほどのSSIDと暗号化キーで出た出力を設定すればよいです。
これでwpa_supplicantを起動します。