Buffalo WLI2-TX1-G54 の分解と無線 LAN カードの取り外し

昨日 NVRAM へポート設定に誤った値を書き込んだため、文鎮化してしまった バッファローのイーサネット・コンバータの WLI2-TX1-G54 を分解しました。

文鎮化してしまった WLI2-TX1-です。

Buffalo WLI2-TX1-G54 が文鎮化（レンガ化）
http://near-unix.blogspot.jp/2016/06/buffalo-wli-tx1-g54.html

経緯

このブログの掲示板へ有益な情報を多く提供してくださる SSS さんより、LAN ポートのアクセスが出来なくなったときに、試して欲しい脱出方法として、WLI2-TX1-G54 の内部にある無線 LAN カード（Mini-PCI）を取り外す方法が紹介されていました。

WLI-TX1-G54の文鎮化の記事について
http://livingston.bbs.coocan.jp/?m=listthread&t_id=23

これは無線 LAN カードがなくなることにより Linux システムが自動的にポート番号を割り振り直してしまう特徴を活かして、新たに振り直されたポート番号によって運が良ければ通信が出来なくなっている状態から脱出できるかもしれないというものでした。

もう文鎮化してしまっているので、一度は試してもよい方法だと考えて試してみることとしました。

WLI2-TX1-G54 の分解

以前にも同様の筐体を分解したことがあるため、分解作業は順調に行うことができました。

頭頂部のカラー部品を取り外しました。分解を参考にする読者さんは爪の位置をよく観察して分解してください。

頭頂部のカラー部品を取り外したところ

前面部品を取り外しました。頭頂部の爪を外した後、左右の側面の爪を外して、最後に底部の爪を外す要領で取り外しました。

前面部品を取り外したところ

左右に筐体を分割しました。これも頭頂部にある二箇所の爪を外した後、底部の一箇所の爪を筐体を上下にずらすような形で爪を外しました。最後に背面部分の二箇所の爪を外しました。

筐体を左右に分割したところ

内部に収まっているボードやアンテナ類を取り外しました。

筐体からボードを取り外したところ

無線 LAN カードの取り外し

ハンダ付けで固定されている無線 LAN カードをハンダゴテを使って取り外しました。

ボードから無線 LAN カードを取り外したところ

動作確認

WLI2-TX1-G54 の無線 LAN カードを取り外して、LAN ポートへパソコンからケーブルを接続しました。WLI2-TX1-G54 の LAN ポートにはどのような IP アドレスが設定されているのか不明のため、パソコン側には arp コマンドを使って IP アドレスを 192.168.1.1 へ設定しておきました。

-- arp コマンドの設定例 --

# arp -s 192.168.1.1 00:11:22:33:44:55

現状の DD-WRT v23 SP2 がインストールされている状態では、LAN ポートの反応はありませんでした。そして家庭内 LAN へ接続しなおして、DHCP による IP アドレスをしてもらう状態にしてみましたが、IP アドレスが DHCP サーバから配給された気配はありませんでした。

どうも無線 LAN カードを取り外しても適切なポート番号が割り振られなかったもようです。

TFTP による流し込み

この無線 LAN カードを取り外した状態で TFTP によるファームウェアの流しこみができるか確認してみました。運良くこの TFTP による流し込みは生きているようです。そこで Openwrt Backfire 10.03.1 をインストールしてみました。

OpenWrt で動作確認

OpenWrt がインストールされた状態で、再度上記ように WLI2-TX1-G54 の LAN ポートの確認を行ってみましたが、反応はありませんでした。

OpenWrt 上でハードリセット

そして DD-WRT の時には失敗した 30/30/30 ハードリセットを この OpenWrt 上でも行ってみました。DD-WRT の時には、リセットボタンを押していても LED ランプは無反応でしたが、OpenWrt では反応がありました。これはハードリセットにより NVRAM を消去してくれた可能性がありました。

再起動させて動作確認を行ってみましたが、OpenWrt では元々動作しているのか不明でした（笑）。

再度 DD-WRT のインストール

そこで TFTP によるファームウェアの流し込みによって DD-WRT v23 SP2 を再度インストールし直しました。そして無線 LAN カードを取り付けて DD-WRT の SSID が発射されていないかを確認しました。しかし待てど暮らせど DD-WRT の SSID を発見することができませんでした。OpenWrt 上でのハードリセットは失敗だったようです。

DD-WRT を再度インストールして無線 LAN 通信が可能となっているかどうかを確認しました。

いくつかこの文鎮化した状況を脱出するための方法を掲示板上にいくつかアドバイスして頂いておりますので、今後これらを確かめてみたいと思っています。

Buffalo WLI2-TX1-G54 が文鎮化（レンガ化）

DD-WRT v23 SP2 をなんとかインストールすることが出来ていたバッファローのイーサネット・コンバータ WLI2-TX1-G54 が動作しなくなってしまいました。

NVRAM の設定ミスで動作しなくなってしまった WLI-TX1-G54 です。

経緯

DD-WRT v23 SP2 をインストールした WLI2-TX1-G54 の LAN ポートは、WAN として設定されていました。これと同様なことが OpenWrt をインストールしたときも発生していたのではないかと考えていました。

そこで何か対策方法は無いものかと考えていました。

