ししおどし

Eclipse (neon) に Amateras Modeler（プラグイン）を追加した。 GEF SDK のインストール（http://download.eclipse.org/releases/neon から GEF をフィルタリングして見つければよい） Amateras Modeler のインストール（http://takezoe.github.io/amateras-update-site/ からインストールすればよい） 使い方は、File > New > other > AmaterasUML > クラス図 で新規作成し、クラスファイルをドロップすれば自動的にクラス図が表示される。

Core 2 Duo のデスクトップ PC から、HP の Core i7 のノート PC に移行して 1 ヶ月以上が経過した。当初は、様子を見て、旧環境をそのまま放置しておいたのだが、どうやら新環境で問題はなさそうなので、旧マシンは処分することにする。 差し当たって、HDD のデータを完全消去しておく。「 Linuxを利用したHDDの完全消去 」を参考にした。よくまとまっていて、むしろ Live 環境の作成について字数が多くなり過ぎというくらいで、特に他に情報を参照する必要はなかった。 簡単にポイントをまとめておくと： Live 環境 スーパーユーザー化 デバイスファイル名の調査 shred コマンド で、デバイスファイル名自体は除くとして、su や shred の各コマンドのオプションもそのまま使えるものだった。 Live 環境は、色々なやり方があり、僕の場合、UNetbootin を使った Live USB を作成した（ISO イメージは Ubuntu GNOME のものを使った）。

「 ソフトバンクがiPhoneの修理を拒否？Twitterユーザーの報告が話題 」というニュースを目にした。 このニュースは、そもそものソースのユーザーの印象をそのまま受けたニュースとして拡散しているので、基本的には「ソフトバンクの対応が酷い」という主旨の話題として取り上げられている。 しかし、僕が個人的に、このニュースにひっかかるものを感じて、ピンときたものがあったのは、昨年 2015 年の 5 月頃の出来事のことである。 当時、知人（女性）が古くなって使い勝手の悪くなった Windows ノート PC をどうにかしたいと相談してきたので、たまたま、新しい 12 インチの MacBook が登場したばかりのタイミングだったので、「渡りに船」とばかり、勧めて、彼女は MacBook を購入したのだった。アップル・オンラインからの直接購入である。 そしてその際、一つだけ、僕の趣味を反映してもらって、US キーボード版にしてもらった。そのためか、日本国内からではなく、香港からの発送となった。 従来の MacBook Pro や MacBook Air のユーザーが様子見で、まだ世間では MacBook の評価が定まっていない時期、彼女は届いた MacBook に大喜びだった。しかし── その MacBook が、約 1 ヶ月で故障し、立ち上がらなくなったのである。 彼女は、アップル製品の正規サービスプロバイダである クイックガレージ に持ち込むなどして、数日の紆余曲折を経た結果、最終的に「初期不良」との診断となり、交換となった。 次に送られてきた新品は、見違えるように、快調なものだった。 事態が落ち着いてから、彼女が漏らした感想は、「最初の機体はりんごのマークのロゴが腐食してくすんでいた。新しい機体はピカピカだ」というものだった。 僕は、「もしかして、香港から送られてくる、その過程で、内部の人間が偽物（または廃棄されるべき不良品）とすりかえた可能性があるかもしれない」と思った。アップルという会社自体に対する信頼が揺らぐものでもないが、あれだけ大きなグローバル企業だから、内部に不貞の輩が入り込んでくることは、どうやっても避けられないだろう。 MacBook も 2016 年版くらいになると、そろそろ従来のアップル信者も使い出してきているようだが、当

Gimp で処理を自動化して複数の画像ファイルを処理するために、Script-Fu や Python-Fu がデフォルトで用意されている。Lisp や Python をスラスラ操れる人ならいいのだけど、僕の場合、Java や Perl が「ネイティブに」操れる言語で、Lisp や Python の方はリファレンスを駆使しないと、ちょっと厳しい。 それほど大げさな処理をするのではなくて、一律、サイズを変更したり、画像を回転させる程度の決まりきったことをしたいだけ。こういう時に便利な Gimp 用プラグインが、 David's Batch Processor (DBP) 。おそらく Ubuntu (Linux) 用で、公式ページに説明されている通りのインストール手順に従って、make すると、インストールできる。 やりたい操作が、GUI の形で行えるので、とても使い易い。

