Raspberry Pi の GPIO が物故

動かない自作基板をデバッグすること1日、 Raspberry pi の GPIO 11 (SCLK) が high から変えられなくなっていることが判明。

$ gpio mode -g 11 out
$ gpio write -g 11 0
$ gpio readall
+-----+-----+---------+------+---+---Pi 3---+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
 |     |     |    3.3v |      |   |  1 || 2  |   |      | 5v      |     |     |
 |   2 |   8 |   SDA.1 |   IN | 1 |  3 || 4  |   |      | 5v      |     |     |
 |   3 |   9 |   SCL.1 |   IN | 1 |  5 || 6  |   |      | 0v      |     |     |
 |   4 |   7 | GPIO. 7 |   IN | 1 |  7 || 8  | 0 | IN   | TxD     | 15  | 14  |
 |     |     |      0v |      |   |  9 || 10 | 1 | IN   | RxD     | 16  | 15  |
 |  17 |   0 | GPIO. 0 |   IN | 0 | 11 || 12 | 0 | IN   | GPIO. 1 | 1   | 18  |
 |  27 |   2 | GPIO. 2 |   IN | 0 | 13 || 14 |   |      | 0v      |     |     |
 |  22 |   3 | GPIO. 3 |   IN | 0 | 15 || 16 | 0 | IN   | GPIO. 4 | 4   | 23  |
 |     |     |    3.3v |      |   | 17 || 18 | 0 | IN   | GPIO. 5 | 5   | 24  |
 |  10 |  12 |    MOSI |   IN | 0 | 19 || 20 |   |      | 0v      |     |     |
 |   9 |  13 |    MISO |   IN | 0 | 21 || 22 | 0 | IN   | GPIO. 6 | 6   | 25  |
 |  11 |  14 |    SCLK |  OUT | 1 | 23 || 24 | 1 | IN   | CE0     | 10  | 8   |
 |     |     |      0v |      |   | 25 || 26 | 1 | IN   | CE1     | 11  | 7   |
 |   0 |  30 |   SDA.0 |   IN | 1 | 27 || 28 | 1 | IN   | SCL.0   | 31  | 1   |
 |   5 |  21 | GPIO.21 |   IN | 1 | 29 || 30 |   |      | 0v      |     |     |
 |   6 |  22 | GPIO.22 |   IN | 0 | 31 || 32 | 0 | IN   | GPIO.26 | 26  | 12  |
 |  13 |  23 | GPIO.23 |   IN | 0 | 33 || 34 |   |      | 0v      |     |     |
 |  19 |  24 | GPIO.24 |   IN | 0 | 35 || 36 | 0 | IN   | GPIO.27 | 27  | 16  |
 |  26 |  25 | GPIO.25 |   IN | 0 | 37 || 38 | 0 | IN   | GPIO.28 | 28  | 20  |
 |     |     |      0v |      |   | 39 || 40 | 0 | IN   | GPIO.29 | 29  | 21  |
 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+---Pi 3---+---+------+---------+-----+-----+

テスターでも high のままであることを確認。いつ壊してしまったのだろう。。。

MSI B150M で Wake-on-LAN

MSI 製マザーボード B150M 使用のマシンで Wake-on-LAN するときに意外とハマったので、いつか誰かの役に立つかもしれないと思い記録しておく。

• 電プチすると Wake-on-LAN できない。正常終了すること。以前のマザーボードではたぶんこんなことはなかった。
• BIOS の更新が必要。出荷時のバージョンではマジックパケットを送ってないのに、それどころか LAN ケーブルを抜いていても、勝手に起動する。
• 以上に注意すれば、 BIOS の設定は、 Resume by PCI-E device を Enabled にするだけで OK
• ethtool の設定は不要。デフォルトで on

Proxy ARP で2つのサブネットをつなぐ

前回、 ICMP redirect を使って ローカル用サブネットから VPN 用サブネットに経路制御しているという話を書いた。 これはやや不安定ながらも動いていたのだが、最近の Windows や Mac では ICMP redirect の受け取りが無効になっているため、この方法は使えなくなって困っていた。