対策方法の一つとして思いついたのが、NVRAM へ設定されてる LAN と WAN の設定を入れ換えてみれば、改善されるのではないかと考えました。

NVRAM の設定の調査

telnet 接続した後、 NVRAM の設定を WLI2-TX1-G54 と WLA2-G54C とで比較してみました。

やはり設定が異なっており、WAN と LAN のデバイス名が入れ替わっていました。

WLI2-TX1-G54
　Wifi=eth0
　WAN=eth1
　LAN=eth2

WLA2-G54C
　Wifi=eth0
　WAN=eth2
　LAN=eth1

NVRAM の設定変更

以下のように WLI2-TX1-G54 の NVRAM の設定を変更しました。

# nvram set lan_ifnames=eth0 eth1
# nvram set wan_ifnames=eth2
# nvram set wl0_ifname=eth1
# nvram set wan_iface=eth2
# nvram set wan_ifname=eth2
# nvram commit
nvram_commit(): end

動作確認

再起動させたところ、LAN ポートにも 無線 LAN にも反応が無くなってしまいました（涙）。しかし LED ランプの点灯状況から DD-WRT は、起動しているようです。

ポート変更による影響により CFE ブートでの TFTP の受付もしなくなってしまいました。

30/30/30 ハードリセット

DD-WRT でよく使用される 30/30/30 ハードリセットを何度も試みましたが、NVRAM の消去が出来ないようで、誤った設定を回復することができませんでした。

JTAG によりフラッシュメモリのバックアップと書き込みができれば回復させることも可能なはずですが、BCM4702 チップに限って、どの無線 LAN ルータも何故かフラッシュメモリの読み出しと書き込みが出来ないでいます。

文鎮へ

現在の私の力量では、これ以上のことは出来そうにありません。将来 JTAG によるフラッシュメモリへの書き込みができるようになるまで放置するしかないようです。

[訂正] 2016-06-16

本文ならびに表題を含めて WLI-TX1-G54 と表記しておりましたが、WLI2-TX1-G54 が正解です。すでに訂正をおこなっています。

Buffalo WLI2TX1-G54 へ OpenWrt をインストール（失敗）

先日バッファローの WLA2-G54C へ OpenWrt Backfire 10.03.1 をインストールすることに成功しました。

今日は、WLA2-G54Cで気を良くしたことから、同社の外観が酷似しているイーサネット・コンバータ WLI2-TX1-G54 へ OpenWrt Backfire 10.03.1 をインストールしてみました。しかし結果を先に述べますと、インストールに失敗しました。

OpenWrt のインストールに失敗した WLI-TX1-G54 です。

インストールの前提条件

WLA2-G54C へ OpenWrt をインストールする直前には DD-WRT v23 SP2 をインストールしていました。今回の WLI-TX1-G54 は、メーカ純正のファームウェアに直接インストールを試みることとしました。

openwrt-brcm47xx-squashfs.trx
https://downloads.openwrt.org/backfire/10.03.1/brcm47xx/openwrt-brcm47xx-squashfs.trx

OpenWrt Backfire 10.03.1 のインストール

具体的なインストール方法は、いわゆる TFTP 流し込み方法で行いました。

メーカ純正のファームウェアを初期化しました。これにより WLI-TX1-G54 の IP アドレスは 1.1.1.1 となりました。

そしてファームウェアを流し込むパソコンを 1.1.1.2 に設定しました。

パソコンと WLI-TX1-G54 の間をイーサネット・スイッチ（ハブ）経由で接続しました。

パソコン（Debian Jessie）の端末ソフトウェアから次の通りのコマンドで OpenWrt のファームウェアを TFTP で流し込みました。

# tftp 1.1.1.1
tftp > binary
tftp > trace
tftp > rexmt 1
tftp > timeout 60
tftp > put openwrt-brcm47xx-squashfs.trx　このコマンドを文字入力した時点で Enter キーを押さず一時的に作業を停止します。

WLI2-TX1-G54 の電源を一旦切断します。（重要）

上記の put openwrt-brcm47xx-squashfs.trx コマンドを Enter キーを押して実行させます。

すると端末ソフトウェア上では転送の応答がないことが1秒ごとに表示されます。

ここですぐに WLI2-TX1-G54 の電源を投入します。すると数秒後に TFTP 転送が開始されます。この時間わずか10数秒たらずです。

端末ソフトウェア上では TFTP 転送が終了していますので quit コマンドで TFTP のモードから抜けます。

OpenWrt の動作確認

ファームウェアの書き込みが終了すると、 DIAG の LED ランプが赤く点灯した後、オレンジ色へ変化するなど、何らかの動作をしているようでした。しかし LAN ポートへアクセスを試みましたが、全然反応してくれませんでした。
LAN ポートが 192.168.1.1 に設定されていると予想しましたが、異なる IP アドレスに設定されてしまっていることも考えて、操作するパソコン上で arp コマンドで IP アドレスの設定を行ってみましたが、結果は同じでした。

-- arp コマンドの設定例 --

# arp -s 192.168.1.1 00:11:22:33:44:55

DD-WRT v23 SP2 をインストール

上記のように OpenWrt のインストールに失敗したことから、DD-WRT のインストールを試みました。

