2019年2月24日日曜日

実家ネットワークの再構築

目標

WAN 直結の DMZ(192.168.0.0/24)と、純プライベートな内部 LAN 領域(192.168.1.0/24)の二段構成とし、DMZ へのゲートウェイとなるルーター(OpenWrt 機)にネットワークセパレーターとしての役割を担せ、そこで集中的にセキュリティ管理する。

現状

従来の構成は、管理上の平易さから、LAN は全て 192.168.0.0/24 のみで、WAN へのゲートウェイとなるルータを介して WAN に直結するフラットな一段構成である。今後 WWW サーバーを運用するなど外部向けの公開を念頭に入れると流石にセキュリティ上の懸念もあるため、WWW サーバーを置く DMZ とセキュリティを特に意識しないで済む内部 LAN 領域とに分け、この二種の領域の境界にネットワークセパレーターとしての OpenWrt 機を DMZ へのゲートウェイルーターとして置くという構成にしたいと考えるようになった。こうしておけば、たとえ WWW サーバーが侵入されたとしても、これを踏み台としてネットワーク的に分離された内部 LAN 領域に侵入されるわけではないので、内部 LAN 領域の安全性は維持できる(DMZ から 内部 LAN へのルーティングは行なわず、内部 LAN から DMZ への IP マスカレードによる一方的なアクセスのみ可能とする)。

デメリット

唯一のデメリットとしては、素人向けの話として丸暗記的に嫌われる「二重ルーター状態」になることで、UPnP に頼ることができなくなる点である。内部 LAN とそのゲートウェイルーターの間では UPnP を活用してもいいのだが、その設定内容に対応したポートマッピングを手動で WAN へのゲートウェイルーターにも設定する必要がある。とはいえこれは当然、得ようとしているセキュリティ上のメリットと表裏一体となる作業なのであるから、デメリットと呼ぶべきものではないことなのかもしれない。

暫定措置

理想としてはこのゲートウェイルーターに、Wi-Fi ブリッジ、OpenVPN サーバー、DHCP サーバーの役割も担わせた OpenWrt 機を当てたい所だが、現状、この位置にあるのはブリッジ運用中の NEC の Aterm WG1200HP で OpenWrt 化は無理。一方の手持ちの OpenWrt 機は WZR-HP-AG300H で、Wi-Fi 規格も古くこの要の位置に設置するには非力である。将来的には、Wi-Fi の AC 規格に対応した Netgear の R7800 あたりを入手して OpenWrt 化したものを配置したいと思っているが、現状はこのまま WG1200HP で行くことにする。

  1. ゲートウェイルーターの WG1200HP に OpenVPN サーバーや DHCP サーバーの役割を担わせず、ブリッジ運用からルーター運用に切り替えて、DMZ(192.168.0.0/24)と内部 LAN 領域(192.168.1.0/24)を区切るゲートウェイルーターとする。もちろん、Wi-Fi ブリッジとしての役目は従来通り。
  2. OpenVPN サーバーと DHCP サーバーの役割は、後方(別フロア)の Wi-Fi ブリッジである OpenWrt 機(WZR-HP-AG300H)に担わせる。
  3. 暫定措置の唯一のデメリットは、OpenVPN サーバーが奥のブリッジになってしまうという点である(DHCP サーバーを奥のブリッジに割り当てることによるデメリットは特にない)。トラフィック的に、ゲートウェイルーターに繋がった機器へのアクセスにおいて VPN 経由の通信が折り返して重複する形となる。実際には VPN はたまにしか使わないので、それほど気にすることではないのだが。
  4. もう 1 台の OpenWrt 機(こちらも WZR-HP-AG300H)は WWW サーバーや CGI/Python、DB(や、可能であればメールサーバー)の機能をセットアップし、DMZ に置く。ルーターとしての機能や(有線・無線を問わず)ブリッジとしての機能は不要である(ある意味、OpenWrt で Wi-Fi が正常に機能する機種という意味で選んだ WZR-HP-AG300H である必然性すらない。安価に入手できて省電力でそこそこ処理能力がある OpenWrt 化できる端末であればよい)。

OpenWrt on WZR-HP-AG300H: VPN サーバー

