How to Use Your EZCast Device with Your iPhones/iPads

UI Language

Yeah, I know. The manual sucks. Welcome the wonderful world of directly imported Chinese products.
But once set up, the device works rather well. If you could give me a week or so, I would write up an introduction for iOS device users.

The caveat you need to know at this point is; the official YouTube app on iOS devices is not capable of streaming videos to EZCast. It did in the past so the compatibility must have gotten broken at some point. You could instead use third-party YouTube apps (with AirPlay capabilities), and they seem to work fine with EZCast.

Oops, I failed to notice your first message. Do I have one? No. I have like ten. LOL I purchased one first and tested it. It give me satisfactory results so I ordered a dozen, which are all meant to be used as presents. I do not have a big TV with an HDMI input so for me, that device is useless.

That device is rather versatile, but for iOS users, any media app that supports AirPlay (most do) can be used to stream contents to the device (except the official YouTUbe app at this time). It is supposed to be able to be used with a Mac too, but I haven’t tested that feature.
I am glad if you liked the device… but neither of us knows that yet. Sorry it took me this much time (almost four years!) but I’ve been meaning to show my appreciation all this time. It’s just that my life here has been crazy.

Amazon Fire TV vs. Roku vs. Chromecast vs. Apple TV – How they Compare with Each Other – The Fuse Joplin

AirPlay – Wikipedia, the free encyclopedia

TP-Link TL-WR703NのOpenWrtをBarrier Breaker RC3にアップグレード

自分の持つポータブルルーターTP-Link TL-WR703NにはOpenWrtのAttitude Adjustment (12.09, r36088)をインストールしてあったが、BarrierBreaker 14.07 RC3が公開されTP-Link TL-WR703Nのイメージも用意されていた(r42056)ためインストールしてみた。わざわざアップグレードした理由があるのだがそれは後日。

ちなみに自分でもソースを取ってきてビルドしてみたがうまくいった。以前試したときにはサイズが大きくなりすぎてファームウェアのイメージが作成できないという問題があったが、今回はそういう問題は一切なかった。

以下アップグレードの手順。

1. Web UI(Luci)で設定ファイルのアーカイブのダウンロード(結局役に立たないどころか害になってしまったが。後述)。

2. 次に同じくLuciでsysupgrade.binイメージをアップロードしてアップグレード。設定を維持する、というチェックボックスを入れておく。

3. 本体メモリだけでは絶対的に容量が不足するので、Extrootで外部USBメモリを使う。Ext4でフォーマットするのなら以下で準備。

opkg update
opkg install kmod-usb-storage block-mount kmod-fs-ext4

このステップで以下の様なエラーが出る(パッケージ名は違うが例として):

root@OpenWrt:~# opkg install kmod-scsi-generic
Installing kmod-scsi-generic (3.10.49-1) to root...
Downloading http://downloads.openwrt.org/barrier_breaker/14.07-rc3/ar71xx/generic/packages/kmod-scsi-generic_3.10.49-1_ar71xx.ipk.
Installing kmod-scsi-core (3.10.49-1) to root...
Downloading http://downloads.openwrt.org/barrier_breaker/14.07-rc3/ar71xx/generic/packages/kmod-scsi-core_3.10.49-1_ar71xx.ipk.
Configuring kmod-scsi-core.
kmod: failed to insert /lib/modules/3.10.49/sd_mod.ko
Configuring kmod-scsi-generic.
kmod: failed to insert /lib/modules/3.10.49/sg.ko

該当ファイルは該当ディレクトリに最初から存在していた。他のパッケージをopkgでインストールしようとしても同じようなエラーが発生したが今のところ特に問題は起きてない。

さて、Extrootは前回Attitude Adjustmentにアップグレードした際にもやったことなのでスムーズに行くかと思いきや、うまくいかない。

Extrootの仕組みがBBではAAからは変わったようで、”how to use the new block-mount ? (Page 1) — General Discussion — OpenWrt“というスレッドもある。前者にメモとして書かれている以下がポイント。

If the partition containing your extroot isn’t mounted during boot, but you can mount it without problems from a shell, you should try to increase config ‘global’ / option delay_root. On my system I had to set it to 15 to get extroot working.

自分のケースにぴったりあてはまる。それに従い、/etc/config/fstabを以下のようにする。

config global 'automount'
        option delay_root '15'
        option from_fstab '1'
        option anon_mount '1'

実際これでうまくいった。不思議なのは、その後このファイルの中身が書き換えられてて、delay_rootを含む行は消されていた。それでもなぜかこれ以降はうまくいっている。

4. バックアップしていた設定ファイルのリストア

このステップが必要だったかわからない。これをせずとも自分が行った設定はほとんど残っていたと思う。

1.のステップでLuciで作成しておいた設定アーカイブをアップロードしたら、Luciがテーマが見つからないと言ってLuciが使えなくなってしまった。

opkg --force-reinstall install luci-theme-bootstrap

で回避。ただ、BBではAAのときとLuciのlook and feelはかなり変わっていた。余白の多いゆったりとしたレイアウトだったが、上の結果AAのときと同じに戻った。自分としてはそちらの方が好みだったので問題はない。