昨日、何か手はないかと Linux のマニュアルを眺めていたら Proxy ARP という方法を発見。 ローカル用のサブネットにあるマシンに対して、 VPN 用のサブネットにあるマシンが同一サブネットにあると誤解させた上で、ルータ B に代理 ARP 応答をさせることで、 VPN 宛のパケットを ルータ B に吸収させるという仕組みである。

これで最近のクライアントでも VPN 内のマシンにアクセスできるようになった。

Linux: IP forwarding を有効にすると ICMP redirect が無効になる

タイトルに書いたとおりなんですが、Linux のデフォルトでは、 IP forwarding を有効にすると ICMP redirect の受け取りが無効になるようです。

Linux の sysctl のマニュアルをよく読めば書いてあるのですが、ぐぐってもあまりこの症例が出てこず、久しぶりに tcpdump とにらめっこしました。

自宅にはローカル用と VPN 用の２つのサブネットが存在していて、 ローカル用のサブネットに属するマシンは、インターネットにつなぐにはルータ A 、 VPN 用のサブネットにつなぐにはルータ B と話さなければならない構成になっており、そのために ICMP redirect を使っています。ルータ A をデフォルトゲートウェイとしておいて、 VPN サブネットにつなぎたいという要求がきたときにルータ B が経路だと応答するわけです。

Windows / Mac ではすでに ICMP redirect の受け取りはデフォルトで無効になっているようで、現代ではそれに頼らずルータ A がパケットをまるっとルータ B に転送したほうが良いようですが、行きと帰りの経路が違うせいかルータ A は最初の SYN パケット以外を転送してくれず、 TCP ではこの手は使えません。良い解決法はないものか…。(似たようなことを言っているブログを見つけました。)

2016/10/18 追記: Proxy ARP による解決策を見つけました。

重症プラティその後

1月25日の投稿で重症だと思っていたプラティは、なんとその後、妊娠中であったことが判明。

しっかり目を凝らさないと見えないですが、可愛いです!!!

以上、2月14日の写真でした。随分と投稿をサボってしまいました。いまではすっかり大人になっています(汗)

btrfs send/receive は rsync よりどのくらい速いのか？

Cinnamon デスクトップ環境のみをインストールした Debian のイメージ (3.7GB, ファイル数114842) を用意し、それを同じマシンの別のハードディスクに同期する時間を計測した。使用した Linux カーネルは 4.3 である。

ベンチマーク結果は次の通り:

同期方法	初回(全コピー)	2回目以降(差分コピー)
ext4 + rsync	1m23.188s	0m3.543s
btrfs send/receive	0m53.661s	0m0.679s

見ての通り、 btrfs send/receive が rsync に比べて圧倒的に高速であった。

差分コピーにおいて、 btrfs send/receive は全ファイル数が増えてもかかる時間はほとんど変わらないのに対し、 rsync は全ファイルの更新時刻をスキャンするためそれに比例した時間がかかる。したがって、同期するファイルシステムが大きくなるにつれ、 btrfs send/receive と rsync の差は拡大する。巨大なファイルシステムのバックアップに btrfs send/receive は非常に適している。一方、 btrfs send/receive はオーバーヘッドは少なくなく、ファイル数が20000以下の場合は rsync のほうが btrfs send/receive より速い。

ただし、 btrfs send/receive は2016年2月現在、実験的機能とされており、既知の問題も多く存在する。rsync は遅いとはいえ、速度より信頼性が求められるバックアップ用途としては十分実用に耐えるものである。でも次期マシンでは rsnapshot (rsync を使ったバックアップツール)から btrbk (btrfs send/receive を使ったバックアップツール)に移行してみてもいいかなと思わせる結果となった。

プラティ重症

尾びれに白点のようなものが1つ見られ要注意対象だったプラティの一匹が、(それが原因ではない気がするが)給水口のスポンジの隙間で動けなくなっていたので、救助し予備水槽に隔離した。

現在左胸びれに異常があり容態は厳しい。