VPN は tun モードでセットアップした(が、それとは別に tap モードでもセットアップし、両立させた)。基本的には OpenWrt 公式のガイド(👉 OpenVPN Basic)に従ったが、必ずしも公式ガイドその通りに uci コマンドを使ってセットアップせずとも、コンフィグファイルを直接編集したり、一部の操作は LuCI でも代用できると思う。

PKI の準備

PKI をセットアップ(= Easy-RSA をインストール)し、必要な証明書等を生成する。これはガイドの通りにそのまま。 👉 OpenVPN Basic: PKI

VPN 用の仮想の物理インターフェースの作成と、論理インターフェースの作成

仮想の物理インターフェース tun0 を紐付けた論理インターフェース vpn_router を作成する。プロトコルは none(LuCI 上では Unmanaged と表示される)👉 OpenVPN Basic: Network

また、これは独自にやり方を見出したが、tap モードでセットアップすることもでき、物理インターフェース tap0 を作った場合は、論理インターフェースを新設せず、論理インターフェース lan の物理インターフェースの一つとして tap0 を追加するだけで良い(上のスクリーンショット。論理的に lan の一部として存在するので、tun モードの場合のように、Firewall の設定をする必要はない)。

OpenVPN Services

OpenVPN サービスをセットアップ(= openvpn-openssl をインストール)し、設定する。ガイドでは uci コマンドを使っているが、luci-app-openvpn をインストールすれば、LuCI の GUI でも代用できないことはないと思う。ガイドの uci コマンドでは環境変数を使って自動化している部分があり、何らかの理由で不具合がある場合には、あとで適宜設定を修正する必要があるかもしれない。また、VPN 用のネットワークアドレスも、自分で使いたいものに修正する。👉 OpenVPN Basic: VPN-Service

ポート番号が重複しないようにすれば、同時に、tun と tap のサーバー(上のスクリーンショットの router_server と bridge_server がそれぞれ該当する)を立ち上げることも可能。

Firewall

公式ガイドでは Firewall の設定を行っているが、当該機がルーターでセットアップ・運用されている場合に wan からの通信を vpn_router に通すためのものであり、ブリッジでセットアップ・運用されている OpenWrt 機の場合は wan ゾーン自体が削除されているため、関係ないだろう。
ゾーンとして vpn を定義し、lan ゾーンとの間でのトラフィックを全許可する。さらに Masquerading を設定するのが肝(下のスクリーンショットと次節参照)。👉 OpenVPN Basic: Firewall

Masquerading

当初は接続先ネットワークのゲートウェイルーターの静的ルーティング設定で強引に(?)VPN 専用ネットワークへのルーティングを可能にしていたため気付かなかったが、後に接続先ネットワークのゲートウェイルーターを静的ルーティング設定ができないもの(Aterm WG1200HP)に置換したことで、突如 VPN サーバー以外の接続先の LAN 側ネットワークに接続できなくなった。OpenWrt の Masquerading の設定なども試したものの打開できず、「ゲートウェイルーターが静的ルーティングすらできない安物だから」と一度本気で諦めたほどである。

しかし翌日ふと閃いて、Masquerading を、VPN 側ではなく、LAN 側で設定したところ、嘘のように問題が解消した。理論上からしても、Masquerading できれば静的ルーティングの必要性はまったくなかったわけだし、むしろ静的ルーティングしない方がセキュリティ上好ましいくらいである。

スクリーンショットに表示されているチェックこそが、tun モードでの VPN における重要で決定的な魔法だった。

追記(2019-03-10):proto 'tcp' にすべし!

これは OpenWrt での OpenVPN 特有の話ではないのだが、デフォルトの話として使用プロトコルは UDP ではなくて TCP にすべきである。何かどうしても TCP では嫌で UDP で高速化を図りたい人のみ、意図して UDP にすべきで、デフォルトでは OpenVPN というものは TCP を使うことにしておくべき。

当初、WiMAX 回線からの VPN サーバーへの接続で完全に全く問題がなかったので気付かなかったのだが、公衆 Wi-Fi を使ってみた時に、急に接続できなくなって一日ほどずっといじくり回して悩んでいた。プライベートネットワークアドレスの競合なのかなと悩んだり。公衆 Wi-Fi 側で VPN をフィルタリングしてブロックしている可能性も頭をよぎった(こういう邪推をする人はチラホラいるようである。だが、これは全くの大間違い、冤罪もいいところである)。