5. その他

OpenWrt BB rc3上のuhttpdのCGIが思うように動作しない

後で出てくる横線以下は作業しながら自分用のメモに記録していたもの。それでも後で整理しようと思ったが諦めた。ちなみに”Bad Gateway.”というエラーが最初出ていたが、これは自分のCGIスクリプトの初歩的ミスによるもの。

ポータブル・ルータTP-Link TL-WR703NにOpenWrtを載せているのだが、そのBarrier Breaker (14.07-rc3, r42056)が公開されたのでインストールしてみた。理由は後日。

これには、ルータの各種設定ができるWeb UI (”Luci”と呼ばれている)を提供するため、uhttpdというWebサーバーがプリインストールしてあり、デフォルトでは自動で起動するようになっている。これは別の目的にも利用してきた。うちの玄関にあるIPカメラのアラーム端子に接続されたブザーを押すと、IPカメラはアラーム入力があったと判断し、「アラームサーバー」に通知してくれる。この「アラームサーバーへの通知」は実際には、Webサーバに対して特定のURLをGETすることで行われる。(この辺は以前”Wifiカメラ用偽アラーム・サーバ “書いた。)パスは/api/alarm.asp?… なのだが、OpenWrt上のuhttpdに対してアクセスするようにし、このalarm.aspをuhttpdのCGIスクリプトとして実現し、そのスクリプトで父と自分のAndroid端末に通知するようにしてきた。

ところがBB rc3にアップグレードしてから動かなくなってしまった。

IPカメラから192.168.11.170にあるOpenWrtルーターに対して

GET /api/alarm.asp?username=AAA&userpwd=BBB&rea=2&io=0 HTTP/1.0.

というリクエストが送られるのだが、それに対応するhttp://192.168.11.170/api/alarm.asp?username=AAA&userpwd=BBB&rea=2&io=0というURLをブラウザでアクセスすると、期待された動作をする。

ブラウザから送られた場合は、IPカメラから送られる上のシンプルなリクエストだけではなく、いろいろヘッダが付いている。それが動作の違いの理由かと考え、”cURL – How To Use“を参考にして、余計なヘッダがつかない同じリクエストが送られるよう:

$ curl -H "User-Agent:" -H "Accept:" -H "Host:" -0 -G "http://192.168.11.170/api/alarm.asp?username=AAA&userpwd=BBB&rea=2&io=0"

としてみると、それでも期待された動作をする。

念のためngrepを使い、”ngrep(8): network grep – Linux man page“参照して

ngrep -W byline -q port 80

などとしてルーター上のパケットを眺めてみても、IPカメラからのリクエストと、他のPCからcURLからのそれとの見かけの違いは見当たらない。しかし、uhttpdはなぜか前者に対しては全く反応しない(OKもなし)。

パッと見えない違いとしては、ひょっとしてIPカメラからのGETでは、行末が正しく(CR+LF) x 2 になってないのかと疑ったが、以下を見るとちゃんとなっている模様(ngrepの-xオプションはヘキサ表示を指示するもの。なお、これら実験の過程で、複数の「アラームサーバー」の挙動を比較するため、アラームサーバーのポートをいろいろと換えたので一定していない)。

root@OpenWrt:/www/api# ngrep -x -q port 8081
eth0: no IPv4 address assigned: Cannot assign requested address
interface: eth0
filter: (ip) and ( port 8081 )

T 192.168.11.81:2148 -> 192.168.11.170:8081 [AP]
 47 45 54 20 2f 61 70 69 2f 61 6c 61 72 6d 2e 61 GET /api/alarm.a
 73 70 3f 75 73 65 72 6e 61 6d 65 3d 41 41 41 26 sp?username=AAA&
 75 73 65 72 70 77 64 3d 42 42 42 26 72 65 61 3d userpwd=BBB&rea=
 32 26 69 6f 3d 30 20 48 54 54 50 2f 31 2e 30 0d 2&io=0 HTTP/1.0.
 0a 0d 0a ...

それではWebサーバーをuhttpdではなく何か他のものにしてみればいいのではないかと、”Web Server Overview – OpenWrt Wiki“を参考にmini_httpdを選んでインストール。mini-httpd – OpenWrt Wikiを参考に設定。ところが、mini-httpdだと、1度目はCGIスクリプトが起動されるがその後成功しない。2度目以降も、スクリプトにあるtelnetコマンドで端末に接続はするようなのだが、Android端末側(SSH Serverアプリ)でError shell: sendto failed: EPIPE (Broken Pipe)というエラーを吐いていて、肝心の通信は行われない模様。ちなみに、Luciはmini-httpdでも動くのだが、uhttpdで動かす場合に比べると目に見えて遅い。

もうやけになって、netcatに影響を受けて作られたとするNcatを使い、なんちゃってWebサーバーを作ってごまかすことにした。”ncat(1) – Linux manual page“や”Neat Tricks“を参考にして、以下を/etc/rc.localに含めることでスタートアップ時に実行されるようにした。

/usr/bin/ncat --recv-only -lk -p 8081 --sh-exec "awk '/^GET/ {system(\"/www/api/alarm.asp 2>&1 > /dev/null\")}'" &