インストール方法は TFTP 流し込み方法で行いました。ただし IP アドレスは、arp コマンドで 192.168.1.1 と設定している関係から 192.168.1.1 として tftp コマンドを操作しました。運良くフラッシュメモリの CFE 部分は生きていたようで、TFTP によるファームウェアの流し込みは成功しました。

DD-WRT v23 SP2 のインストールに成功した WLI2-TX1-G54 です。

DD-WRT の動作確認

OpenWrt と同様に LAN ポートの反応はありませんでした。
しかし DD-WRT の特徴なのですが、無線 LAN 部分がセキュリティ無しの状態で起動していました。そこで無線 LAN から WLI-TX1-G54 の DD-WRT の設定画面へアクセスを試みたところ、無事成功しました。

この DD-WRT の設定画面から LAN ポートの状態を確認すると WAN (DHCP) として設定されていることが判明しました。家庭内 LAN のケーブルを WLI-TX1-G54 の LAN ポートへ接続してみると、無線 LAN アクセスポイントして動作するようになりました。

OpenWrt 化への考察

上記のとおり、DD-WRT では LAN ポートが WAN として設定されていました。どうも OpenWrt でも WAN として設定されていた可能性があります。今後 WAN として設定されるポートを LAN として認識させる方法があれば OpenWrt でも動作しそうな感じがしました。今後の検討課題としたいと思います。

Buffalo WLA2-G54C へ OpenWrt をインストール

掲示板の方へ読者さんから バッファローの無線 LAN アクセスポイント WLA2-G54C へ OpenWrt （三種類）をインストールしたとの報告を受けました。そこで早速、我が家でも WLA2-G54C へ OpenWrt Backfire 10.03.1 をインストールしてみました。

WLA2-G54C dd-wrtはNG、openwrtを3種類焼けました
http://livingston.bbs.coocan.jp/?m=listthread&t_id=22

• Barrier Breaker 14.07
• Attitude Adjustment 12.09
• Backfire 10.03.1

今回 OpenWRT をインストールした WLA2-G54C です。

経緯

我が家の手持ちの WLA2-G54C には DD-WRT v23 をインストールしていました。もともと癖のある機種のようで、DD-WRT の中でも v24 のバージョンのものは正常に動作しないという曰くつきのものです。

buffalo WLA2-G54C を DD-WRT 化
http://near-unix.blogspot.jp/2010/11/buffalo-wla2-g54c-dd-wrt.html

DD-WRT をインストールした直後は暫く使用していましたが、そのうち使用しなくなり放置した状態でした。

今回、上記のように読者さんより OpenWrt がインストール可能だとの報告を受けて、実際にインストールしてみました。

OpenWrt のインストールバージョン

OpenWrt は、やはり新しいバージョンのものほど動作が重たくなるようで、Backfire 10.03.1 以外が実用的な動作をしない模様です。そこで今回は、Backfire 10.03.1 をインストールしました。

openwrt-brcm47xx-squashfs.trx
https://downloads.openwrt.org/backfire/10.03.1/brcm47xx/openwrt-brcm47xx-squashfs.trx

OpenWrt Backfire 10.03.1 のインストール

具体的なインストール方法は、いわゆる TFTP 流し込み方法で行いました。

すでに DD-WRT がインストールされていることから、まずこの DD-WRT を初期化しました。これにより WLA2-G54C の IP アドレスは 192.168.1.1 となりました。

そしてファームウェアを流し込むパソコンを 192.168.1.2 に設定しました。

パソコンと WLA2-G54C の間をイーサネット・スイッチ（ハブ）経由で接続しました。

パソコン（Debian Jessie）の端末ソフトウェアから次の通りのコマンドで OpenWrt のファームウェアを TFTP で流し込みました。

# tftp 192.168.1.1
tftp > binary
tftp > trace
tftp > rexmt 1
tftp > timeout 60
tftp > put openwrt-brcm47xx-squashfs.trx　このコマンドを文字入力した時点で Enter キーを押さず一時的に作業を停止します。

WLA2-G54C の電源を一旦切断します。（重要）

上記の put openwrt-brcm47xx-squashfs.trx コマンドを Enter キーを押して実行させます。

すると端末ソフトウェア上では転送の応答がないことが1秒ごとに表示されます。

ここですぐに WLA2-G54C の電源を投入します。すると数秒後に TFTP 転送が開始されます。この時間わずか10数秒たらずです。

端末ソフトウェア上では TFTP 転送が終了していますので quit コマンドで TFTP のモードから抜けます。

動作確認

しばらくすると WLA2-G54C の本体が自動的に再起動します。OpenWrt をインストールした場合、DIAG や WIRELWSS, ETHERNET の LED ランプが全点灯してしまうようです。パソコンから WLA2-G54C の新しい初期 IP アドレスの 192.168.1.1 へブラウザでアクセスをして初期設定をしました。

WLA2-G54C へインストールした OpenWrt の設定画面

興味深いところは、ルータモデル（Router Model）がジーメンスの SE505 V2 となっているところでした。ネット上で SE505V2 を検索してみると WAN と 4 つの LAN ポートを持つ普通の無線 LAN ルータでした。何か相関性でもあるのかと想像してしまいましたが、単純に機種名の判定ミスのようです。