UDP が諸悪の根源であった。寝る前に海外の掲示板情報で「TCP にすべし」という情報をチラッと目にし、「ああ、昔 DD-WRT で初めて OpenVPN に取り組んだ時もそういう話を聞いたことがあったな、明日試してみよう」と思って眠り、翌日 TCP にした途端、嘘のように超絶安定化してサクサクと繋がるようになった。何てことだ。

世間では、VPN は「デフォルトが UDP で、問題があれば TCP」みたいな扱いだが、これ、逆だろう。

ハマり所についての考察

サーバー側のセットアップとしては、以上で、特に問題がなければ、難しい設定をする必要もなく上手く動いてしまう。動かない場合には、OpenWrt 機のネットワークやファイアーウォールの設定がおかしかったり、ネットワークのゲートウェイにおける、ポートマップが適切でなかったり、ルーティングが適切でなかったり、またOpenVPN クライアント側の設定が適切でなかったりである。自分の場合も当初は一発で上手く動かなかったので、できるだけ単純なネットワーク環境にして一つ一つセットアップし直してみたりしたが、最終的には、OpenWrt 機における上記の OpenVPN サーバー自体の設定に起因するミスではなく、ファイアーウォールの設定や、ネットワークのゲートウェイ側の設定、クライアント側の設定などが原因だった。OpenVPN 自体は、サーバーとクライアントで OpenVPN アプリが稼動している限り、同じ設定内容の設定ファイル(.ovpn)を使えば、通信できるようになっているので、暗号化方式のせいだとか、そういうところで失敗することは意外とないと思う。それ以前に、ネットワーク(ファイヤーウォール等)やルーティングが上手く機能していない可能性が高い。

VPN サーバーがセットアップ作業の一つの区切り

以上、VPN サーバー化によって、遠隔でも OpenWrt 機でのセットアップ作業を継続できるようになるのは大きい。

2019年2月23日土曜日

OpenWrt on WZR-HP-AG300H: ブリッジ化

WZR-HP-AG300H では初期状態ではルーターとしてセットアップされている。つまり、図においての物理インターフェース eth1 が論理インターフェスの wan に紐付けられている状態である。

Network > Interfaces 設定

なので、論理インターフェース的に wan と lan の二段構成になっている状態を解消して、単なるブリッジ状態にするには、LuCI 上で Network > Interfaces 設定で wan のエントリーを削除した上で、lan の Physical 設定で物理インターフェスの eth1 を lan に紐付け、さらに IPv4 のアドレス、ネットマスク、ゲートウェイ等の設定を UP ポート側の LAN に合わせたものにすればいい。基本的にこれだけで ok のはずである。

作業上の注意としては、先に wan のエントリーを削除して lan の設定をする前の段階で、一旦変更を反映させてしまうと、UP ポートが単に使えない状態になってしまい、UP ポートに LAN ケーブルを接続して設定作業をしていたならば、LuCI 自体にアクセスできない状態になり、焦ってしまうかもしれない点である。Wi-Fi か、LAN ポートに LAN ケーブルを接続すれば問題ないはずである。

Network > Switch 設定

初期状態では VLAN がセットアップされており、LAN ポート 1 〜 4 は、VLAN のノード 1 である eth0.1 に属している。VLAN を使わないのであれば、VLAN 関係の設定を削除して、単純に eth0 で扱っても良さそうだが、もしかしたら、一度試して支障が生じたことがあるかもしれない。現状ではデフォルトのまま放置している。

/etc/config/network

以上のような形で、/etc/config/network の内容は、wan のエントリーが削除され、lan のエントリー部分が以下のようになった:

config interface 'lan'
 option type 'bridge'
 option proto 'static'
 option netmask '255.255.255.0'
 option gateway '192.168.0.1'
 option broadcast '192.168.0.255'
 option dns '192.168.0.1'
 option ip6assign '60'
 option ifname 'eth0.1 eth1'
 option ipaddr '192.168.0.10'