仮想ホストの HTTPS や証明書の設定をしていた時、何かの拍子、というか XXX.myqnapcloud.com の証明書の設定をリセットした拍子に、Web UI にログインできなくなり、困った状態になった。延々と Web 画面がリダイレクトされるループ状態になってしまう。 原因は、デフォルトでは、Web UI の HTTP ポートが 80、HTTPS ポートが 443 で、仮想ホストの Web サーバーの HTTP ポートが 8080、HTTPS ポートが 8081 のところを、Web UI と仮想ホストで入れ替えて、Web UI が HTTP（8080）と HTTPS（8081）、仮想ホストが HTTP（80）と HTTPS（443）にしていた。さらに、Web UI を HTTPS のみでログインできるようにして、HTTP ではログインできないようにしていた。ポート設定が、証明書のリセットのタイミングで Web UI のポート設定がデフォルトに戻り、HTTP はログインを拒絶して HTTPS にリダイレクトするのだが、リダイレクト先が間違っており、仮想ホストの無効なポートへのアクセスとして処理されて Web UI の HTTP へとリダイレクトを戻す、というループに陥ってしまったようだ。 最悪、NAS の設定をリセットして再起動すればいいわけだが、SSH によるログインはまだできる状態だったので、リセットが避けられればそれに越したことはない。情報を検索すると、 QNAP のフォーラム にまさしく同じ状況に陥っている人がいて、達人の pwilson さんが対処法を回答していた。お蔭様で、設定リセットすることなく、復帰することができた。 pwilson さんは一連のコマンドをアドバイスしてくれているが、僕のケースでは、HTTP でのログインさえ再び有効化すればよかったので、SSH で、 setcfg System 'Force SSL' '0' /etc/init.d/Qthttpd.sh restart /etc/init.d/stunnel.sh restart だけ実行して、HTTP でのログインを有効にして、あとは、HTTPd と stunnel を再起動するだけで十分だった。 それで Web UI にログイン

中間証明書の問題はクリアしても、 SSLLabs のテスト は、RC4 を使っているせいで B 評価となる。ところが、myqnapcloud の方は A 評価なのに気付いた。 これもおそらく、QNAP の中の人が、仮想ホストでの使い勝手を考慮していないためだろう。 myqnapcloud の設定は、/etc/config/apache/extra/apache-ssl.conf ではないかと推測し、その SSLCipherSuite の設定を /etc/config/apache/extra/httpd-ssl-vhosts-user.conf に移植してみた： - SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!SSLv2:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM + SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL

昨日はどうにか仮想ホストでちゃんと中間証明書を有効にする方法を確立した。さらに一日経って、頭が整理できて、全体的により洗練されたやり方に行き着くことができた。昨日の成功をベースにして SNI（仮想ホストのそれぞれで別々の証明書を使い分けること）も余裕でできることがわかったので、それも含めて、全体を整理し、洗練したやり方になったので、それをまとめておこうと思う。 Web サーバーのポートの設定 Web UI 用のポートは「システム設定 > 一般設定 > システム管理」で 8080（HTTP）と 8081（HTTPS）に設定した。さらに、「HTTPS のみを使用する」設定にした。 Web サーバーのポートは「Webサーバ > Webサーバ」で 80（HTTP）と 443（HTTPS）に設定した。さらに仮想ホストの設定で、 443（HTTPS）の設定の仮想ホストだけをエントリーした。 StartSSL での証明書の取得 StartSSL で、仮想ホストそれぞれの証明書と、XXX.myqnapcloud.com 用の証明書もついでに取得する。これらの中間証明書はすべて共通（StartSSL）の中間サーバーのものとなるので、中間証明書は別々に用意しなくてもいいのが洗練されたやり方となるポイント。 それぞれの Web サイト認証は、「Website Control Validation」のリンクをクリックして、認証用の HTML をダウンロードし、ウェブサイトのルートに設置してから、認証ボタンを押して、認証を成功させることができる（認証後は、認証用 HTML を削除して構わない）。ちなみに、XXX.myqnapcloud.com のルートは、/share/Web そのものである。 XXX.myqnapcloud.com 用の証明書の設定 XXX.myqnapcloud.com（Web UI）用の証明書は、Web UI から「システム設定 > セキュリティ > 証明書とプライベートキー」で行える。StartSSL からダウンロードした zip の中の さらに ApacheSever.zip の中の 2_XXX.crt を証明書としてアップロード、秘密キーには、StartSSL のツールボックスの「Decrypt Private