とりあえず無線 LAN クライアント（Client）として自宅のアクセスポイントへ接続してみましたが、特に問題もなく接続していました。

単純に無線 LAN クライアントの設定にしてしまうと、 WLA2-G54C 本体は自宅内の LAN のサブネット 192.168.24.0/24 の IP アドレスで接続してしまうのですが、その配下のパソコンの IP アドレスは WLA2-G54C の DHCP サーバから配布された 192.168.1.0/24 などの IP アドレスが設定されてしまいます。　家庭内 LAN と同じ 192.168.24.0/24 でパソコンを設定したい場合には、中継ソフトウェアの relayd のインストールが必要ですが、OpenWrt の Backfire 10.03.1 には、パッケージが用意されていませんでした。今回のように無線 LAN クライアントして使用する場合には、家庭内 LAN と異なるサブネット空間で動作させるしかないようです。

FON2100E をリピータ（中継器）にしました
http://near-unix.blogspot.jp/2016/02/fon2100e.html

しばらく無線 LAN クライアントとして使ってみたいと思います。

I-O DATA WN-G54/US の USB プラグを交換

入手したばかりのアイ・オー・データ WN-G54/US ですが、USB プラグの周辺を触ると接触不良となるようで、通信が切れてしまいます。そこで分解を行って USB プラグの部分を修理しました。

USB プラグを交換した WN-G54/US です。

分解

以前にも同型の WN-G54/BB を分解したこともあり、気軽に分解してしまいました。しかし、今回は爪をいくつか折ってしまいました（涙）。内部には Atheros AR5523A チップが搭載されているのが見えました。

ケースを分解した WN-G54/US です。
チップに AR5523A が使用されていました。

内部のボードを取り出して背面を観察したところです。

USB プラグの再ハンダ付け

入手したときから USB プラグが傾いた状態となっていました。どうもパソコンへ装着したまま本体に大きな力が加わってしまったようです。そのため、USB プラグのリードのハンダ付けが割れてしまったものと考えました。確かにケースを固定するためにある左右の爪の部分はハンダが割れてグラグラする状態でした。

最初に USB プラグのリードを再ハンダ付けしました。
この写真は再ハンダ付けを行う直前のものです。
しかし接触不良は解消されませんでした。

USB プラグの交換

しかし USB プラグのリードを再ハンダ付けを行って、動作確認しました。しかし接触不良が再発しました。どうもこのリード部分のハンダ割れが原因ではなかったようです。
そこで手元に以前取り外して保存していた USB プラグがあったことから、この USB プラグと交換してみました。

USB プラグを取り外したところです。

左側の黒い絶縁体のものが今回取り付けた USB プラグです。
右側の白い絶縁体のものが元々取り付けられていた USB プラグです。

やはり USB プラグに問題があったようです。USB プラグの交換によって接触不良は解消されました。USB プラグのケースや内部の接点に障害が発生していた模様です。これで安心して使用できる状態となりました。

USB プラグの交換で接触不良が解消されました。

I-O DATA WN-G54/US を入手

アイ・オー・データの無線 LAN アダプタ WN-G54/US をインターネット・オークションにて入手しました。

アイ・オー・データ WN-G54/US

概要

外観は、以前紹介した同社の WN-G54/BB と同じ形状で色違いなものとなっています。しかし内部のチップは異なっており、Atheros AR5005UG 系のものが使用されている模様です。無線 LAN 特性は、2.4GHz 帯の IEEE 802.11b/g となっています。

I-O DATA WN-G54/BB を入手
http://near-unix.blogspot.jp/2016/01/i-o-data-wn-g54bb.html

WN-G54/BB（上）と WN-G54/US（下）の比較

デバイス ID の追加

WN-G54/US を Debian Jessie が稼働しているパソコンへ装着してみましたが、反応がありませんでした。そこで ar5523 のドライバ・モジュールへデバイス ID （04bb:0929）を追加してビルドしました。

デバイス ID を追加した ar5523 ドライバ・モジュールを使って動作確認をしてみたところ問題なく動作しました。

動作中は、楕円形のラベルの中にある LED ランプが黄色く光っていました。

動作中点灯する LED ランプです。

ダウンロード

今回ビルドしたドライバ・モジュールを「Debian 用ドライバ保管庫」へアップロードしています。自由にダウンロードして使用してください。ただし自己責任でお願いいたします。

該当する Debian バージョンのホルダの中にあるドライバ・モジュールの ar5523.ko をダウンロードするか、私がビルドしたドライバ・モジュールを一纏めにした圧縮ファイル（tar.gz）をダウンロードして使用してください。このドライバ・ モジュールを一纏めにした圧縮ファイルのダウンロードをお奨めします。

ドライバ・モジュールを一纏めにした圧縮ファイルの場合、解凍後、ドライバ・モジュールのインストール・スクリプト modules-update.sh を特権ユーザ（root）で実行させると、自動的にドライバ・モジュールをインストールしてくれます。

$ su
# ./modules-update.sh

注意

ar5523 ドライバ・モジュールは Debian Jessie （32bit, 64bit）のみの提供となります。Debian Wheezy 用のものはございません。

Buffalo WLI-UC-GNHP が故障

自宅の玄関口に設けていた監視カメラ（LD-HLA + WLI-UC-GNHP）からの通信が途絶えてしまいました。調査したところ、無線 LAN アダプタの WLI-UC-GNHP が故障していました。

