趣味の電子工作などの記録。時にLinuxへ行ったり、ガジェットに浮気したりするので、なかなかまとまらない。
Ubuntuに付属の動画プレイヤーには「動画」メニューの中に再生履歴を表示する機能があるのですが、その履歴を消去することができません。適当に検索していたら、メニューから表示を消す方法がわかりましたので、メモしておきます。
/usr/share/totem/totem.ui ファイルを開き、「recent」を含む以下の２行（黄色文字を含む２行）を消去すると、表示が出なくなります。
Arduinoの嬉しいところは、電子工作の世界としては珍しくライブラリがあるところです。
で、早速LCDモジュールを接続し、LCDに出力してみました。表示内容は左から室温、湿度、センサ抵抗値の対数値です。写真を見るとわかるのですが、室温２５度、湿度２５％なので、めちゃくちゃ乾燥しています。
接続したLCDは秋月の３００円LCDモジュール（HD44780U使用、16文字×1行）です。この手のLCDモジュールは画面の右半分と左半分のアドレスが連続していなかったりします。そのため何らかの工夫が必要になるのですが、残念ながらArduinoのLiquidCrystalライブラリはそこまではサポートしていないようです。ソースをみてもそれらしい記述はありません。ただ、20文字×4行のLCDモジュールを想定した処理は入っているようですので、それを利用して8文字×2行として設定を行い、右半分は2行目扱いで文字を表示することでお茶を濁しました。
無事に「HS15P湿度センサの簡易動作実験」の追試ができたところで、これをArduinoに移植してみました。
回路図は・・・・省略。
という接続です。
ソフトウェアの方はほぼそのままの移植ですが、
などの変更をしました。それ以外はそのまま移植しましたが、あっさりそれっぽく動きました・・・。ただ、校正のための道具がないので、そこまで・・・と思ったのですが、もうちょっと頑張ってみます。
まず、元のATTINY13でHS15Pの代わりに用意した1KΩ、10KΩ、100KΩ、1MΩの抵抗をつけてデバッグ用に出力されている抵抗の対数値を記録します。1KΩ時が219、10KΩ時が180、100KΩ時が140、1MΩ時が99と、ほぼ理論値通りになりました。
この抵抗をArduino版に接続すると、1KΩ時が226、10KΩ時が181、100KΩ時が141、1MΩ時が100といずれも少し大きめの値が出力されます。これは充電時間が長めになっているからだと思われます。
そこで、時間設定を0.1us単位で管理して、delayMicroseconds()に渡す際に10で割ってやると、1KΩ時が240、10KΩ時が209、100KΩ時が141、1MΩ時が99と、大きな誤差がでるようになってしまいました。おそらく除算を必要とするようになってしまったので、結果的にwaitが増えてしまったのでしょう。
結局、測定レンジを充電時間で指定するのではなく、インデックスで指定するようにしてwaitの時間はその中で swtich()～case で充電開始終了を含めたテーブル形式にして、待ち時間も調整することにしました。その結果、1KΩ時が219、10KΩ時が180、100KΩ時が139、1MΩ時が99と、ほぼ合うようになりました（当然ですが・・）。
これでセンサをHS-15Pに戻せば概ね正しい値を測定できるはずです。
組み上げたら、まずヒューズビットを書き込みます。
$ avrdude -c avrisp2 -p t13 -P usb -t
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e9007
avrdude> r lfuse
>>> r lfuse
0000 6a |j |
avrdude> r hfuse
>>> r hfuse
0000 ff |. |
avrdude> w lfuse 0 0x3a
>>> w lfuse 0 0x3a
avrdude> w hfuse 0 0xff
>>> w hfuse 0 0xff
avrdude> quit
>>> quit
avrdude: safemode: Fuses OK
avrdude done. Thank you.
次に、プログラムを書き込みます。
$ avrdude -c avrisp2 -p t13 -P usb -U flash:w:TestHS15.hex:i
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9007
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file “TestHS15.hex”
avrdude: writing flash (896 bytes):
Writing | ################################################## | 100% 0.38s
avrdude: 896 bytes of flash written
avrdude: verifying flash memory against TestHS15.hex:
avrdude: load data flash data from input file TestHS15.hex:
avrdude: input file TestHS15.hex contains 896 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 0.26s
avrdude: verifying …
avrdude: 896 bytes of flash verified
avrdude: safemode: Fuses OK
avrdude done. Thank you.
・・・・が、このままではシリアルの論理が違うので、このままでは表示できません。
2SC2120を１段間に入れて、論理を反転させました。また、よく考えると温度を取得するためのLM35DZのA/D変換の基準電圧はVccで5Vが前提になっています。しかしPICによるシリアルモニタから供給できるのは3.3Vなので、正常に温度が取得できなくなるはずです。ですので、外部電源５Vで動作するように改めました。
DebianのPCにつないで、screenをシリアルターミナルとして起動すると、A/D変換値、温度、湿度の順で周期的に出力されます。（screenコマンドは、C-a H でログファイルを吐くので、その機能でファイルに記録することもできる）
ちなみに自分の部屋の湿度は暖房あり（エアコン使用）で20%台、暖房無しで30%程度でした。非常に乾燥しやすい部屋とはいえ、あってるのかよくわかりません。
そこで、ビニール袋に濡らしたティッシュペーパーと共に入れて封をして放置してみたところ、23度20%（ソースをみるとわかりますが、20%以下は計測できません）からぐんぐん袋内の湿度が上昇し、すぐに80%近く、30分くらいで90%くらいになりました。
部屋の片付けをしていたら、秋月で買ったHS-15Pという湿度センサが出てきました。
ずいぶん前に使っていた加湿器が強力過ぎて部屋が水浸しになってしまったので、その制御に使おうと思って買ってあったものですが、結局加湿器自体使わなくなってしまったのでお蔵入りしてすっかり忘れていました。
で、「HS１５P湿度センサーの簡易動作実験」を参考にして、湿度センサを動かしてみることにしました（単なる追試とも言う）。こちらのページでは「インチキ動作させる」などと書かれていますが、至ってマジメに手抜き動作をされておられます。バカ正直にデータシートやアプリケーションノートの通りに動かすのではなく、基本原理に立ち返って考え直すこういう工夫、とっても大事だと思うんですよね～。
で、写真のように適当にちゃちゃっと組み上げます。ICクリップの下にいるのがATTINY１３Aです。・・・・が、写真はHS15P取り付け前でした・・・。シリアルは受けるだけなので、以前作ったシリアルモニタを1chだけ使います。
～つづく～
Ubuntuは結構頻繁にアップデートマネージャでのアップデートが出ます。本来は一つ一つ確認しながら進めればいいのでしょうが、たくさんあるのでアップデートマネージャの表示が出たら特に確認せずに進めてしまいます。
で、先日もいつものようにアップデートマネージャでポチッとアップデートをしたら、再起動後に無線LANの接続ができなくなってしまいました。
理由がわからなかったのですが、とりあえずドライバを再度インストールしたら使えるようになりました。
ここしばらく、IPv6対応でいまできることってなに、ということでいろいろやってみましたが、その中で疑問に思うことがあるので記載します。
IPv6のアドレスの長さは128bitなので、IPv4の32bitに比べると2^96倍もあって事実上無数にある、という説明がされています。しかし、IPv6のアドレス構造を見てみると、「前半がプレフィックス・ネットワークID」「後半がインタフェースID」となっています。また、サブネットマスクは/48か/64のどちらかであまり意識することはない、とされています（Wikipediaによる）。また、同じくWikipediaによると、同じくOCNによるIPv6サービスでは月額３００円で/64のネットワークブロックを２つ取得できる、とされています。
つまり、/48とか/64のアドレスが従来のIPv4グローバルアドレスに相当し、従来NATなどのプライベートIPアドレスで対応していた部分に/64の下のアドレスを企業内や家庭内で割り振る、ということになるのだと思います。そう考えると、「IPv4の32bitに比べると2^96倍」というのは誇張で、2^32倍くらいに考えるのが妥当なんだと思います。
さらに、IPv6アドレスの割り当て状況をみると、IANAは地域のRIRに/12単位でIPv6アドレスの割り当てを進めていくように見えます。従来IPv4ではこれが/8の単位だったのでしょう。ここで気づくのは、一度に割り当てる単位で数えるとIPv6とIPv4は16倍の違いしかない、ということです。まあ、それでも/12のIPv6アドレスブロックを/48の単位でエンドユーザーに割り当てていくと割り当ての際に/36の自由度があって、IPv4全体のアドレス空間以上を一度にRIRに割り当てることになるのだから、あまり心配はないのかもしれません。ただ、今後、それこそ家電製品どころか照明器具、壁のスイッチ、水道の蛇口、窓ガラス、扉、錠前・・・などに組み込まれたワンチップマイコンのようなものまでもIPv6を喋るようになるかもしれない、ということを考えると、無闇にアドレスブロックを浪費しても大丈夫なのだろうか、という気もします。
無駄な心配でしょうかね？？
≪おまけ≫
Arduinoというか、フィジカルコンピューティングの世界でIPv6っていろいろ面白い使い方があるような気がするのだけど、どうでしょうかね。実験だけならIPv4でも十分だから別にIPv6でなくたっていいのだけど。
IPv6で接続可能になったDebianですが、WordPressをインストールしてみることにしました。簡単そうな参考サイトはここでしょうか・・・。
# aptitude install wordpress
でjavascript,mysql,perl,phpなどの関連モジュールが一気にインストールされます。
・・・が、mysqlのサーバ自体はインストールされていないようですので、インストールします。
# aptitude install mysql-server
php5のインストールを認識させるため、apache2を再起動します。
# /etc/init.d/apache2 restart
/var/www/index.htmlを消去し、/var/www/index.php に以下の内容を作成します。
＜?
php phpinfo();
?＞
生成後、「http://（IPアドレス）」にアクセスして、PHPの状態が表示されるのを確認します。
・・・・
いろいろやってるうちに、メモが取りきれませんでした（^^;
なので、覚えていることだけ。
といったところでしょうか。
これで一応、IPv６アドレスからWordPressにアクセスできました。・・・置くコンテンツは特にないし、それ以上にPentium500MHz+192MBでは重くて使いようがないのですけどね。
（追伸）
ここのバックアップサイトにしてみようかと思ったのだけど、テーマの設定でプレビューすらできないので、消してしまいました・・・。
現在の状態では、Debianは起動後に手動で /usr/local/gogoc/bin/gogoc を起動しなければならないのですが、これを自動化したいと思います。
そこで、Debianの起動スクリプトを作ります。ここ（@IT）にあるのを雛形に、以下のようなファイルを作りました。
#!/bin/bash
setip6tables() {
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT ACCEPT
ip6tables -F
ip6tables -Z
ip6tables -X
ip6tables -N ufw6-after-forward
ip6tables -N ufw6-after-input
ip6tables -N ufw6-after-logging-forward
：
：（長いので中略）
：
ip6tables -A ufw6-before-output -m state --state RELATED,ESTABLISHED -j ACCEPT
ip6tables -A ufw6-before-output -j ufw6-user-output
ip6tables -A ufw6-skip-to-policy-forward -j DROP
ip6tables -A ufw6-skip-to-policy-input -j DROP
ip6tables -A ufw6-skip-to-policy-output -j ACCEPT
ip6tables -A ufw6-track-output -p tcp -m state --state NEW -j ACCEPT
ip6tables -A ufw6-track-output -p udp -m state --state NEW -j ACCEPT
}
clearip6tables() {
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT DROP
ip6tables -F
ip6tables -Z
ip6tables -X
}
start() {
echo -e "Set ip6tables: "
setip6tables
echo -e "Starting gogoc Freenet6 client: "
/usr/local/gogoc/bin/gogoc -y -f /usr/local/gogoc/bin/gogoc.conf -r 180 &
return 0
}
stop() {
# killproc gogoc
echo -e "Clear ip6tables: "
clearip6tables
return 0
}
case "$1" in
start)
start
;;
stop)
stop
;;
esac
本来なら、ip6tablesの設定はわけた方が良さそうな気もしますが、ここに含めています。
また、gogoc（Freenet6クライアント）の停止のしかたがわからないので、代わりにip6tablesで全てをDROPする設定をするようにしました。
このファイルを /etc/init.d/gogoclient として root で保存し、ファイル属性を 700 に変更します。そして起動時に呼ばれるようにするため、update-rc.dを使って設定します。
# sudo update-rc.d gogoclient start 99 2 3 4 5 .
update-rc.d: warning: /etc/init.d/gogoclient missing LSB information
update-rc.d: see
Adding system startup for /etc/init.d/gogoclient …
/etc/rc2.d/S99gogoclient -> ../init.d/gogoclient
/etc/rc3.d/S99gogoclient -> ../init.d/gogoclient
/etc/rc4.d/S99gogoclient -> ../init.d/gogoclient
/etc/rc5.d/S99gogoclient -> ../init.d/gogoclient
#
再起動すると、自動的にFreenetに接続するようになります。なお、起動時はなぜか素直につながらないことが多いようですが、リトライするうちにつながるようです。
停止する際は、
# /etc/init.d/gogoclient stop
で全てのIPv6をブロックするようにip6tablesを設定変更します。
外からアクセス可能となると、いろいろ心配になるものです。ルートキットの存在についてはchrootkitやrkhunterなどで確認できますが、できれば感染前に防ぎたいものです。
それで調べていたら、自分自身にnmapを使ってポートスキャンをかけてみる、という記述を見かけたので試してみました。nmapは一般的なポートスキャンツールですが、他者に使うのは非常に迷惑ですので、取扱いには十分注意が必要です。
で、インストールです。
# aptitude install nmap
実際にスキャンする場合は、IPv4では、
# nmap localhost
IPv6の場合は、
# nmap -6 ::0
でスキャンできます。
自分のところではDebianでは、
が開いていて、同様にUbuntuではIPv4,IPv6共に、
が開いていました。
しかし、よく考えると、それぞれiptables/ip6tablesでFirewallを構築しているので、localhostに関してはあまり意味がありません。ですので、お互いにスキャンをかけたところ、Debianはsshとhttpのみオープン、Ubuntuは全ポートがフィルタリングされていました。狙い通りなので安心しました。（IPv6の場合はオーストラリアと北米まで行って来いでポートスキャンなのですごく無駄な感じはしますが・・・）