QNAP で HTTPS のために SSL 通信用のデジタル証明書をセットアップできたと思っていたら、PC 等他の環境では問題がないものの、Android の Chrome でセキュリティ警告（NET::ERR_CERT_AUTHORITY_INVALID）が出るという問題に直面した。 SSLLabs のテスト では incomplete chain や extra download と言われる。 丸一日かかって、どうやら完全に問題を克服することができた。 だいたい、こういうノウハウというのは、英語の情報（QNAP のフォーラム等）を参照すればどうにかなるもので、ほとんどのプロのエンジニアの人でも、正解となる先人の情報をどう見付けてくるかという話で、それをそのまま自分のブログに記録しているだけのケースが基本だろう（特に日本語においては）。（プロではないただのエキスパートなだけの）僕も、そういうつもりでいたのだけど、今回は、既存の情報が、低レベルなものしか見付からず、結局、自分の要求する水準のものを実現するために、自分でオリジナルに解法を確立する他なかった。 まず、何が馬鹿馬鹿しいかというと、QNAP の Web UI のセキュリティ設定があって、あそこで証明書を設定するものだと思っている人がほとんどだと思うのだが、あれがまず、騙し。あれって、myqnapcloud.com の Web UI 用の Web サーバーにしか関係がない、というかその用途しか、QNAP の中の人も念頭にない。仮想ホストで、独自ドメインを使って Web サーバーを使う場合のことは、全く蚊帳の外という……。 ほんで、英語の情報をどんなに探し回っても、Web UI 用の Web サーバーに対する証明書のセットアップについて、中間証明書を有効にする方法ばかり。それも古い情報が多いなと思ってたら、Web UI 用の Web サーバーについては、Web UI から中間証明書がコピー＆ペーストで設定できるように今では対応済なんだから、当然。 もう、しょうがないので、最後は「ランボー怒りのリバースエンジニアリング」。Apache 関連のコンフィグを眺め回して、試行錯誤繰り返して、やっと仮想ホストでデジタル証明書を中間証明書を含めて適切に設定する方法を突き止めた。 httpd-ssl-v

QNAP の AppCenter で色々と追加パッケージをインストールできるという話だけど、Perl のバージョンが 5.10 というのはやる気がなさ過ぎる。 ……で、そもそも、QNAP のサーバーは初めて使うので、元々 Optware だとかのその手の類のものは何もインストールされていない状態だったのだけど、調べてみると、Entware、Optware、QNAPware、Itsy OPKG というのは、ぜ〜んぶ古くて、今は Entware-ng が活きてるものらしい。しかし、ネットで QNAP の情報を調べても、特に日本語では、古い情報が比較的多く残ってるので、この点は要注意だと思った。そこまで QNAP を使い倒しているような人が少ないせいだと思う。 Entware-ng については非常に情報が少なく、さらに、自分の使っている HS-210 で使えるかどうかも全く不明な状態だったが、今まで AppCenter も使ったことのない状況で、いきなり、 apps.qnap.community というサイトから qpkg をダウンロードし、AppCenter の設定からファイルを指定して手動でインストールするという、冒険に出た。全く確信はなかったが、これ以上情報を調べるのはもっと面倒臭かった。 すると、インストールは簡単に終ったようで、AppCenter のマイアプリに Entware-ng のアイコンが加わっているので、アンインストールも簡単そうだ。 それで、次に、ちゃんと動くのかどうか、SSH でログインしてみた。Perl が目的だったから、perl -v したが、何も反応なし。 perl -v -sh: perl: command not found どうやら、Entware-ng がインストールされた状態で、Entware-ng を使って、Perl などの個別のモジュールをインストールするようだ。それには opkg コマンドを使うらしい。Ubuntu の apt-get みたいなものだろう。下のような流れで Perl をインストールした： opkg update Downloading http://pkg.entware.net/binaries/armv5/Packages.gz. Updated list of availabl