症状

無線 LAN アダプタの WLI-UC-GNHP が故障した模様で、無線 LAN 通信が出来なくなった他、 WLI-UC-GNHP の本体が異常な発熱をしていました。

無線 LAN アダプタを交換

そこで無線 LAN アダプタを交換することとしました。交換するにあたって、以前より気になっていた rt2800usb ドライバで動作するチップの発熱の多さを気にして、今回は zd1211rw のドライバで動作する無線 LAN アダプタを使用することとしました。

（旧） Buffalo WLI-UC-GNHP -- rt2800usb
（新） Buffalo WLI-U2-KG54L -- zd1211rw

下が故障した WLI-UC-GNHP です。
上は今回から使用する WLI-U2-KG54L です。

監視カメラの本体となる HD-HLAN を設置場所から降ろした後、シリアルコンソールを接続して、無線 LAN 設定をし直しました。

zd1211rw のファームウェアをインストールしました。

# apt-get install firmware-zd1211

そして udev において無線 LAN のデバイス名を指定するファイルを編集して、以前 wlan0 となっていた項目を削除しました。

# /etc/udev/rules.d/70-persistent-net.rules

この状態で新しく使用する無線 LAN アダプタの WLI-U2-KG54L を接続すると、自動的に wlan0 として登録してくれました。

動作確認

監視カメラを設置する前に地上で動作確認を行いました。

HD-HLAN による監視カメラの動作確認です。

設置

動作確認が終わったところで、元通りに監視カメラを設置しました。

元通り玄関口へ設置し直しました。

参考記事

玄人志向 玄箱用 Debian Jessie wifi 対応版
http://near-unix.blogspot.jp/2016/04/debian-jessie-wifi.html

Linksys WRT320N へ OpenWrt をインストール

今日は久しぶりに無線 LAN ルータの話題です。以前入手して、各種整備をした後、放置していたリンクシスの WRT320N へ OpenWrt Chaos Calmer 15.05 をインストールしました。事情があり、遠隔地で使用する無線 LAN ルータとして OpenVPN などを一緒に設定しました。

今回 OpenWrt をインストールした Linksys WRT320N です。

過去の WRT320N の記事です。

Linksys WRT320N へ DD-WRT をインストール
http://near-unix.blogspot.jp/2015/02/linksys-wrt320n-dd-wrt.html

Linksys WRT320N の 5GHz 帯の通信転送速度
http://near-unix.blogspot.jp/2015/03/linksys-wrt320n-5ghz.html

Linksys WRT320N の Tomato ファームウェアで J52 対応
http://near-unix.blogspot.jp/2015/03/linksys-wrt320n-tomato-j52.html

Linksys WRT320N の電源ソケットの修理
http://near-unix.blogspot.jp/2015/03/linksys-wrt320n.html

Linksys WRT320N へシリアルコンソールの端子を設置
http://near-unix.blogspot.jp/2015/04/linksys-wrt320n.html

インストールの目標

OpenWrt をインストールした後、OpenVPN で WRT320N が管理している LAN へログインできるようにすることを目標としました。そのため、通常の OpenWrt のインストールの他、OpenVPN やダイナミック DNS のインストールと設定を行いました。

OpenWrt Chaos Calmer 15.05 のインストール

以下の OpenWrt Wiki を参考にしてインストールを行いました。直前まで Tomato ファームウェアをインストールしていましたが、ファームウェアのアップグレード機能で OpenWrt のファームウェア（openwrt-15.05-brcm47xx-mips74k-linksys-wrt320n-v1-squashfs.bin）を指定してアップグレード処理することにより、OpenWrt をインストールすることができました。

Linksys WRT320N/E2000 [OpenWrt Wiki]
https://wiki.openwrt.org/toh/linksys/wrt320n

ファームウェアのダウンロード
https://downloads.openwrt.org/chaos_calmer/15.05/brcm47xx/mips74k/
openwrt-15.05-brcm47xx-mips74k-linksys-wrt320n-v1-squashfs.bin

OpenWrt をインストールした WRT320N のステータス画面です。

以下の設定では telnet でログインを行って端末上からパッケージ類のインストールを行い、ブラウザ画面の LuCiから各種の設定を行いました。

無線 LAN  ドライバを brcm-wl へ変更

標準の無線 LAN のドライバは b43が使用されているため、2.4GHz 帯の IEEE 802.11 b/g のみの対応となっています。これを 5 GHz 帯の 11a や 11n モードへ対応するために brcm-wl ドライバへ変更しました。この変更は過去にも Broadcom のチップを使用している無線 LAN ルータでも同様に行っています。

# opkg update
# opkg install kmod-brcm-wl wlc nas
# opkg remove kmod-b43 kmod-b43legacy
# reboot

ダイナミック DNS の設定

インターネット経由で WRT320N へアクセスするためにダイナミック DNS を使って IP アドレスを取得できるようにしました。OpenWrt では ddns-scripts をインストールして使用します。そして使用するダイナミック DNS のサーバ は No-IP を使用しました。そのため No-IP 専用の ddns-scripts_no-ip_com をインストールしました。

# opkg update
# opkg install ddns-scripts ddns-scripts_no-ip_com luci-app-ddns
# reboot