もちろん、IP アドレスやゲートウェイ等の設定内容は、環境に依るので、ここでのポイントはインタフェースとして eth0.1 と eth1 がアサインされている点だろう。

ちなみに、LuCI 上では Wi-Fi の物理インターフェス wlan0 と wlan1 がアサインされているにもかかわらず、/etc/config/network 上では記載されていないのは、Linux(OpenWrt)の仕様である。論理インターフェースである lan がセットアップする段階では Wi-Fi に関するデバイスの初期化が追い付かず、後からセットアップされるため、/etc/config/wireless 側で紐付けされる論理インターフェースを定義することになる。そして LuCI の表示はこれらを総合した情報を出力している。

Network > Firewall 設定

初期状態のファイアーウォールの Zone のうち wan は存在しないので不要となり、削除した。

さらに、初期状態のファイアーウォールの Traffic Rules はすべて、ルーターとして機能する場合の wan ⇔ lan 間に関するものであり、lan ⇔ lan 間でブリッジとして機能する際に必要なものではない。完全に削除した。

OpenWrt on WZR-HP-AG300H: Timezone and NTP

System 設定

Timezone を Asia/Tokyo にした。

NTP サーバー候補には 1: ntp.nict.jp; 2: ntp.jst.mfeed.ad.jp; 3: openwrt.pool.ntp.org を入れておいた。

OpenWrt on WZR-HP-AG300H: SSH

Wi-Fi の有効化作業と並んで、SSH の有効化作業もその後の設定作業環境に関わる物事なので、最優先となる作業だ。

👉 SSH Configuration

System > Administration 設定

ルーターのパスワードを設定し、さらに SSH 用の公開鍵を登録しておく。

公開鍵を登録した場合、パスワード認証を無効化することも可能だが、現状では実質的に LAN 内部からしかアクセスできない状態のため、それほどセキュリティを心配する必要がないと考え、(Dropbear の設定で)特に無効化するようなことはしていない。むしろ現状では、設定を色々といじっていて、公開鍵認証でログインができなくなったりした場合に、パスワードで SSH ログインできないと面倒なことになるというリスクの方が大きい。

また、現状ではこの OpenWrt 機自体が LAN 内部からしかアクセスできない状態だが、そうではない(DMZ に設置したり、公開用の WWW サーバーを兼ねている等の)場合は、Dropbear の設定で Interface を LAN のものに絞っておくことによって、SSH が LAN 内部からしかアクセスできないようにすることができる。

二階堂重人氏のデイトレード本

二階堂重人『最新版 株デイトレードで毎日を給料日にする!』(すばる舎、2018-11-27)

株自体の入門書でもないのに、ロウソク足や信用取引についての説明にページ数を割くなど、どうでもいい情報があるので、「デイトレードのテクニックそのもの」についての情報は薄い。ポイントとしては 2 点程度か。

  1. デイトレ銘柄のキャッチの仕方
  2. チャートによる売買タイミング

以上の 2 つの次元で構成されるという点は特に目新しいものではない。銘柄の選別はランキングを使う等の漠然とした話で、ありふれた手法だと思う。唯一、この本の中で詳細かつ具体的に著されているのは、ボリンジャーバンドと変動平均を組み合わせた売買タイミングの方法だけだと思う。

著者のボリンジャーバンドと変動平均を組み合わせた売買タイミングの方法

  1. +2σ を上抜けする急上昇
  2. +1σ を割る反落
  3. 5 分足の 12 本変動平均(1 時間分)を割らずに反発
  4. +1σ を抜けて 12 本変動平均がサポートとなる押し目を形成したことを確認

以上で速やかに in する。

この手法の主旨としては、急上昇の動きをキャッチしようとするところ(トレンドフォロー)にあるが、+2σ を上抜けしたからといって、トレンドフォローが正解の場合と、反対に反落する逆張りが正解の場合があり、これだけではバクチとなる。そのため、一旦反落して押し目を作り、再度、本格的な上昇が開始する前に乗ってしまおうという作戦だろう。押し目狙いなので、まず一旦は反落して一休みする流れは必要であるが、押し目となって再度本格的な上昇が始まるか、そのまま反落して元の黙阿弥になってしまうかを、1 時間分の変動平均がサポートとして機能しているかどうかを基準にしているわけである。