QNAP の Apache では、.htaccess がデフォルトでは無効化されているので、有効にするには、apache.conf の設定を 1 ヶ所、変更する必要があります。 <Directory /> Options FollowSymLinks - AllowOverride None + AllowOverride All Order deny,allow Deny from all </Directory> apache.conf は /etc/config/apache/apache.conf にあります。vi を使って編集してもいいですが、僕の場合は、scp を使ってローカルにコピーし、gedit で編集して、scp でアップロードして戻すやり方で作業しています。

2016-05-03 の記事「 楽天カード（JCB）でドトールバリューカードへクレジットチャージする方法 」では、JCB から直接チャージできないドトールのバリューカードへ、楽天のバーチャルマスターカードを経由してチャージする方法を紹介しました。 今、偶然、気付いたのですが、JCB でチャージ可能になっているじゃないですか！ それも、7/29 に始まったばかり。 実は、7 月 25 〜 31 日の期間限定で、LINE Pay カードのポイントが通常の 2 倍の 4.0% になっているところだったので、早速、上限の 3 万円ギリギリまでチャージしてしまいました。偶然良いタイミングで気付いたものです。 LINE Pay の件は脇に置くとして、ドトールの神対応ぶりに感心しました。 実は、5 月の時点で、上記のようなバーチャルマスターカードによる迂回策を編み出す前に、ドトールに JCB が使えるようにして欲しいとの要望を出していたのです。オンラインフォームから送信したので、こちらの文章は残っていませんが、ドトールからの回答はちゃんとメールでいただきました： Sent: Wednesday, April 27, 2016 at 5:04 PM From: support-dcs@doutor.co.jp To: xxxx@xxxxx.xxx Subject: バリューカードの件・お詫び申し上げます 拝啓 時下ますますご清祥のこととお慶び申し上げます。 平素は、弊社チェーン・ドトールコーヒーショップをご利用いただきまして、誠 にありがとうございます。またこのたびは、ドトールバリューカードに関しまし て、貴重なご意見を賜りましたこと、重ねて御礼申し上げます。 しかしながら、マイドトールにてクレジットチャージを行う際“ＪＣＢ”カードの ご利用が叶いませんことから、ご不便をお掛けしておりますこと、お詫び申し上 げます。 現状、同カードの導入の予定はございませんが、弊社関係部署に申し伝え、今後 の検討課題とさせていただきます。 このたびは、貴重なご意見を賜りまして、誠にありがとうございました。 敬具 株式会社ドトールコーヒー お客様相談室　 僕自身がどういう言い方で要望を伝えたのか残っていないのが残念ですが、確か、「ドトールの客層だと、普通に JCB を