ダイナミック DNS の設定は、ブラウザ画面の LuCi から設定を行いました。種類に "No-IP.com" を選んで、ユーザ名やパスワードを設定すれば、すぐに設定は反映されて、WAN 側の IP アドレスが No-IP の DNS サーバへ登録されました。

ダイナミック DNS の設定画面
IPv4 の設定のみを行いました。

"Edit" ボタンを押して編集画面へ移行した画面です。
ここで詳細な設定を行いました。

OpenVPN の設定

OpenVPN をインストールするにあたって、証明書類は WRT320N 上で作成すると時間がかかりそうだったので、パソコンで作成しました。この証明書に作成については記述を割愛しました。証明書の作成や OpenVPN の設定は、過去の記事と OpenWrt Wiki を参考にしてください。

FreeBSD の自宅サーバへ OpenVPN をインストール（ルーティング方式）
http://near-unix.blogspot.jp/2014/08/freebsd-openvpn.html

OpenVPN Setup Guide for Beginners [OpenWrt Wiki]
https://wiki.openwrt.org/doc/howto/vpn.openvpn

OpenVPN のパッケージをインストールしました。

# opkg update
# opkg install openvpn-openssl luci-app-openvpn collectd-mod-openvpn

まず最初に OpenVPN で使用する tun0 のインターフェースを uci 設定コマンドで作成しました。

# uci set network.vpn0=interface
# uci set network.vpn0.ifname=tun0
# uci set network.vpn0.proto=none
# uci set network.vpn0.auto=1

次に OpenVPN のパケットを通過させるトラフィック・ルール（Allow-OpenVPN-Inbound）をファイアウォールへ作りました。使用するポート番号は、標準の 1194 ではなく 1196 を使用しました。初めて設定する読者さんは、とりあえず標準の 1194 で設定することをお奨めします。

# uci add firewall rule
# uci set firewall.@rule[-1].name=Allow-OpenVPN-Inbound
# uci set firewall.@rule[-1].target=ACCEPT
# uci set firewall.@rule[-1].src=*
# uci set firewall.@rule[-1].proto=udp
# uci set firewall.@rule[-1].dest_port=1196

さらに OpenVPN のトンネルのファイアウォール・ゾーン（vpn）を作成しました。

# uci add firewall zone
# uci set firewall.@zone[-1].name=vpn
# uci set firewall.@zone[-1].input=ACCEPT
# uci set firewall.@zone[-1].forward=REJECT
# uci set firewall.@zone[-1].output=ACCEPT
# uci set firewall.@zone[-1].network=vpn0
# uci add firewall forwarding
# uci set firewall.@forwarding[-1].src='vpn'
# uci set firewall.@forwarding[-1].dest='wan'

以上の uci コマンドで設定した内容を反映させました。

# uci commit network
# /etc/init.d/network reload
# uci commit firewall
# /etc/init.d/firewall reload

OpenVPN の詳細設定をブラウザ設定画面の LuCi で行いました。主に証明書類（ca, dh, cert, key）の設定を行ったのですが、設定画面の左下にある追加項目を選択して "Add" ボタンを押して、追加しては、証明書のファイルを指定しました。

OpenVPN の設定画面
インストール直後には三種類の設定がありましたが、不要なものは削除しました。
 "sample_server" を変更して "WRT320N_Server" としました。

OpenVPN の詳細設定画面です。

証明書類は項目を追加しながらファイルを指定しました。

以上の設定で OpenVPN のだいたいの設定が終わりました。しかしまだ細かな部分の設定が残っていますので、直接 OpenVPN の設定ファイル（/etc/config/openvpn）を編集して、設定を行いました。

# vi /etc/config/openvpn

以下は OpenVPN の設定ファイル（/etc/config/openvpn）の参考例です。最下段（四段）の青文字部分が、追加した部分です。WRT320N のサブネットは、192.168.1.0 を使用して、さらに OpenVPN のトンネルには 192.168.11.0 のサブネットを使用するようにしています。DNS サーバは WRT320N の DNS 機能を使用するようにしました。

config openvpn 'WRT320N_Server'
        option proto 'udp'
        option dev 'tun'
        option ifconfig_pool_persist '/tmp/ipp.txt'
        option keepalive '10 120'
        option comp_lzo 'yes'
        option persist_key '1'
        option persist_tun '1'
        option user 'nobody'
        option status '/tmp/openvpn-status.log'
        option verb '3'
        option port '1196'
        option dh '/lib/uci/upload/cbid.openvpn.sample_server.dh'
        option cert '/lib/uci/upload/cbid.openvpn.sample_server.cert'
        option key '/lib/uci/upload/cbid.openvpn.sample_server.key'
        option ca '/lib/uci/upload/cbid.openvpn.sample_server.ca'
        option enabled '1'
        option server '192.168.11.0 255.255.255.0'
        option push 'route192.168.1.0 255.255.255.0'
        option push 'redirect-gateway def1'
        option push 'dhcp-option DNS 192.168.1.1'

以上で設定は終了です。念の為 WRT320N を再起動させて、動作確認を行いました。

OpenWrtをインストールした WRT320N です。

NTT FT-STU-Bng を入手

NTT の USB 型無線 LAN アダプタの FT-STU-Bng を入手しました。