空売りの場合はそのまま上下対称のやり方となる。

ちなみに、利益確定については、特に定まった手法はないようだ。

2019年2月20日水曜日

OpenWrt on WZR-HP-AG300H: Wi-Fi

OpenWrt をインストールしたら、まず最初に手を付ける作業が Wi-Fi。初期状態では Wi-Fi が無効化されているため、Wi-Fi を有効化しておかないと、有線 LAN で直結していないノート PC(Macbook)から作業できない、というのが個人的には決定的な理由。

Device 設定

2.4G 帯と 5G 帯それぞれ、Channel と Transmit Power を設定する。また、それぞれの Advanced 設定の Country Code も JP に設定しておく。

5G のチャンネルは auto で問題ないと思うが、2.4G の方は auto にすると、12ch 以降が選ばれてしまう場合があり、受信側端末によっては 11ch までしか対応していないこともあるので、手動で 1~11ch を選んだ方が良い。

あと、出力について、OpenWrt や DD-WRT ではパブロフの犬のように「出力が 10mW を超えると日本で違法どーだこーだ」の話になりやすいようだが、物好き者 dd-wrtの電波出力調整に関してによると:

電波法でいう10mWっていうのは、10mW/MHzです。 このMHzというのは帯域幅のことですので通常のWi-Fiは1chにつき20MHz幅です。つまり10x20=200(mW)までは日本の電波法の許す上限になります。28mWも63mWも可愛いものです。アンテナを4dBi程度のものにしてもまだまだ余裕があります。日本のホテルのロビーや公共施設なんかに備えられてるWi-Fiはもっと強いですよ。 ちなみに特小は1000mWまで無免許で使えますがWi-Fiは特小に含まれてません。 40MHz幅や80MHz幅のチャンネルを広く使って速度をあげる製品も出てますが、文字通りの解釈ですと10x40=400(mW)とか10x80=800(mW)がOKになりそうなものですが、総務省も馬鹿ではないので、40MHz幅の場合は5mW/MHz、80MHz幅の場合は2.5mW/MHz、160MHz幅の場合は1.25mW/MHzと明記してます。それなら最初から200mWまでって書けば良いのにと思いますけど。

ということらしい。WZR-HP-AG300H の OpenWrt の設定では、最高でも、規制上限 200mW の 1/3 未満の値の 63mW までしか設定できない。

Interface 設定

2.4G 帯と 5G 帯それぞれ、ESSID や Encryption、Cipher、Key を設定し、とどめに KRACK 対策を有効化する。

Encryption
WPA2-PSK(OpenWrt もいつかは WPA3 にアップグレードされるでしょう)
Cipher
Force CCMP (AES)
Key
他の家族の利用も考えると面倒臭いので、本体のラベルに記載されたものをそのまま流用した。

ちなみに、KRACK 対策は少々のオーバーヘッドと引き換えになるようであるが、公衆 Wi-Fi だとかのよほどのトラフィックの激しい環境でない限り、そこを気にするよりも、セキュリティの向上を採りたい。

WZR-HP-AG300H with OpenWrt

2 台目となる Buffalo の Wi-Fi ルーター親機 WZR-HP-AG300H をメルカリで入手した。ちなみに 1 台目は友人が不要になったものをたまたまもらっただけで、特に WZR-HP-AG300H であることを狙ったわけではない。もらってしまってから、DD-WRT というカスタムファームウェアに書き換えられること、それによって、OpenVPN が使えるということを知り、Buffalo 公式の OEM ファームウェアで使える(セキュリティ性能が脆弱な)PPTP ではなく OpenVPN を是非使いたかったので、それだけが目的で DD-WRT にしてみたという経緯であった。なので特に元の OEM ファームウェアに戻すことなど考えずに、その時はただ DD-WRT(v24-sp2 (12/22/14) std - SVN revision 25697)化した。

2014 年頃で DD-WRT の方は(少なくとも WZR-HP-AG300H 用については)安定版のリリースが停滞してしまっている(専らベータ版のみ)。せめて KRACK 対策された安定版が欲しいところ。一方、OpenWrt の方は今でも WZR-HP-AG300H 用の最新版が用意されている。