rsync は SSH 越しでも行えるので、QNAP の SSH サーバーをセットアップすれば、「VPN を経由した NFS による rsync」（👉 その 2 ）という少々器用な真似をせずに済むようになる。 ※ただし、QNAP の SSH は admin しかログインできない点には留意する。以下の作業ではすべて、admin で SSH 接続するためのものである。 QNAP の SSH 環境を整備する 自機側で RSA キーペアを作成する。 ssh-keygen -t rsa -C " 作成するキーペアに関するコメント情報 " 作成したキーペアのうち、公開鍵（id_rsa.pub）の方を QNAP (NAS) へ scp コマンドで転送する。当然、この際は、QNAP 側の SSH サービスはオンにしておく必要があり、admin アカウントとパスワード認証で scp の処理を実行することになる。 scp ~/.ssh/id_rsa.pub admin@ (NAS IP Address) :~ (admin にとっての ~ へコピー) SSH で QNAP に admin でログインし、~/id_rsa.pub を ~/.ssh/authorized_keys へ（追記）コピーする cat id_rsa.pub >> .ssh/authorized_keys chmod 600 .ssh/authorized_keys rm id_rsa.pub 以上で、QNAP 側の準備は終わり。 SSH から一旦ログアウトし、再び SSH で QNAP にログインすると、（自機側によって）パスフレーズを尋ねられる。問題なければ、ログインに成功する。これでパスワード認証ではなく、公開鍵認証によるログインができるようになった。 ※自機にある作成したキーペアはちゃんと管理しておくこと（セキュリティ面と、バックアップ面の両面において） 一応、SSH を利用するための作業としては以上である。SSH というのは、公開鍵をサーバー側にアップロードしておいて（公開鍵をアップロードできるのは、本人であるという前提による）、その公開鍵（サーバー側）と暗号鍵（本人側）をペアで使って、本人認証を行うというのが基本コンセプト。 ただし

👉 その 1 では主に rsync コマンドの記述について説明したので、ネットワーク経由で NAS の指定した path にバックアップする方法の詳細については述べなかった。今回からは、その部分について、僕が試行した方法について説明する。 NAS の特定のフォルダを、NFS を使って自機にマウントして、自機のフォルダとして利用する まず最初に僕がやったのが、NFS を使って自機にマウントして、自機のフォルダと見做せるようにし、rsync では、ローカルのフォルダー間での同期として扱うやり方である。この場合、rsync の dest_path の指定において、NAS のネットワークアドレスに関する（admin@XXX.XXX.XXX.XXX: の部分の）記述は不要となり、次のような形で済む： rsync -auv --delete --progress ~/mydata /mnt/qnap/backup Linux（UNIX 系 OS）の非常に優れた文化が、このように、ネットワークドライブであろうが、さらには、入出力デバイスであろうが、すべて「ファイル」としてアクセスできるように、スッキリと極めてスマートに整えられている所である。 それはいいとして、この場合、rsync 側では、ネットワークのことは意識する必要はなくなるものの、NFS を使ってマウントする際には、ネットワークアドレスを指定する必要があるので、実質的には違いはない。誰が請け負うかが変わっただけである。 1: QNAP 側 で NFS を設定する QNAP 側では、「権限 > 共有フォルダ > NFS ホストのアクセス」で homes を「アクセス権：制限なし」にする。 2: Ubuntu 側で NFS を設定する まず、NFS をインストールする： apt-get install nfs-common NAS の共有フォルダを、Ubuntu 側に NFS としてマウント： マウント用ディレクトリを用意： mkdir /mnt/qnap マウントする： mount -t nfs XXX.XXX.XXX.XXX :/homes/ username /mnt/qnap （参考： How To Set Up an NFS Mount on