今回入手した NTT FT-STU-Bng です。

概要

親指先ほどの大きさの USB 型無線 LAN アダプタです。
無線 LAN の特性は、2.4GHz 帯の IEEE 802.11 b/g/n 対応となっています。内部のチップには Ralink 社の RT2870 が使用されている模様です。

NTT FT-STU-Bng の背面表記の様子です。

デバイス ID を追加してビルド

Debian Jessie が稼働しているパソコンへ本機（FT-STU-Bng）を装着してみたところ、なんの反応もありませんでした。デバイス ID （0411:0192）が登録されていない模様でした。そこでデバイス ID （0411:0192）を rt2800usb ドライバ・モジュールへ追加してビルドすることとしました。なおデバイス ID のベンダーコードの "0411" を見てのとおり、バッファローが製造委託された製品のようです。また lsusb コマンドでも Buffalo の名前が読み取れます。

動作確認

FT-STU-Bng のデバイス ID を追加してビルドし直した rt2800usb.ko をカーネル・モジュールとしてインストールした後、動作確認を行いました。ちゃんと認識をして rt2800usb.ko ドライバ・モジュールで稼働しました。

稼働中は、本体先端の内側から青色の LED ランプが点灯していました。

動作中の NTT FT-STU-Bng のランプの点灯状況です。

ダウンロード

今回ビルドしたドライバ・モジュールを「Debian 用ドライバ保管庫」へアップロードしています。自由にダウンロードして使用してください。ただし自己責任でお願いいたします。

該当する Debian バージョンのホルダの中にあるドライバ・モジュールの rt2800usb.ko をダウンロードするか、私がビルドしたドライバ・モジュールを一纏めにした圧縮ファイル（tar.gz）をダウンロードして使用してください。このドライバ・ モジュールを一纏めにした圧縮ファイルのダウンロードをお奨めします。

ドライバ・モジュールを一纏めにした圧縮ファイルの場合、解凍後、ドライバ・モジュールのインストール・スクリプト modules-update.sh を特権ユーザで実行させると、自動的にドライバ・モジュールをインストールしてくれます。

$ tar zxvf Jessie-wifi-modules_pack.tar.gz
$ su
# ./modules-update.sh

Corega 無線 LAN アダプタ CG-WLCB54AGM を入手

コレガの無線 LAN アダプタ CG-WLCB54AGM をインターネット・オークションにて入手しました。

今回入手したコレガ CG-WLCB54AGM です。

概要

カードバス形式の無線 LAN アダプタです。コレガの製品によく見られるアンテナ部分が薄型の製品で、上下の PC スロットと干渉し難くなっているのが外観上の特徴です。

コレガ CG-WLCB54AGM の外観です。

無線 LAN 部分については、2.4GHz 帯と 5GHz 帯の IEEE 802.11a/b/g 対応となっています。さらに MIMO による 108Gbps 通信にも対応となっていました。

内部には Ralink 社の RT2600 が使用されている模様で、lspci コマンドでその内容が読み取れます。Debian Jessie におけるドライバは rt61pci という今まで見かけたことのないものが適合しました。

動作確認

Debian Jessie が稼働しているノートパソコンの PC カードスロットへ装着すると自動で rt61pci ドライバ・モジュールが読み込まれました。そして CG-WLCB54AGM の内部で使用するファームウェア（firmware-ralink）を事前にインストールしておくと、すぐに動作を開始しました。2.4GHz 帯も 5GHz 帯も問題なく動作していました。ただし MIMO としての動作は、機材がないため、確認することができませんでした。

# aptitude update
# aptitude install firmware-ralink

rt61pci - Debian Wiki
https://wiki.debian.org/rt61pci

ただし、gnome3 のデスクトップを使用していると、周辺にある無線 LAN アクセスポイントを探し出すところまで動作するのですが、何故か接続できませんでした。Xfce4 のデスクトップの場合には問題なく動作しました。同じネットワーク・マネージャを使用しているはずなのに、どうしてこのような差異が出てしまうのかは不明です。

動作中の CG-WLCB564AGM は二個の LED ランプが点灯していました。Link/Act のランプは無線 LAN 通信の状況に応じて点滅を繰り返していました。

CG-WLCB54AGM の LED ランプの点灯状況

シリアル - USB 変換モジュール FTDI232 が Debian Jessie で動作しました

メーカ不詳の シリアル - USB 変換モジュール FTDI232 が Debian Jessie で動作しました。

Debian Jessie で動作することが確認できた FTDI232 です。

経緯

以前、弊ブログにて紹介しました FTDI232 は、Windows XP や Puppy Linux 5.7.1 JP で動作することが確認出来ていました。しかし肝心な Debian Jessie では、受信のみの動作だけで、送信の動作ができない状態でした。さらに調べてみると Debian Wheezy でも同様の状況でした。

メーカ不詳 シリアル - USB 変換モジュール FTDI232
http://near-unix.blogspot.jp/2016/04/usb-ftdi232.html