さらに、OpenWrt は色々と追加パッケージを自分で好きなように入れることができ、中には、Asterisk や Python やデータベースのパッケージもあるという。これは OpenWrt に俄然、興味を惹かれた。

またよくよく調べてみると、昔の時点だけでなく 2019 年の今に至るまで、OpenWrt 用の Buffalo 製ハードとしては WZR-HP-AG300H はメチャクチャ最適な機種らしいということがわかってきた。

型番の AG というのは、Wi-Fi の周波数が 5GHz 帯の IEEE 802.11a と 2.4GHz 帯の IEEE 802.11g の両対応という意味のようで、これ以前の機種や廉価版機種では G のみの型番のものが多く(それらはハードオフなどでも見捨てられてジャンクとして転がっている)、Wi-Fi 性能の点で一線を画している。さらに型番の 300 は IEEE 802.11n の通信速度 300Mbps のことだろう。

とはいえ、後に 3x3 MIMO(450Mbps)や 4x4 MIMO(600Mbps)の機種も登場しているし、IEEE 802.11ac という規格のものも出てきているので、Wi-Fi 性能の点ではもっと新しい世代の Buffalo のルーターもあり、そちらの方がなおさらいいのではないかと言うと、実はそうでもない。WZR-600DHP3 など後の世代のものは CPU 性能がさらに向上し、RAM もフラッシュメモリーもさらに容量が多くなっている。しかし、これら(ブロードコム系無線チップ搭載のもの)は、OpenWrt にファームウェアを書き換えると、Wi-Fi 機能が使えなくなってしまう。Wi-Fi チップに関する制御コードが暗号化されてしまっていて、自由に利用できないとか何とか、ビジネス的な事情によるもののようである。つまり現実問題として、Wi-Fi ルーターとして利用可能な OpenWrt 用の安価な中古ハードウェアとしては、WZR-HP-AG300H が最善の選択となってしまうみたいなのだ(金に糸目を付けなければ、Netgear の R7800 あたりに OpenWrt を載せてみたいものだが)。

1 台目が WZR-HP-AG300H となったのは単なる偶然だったが、今回の 2 台目はそういうことで狙ってこの WZR-HP-AG300H を入手した。1 台目の DD-WRT を OpenWrt に書き換えても良かったのだが、1 台目を DD-WRT に書き換えた時は特に何も戻すこと等は考えていなかったので、オリジナルの OEM ファームウェアのバックアップを取ることなどもしておらず、片道切符での作業だった(調べてみたら、バックアップを使わずとも戻せるので、この点は気にしなくてもよかったことだが)。そういったこともあって、現に運用中の DD-WRT の WZR-HP-AG300H をぶっつけ本番で OpenWrt 化するのはためらわれたので、たかだか 1000 円程度で入手できるものであるからと、2 台目をメルカリで確保し、これを使って安全に気の済むまでいじってみることにした。

OEM ファームウェア(メルカリ入手時 1.72)のバックアップ作業やその検証

mkdir /mnt/usb0_0/firm1.72
dd if=/dev/mtdblock/0 of=/mnt/usb0_0/firm1.72/mtdblock0.bin
dd if=/dev/mtdblock/1 of=/mnt/usb0_0/firm1.72/mtdblock1.bin
dd if=/dev/mtdblock/2 of=/mnt/usb0_0/firm1.72/mtdblock2.bin
dd if=/dev/mtdblock/3 of=/mnt/usb0_0/firm1.72/mtdblock3.bin
dd if=/dev/mtdblock/4 of=/mnt/usb0_0/firm1.72/mtdblock4.bin
dd if=/dev/mtdblock/5 of=/mnt/usb0_0/firm1.72/mtdblock5.bin
dd if=/dev/mtdblock/6 of=/mnt/usb0_0/firm1.72/mtdblock6.bin

ubootenv set で変数を一種類のみ変更して前後でのファームウェアイメージの変化を調べたところ、mtdblock1 以外に mtdblock4 にも変化が見られた。また、純正ファームウェア上での「設定初期化」では、ubootenv の変更はリセットされなかった。dd コマンドによる mtdblock1 の書き戻しで、ubootenv list の内容がリストアされることも確認した。一方、mtdblock4 は ubootenv set の前後のいずれとも一致しなかったので、起動毎に構成されるような一時的なデータが格納されるものと思われる。