実家に設置している QNAP 製の NAS に、自機（Ubuntu）からデータを rsync でバックアップする体制を確立する。 rsync は、最初に一度バックアップしてしまえば、以降は差分（変更したもの）だけを修正する形になるので、毎回全体を丸ごとバックアップするような重い作業とはならず、極めてスマート。 rsync コマンドの使い方 rsync コマンドは、man rsync すれば詳細は調べられるとして、自分にとって必要な形は次の通り： rsync -auv --delete --progress src_folder dest_path -a はアーカイブ用オプションで、ファイルの権限情報の保持などのいくつかのオプションのセット指定。-u は、タイムスタンプが新しくなる場合にのみ更新する。-v --progress は詳細な情報を作業の進行とともに表示。--delete は、削除したファイルも同期して削除する。 src_folder と dest_path は他の多くの人が指摘するように、ひとつのハマりポイントなので注意すること。通常、バックアップする場合は、あるフォルダーを丸ごと NAS にコピーする意識で行う。こういった場合、 src_path の指定はフォルダー名で終わり、/ を付けない形で記述する。/ を最後に記述してしまうと、そのディレクトリの中の各ファイルを意味してしまい、バックアップ先に、そのディレクトリ直下の各ファイルが直接ぶち撒けられる形となるので、要注意。 一方、 src_path の指定をフォルダー（ src_folder ）にした場合、 dest_path は、そのフォルダーが置かれるべきパスにするべきである。つまり、バックアップ元の最後尾にあるフォルダー名は抜いた、そのフォルダーが配置されるべきディレクトリ名を指定する必要がある。初回のバックアップでは失敗しても気付かないかもしれないが、もし失敗した場合、同じフォルダー名のディレクトリが二重で置かれることになる。次回のバックアップでも同じ指定をするのなら、それでもいいのだが、もし一貫性がないと、前回のバックアップと別物として扱われ、差分ではなく、また新たに丸ごとがバックアップされてしまうようなことにもなりかねない。 例えば、自機の ~/mydata

👉 ゴーダ経のこと はかなり前から一度まとめたいと思っていたトピックで、日々の生活でいつの間にやら流れてしまっていました。それが最近、知人にとある出来事が起って、五戒のことについて意識の焦点が当たりました。それで、五戒を預流果聖者の必要条件とするかどうかという、ゴーダ経のことを思い出して、今回ついにブログにまとめてしまったというわけです。 知人は、それなりに善良なテーラワーダ仏教徒なのですが、ある時、新しく移った職場の関係で、流れで飲酒してしまったことがありました。その件で少なくともその時点において「五戒が身に付いていない＝預流果ではない」ことは確定したわけですが、全般的には五戒を守る生活をしており、テーラワーダ仏教と特に縁のない、五戒とは無縁なタイプの人とは、一線を画していることは確かでした。 その知人の職場で、問題が発生し（知人自身は問題とは何の関係もありません）、組織が崩壊してしまい、新しい職場を探さなければならない事態になったそうです。 ところが、知人は色々と今の職場の責任者の方が親切に気遣ってくれて、新しい職場へ移れることになったそうです。 本当は元のまま平穏無事に続けられたらもちろんそれに越したことはなかったと思いますが、今の職場の他の人達の状況と比較すると、明らかに「不幸中の幸い」とでも呼ぶべきか、嵐の中、比較的無事にくぐり抜けているように見えます。 これが五戒の力だと思います。同じ嵐に遭っても、その嵐をどれだけまともにくらってしまうか、しまわないか。 戒は防護です。 戒を禁欲と捉えている人は、形式上で戒を守っても、戒禁取（かいごんしゅ）として機能するのがオチでしょう。 戒が防護だとわかっている人は、それは単にプラスでしかないので、止めろと言われても、解くことはないでしょう。 何らかのマイナス（犠牲）との引き換えのご褒美の何かプラスを期待するという、戒禁取ではないのです。 知人の職場に起ったような事態は、捉えようによっては、「魔」が引き起したというべき、不幸な出来事です。ヤッカ（夜叉）とは、いわゆる西洋世界におけるデーモン（魔神）と呼ばれているものこそはヤッカのことであり、人に憑依したり、何か破滅的な事態を引き起します。また、「魔（マーラ）」という言葉自体は、他化自在天のうち、悪意を持つ神を指しますが、不幸な物事を直接引き起すとい