IPカメラからは1回の通知につきGET文と空行の2行が送られてくるので、Awkで前者にだけ(本来はCGI用だった)スクリプトが起動されるようにした。

本当はパスをしっかり確認するなどもっときちんと処理すべきなんだろうが、実際上はこれで問題はない。ともかく安定して動いてくれることが大事。それは達成できたと思う。


T 192.168.11.81:2097 -> 192.168.11.170:80 [AP]
GET /api/alarm.asp?username=AAA&userpwd=BBB&rea=2&io=0 HTTP/1.0.
.


T 0.0.0.0 -> 0.0.0.0
...........................
Y...........

T 192.168.11.63:49276 -> 192.168.11.170:80 [A]
......

T 192.168.11.63:49276 -> 192.168.11.170:80 [AP]
GET /api/alarm.asp?username=AAA&userpwd=BBB&rea=2&io=0 HTTP/1.1.
User-Agent: curl/7.37.0.
Host: 192.168.11.170.
Accept: */*.
.


T 192.168.11.170:80 -> 192.168.11.63:49276 [AP]
HTTP/1.1 502 Bad Gateway.
Connection: Keep-Alive.
Transfer-Encoding: chunked.


T 192.168.11.63:49276 -> 192.168.11.170:80 [A]
......

T 192.168.11.170:80 -> 192.168.11.63:49276 [AP]
Keep-Alive: timeout=20.
Content-Type: text/html.
.
14.

Bad Gateway

. 28. The process did not produce any response. 0. .

cURL – How To Use

$ curl -H "User-Agent:" -H "Accept:" -H "Host:" -0 -G "http://192.168.11.170/api/alarm.asp?username=AAA&userpwd=BBB&rea=2&io=0"

Bad Gateway

The process did not produce any response

T 192.168.11.63:50248 -> 192.168.11.170:80 [AP]
GET /api/alarm.asp?username=AAA&userpwd=BBB&rea=2&io=0 HTTP/1.0.
.


T 192.168.11.170:80 -> 192.168.11.63:50248 [AP]
HTTP/1.0 502 Bad Gateway.
Connection: close.


T 192.168.11.170:80 -> 192.168.11.63:50248 [AFP]
Content-Type: text/html.
.

Bad Gateway

The process did not produce any response

Web Server Overview – OpenWrt Wiki

mini_httpd

mini-httpd – OpenWrt Wiki

mini-httpdを使っていると以下のような不審な交信が起こってて気持ち悪い。

T 192.168.11.1:1304 -> 192.168.11.170:80 [R]
......

T 192.168.11.170:80 -> 192.168.11.1:1308 [AP]
(null) 400 Bad Request.
Server: mini_httpd/1.19 19dec2003.
Date: Mon, 18 Aug 2014 08:06:44 GMT.
Cache-Control: no-cache,no-store.
Content-Type: text/html; charset=%s.
Connection: close.
.
<HTML>
<HEAD><TITLE>400 Bad Request</TITLE></HEAD>
<BODY BGCOLOR="#cc9999" TEXT="#000000" LINK="#2020ff" VLINK="#4040cc">
<H4>400 Bad Request</H4>
Can't parse request.
<HR>
<ADDRESS><A HREF="http://www.acme.com/software/mini_httpd/">mini_httpd/1.19 19dec2003</A></ADDRESS>
</BODY>
</HTML>

ncat -lkC -p 8081 –sh-exec “/www/api/alarm.asp 2>&1 > /dev/null”

Cオプションは行末文字をサーバが期待するCRLFに変更するもの。”ncat(1) – Linux manual page” “Neat Tricks

OpenWrtをクロスコンパイルできる環境の構築

OpenWrtをクロスコンパイルできる環境を構築した。端的にはLinuxマシーンで、”OpenWrt Buildroot – About – OpenWrt Wiki“に従うだけなのだったのだが、いろいろ躓いた(自分は参照しなかったが”Easy Build – OpenWrt Wiki“もある)。

Windows 7とLubuntuのデュアル・ブートが可能なPCで、LubuntuからUSB HDDのNTFSボリュームで作業した。これがいけなかった。

まず、gitでダウンロードしたソース・パッケージの中のscriptsディレクトリのスクリプトに実行可能フラグが立ってなかった。NTFSが原因かと考え、この推測は結果としては正しかった。が、”permissions – How do I use ‘chmod’ on an NTFS (or FAT32) partition? – Ask Ubuntu“の2番めの解答に従えば解決すると期待した(参考:”User Mapping | Tuxera“、”Ownership and Permissions | Tuxera“)。

ところがやはりパーミッションの問題が起こる。何か自分の設定がまずかった可能性はあったが、それを追求するのには時間がかかるだろうと諦めて、該当パーティションをExt4でフォーマットしなおしてやり直すと、最新リリース版の12.09 “Aptitude Adjustment”のコンパイルは全く問題なくできた。時間はかかったが。

このボリュームはWindows 7からもアクセスしたいのだが、後日以下を見ながら何とかしよう。

 

以下はNTFSボリュームで作業するのを諦めてExt4ボリュームに替える前に四苦八苦していたときのメモ。


make[2]: Entering directory `/media/yasuro/Work/openwrt/tools/mtd-utils'
mkdir -p /media/yasuro/Work/openwrt/dl
echo "Checking out files from the git repository..."; mkdir -p /media/yasuro/Work/openwrt/tmp/dl && cd /media/yasuro/Work/openwrt/tmp/dl && rm -rf mtd-utils-1.4.5 && [ \! -d mtd-utils-1.4.5 ] && git clone git://git.infradead.org/mtd-utils.git mtd-utils-1.4.5 --recursive && (cd mtd-utils-1.4.5 && git checkout 5319b84974fcb71504aed2d1b8285e9c0a4a4bb8) && echo "Packing checkout..." && rm -rf mtd-utils-1.4.5/.git &&         /bin/tar cfz /media/yasuro/Work/openwrt/tmp/dl/mtd-utils-1.4.5.tar.gz mtd-utils-1.4.5 && mv /media/yasuro/Work/openwrt/tmp/dl/mtd-utils-1.4.5.tar.gz /media/yasuro/Work/openwrt/dl/ && rm -rf mtd-utils-1.4.5;
Checking out files from the git repository...
Cloning into 'mtd-utils-1.4.5'...
remote: Counting objects: 5612, done.
remote: Compressing objects: 100% (1476/1476), done.
remote: Total 5612 (delta 4088), reused 5612 (delta 4088)
Receiving objects: 100% (5612/5612), 1.60 MiB | 656.00 KiB/s, done.
Resolving deltas: 100% (4088/4088), done.
Checking connectivity... done.
error: Your local changes to the following files would be overwritten by checkout:
        load_nandsim.sh
        make_a_release.sh
        tests/ubi-tests/runtests.sh
        tests/ubi-tests/stress-test.sh
Please, commit your changes or stash them before you can switch branches.
Aborting
make[2]: *** [/media/yasuro/Work/openwrt/dl/mtd-utils-1.4.5.tar.gz] Error 1

自分はソースコードさえ入手できればよいので、”git-checkout(1)” openwrt/include/download.mk 中の git checkout 文に -f オプションをつけることで対処。その後makeすると以下のメッセージが。

Note: checking out 'c9c9d5cb085acc58b6579ace83fb79c085a9db27'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

openwrt/build_dir/host/m4-1.4.16でMakefileがない、とエラー。このディレクトリにあったconfigureスクリプトを実行した上で再度make。

Huawei E169 USB 3GドングルをTP-Link TL-WR703N上のOpenWrtで使えるようにする

Huawei E169 USB 3Gドングル

Huawei E169 USB 3Gドングル

理由は後日説明するとして、Huawei E169 USB 3GドングルAliexpress.comにて送料無料の$20.77で購入

E173この業者に勧められた。スペック的には差がないように思われたが、この業者のストックにあったものではE169には外部アンテナ接続端子があったがE173にはなかったので前者を選んだ。モデルとしてはE173には外部アンテナ接続端子付きのものもあるらしい。

Windows 7 PCではUSBポートに差し込むと、USBディスクとして認識され、そこにあるインストーラでドライバやクライアントソフトをインストールできる。その上で、”Huawei E169 (E169G, E169V, K3520) – 3G modem wiki“の情報に従い、ファームウェアとPC用クライアントソフトのアップデート。 PCクライアントソフトは”Mobile Partner”ないしは”Vodafone Dashboard”のはずらしいが、”Optus Wireless Broadband”なるソフトしか見当たらない。音声通信ができるかテストしたかったが、ファームウェアやPC側ソフトのアップグレードによって、クライアント・アプリに現れるはずの音声通信用ボタンが現れない。そもそもPCから音声通話することは目的ではなかったから、それ以上は追求せずSMSの送受信ができることだけ確認。

Mobile Partner Version 23.009.09.02.910 Released | HuaweiNews“から公式Mobile Partnerアプリを入手できた(Windows版だけではなくLinux版も同梱)。それで音声通話もできることが確認できた。

次に、本来想定していた使用形態に移行した。それはポータブルルーターTP-Link TL-WR703Nから使用することだが、そのために以前からインストールしてあったOpenWrtのアップグレードをしたり、USB機器を複数使えるようハブを接続したりしてあった。

USB GSM/UMTSモデムを介したSMSやMMSの送信“に書いたように、SMSだけであれば、OpenWrtでは予めリポジトリに用意されているパッケージをインストールするだけでつぐ使えるようになるGnokiiで利用できるようになる。MMSも扱いたいので、最終的にはこれではなくMbuniを使うことになるのだが、残念ながら自分でビルドしないとならない。なのでまずはパッと使えるGnokiiでテスト。

まず、”Use 3g/UMTS USB Dongle for WAN connection – OpenWrt Wiki“を参照に、必要なパッケージをインストール。comgt, kmod-usb-serial-option, usb-modeswitch-data, luci-proto-3gだけをインストールした(と思う)。他に必要なパッケージもあるが、上記パッケージが依存しているため結果として必要な物は全てインストールされる(と思う)。USBそのものに関するパッケージはusbutilsのみをインストール。lsusbコマンドを使いたかったので。

View topic – SMS Gateway – OpenWRT“からGnokiiの設定に関するところだけを真似た。WAN関係は現時点では不要なので無視。Gnokiiの設定として/dev/ttyUSB0をポートとして指定することで、SMSの送信(gnokii --sendsms 宛先電話番号)、音声通話の発信(gnokii --dialvoice 宛先電話番号)やその中止(gnokii --hangup 呼ID)はできるようになった(もちろんOpenWrt側で音声の入出力はできないので単に鳴るだけ)。ただし、SMSの受信(gnokii --smsreader)は思うように動作しているように思えない。

しかし、”Send SMS or Email using 3G/GSM modem – OpenWrt Wiki“と”Using AT commands to send and read SMS – Nokia Developer Wiki“を参照して、picocomコマンドを利用して直接ATコマンドを使うと、SMSの受信ができることは確認できた。

SMSの送受信を行うためのデーモンとしてGnokiiのwikiではSMSdを紹介しているが、残念ながらOpenWrt用バイナリ・パッケージは用意されてないので使うには自分でビルドしなければならない。だがMMSも必要なのでMbuniを自分でビルドしなくてはならないことは決定済み。なのでSMSのみのSMSdをビルドすることはないだろう。

追記:
たまたま見つけた”Huawei – GnokiiWiki“によって、OpenWrtがドングルを認識した際に自動的に作成するデバイスが/dev/ttyUSB0, /dev/ttyUSB1, /dev/ttyUSB2の3つあるのだが、そのうちSMS受信の通知を受けられるのはその内の1つだけだということを知った。このページは、通常そのデバイスが/dev/ttyUSB1だと記載しているが、そうGnokiiの設定してもSMSの受信ができないどころか送信もできなかった。代わりに/dev/ttyUSB2と設定することで、Gnokiiを使ってSMSの送信も受信もできた。

さらなる追記:
Huawei UMTS USB Stick E169 with Linux“には、”If you have udev you should now have /dev/ttyUSB0, /dev/ttyUSB1 and /dev/ttyUSB2. These are the devices for the UMTS modem, for the GSM modem and a device for sending an receiving SMS, respectively”という記載がある。

これで最初のステップとして達成したいことは達成できた。以下は余談。

Wireless Router with a 3G/UMTS/HSDPA dongle“にhuaweiaktbbo ( Huawei E156/E169/E220 activation tool)というパッケージが紹介されているが、E169がモデムと認識されているのでインストールしない。が、 e169-stats (Huawei E169 statistics, works with other Huawei’s devices.)というパッケージがあるのに気づいたのでこれはインストールしてたが、e169-stats /dev/ttyUSB0でちょっとした統計情報が表示される。

Usb-modeswitchからのSwitching seemingly failedというメッセージが繰り返し表示されるが、”#10475 (usb-modeswitch “seemingly” fails, stick works fine) – OpenWrt“によると気にしなくていい模様。デバイスの初期化に予想以上に時間がかかっているのを失敗したと判断されるだけ、ということのよう。

Huawei E169 USB 3GドングルへのSIMカードの正しい挿入向き

Huawei E169 USB 3GドングルへのSIMカードの正しい挿入向き

実は最初にSIMカードの向きを逆に入れてしまい、当然の結果としてSIMカードが認識されない、というハズカシイ失敗を犯した。

以下はWAN設定をする際に参考になるかも:

追記:後日さらにもう1台E169を購入した

以下はシステム・ログの一部だが、最初はusb_modeswitchがうまく行ってないのではと考えていたのでコピーしていた。

Aug  8 20:51:04 OpenWrt kern.info kernel: [   14.870000] usb 1-1.2: new full-speed USB device number 4 using ehci-platform
Aug  8 20:51:04 OpenWrt kern.info kernel: [   15.000000] scsi1 : usb-storage 1-1.2:1.0
Aug  8 20:51:04 OpenWrt kern.info kernel: [   15.140000] usb 1-1.2: USB disconnect, device number 4
Aug  8 20:51:04 OpenWrt kern.info kernel: [   15.470000] usb 1-1.2: new full-speed USB device number 5 using ehci-platform
Aug  8 20:51:04 OpenWrt kern.info kernel: [   15.600000] scsi5 : usb-storage 1-1.2:1.3
Aug  8 20:51:04 OpenWrt kern.notice kernel: [   16.600000] scsi 5:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
Aug  8 20:51:04 OpenWrt kern.notice kernel: [   16.610000] scsi 5:0:0:1: Direct-Access     HUAWEI   SD Storage       2.31 PQ: 0 ANSI: 2
Aug  8 20:51:04 OpenWrt kern.notice kernel: [   16.630000] sd 5:0:0:1: [sdb] Attached SCSI removable disk
(中略)
Aug  8 20:51:04 OpenWrt kern.info kernel: [   32.500000] usbcore: registered new interface driver usbserial
Aug  8 20:51:04 OpenWrt kern.info kernel: [   32.500000] USB Serial support registered for generic
Aug  8 20:51:04 OpenWrt kern.info kernel: [   32.510000] usbcore: registered new interface driver usbserial_generic
Aug  8 20:51:04 OpenWrt kern.info kernel: [   32.520000] usbserial: USB Serial Driver core
Aug  8 20:51:04 OpenWrt kern.info kernel: [   32.580000] USB Serial support registered for GSM modem (1-port)
Aug  8 20:51:04 OpenWrt kern.info kernel: [   32.580000] option 1-1.2:1.0: GSM modem (1-port) converter detected
Aug  8 20:51:04 OpenWrt kern.info kernel: [   32.590000] usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB0
Aug  8 20:51:04 OpenWrt kern.info kernel: [   32.600000] option 1-1.2:1.1: GSM modem (1-port) converter detected
Aug  8 20:51:04 OpenWrt kern.info kernel: [   32.600000] usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB1
Aug  8 20:51:04 OpenWrt kern.info kernel: [   32.610000] option 1-1.2:1.2: GSM modem (1-port) converter detected
Aug  8 20:51:04 OpenWrt kern.info kernel: [   32.620000] usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB2
Aug  8 20:51:04 OpenWrt kern.info kernel: [   32.620000] usbcore: registered new interface driver option
Aug  8 20:51:04 OpenWrt kern.info kernel: [   32.630000] option: v0.7.2:USB Driver for GSM modems
Aug  8 20:51:06 OpenWrt user.notice usb-modeswitch: 1-0:1.0: Manufacturer=Linux_3.3.8_ehci_hcd Product=Generic_Platform_EHCI_Controller Serial=ehci-platform
Aug  8 20:51:06 OpenWrt user.notice usb-modeswitch: 1-1:1.0: Manufacturer=? Product=? Serial=?
Aug  8 20:51:06 OpenWrt daemon.notice netifd: Interface 'loopback' is now up
Aug  8 20:51:06 OpenWrt kern.info kernel: [   37.070000] device eth0 entered promiscuous mode
Aug  8 20:51:07 OpenWrt kern.info kernel: [   37.400000] eth0: link up (100Mbps/Full duplex)
Aug  8 20:51:07 OpenWrt kern.info kernel: [   37.400000] br-lan: port 1(eth0) entered forwarding state
Aug  8 20:51:07 OpenWrt kern.info kernel: [   37.410000] br-lan: port 1(eth0) entered forwarding state
Aug  8 20:51:07 OpenWrt daemon.notice netifd: lan (790): udhcpc (v1.19.4) started
Aug  8 20:51:07 OpenWrt user.notice usb-modeswitch: 1-1.4:1.0: Manufacturer=? Product=USB_Mass_Storage_Device Serial=ad620dd011662b
Aug  8 20:51:07 OpenWrt daemon.notice netifd: lan (790): Sending discover...
Aug  8 20:51:07 OpenWrt daemon.notice netifd: lan (790): Sending select for 192.168.11.170...
Aug  8 20:51:07 OpenWrt daemon.notice netifd: lan (790): Lease of 192.168.11.170 obtained, lease time 172800
Aug  8 20:51:07 OpenWrt user.notice usb-modeswitch: 1-1.2:1.0: Manufacturer=ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ Product=HUAWEI_Mobile Serial=ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Aug  8 20:51:07 OpenWrt user.notice usb-modeswitch: 1-1.2:1.0: Selecting /etc/usb_modeswitch.d/12d1:1001 for mode switching
Aug  8 20:51:07 OpenWrt user.notice usb-modeswitch: 1-1.2:1.0: Switching seemingly failed
Aug  8 20:51:07 OpenWrt daemon.notice netifd: Interface 'lan' is now up
Aug  8 20:51:08 OpenWrt user.notice ifup: Enabling Router Solicitations on loopback (lo)
Aug  8 20:51:08 OpenWrt user.notice ifup: Allowing Router Advertisements on lan (br-lan)
Aug  8 20:51:08 OpenWrt user.notice usb-modeswitch: 1-1.2:1.0: Switching seemingly failed
Aug  8 20:51:09 OpenWrt kern.info kernel: [   39.410000] br-lan: port 1(eth0) entered forwarding state
Aug  8 20:51:09 OpenWrt user.notice usb-modeswitch: 1-1.2:1.0: Switching seemingly failed
(中略)
Aug  8 20:51:15 OpenWrt user.notice usb-modeswitch: 1-1.2:1.1: Manufacturer=ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ Product=HUAWEI_Mobile Serial=ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Aug  8 20:51:15 OpenWrt user.notice usb-modeswitch: 1-1.2:1.1: Selecting /etc/usb_modeswitch.d/12d1:1001 for mode switching
Aug  8 20:51:15 OpenWrt user.notice usb-modeswitch: 1-1.2:1.1: Switching seemingly failed
Aug  8 20:51:15 OpenWrt cron.info crond[1194]: crond: crond (busybox 1.19.4) started, log level 8
Aug  8 20:51:16 OpenWrt authpriv.info dropbear[1207]: Running in background
Aug  8 20:51:16 OpenWrt user.notice usb-modeswitch: 1-1.2:1.1: Switching seemingly failed
Aug  8 20:51:17 OpenWrt user.notice usb-modeswitch: 1-1.2:1.1: Switching seemingly failed
(中略)
Aug  8 20:51:23 OpenWrt user.notice usb-modeswitch: 1-1.2:1.2: Manufacturer=ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ Product=HUAWEI_Mobile Serial=ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Aug  8 20:51:23 OpenWrt user.notice usb-modeswitch: 1-1.2:1.2: Selecting /etc/usb_modeswitch.d/12d1:1001 for mode switching
Aug  8 20:51:23 OpenWrt user.notice usb-modeswitch: 1-1.2:1.2: Switching seemingly failed
Aug  8 20:51:24 OpenWrt user.notice usb-modeswitch: 1-1.2:1.2: Switching seemingly failed
Aug  8 20:52:49 OpenWrt user.notice usb-modeswitch: 1-1.2:1.2: Switching seemingly failed
Aug  8 20:52:50 OpenWrt user.notice usb-modeswitch: 1-1.2:1.2: Switching seemingly failed
Aug  8 20:52:51 OpenWrt user.notice usb-modeswitch: 1-1.2:1.2: Switching seemingly failed
Aug  8 20:52:52 OpenWrt user.notice usb-modeswitch: 1-1.2:1.2: Switching seemingly failed
Aug  8 20:52:53 OpenWrt user.notice usb-modeswitch: 1-1.2:1.2: Switching seemingly failed
Aug  8 20:52:55 OpenWrt user.notice usb-modeswitch: 1-1.2:1.3: Manufacturer=ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ Product=HUAWEI_Mobile Serial=ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Aug  8 20:52:55 OpenWrt user.notice usb-modeswitch: 1-1.2:1.3: Selecting /etc/usb_modeswitch.d/12d1:1001 for mode switching
Aug  8 20:52:55 OpenWrt user.notice usb-modeswitch: 1-1.2:1.3: Switching seemingly failed
Aug  8 20:52:56 OpenWrt user.notice usb-modeswitch: 1-1.2:1.3: Switching seemingly failed
Aug  8 20:52:57 OpenWrt user.notice usb-modeswitch: 1-1.2:1.3: Switching seemingly failed
Aug  8 20:52:58 OpenWrt user.notice usb-modeswitch: 1-1.2:1.3: Switching seemingly failed
Aug  8 20:52:59 OpenWrt user.notice usb-modeswitch: 1-1.2:1.3: Switching seemingly failed
Aug  8 20:53:00 OpenWrt user.notice usb-modeswitch: 1-1.2:1.3: Switching seemingly failed
Aug  8 20:53:01 OpenWrt user.notice usb-modeswitch: 1-1.2:1.3: Switching seemingly failed
root@OpenWrt:~# cat /sys/kernel/debug/usb/devices

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480  MxCh= 1
B:  Alloc=  0/800 us ( 0%), #Int=  2, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev= 3.03
S:  Manufacturer=Linux 3.3.8 ehci_hcd
S:  Product=Generic Platform EHCI Controller
S:  SerialNumber=ehci-platform
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 4
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0409 ProdID=005a Rev= 1.00
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms

T:  Bus=01 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  5 Spd=12   MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=12d1 ProdID=1001 Rev= 0.00
S:  Manufacturer=ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
S:  Product=HUAWEI Mobile
S:  SerialNumber=ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
C:* #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=128ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E:  Ad=84(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E:  Ad=85(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=83(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

T:  Bus=01 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#=  3 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0457 ProdID=0151 Rev= 1.00
S:  Product=USB Mass Storage Device
S:  SerialNumber=ad620dd011662b
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 98mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=16ms
root@OpenWrt:~# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0409:005a NEC Corp. HighSpeed Hub
Bus 001 Device 003: ID 0457:0151 Silicon Integrated Systems Corp. Super Flash 1GB / GXT  64MB Flash Drive
Bus 001 Device 005: ID 12d1:1001 Huawei Technologies Co., Ltd. E169/E620/E800 HSDPA Modem

SMS Tutorial: Introduction to AT Commands, Basic Commands and Extended Commands

[古記事]玄関やトイレにWifi電波が届くよう、ブリッジ接続でプラネックス製ちびファイMZK-RP150Nを設置

結局ちびファイに落ち着いた

結局ちびファイに落ち着いた

またまた未完成の古い記事の草稿。未完成の文章が多いこと、Atword.jpのブログサービスそのものが廃止されてしまったため、そこにあった自分のブログ記事に対するリンクが今や全て無効であることもいつもと同じ。

ちなみに、この記事の後で出てくる水平線の下でいろいろとああしよう、こうしようと悩んでいたのだが、結局のところずるずるとイーサーネットケーブル(UTPケーブル)を引き、そこにPlanex 11n/g/b対応 高速150Mbps リアルポータブル Wi-Fiルータ (ちびファイ)MZK-RP150Nアマゾンで¥ 2,180で購入)を接続。そこから有線で玄関のIPカメラに繋ぐこととした。これにより玄関のIPカメラへの接続が安定するだけでなく、この通路(玄関から始まり、右手に父の部屋、左手にトイレに挟まれて、さらに洗面所、そして浴室にまで至る)近辺のwifi電波の改善が達成された。

ちびファイの固定には、パッケージの一部としてそれが入っていたプラスチックケースを利用し、それにちびファイを入れた状態で、押しピンで木の板に固定している。プラスチックケースはカットして、各種ケーブルが外から中のちびファイに挿さるようにしてある。押しピンは緩めに刺すことで、ケースの中に空気が流れやすくして、排熱にも配慮した。

右の写真は、今年初めに行った介護保険を利用したリフォームの後に撮影したもの。ちびファイの右横は元々は単なる通路だったところを父の部屋を区切る開き戸にしたのでその枠が見える。また、2Fのルータからずるずると引っ張ってきたイーサーネットケーブルは、当初は父の部屋の隅を這わせていた。この記事の後で出てくる水平線より下の写真でも、今は戸になっているところから線が来ているのが分かる。しかし、リフォーム時に、父の部屋から、屋根裏を通ってこの写真の左側の壁に抜けるパイプがこの家の建築時に用意されていたことがわかった。どういう用途を想定していたのかは不明だったが、せっかくなのでそこにイーサーネットケーブルを通し、そこからちびファイに接続している。したがって、上の写真では、2Fのルータからずるずる引っ張ってきたグレーのイーサーネットケーブルは左から来ている。もう一方の茶色のイーサーネットケーブルは、玄関のIPカメラに繋がっている。


玄関やトイレにWifi電波がなかなか届かないことの対策

ソフトバンクが無償配布するFonera SimplことFON2405E

ブリッジ接続

ズルズルケーブルを引っ張った。柱に据え付けるのに、本体は壁にかけることを想定したビス用穴などない。ずっと、本体には手を入れず、何かしらのケースに入れて、それを柱に固定することばかり考えてきた。

分解して、ケースそのものに手を入れてそれで取り付ける。

ゴム足がネジ穴カバーを兼ねていているので、それを剥がし、それでアクセスできるようになるトルクスネジを外せばよいとのこと。トルクスネジとは初耳だったが、ヨーロッパでは普及しており、ヘックスローブ、ヘクスローブとも呼ばれているらしい。

最近では日本でもトルクスドラバーが百均ショップで手に入るようになったらしい。が、そのサイズについてはT9だと断言している記述もあれば、T6ないしT5がよいのでは、としている記述もある。しかし、それにもまして、「2mmのマイナスドライバーでこじ開ける事ができる」としている記述もある。う?ん、新たな出費はせずに済ませられるのならそれに越したことはないが、こういったことをやるのは、本体内をいじる(具体的にシリアル接続してファームウェアを書き換える)のが目的の人で、それにはケースが閉じられなくっても構わないかもしれないが、こちらはそうではない。

金をかけずにすぐできること: 無線ルーターWZR-HP-AG300HのファームウェアをDD-WRTに入れ替えてごにょごにょ…する代わりに、同じバッファロー製の無線LANルータを拝借してそれにDD-WRTを入れて思うような効果が出るか検証。出れば万々歳だけど、おそらくはダメ。というのは、現在WZR-HP-AG300Hは1階増築部分(木造)にあり、元々の鉄筋コンクリートの建物から見れば建物の外。そこから、建物の逆の端までwifi電波が到達することはあまり期待できない。

家で使っている

金をかければすぐできること:玄関やトイレにWifi電波がなかなか届かないことの対策」に挙げたような中継器を試してみる。ただし効果の程は想像もつかない。

非常に手間のかかること、その1: 大元の無線LANルータから、せめてもう少し近くまで有線で引っ張ってくる。一番重要な玄関のIPカメラまで直接有線で繋げられるのが理想的だか、そこまでいかなくても、その隣の部屋(父の居室)にまで引っ張って、そこに無線リピーターを設置するだけでかなり違うだろう。

eo光の宅内調査と我が家の配管状況」に書いたように父がそれなりの配管システムを構築しているが、込み入っていて非効率的であるため、これにはかなり手間がかかる。その記事に書いたように、ツナギ箱3からツナギ箱1を経由して、2F西側部屋に入っているUTPケーブルがある。これは来たる10ギガビット・イーサネットの時代に備えて、カテゴリー6a以上のケーブルに取り替えなければならないことはわかっているので、これを取り替える際、1本ではなく2本のUTPケーブルを既存ケーブルにつないでずるずると配管内を通し、1本はツナギ箱1から屋内に入れ、もう1本はさらにツナギ箱2に下ろす、ということが考えられる。ただし、この「さらにツナギ箱2に下ろす」の部分が、そう都合よくいくものか全く想像がつかない。しかもこれは、効率の面から父の居室の家具の再配置のときに合わせてやるべきだろう。

非常に手間のかかること、その1:
金をかけずにいずれできること: FONERA SIMPLのアンテナは汎用アンテナだそうだが、現在2台使用しているwifiカメラが上述のように有線でつながるようになると、それに付属する同じく汎用(と思われる)アンテナを流用できるかもしれない。後者は海外仕様なのでひょっとすると改善する?