さらに 1.72 → 1.73 へのアップデートで、mtdblock2、mtdblock3、mtdblock4、mtdblock6 が変化した。やはり、mtdblock0 は U-Boot 本体であるから不変であるべきであろうし、mtdblock5 の ART というのは、シリアル関係のファームなのだろうか、OS とは別個のものなのだろう。

OpenWrt ToH の Flash Layout によると、サイズから推測するに、OpenWrt では、rootfs_data 用の領域が増えているだけで、残りの 7 ブロックについてはサイズ的に一致している。一方、DD-WRT の方は、U-Boot(RedBoot に変更される)も含めて大幅に書き換えられているようである。

ubootenv コマンドによる TFTP の有効化等

OEM Web UI のデバッグモードにてコマンドを実行:

ubootenv set accept_open_rt_fmt 1
ubootenv set region US

OEM ファームウェア 1.73

オリジナルの OEM ファームウェアでは 1.73 がベスト。デバッグモードが使えて、ubootenv コマンド(TFTP の有効化と、リージョン変更のために必要)や dd コマンド(オリジナル状態の ROM イメージをバックアップしておくために必要)等が実行できるから。1.74 以降はデバッグモードが無効化されている。

OpenWrt(や DD-WRT)へのファームウェアの載せ替え作業自体は、デバッグモードが使える(1.73 以下である)必要はなく、(1.74 以降であっても)Web UI からのアップデートでインストールが可能である。

文鎮化

何度かネットワーク設定を誤って文鎮化したことがあった。TFTP リカバリー機能(予め、OEM Web UI で ubootenv コマンドを使って TFTP を有効化しておく必要がある。この方法が使えないと、殻割りしてシリアルコンソールによるデバッグ方法しか手段が残されていない)を使って回復させた。

OpenWrt を TFTP リカバリーから入れられるようにするため、ubootenv で region を US にしていたため、日本版の OEM ファームウェアは入れられなかったので、US 版の OEM ファームウェア(ちなみにバージョンは 1.78)を使う必要があった。

また、OEM ではなく、OpenWrt でリカバリーする場合には、TFTP 用のファームウェア必要となるが、15.05 のファームウェア openwrt-15.05.1-ar71xx-generic-wzr-hp-ag300h-squashfs-tftp.bin が現時点で最新の TFTP 用であり、一旦 15.05 で復活させて、それを 18.06 にアップグレードする形で復旧した。

TFTP サーバー機としては、Windows10 機を使った。手持ちの Macbook には有線 LAN の接続手段が無く、Linux 機もスイッチングハブを介さないケーブル直結状態では ip コマンドが失敗するので、Windows に落ち着いた。1: netsh コマンド; 2: arp -a コマンド; 3: tftp -i コマンドの計 3 行のコマンドからなるバッチファイル(recover. bat)を使ってタイミングを測って実行するやり方で上手く行った。

Technical Glossary