その後、FTDI232 の中に使われているチップ（FT232RL）を動作させている ftdi_sio.ko のソースコードを調査してみました。問題の FTDI 社が行った偽物の対策が、Linux カーネルモジュールにも影響を与えているか？についてです。私が理解した範疇では、Windows 用ドライバによってデバイス ID を "0403:0000" に書き換えられたチップを "BRICKED" と認識して、何も動作しないように 2014 年ごろに変更が加えられているだけで、Linux のドライバ・モジュールが積極的に動作を制限することはないものと判断しました。

そうすると、余計に Debian Jessie でデータの送信が出来ない理由が解りません。

screen コマンドで動作

そこでネット上を「debian ft232rl」などといろいろと検索してみました。しかし送信だけが出来ない事例を見つけることができませんでした。チップそのものを認識出来ないなどの問題だけが発見できました。その他、多くは Debian 上での使用方法についての解説できした。そこで気づいたことは、このようなシリアル・ポートを使用するときによく使う cu コマンドを使用する事例が何故か見当たりませんでした。その代わり screen を使うものばかりでした。そこで screen コマンドで試しに FTDI232 と通信させてみました。

 すると相手先に送信していることを示す LED ランプがチカチカ点灯しているのを発見しました。急遽、玄箱のシリアルコンソールの外部端子へ接続して確認すると、ちゃんと送受信ができているのを確認しました。

中央部にある二個の LED ランプが送信と受信に対応して点滅しました。

これから判断できることは、ドライバ・モジュールの ftdi_sio.ko は正常に動作しており、何らかの理由で cu コマンドからの送信データを出力出来ない状況にあるようです。

screen で操作事例

screen での通信開始時のコマンドは次の通りです。通信速度は、玄箱用に 57600bps の事例で表記しています。一般ユーザから操作することができます。

$ screen /dev/ttyUSB0 57600

screen の終了は "Ctrl + A" の後、"\（バックスラッシュ）" です。

以下は、玄箱を制御中の端末画面のスクリーンショットを取得したものです。

玄箱起動時の様子です。

玄箱が起動してログインできる状況となりました。
従来であれば、ここで何も出来なくなっていました。

パソコンからのデータが玄箱へ届いてログインできました。

シリアル通信を終了するときには Ctrl+A と \（バックスラッシュ） です。

これでようやく Debian Jessie のマシンから FTDI232 を操作することができるようになりました。Debian Jessie で操作できないことが判明した後、ずっとモヤモヤがありましたが、これですっきりと晴れました！

カモン 9-KE ケーブルのピンヘッダ対応加工

一番最初に入手した玄箱には、カモン 9-KE のケーブルを改造したシリアルケーブルがついていました。本体から直接飛び出した構造で取り付けられていたため、とても邪魔な存在でした。そこでこのシリアルケーブルを取り外して、シリアルケーブルの先端を通常のピンヘッダで使えるに処理しました。

カモン 9-KE シリアルケーブル

ピンヘッダのコンタクトの圧着

現状のシリアルケーブルの先端は、私のところで使用しているピンヘッダのソケットとは違うソケットのものが取り付けられていました。そこで以前のソケットのコンタクトを切断して、新しくコンタクトを取り付けることとしました。

カモン 9-KE ケーブルの先端に取り付けられてコンタクトの様子です。
以前の所有者さんが取り付けたもののようです。

コンタクトの部分を切断した後、さらに必要な長さまで集合ケーブルの外皮を剥きました。すると内部からアースと思われる裸の撚線が出てきました。ケーブルの信号の役割は次の通りです。なおここで記述している「送信」と「受信」については、ケーブル側の役割です。これを対象物へ接続するときには、反対側の極性（送信→受信、受信→送信）へ接続する必要があります。

・茶色：GND
・赤色：GND
・黒色：送信 Tx
・朱色：受信 Rx

集合ケーブルの外皮を剥いたところです。

エンジニアの圧着ペンチ PA-09 を使用して、コンタクトを圧着しました。GND の赤色は Vcc と間違えやすいので、切断して未使用としました。

新しくコンタクトを圧着したところです。

4 ピンのソケットへコンタクトを挿入して完成です。

ピンヘッダのソケットへ装着したところです。

動作確認

FON2200 のシリアルコンソールのピンヘッダへ装着して確認してみました。FON2200 からの出力はちゃんと受信できるのですが、パソコン側からの信号を受け取ってもらえませんでした。

この時には原因が不明だったのですが、後でカモン 9-KE シリアルケーブルについてネット上を検索してみると、ケーブルの出力は、トランジスタのオープン・コレクタとなっているようです。そのため、シリアルコンソールの入力端子部分にプルアップ抵抗器が存在しないと電位を変化させることができず、パソコン側からの信号を伝えることが出来なかったようです。確認はしていませんが、FON2200 のシリアルコンソールの入力端子（Rx）にプルアップ抵抗器（1KΩ〜10KΩ程度）を設置すると動作するはずです。

FON2200 ではシリアルコンソールの入力のプルアップ抵抗が必要のようです。

FON2200で良い結果が得られなかったことから、玄箱のシリアルコンソールの外部端子へ装着して動作確認を行ってみました。こちらは問題なく動作しました。確かに玄箱のシリアルコンソールの入力端子にはプルアップ抵抗器が存在していました。そのためカモン 9-KE ケーブルでちゃんと動作したものと思われます。

玄箱ではシリアルコンソールの入力にプルアップ抵抗器が設置済みのため、問題なく使用出来ました。