Linksys WUSB54G-JP を昔、オークションで中古ルーターを落札したときのオマケで入手したものの、ほとんど使われる機会のないまま眠らせていた。ふと今使っている Linux (Ubuntu) マシンで有線 LAN の代わりに使おうと思って調べてみたら、あっけなく上手く行った。 WUSB54G-JP はアメリカ版の WUSB54G v4 と同じもののようで、v1~3 と違って v4 だけチップが Ralink 製で、Ralink チップ用のドライバー（p54usb）で動くとの話。今使っている Ubuntu 15.04 では標準でモジュールが含まれているようなので、modprobe するとすぐに動くようになった： sudo modprobe p54usb ひとつだけクリアしなければならない問題があって、このドライバーは、省電力機能がちゃんと対処できていないため、通信がブツ切れになってしまい、例えば、インターネットラジオなどを聴くに耐えない状態になる。 これに対する対処法は省電力機能全体を無効化してしまうこと： sudo iwconfig wlan0 power off これで見違えるようにスムーズな通信が確立できる。 あとはこの iwconfig コマンドを PC を起動する毎に入力するのもバカらしいので、起動スクリプトで実行するようにしておけばいい。 uwsb54gv4.sh という名のスクリプトでも作って、そこにコマンドを記述する： #!/bin/sh iwconfig wlan0 power off これを /etc/init.d に移動し、パーミッションを適当に設定し： sudo mv wusb54gv4.sh /etc/init.d chmod 755 /etc/init.d/wusb54gv4.sh 最後に、起動スクリプトとして設定する： update-rc.d /etc/init.d/wusb54gv4.sh ※起動時はこれで自動で省電力機能の無効化コマンドが実行されるわけだが、ルーター側を再起動するなりして、何らかの拍子に Wi-Fi の接続が一旦切れてしまったような場合は、ドライバーがリセットされて省電力機能が復活してしまうので、都度 iwconfig コマンドで無効化し直す必要があることには留意する

Buffalo の WZR-HP-AG300H というやや古いルーターのファームウェアを DD-WRT 化したものを、有線・無線両方用にブリッジとして使うセッティングをしました。 まず、ルーター自体が古いせいなのか、最近の Buffalo のルーターは DD-WRT 化できない（？）のか、どういった理由なのかわかりませんが、情報を検索しても、2013 年頃のものがほとんどです。DD-WRT のバージョンも 2013 年頃のバージョンの話題ばかりです。しかし、今回の作業に当って調べてみたところ、2014 年 12 月のバージョンが出ていたので、もちろんアップデートしておきましたが、そのことに触れている情報がないということは、今さら感があるのかもしれません。またちなみに、WZR-HP-AG300H の方も、つい最近（2016-05）に、v1.75 の純正ファームウェアが出ているのですが、誰も話題にしていないようです。 基本的に、無線ルーターということから、Wi-Fi 側を LAN にブリッジする設定の情報は見つかりやすい一方、有線の方をブリッジにする話というのはあまり話題にされていないようです。DD-WRT 化しない元の WZR-HP-AG300H であれば、ディップスイッチでルーター機能を OFF にしてブリッジモードにすればいいだけです。わざわざ DD-WRT にしてかつ、ブリッジモードにするという使い方をする人は少ないのかもしれません。 やり方は Buffalo USA の公式の FAQ に載っていたのを見つけ、基本的にそれに従って設定すれば、うまく行きました。 （設定を初期化） Setup > Basic Setup WAN Connection Type : Disabled Local IP Address : 192.168.0.2 Subnet Mask : 255.255.255.0 DHCP Server : Disable (also uncheck DNSmasq options) Gateway/Local DNS : 192.168.0.1 Assign WAN Port to Switch: enable Setup > Advanced Routing operating mode to :

「HWD WiMAX2+ リモコン for W01 / W02」というアプリを公開。 UQ WiMAX の Huawei 製ルーター Speed Wi-Fi NEXT W01 と W02 に対応した Android アプリ。 手軽に、スリープ状態の On/Off、電源の Off/Reset が行えるようにした。 通信量などを見るための常駐アプリは既に存在するようなので、スリープや電源操作だけのためのアプリとして作成。 HWD WiMAX2+ リモコン