U-Boot (Universal Boot Loader)
組み込み機器における、PC-Linux にとっての BIOS + GRUB の部分に相当するもの。もちろん WZR-HP-AG300H にも使われている。この U-Boot が、OEM ファームウェアの Web UI なり、OpenWrt なりを起動してバトンタッチすることになる。つまり、(オリジナル、OpenWrt、DD-WRT の)Web UI によるファームウェアの書き換え処理によって変更されるのは、U-Boot によってバトンが渡される先の OS 本体の部分についてであって、(恐らく)U-Boot は不変である(ただし、mtd コマンド、dd コマンド、cat コマンド等で書き込み先を指定して直接書き込みを行う場合には、そこがたとえ U-Boot の部分であっても書き込めてしまうだろうから、くれぐれも書き込み先の指定は間違えないように注意する必要がある)。
TFTP (Trivial FTP)
U-Boot が備えている機能の一つで、ネットワークからファイルをダウンロードする。ブート用の OS のカーネルイメージをネットワークから読み込(んで、Flash ROM に書き込)むのに利用されている。Buffalo が TFTP を応用したこのような機能を用意しているのは、何らかの理由でファームウェアが壊れた場合に、ファームウェアを改めて書き込み直すというリカバリー手段としてであろう。日本版の WZR-HP-AG300H ではデフォルトでは TFTP が U-Boot の環境変数(フラグ)で無効化されている。
WZR-HP-AG300H の TFTP リカバリー機能
WZR-HP-AG300H の IP アドレス: 192.168.11.1; MAC アドレス: 02:aa:bb:cc:dd:20; TFTP サーバー(PC)の IP アドレス: 192.168.11.2; 待ち時間 4 秒(ubootenv で tftp_wait を 4 秒よりも長い時間に変更できるが、実際には効果がないように思われる)。
👉 BHR-4GRVでのTFTPインストール方法(DD-WRT OpenWrt 適材適所で両方使いたい人向け)BHR-4GRV 用の説明だが WZR-HP-AG300H と基本的に共通している。
👉 WZR-HP-AG300H を tftp で純正ファームに戻す(ばっくらっしゅの備忘録)実際の作業上のタイミングを知る上で、ここの写真入り解説が一番わかりやすい。
👉 WZR-HP-AG300H(OpenWrt ToH)
👉 De-bricking and TFTP Info(DD-WRT wiki)
OpenWrt ファームウェアの種類
***-squashfs-factory.bin(OEM Web UI → OpenWrt)
***-squashfs-sysupgrade.bin(OpenWrt → OpenWrt)
***-squashfs-tftp.bin(U-Boot の TFTP リカバリー機能を用いた OpenWrt 化)
DD-WRT からの OpenWrt 化
DD-WRT の linux ブロックは、OpenWrt の firmware ブロック(さらには OEM ファームウェアの ブロック 6)に相当するようだ。***-squashfs-sysupgrade イメージがそのブロックの中身そのもののようである。
👉 DD-WRT化したWZR-HP-AG300HからOpenWRTのインストール方法(DD-WRT OpenWrt 適材適所で両方使いたい人向け)
👉 オリジナルfirmwareへの復旧方法 > OS上から > CLIコンソールからの復旧(DD-WRT OpenWrt 適材適所で両方使いたい人向け)
OEM ファームウェア上でのファームウェアイメージのバックアップ
👉 BHR-4GRVでのTFTPインストール方法(DD-WRT OpenWrt 適材適所で両方使いたい人向け)dd コマンドによるバックアップが丁寧に記載されている。
👉 ファームウェア・設定ファイルなどのバックアップ・書き込み(DD-WRTまとめwiki)バックアップされるイメージは U-Boot 用のイメージなので、バイナリーが「27 05 19 56」で始まるファイルのはず(未確認)。
OEM ファームウェアのデバッグモード
1.73 以下で、user: bufpy; pass: otdpopy(ところで、bufpy の buf は Buffalo の buf なんだろうけけど、py とか otdpo は何を意味しているのだろうか?)
ubootenv set コマンドで環境変数(accept_open_rt_fmt, region 等)を変更できる。ubootenv list で環境変数のリストを表示できる。
👉 WZR-HP-AG300H、デバッグモードに入り telnetdを起動(ばっくらっしゅの備忘録)
👉 デバッグモードによるファーム書き込みでWZR-HP-AG300HをWZR-600DHPに変身(物好き者)
👉 今日のお品。WZR-600DHP ハードウェア的には WZR-HP-AG300H と同等品の WZR-600DHP だが、ダウンロード配布されている OEM ファームウェアが暗号化されているかいないかという違いがあるようだ。OEM ファームウェアしか使わないのであれば、WZR-600DHP 化して喜んだりするのもありだが、OpenWrt 化を前提にすると、改悪版以外の何物でもない。
DD-WRT での NVRAM リセット方法(未確認)
telnet で 1) erase nvram 2) reboot
👉 【Buffalo】 DD-WRTから元に戻す & OpenWrtの導入 【改造】

OpenWrt 化後の作業

  1. Wi-Fi
  2. SSH
  3. Timezone、NTP
  4. ブリッジ化
  5. VPN サーバー
  6. USB Drive
  7. WWW サーバー(uHTTPd)
  8. Python3
  9. MariaDB
  10. SFTP サーバー

OpenWrt 化後の作業例:👉 OpenWrtを設定していく