muo-ya

Linux向けSMC読み書きツール（I/Oポートアクセス）をRustへ移植した

2024-12-24T12:02:00+09:00

本記事はRust Advent Calendar 2024 Series 3、19日目のエントリです

動機

私は日常の外出時用PCとしてMacBook 2016を使っています。このPCはmacOSのサポートが切れていることもあってUbuntuで使っているのですが、とっくにビンテージ扱いのPCにおいてはバッテリー寿命をのばすために充電上限を設定し、適宜設定更新する必要があります

もちろんこのような端末固有のきめ細かな制御ツールはUbuntu標準機能に入っていないので、以前GNOME拡張として実装しました*1。しかしUbuntu 22.04からUbuntu 24.04へアップデートするとGNOME拡張のサイドロード方法が変わったようで動作しなくなってしまいました

[*1] https://github.com/muojp/itawaly/

個人的にはあまりGNOME Desktop固有の事情に深入りしたくないので、他の方法で書き直すことにしました。PCのI/Oポートを叩く都合上、root権限を付与した単機能のコンパクトなバイナリで実際のI/Oポートオペレーションをおこないつつ、高水準側に便利機能を実装してなんらかのプロセス間通信で連携させるのですが、この低水準側で従来使っていたSmcDumpKey.c（https://github.com/floe/smc_util/blob/master/SmcDumpKey.c）には若干データ出力上の不具合があり、どうせ手を入れるならリライトもアリか、と考えました

あまりCのコードをメンテし続けたくはないので、I/Oポートアクセスのための最小限のコードだけをCの世界に残しつつRustで書き直しました

コードはhttps://github.com/muojp/smc-rw-linux/にあります

ちなみにRustでのSMCアクセスについて、Swiftで書かれたmacOS用の実装やRustのmacOS用クレート*2は見かけたのですが、Linux向けに書かれた実装はサッと見つけられませんでした

[*2] https://crates.io/crates/smc

実装方針

以前はCで書かれたユーティリティーをビルドしてGNOME拡張のJavaScriptコードからプラットフォーム呼び出しで利用していました。I/Oポートアクセス権限の都合上、便利機能の提供側とI/Oポートアクセス部分は別プロセスにしたいので、構成としては今回もさほど変わりません

Rustでの実装は次のような方針で進めました

ccでC側とのインタフェースを用意し、IoPortRw traitでOS差分を吸収
それを実装するLinuxIoPortRwに実際のI/Oポートアクセスのunsafe部分を置き
これらを利用する低水準側操作としてSmcPrimitive traitを定義
今回作ったMacBook用実装はDefaultSmcRw（リポジトリ内にデバイス製造企業名を残したくなかったので曖昧な命名にしています）として実装
高水準側はSmcOperationのデフォルト実装として作り、テスト範囲を低水準側と切り離しやすくする。実際のテストはmockallクレートでやっていく

実装上のポイント

Linuxのsys/io.hはaarch64環境には存在しません。動作ターゲットのMacBook 2016はIntelアーキテクチャですが私は普段の開発をaarch64のLinux環境でしているので、アーキテクチャ依存部分を分離する必要がありました

#if defined(__x86_64__)

#include <sys/io.h>

void port_outb(unsigned char value, unsigned short port) {
        outb(value, port);
}

unsigned char port_inb(unsigned short port) {
        return inb(port);
}

int port_ioperm(unsigned long from, unsigned long num, int turn_on) {
        return ioperm(from, num, turn_on);
}

#else

void port_outb(unsigned char, unsigned short) {
}

unsigned char port_inb(unsigned short) {
        return 0;
}

int port_ioperm(unsigned long, unsigned long, int) {
        return 0;
}

#endif

若干乱暴ですがこれでクロスターゲットのテスト可能範囲をだいぶ増やせました

テスト戦略

前述のようにtraitをSmcPrimitiveとSmcOperationと低水準・高水準に分けて実装し、SmcOperationのデフォルト実装に高水準APIを実装することで、低水準側をmockにしたテストをしやすくしました。この分離がなければ無限にダミーI/Oポート応答シナリオを書くことになってなかなか不毛です

#[cfg(test)]
    mock! {
        SmcTest {}
        impl SmcPrimitive for SmcTest {
            type IoPort = MockIoPortRw;
            fn new(io_port_rw: MockIoPortRw) -> Self;
            fn wait_read(&self) -> libc::c_int;
            fn send_byte(&self, cmd: u8, port: u16) -> Result<libc::c_int, String>;
            fn send_argument(&self, key: [u8; SMC_KEY_NAME_LEN]) -> Result<(), (usize, String)>;
            fn recv_byte(&self) -> Result<u8, ()>;
        }
    }

アプリケーション開発の中でも自動テスト部分ではやはり特殊なことをするケースがそれなりにあって（典型的には多くの人が初めてリフレクションやRTTIを意識するのはテスト文脈ではないでしょうか）、テスト補助ライブラリが複雑な状態に基づくテストケースをテストターゲットの設計へあまり踏み込まずに書ききれる筋力を持つか否かというのは言語自体の書き味と同じくらい重要な場合もあります。もちろん、testableにするためのプログラム構造変更がよりよい設計につながるケースも多いため、テストの窮屈さは設計改善のシグナルのひとつでもありますが、「ここはこれでよし」と定めた際にその方針通り走り切れることもまたテスト補助ライブラリの出来と言語の記述力次第というか。

今回、I/Oポートへの入力値に応じて出力が想定どおりに変化することを確認するためにArcを介した共有メモリでのデータのやり取りが必要になったり、テストの並列実行時にmock生成部分がスレッドセーフではない挙動をする（flakyに失敗する）ためmockのセットアップ部分へMutexベースのロックを利用したりと細かな手当は必要となりましたが、逆に言えばそれだけで済んだのでmockallは今回の用途では十分に実用域で開発を強力に支えてくれると感じました

とはいえautomockでは足りずmock!{}ブロックを書く必要が生じるのはmockall設計上のイレギュラーパターンに半分足を突っ込んでいる状態で、あまりサンプルが豊富ではないしコンパイルエラー時のメッセージも分かりづらくなるためあまり複雑化しないほうが良い気配はありました

また、今回のテストコードを書いている際にpanic関連の挙動についての学びがありました。文脈としては、不正な長さのデータを投入した際に想定通りErr()が戻ってくることを確認するのに加えて、高水準側（ほぼmainメソッド直下）においては想定通りpanicで実行を止めてくれることを確認したかったので、次のようなコードを書きました

let hook = panic::take_hook();
panic::set_hook(Box::new(|_| {

}));
data.data_len = 16;
let result = std::panic::catch_unwind(|| {
    let mut short_buf = [0u8; 8];
    smc_rw.read_smc(SMC_GET_KEY_TYPE_CMD, [0x01, 0x02, 0x03, 0x04], &mut short_buf[0..data.data_len as usize])
});
panic::set_hook(hook);

assert!(result.is_err());
match result {
    Err(panic_msg) => {
        if let Some(msg) = panic_msg.downcast_ref::<String>() {
            assert_eq!("range end index 16 out of range for slice of length 8", msg);
        }
    }
    Ok(_) => panic!("should receive an error")
}

もともとはstd::panic::catch_unwindで単純に情報取得していたのですが、stdoutに出てくるbacktraceが割と邪魔だと気付いたので抑制したいと思ったのがきっかけで対応を練りました。処理としてはpanic時のフックを一時的にほぼ空の実装へ置き換えてテスト実行、その後にもとのフックへ戻しています

想定通りbacktraceが出力されなくなって自動テストの出力が汚れることはなくなり、さらに副作用として、手元PCでこのテストケースだけ150msほどかかっていたのが数msまで短縮されました。やはりbacktraceの生成は普通に重い処理なんだな、、という実感がありました（cargo test時は通常Debugビルドで動いているという都合もあるでしょう）

まとめ

今回の用途は、低水準のI/Oを叩きに行くコンパクトなユーティリティーをそこそこ見通しよく書けてメモリ安全性を確保しやすくテストコードもそれなりに書きやすくコンパイル後のバイナリが許容可能なサイズに収まる*3、というRustとCargo/クレートエコシステムの良さを活かしやすいものでありました

[*3] リリースバイナリが667KiBで決して小さくはないのですが、そのあたりは別エントリに書いたので参照ください。https://b.muo.jp/2024/12/22/rust-release-binary-size ちなみにbuild-stdでビルドすると348KiB、CLI処理用のclapが大半を占めます

Rust製ツールのリリースバイナリを無理なくコンパクトにする

2024-12-22T20:17:00+09:00

シンプルな機能のRustプログラムを書いていたら、リリースビルドでも420KB超と予想以上にサイズが大きくなった。バイナリサイズの削減がどの程度現実的なのかをざっと検証してみる*1

初期状態の確認

releaseビルドの初期状態で429104 bytes

cargo bloatで中身を確認すると、大半が標準ライブラリ由来、特にpanic時のハンドラから呼ばれていると思しきbacktrace生成用のライブラリが上位を占める

$ cargo bloat --release -n 10
...

 File  .text     Size Crate Name
 0.9%   6.3%  14.7KiB   std std::sys::backtrace::_print_fmt::
 0.7%   5.2%  12.1KiB   std std::backtrace_rs::symbolize::gimli::Context::new
 0.6%   4.0%   9.4KiB   std gimli::read::dwarf::Unit<R>::new
 0.6%   4.0%   9.3KiB   std miniz_oxide::inflate::core::decompress
 0.4%   2.9%   6.9KiB   std addr2line::ResUnit<R>::find_function_or_location::
...

バイナリサイズの削減

Cargo.tomlへの定番設定

Cargo.tomlに以下を追加する

[profile.release]
# opt-level = "z"
lto = true
codegen-units = 1
strip = true
panic = "abort"

panic = "abort"がキー！という書き方をしているblog記事類も見つかるが、ここへの期待度はさほど高くない。よほどきれいにstripされない限りは周辺ライブラリの容量削減は見込めないため

これらの設定を追加後にリビルドして326040 bytes、最初の429104 bytesと比較すると24%の削減

opt-level = "z"指定を有効化するとさらに9KBほど減るが、速度を犠牲にする判断をしたくないケースも多い気はするので今回は最終的にコメントアウトした。典型的には短めの固定長配列に対するループのアンロール処理を無効化することでサイズを削るのだろう

stdのコンパクト版ビルド

2018年頃には確立していた手法として、stdの実行時用コンパクト版をビルドする方法がある*3。MSVCでいうところのVC++ Runtime debug版とrelease版のようなもので、Rustでは通常debug時でもrelease時でも同一のプリビルトstdライブラリを静的リンクしているが、ビルド時にソースからstdを構築してバンドルする仕組み（概念としてはstd Aware Cargoと表現されている*2）によって不要なものを削ってバイナリサイズを削れる。当初はXargoで実現されていた機能だが、現在はnightly版のbuild-stdを使用する

$ cargo +nightly build -Z build-std=std,panic_abort -Z build-std-features=panic_immediate_abort --release

ここで指定している-Zオプション群はnightly版のCargoでしかまだ使えない（2024年12月時点）ので、rustupから予めnightly版のtoolchainとstdビルド用のrust-srcを導入しておく必要がある

rustup toolchain install nightly
rustup component add rust-src --toolchain nightly

build-std-features=panic_immediate_abort指定でCargo.toml側のpanic = "abort"指定を補完しているのは良い

これで26KBまで劇的に削減できる

なお、stdをビルドする都合上リリースビルドの所要時間は伸びる。手元の古いPCでは30秒程度のオーバーヘッドが発生するが、リリースビルドをそう頻繁にやるわけではないので開発体験を悪化させる性質のものではない。配布バイナリのサイズ最適化という文脈では許容できる範囲と考えられる

ただ、build-stdは前述のように2024年時点でもnightlyの機能である。std-aware Cargoの仕様策定には複雑な要件が絡み、安定化のためのディスカッションポイントはどれもパワーが必要そうで、すでに数年間議論が止まっていたり当初の議論リード者の関与が薄くなっている点も複数ある。バイナリサイズ削減がビジネス価値につながる企業が急にスポンサーとして付く、のような大幅加速イベントが発生しない限り、2030年ぐらいまでnightlyのままであっても驚きはない状況に見える

build-stdはまだpreliminaryでexperimentalな存在という扱いであることには注意が必要。開発段階で各種自動テストを通していても言語ランタイム/標準ライブラリが差し替えられた状態でそれらの結果が信用できるか、というのは現状での各種リリースバイナリをbuild-std版のstdライブラリと静的リンクして出力することを躊躇するに十分な理由で、そう考えるとよほど特殊な事情がない限りはnightly範囲外のCargo.toml設定群で満足しておくのが無難ではある

実行環境に応じた検討事項

配布サイズと実行時のトレードオフ

配布時のサイズをさらに小さくする選択肢としてはUPXによる実行可能ファイルの圧縮*4やlzipなどの一般的な圧縮形式の利用が考えられる。UPXは実行時にメモリ上でバイナリを展開する必要があり、実際の配布サイズとしては一般的な圧縮形式と大きな差は出ないため、見かけ上の容量削減（自己満足とも言える）に留まる可能性がそれなりに高い。たしかに今回のターゲットでは26KB→15KBぐらいに縮みはしたが作っているツールの性質的には特にUPXは不要だと感じた

WebAssembly向けの考慮

wasm環境での実行を想定する場合、stdをカスタムビルドするよりもno_stdを選択するほうが現実的なケースも多そう。しかしstdの要素は案外あちこちで必要になるのでその都度代替実装を探したり書いたりとしていくハードルは結構高い*5

[*1] https://github.com/johnthagen/min-sized-rust というチュートリアルが丁寧に各手法を紹介しているので参考になる。結果としてはこの内容を辿っていった

[*2] https://github.com/rust-lang/wg-cargo-std-aware

[*3] Xargoは2018年以降アクティブな開発は行われていない。 https://github.com/japaric/xargo/issues/193

[*4] Ultimate Packer for eXecutables https://github.com/upx/upx

[*5] wasm向けのno-stdについてはhttps://hackmd.io/@alxiong/rust-no-stdが出発点としてよさそう

ケーブルボックス内のM4 Mac miniの温度管理

2024-11-28T00:00:00+09:00

今年は久々に手元の作業用Macを買い替えた。個人的には視界の中にMacがあっても特にテンション上がらないので、Mac mini本体は大きめのケーブルボックスの中に設置している。この運用なら発売前から話題になっていた電源ボタン問題とも無縁である

ケーブルボックス内に隔離するとエアフロー確保はそれなりに課題だと思いつつ、冬場なのでひとまず深く考えず後回しにしていた。けれど、年末の大掃除の文脈でレイアウト変更を考えるのも良いなと思ったので、少し考えることにした

まずはケーブルボックス内で実際どれぐらいの温度で動作しているのかを知るところから。Macのシステム情報を取得・可視化する方法はいろいろあるが、Intel Mac用のものなど入り乱れていて Apple SiliconのMac、とりわけ手元のM4 Mac miniで正常動作するのがどれなのかよくわからない。いくつか試した結果、無事に動作したのがStats*1だった

StatsはHomebrewからインストールできる

$ brew install stats

デフォルトではシステムトレイ上にいろいろなシステム情報が表示されるのだけど、CPU使用率やネットワーク速度類が頻繁に画面上で表示更新されていると気が散るので、温度に特化させることにした

データ更新頻度はデフォルトで1秒間隔になっている（表示上は3秒間隔がデフォルトだが実際は1秒）けれど、そんなに頻繁な更新は必要ないので1分間隔にしておく

ポップアップ通知の機能もついているので、ちょっとやばいかなという条件として Airport 50度、Average CPU 75度を設定しておいた

ちなみにStatsにはファン速度のコントローラーもついているので、静音性よりも放熱を優先したい場合は手動でファン速度を上げられる。これは便利

[*1] https://github.com/exelban/stats

2024-12-31追記

温度を1日取ってみたらまあまあ上がっていて本体寿命によくなさそうだったので即ケーブルボックスから取り出して室内のすみっこに置いた

Statsはそれ以来起動していない。1週間ぐらいは状況を確認することになるかなと思ったけれど、状況が可視化されたら思いの外一瞬でカタがついた。ありがたや

このblogの下回りシステムを少しメンテした

2024-11-27T09:54:00+09:00

このblogはRe:VIEW記法で書いたエントリをJekyll+Netlifyで静的サイトとして書き出している

ちょっと古めのアーキテクチャだとは感じるけれどRe:VIEW記法で文書を作るのには慣れているので今から変える理由も特にないかなという

さて久々に新エントリを書いたらNetlifyでビルドエラーを吐いた。Python系の依存解決でエラー

7:50:45 AM:   Downloading funcparserlib-0.3.6.tar.gz (30 kB)
7:50:45 AM:   Installing build dependencies: started
7:50:46 AM: Failed during stage 'Install dependencies': dependency_installation script returned non-zero exit code: 1
7:50:46 AM:   Installing build dependencies: finished with status 'done'
7:50:46 AM:   Getting requirements to build wheel: started
7:50:46 AM:   Getting requirements to build wheel: finished with status 'error'
7:50:46 AM:   error: subprocess-exited-with-error
7:50:46 AM:   × Getting requirements to build wheel did not run successfully.
7:50:46 AM:   │ exit code: 1
7:50:46 AM:   ╰─> [1 lines of output]
7:50:46 AM:       error in funcparserlib setup command: use_2to3 is invalid.
7:50:46 AM:       [end of output]
7:50:46 AM:   note: This error originates from a subprocess, and is likely not a problem with pip.
7:50:46 AM: error: subprocess-exited-with-error
7:50:46 AM: × Getting requirements to build wheel did not run successfully.
7:50:46 AM: │ exit code: 1
7:50:46 AM: ╰─> See above for output.
7:50:46 AM: note: This error originates from a subprocess, and is likely not a problem with pip.

funcparserlib-0.3.6、やけに古い

そもそもなんでPython?というのをすっかり忘れていたのだけど、数年前に自分へのクリスマスプレゼントとしてblockdiagで図を埋め込めるようにしたのだった*1。すっかり忘れていた

Netlifyではruntime.txtにPythonのバージョンを書けるのだけど見てみるとバージョン3.8、今年の10月にサポートが切れている

極力最新にするのも良いけれど手元で使っているデスクトップのUbuntu 22.04デフォが3.10系なので一旦それにあわせておく

pipのバージョン指定を手動で細かくやるのも不毛なので、手元環境でvenvを作り直してそこへ入ったバージョンを採用する

python3 -m venv .venv
source .venv/bin/activate
pip install blockdiag
pip freeze > requirements.txt
echo '3.10' > runtime.txt

として再度デプロイする。どうもまだ図のビルドでエラーを吐いている

blockdiag==3.0.0
funcparserlib==2.0.0a0
pillow==11.0.0
webcolors==24.11.1

ちゃんと今風な依存関係になっているけれど何がまずいのか、デプロイログを見てみる

9:33:56 AM: INFO jekyll: blockdiag -a -T svg -o ./images/html/2019-12-25-diagram1.svg /tmp/review_graph20241127-5628-tmushg
9:33:56 AM: ERROR: 'FreeTypeFont' object has no attribute 'getsize'
9:33:56 AM: ERROR jekyll: failed to run command for id 2019-12-25-diagram1: blockdiag -a -T svg -o ./images/html/2019-12-25-diagram1.svg /tmp/review_graph20241127-5628-tmushg

調べるとPillow 9系から10系以上（現在の推奨は11系）へバージョンアップした際の非互換性FAQらしい

セキュリティ上Pillow 9系を使い続けたくはないが、ここに時間をかけすぎたくもないので一旦撤退がてら9.5.0を使っておくことにした

ひとまず図は再生成されたので一旦よしとする

[*1] https://b.muo.jp/2019/12/25/jekyll-review-blockdiagに当時の記事がある

VS Codeのホイールボタンペーストを無効化する

2024-11-24T00:00:00+09:00

私のメイン環境はUbuntu 22.04 LTSであり、VS Codeの設定としてはほぼデフォルトのままで運用している

ホイールボタンペーストの問題

Linuxデスクトップ環境では、ホイールボタンクリックでクリップボードの内容がペーストされる挙動がデフォルトである。この挙動はLinuxデスクトップ環境における長年の伝統だが、個人的にはあまり直感的でもなければ便利でもない。ホイールボタンクリックは新タブでリンクを開くボタンだと教育されて育った世代なので、ペースト挙動は世間常識から外れていてLinuxデスクトップ環境が一般に普及しない要因のひとつではないかとさえ考えている

人生においてテキストを「ペーストしよう」と思ってホイールボタンをクリックする瞬間が存在するだろうか？と考えてみると、自分の場合にはエディタ作業に誤ってホイールボタンをクリックしてしまうことでコードの途中に意図しないペーストが発生して生産性を下げる懸念のほうが大きいと感じるし、うっかり画面外でペーストしたことに気付かずセンシティブな情報をgit pushした日には面倒が大きすぎる

設定による解決

VS Codeの設定で以下のように変更する*1と、この問題を解決できる

"editor.selectionClipboard": false

設定はsettings.jsonへ直接記述するか、設定画面から変更する

この設定により、以下の操作が無効化される：

テキスト選択時の自動クリップボードコピー
ホイールボタンクリックによるペースト

通常のCtrl+C / Ctrl+Vによるコピー＆ペースト操作は従来通り利用できる

この設定変更はVS Code内でのみ有効であり、他のアプリケーションでの挙動には影響しない。OS全体でこの挙動を無効化する方法もあるが、経験上あまりうまくいったことがない（ホイールボタン自体を無効化するなど副作用が派手で不便なことが多い）ので今回はVS Code内での対応に留めておく

ちなみに個人的にはFirefoxに関して同様の設定をしている。Notionのリンクを新タブで開こうとしてクリップボードを適当なページへぶちまけるリスクは現代において思いのほか現実的で危ういので、これもおすすめする*2

[*1] https://github.com/microsoft/vscode/issues/14610

[*2] https://www.reddit.com/r/firefox/comments/a6i0ba/ysk_you_can_disable_the_disabling_of_copy_and/?rdt=41407

12インチMacBook（2016）をUbuntu 22.04で使う

2023-11-26T00:00:00+09:00

一年の終わりが近い

ので、毎年のように書いている自分の作業環境の話を2023年版にアップデートしておく

920g、黄金時代のMacBook

MacとmacOS

まずmacOSのライフサイクルについておさらいすると、macOSは毎年6月のWWDCあたりで発表され、10月頃のiPhone発売と近い時期にリリースされ、初期リリースから33ヶ月ほどでセキュリティーfixが止まる

セキュリティーfixが止まった頃には次のOSのメジャーバージョンがリリースされているのでそちらへアップデートしろということになるが、非対応デバイスは切り捨てられる*1

歴史的にMacの発売からセキュリティーfixが終了するまでの期間は約7年で、それぐらい経つうちには数回バッテリーがヘタり、バッテリーのGenius Barでの修理受付が終了し、互換バッテリー在庫も枯渇していく*2、というライフサイクルである

[*1] OpenCore Legacy Patcherを利用して新macOSを無理やり旧Macへインストール派閥も存在するがHackintoshの類なのでここでは扱わない

[*2] ちなみに12インチMacBookはキーボードが故障しやすいので交換用パーツを一式手元に抑えてある

あまり知られていないが、もう8年近くも重量1kgを下回るMacBookは発売されていない

いっぽうで2023年にリリースされたmacOS 14（Sonoma）では全世代の12インチMacBookがサポートを打ち切られ、2022年リリースのmacOS 13（Ventura）の2025年7月最終アップデート（見込み）によって全てのサポートが終了する

これがMacBookにおける2025年問題である

サポートの切れたOSを日常利用するのはセキュリティー上望ましくないので12インチMacBookユーザーはそろそろ逃げ道を本格検討する必要があり、その際に有力な選択肢がLinuxである

MacとLinux

12インチMacBookのようなクラシックなデバイスはLinux、とりわけUbuntuでの利用と相性が良い

現代のUbuntu標準GNOME Desktopは非力なCPUでも十分実用的に動作するし、メモリを一定抑制しやすいようにFirefoxを常用するなどすれば*3日常的な作業における支障は少ない

[*3] Appleが低レンジMacにおいて「メインメモリ8GBでいいでしょ？」と設計する裏側にはmacOSのメモリ圧縮機能とSSDへのスワップアウト性能の良さを前提としている部分があり、デスクトップLinuxは必ずしもこの思想と相性が良くないためChromeは正直きびしい部分がある

年が明けたらUbuntu 24.04が近づいてくる

Ubuntuの非サーバー構成インストールではインストール後も定期的にkernelバージョンが上がっていくのでメジャーなLTS更新だからといって基盤部分で大きな変化はないことが多い*4が、メジャーなアップデートではPipeWireやWayland、Flutterの利用領域拡大によって確実に前向きな変化が起きるので早い段階でバージョンアップするようにしている

OSのメジャーバージョンアップは何かとトラブルを引き起こして忌避されがちであるが、個人的にはdist-upgradeせずにOS新規インストール&Homeディレクトリの式年遷宮をする派*5なので、次の遷宮機会時にはこれまでMac標準のAPFSへ割り当てていたディスク領域を大幅にshrinkさせてLinux用に再割当てするのが楽しみ、という程度のお気楽な2年に1度のイベントである

[*4] 逆にLTSライフサイクル中を通じてkernelの新規featuresも取り込まれていきほぼ最新を使い続けられるというメリットがあり、Ubuntuを積極的に選ぶ要素のひとつでもある

[*5] どのみちapt/snapで導入できないものは数えるほどしかインストールしない

さて、Ubuntuでの利用を前提として12インチMacBookのLinuxでのドライバサポート状態をレビューしておく

12インチ MacBook Early 2016（MacBook 9,1）のLinuxドライバサポート状況

内蔵キーボード、トラックパッド、Wi-Fiまでは標準ドライバで賄える

オーディオ出力

スピーカーと有線イヤフォンの利用にはクセがある

Linux標準ドライバだと「イヤフォンジャック経由の出力ができる」
https://github.com/leifliddy/macbook12-audio-driverの非公式ドライバだと「スピーカーからの出力ができる」

これらを手動または半自動で切り替えることになる

個人的には本体スピーカーから音を出したい場面がないので詳しく調べていない

バッテリー管理

前述のように本体内蔵バッテリーはサポートの切れたMacを延命する重要な要素で、バッテリー寿命をのばすためには充電系のコントロールが欠かせない

Mac内部の設定値を適宜いじることでmacOSには及ばないもののそれなりの延命は期待できる

GNOME Desktopから手軽にバッテリー充電上限を設定できるようにhttps://github.com/muojp/itawalyシェル拡張を自作したので、機会があれば試してみてほしい

Bluetooth

厄介その1がBluetoothで、標準サポートされていない

https://github.com/leifliddy/macbook12-bluetooth-driver

ここのBluetoothドライバを導入すれば動作する

kernel更新の都度カーネルモジュールをビルドして組み込むのは若干面倒であるが、作業量自体が多いわけではなく基本的に2-3分で終わる

HIDたとえばトラックボールやHHKB Proを接続して使う分には問題ないが、SBCの音声ストリームですらかなり途切れ途切れになるためBluetoothヘッドセットを接続してBGMを流すような用途にはほぼ使えない

おそらくBT通信チップの初期化シーケンスでネゴシエーションしている動作モードが低ビットレート版のもので本来は接続機器にあわせてモード変更コマンドを発行する必要があるのだろう（高レートで固定すると消費電力へ響くというパターンもありうる）

このあたりは非公式情報によって構築されたドライバの弱みポイントではあり、オーディオ出力やオンライン会議用の利用については内蔵BT利用を諦めてUSB接続のBluetoothドングルを利用するほうが格段に安定する

ちなみに2015年モデル（MacBook 8,1）は前述の非公式ドライバを導入してもBluetoothモジュールが動作しないためBluetoothドングルが必須である

Webカメラ（FaceTime）

厄介その2がWebカメラである

2011年以降のMacはFaceTimeを搭載している

これらの多くはFaceTime HDと呼ばれているが12インチMacBookではどうも縦解像度480が上限のようで、どうひいき目に評してもSDである

この手の内蔵カメラモジュールは内部で適当なUSBインタフェースへ接続されるのが普通かと思っていたらFaceTime HDは内部がPCIe接続になっている

なぜPCIe？と思うが仮に60fps 1080pを24bit ベタRGBで伝送しようとすると約3Gbps必要であり（実際にはFaceTime HDは720pの時代が長くフレームレートも15-20fps程度なので500Mbpsない程度）、内蔵のUSB 2.0へぶら下げるのには多少荷が重い

Wi-Fi/BluetoothモジュールがPCIe x1接続になっているパターンは今でもそれなりに見かけるし、特にプラグアンドプレイを前提とせず電源管理の柔軟性を確保したいデバイスなら悪くない選択肢なのだろう

さて、Linux kernel自体にFaceTimeサポートのコードは取り込まれていないが、https://github.com/patjak/facetimehdの非公式ドライバによって動作することが知られている*6

[*6] 初期化シーケンスで必要となるファームウェアの再配布問題を考えるとおそらくFaceTime/HDサポートが標準へ取り込まれることはないだろう

12インチMacBookについては少々特殊で、前述の非公式ドライバをそのままビルドして組み込んでも初期化でコケて動作しない

https://github.com/patjak/facetimehd/issues/196#issuecomment-569858722のパッチを当てると無事に動作する

ChromeOS Flexという選択肢

仮にAppleがまだ最新OSでデバイスをサポートしているとしてもOS挙動が重すぎて使いたくない、というのはよくある話である

いっぽうChromeOSと廉価版Chromebook群によるPC業界の学びは、用途を十分に絞り込めば現代でもメインメモリ4GB+16GB eMMCという貧弱な構成から十分に実用的なPC環境を構築・維持できるということである

そして2020年にGoogleがCloudReadyを買収し、2022年にChromeOS Flexを公開したことにより非Chromebookへの限定的なChromeOSサポートが拡大しており、古いMacへChromeOS Flexをインストールするという道も現実味を帯びてきている

これが一筋縄でいかないのはChromeOSの構造に由来する

ChromeOSは枯れたLinux kernelにモダンなユーザーランドを組み合わせることでアップデート速度とメンテナンスコストのバランスを取るようになっているため、つまりは搭載しているLinux kernelが極端に古かったりする

MacでLinuxを使う際にはこのあたりの問題を踏みやすい（なにぶんほとんどのハードウェア要素の詳細が非公開で有志による解析と非公式ドライバの開発に依存している）

12インチMacBookは特にMac側のアーキテクチャ分断のモダン側の崖っぷち部分に位置しており、同機が発売された時点のLinux標準ドライバでは内蔵SPIインタフェースのキーボードが利用できない、内蔵NVMe SSDへアクセスできない、といった典型的なペリフェラルサポートにまつわる問題があった

これらは2017年頃までに概ね解消してLinux kernel 5.3周辺で大きく改善したが、ChromeOSのベースバージョンが問題となる

1年ぐらい前に試した際には

ChromeOS 105：Linux 5.10ベース
ChromeOS Flex：Linux 4.4あたりベース

であり*8、ChromeOS FlexのインストーラーをUSBドライブから起動した時点で何も操作できなくなり電源ボタン長押し（これはOSサポートと関係なくPC/AT的な挙動で通る）するしかなくなる状態だった

Chrome OS Flexのベースバージョンも今年の半ばにはLinux 5.10まで上がっている*7ので、おそらくBluetooth・カメラを除けば12インチ用MacBookの安定稼働環境として実用的な状態になっているのではないだろうか

[*7] https://www.reddit.com/r/ChromeOSFlex/comments/145166o/what_kernel_does_chrome_os_flex_use/?rdt=38176

[*8] 厳密には出荷時期の古いChromebookでは最新ChromeOSユーザーランドに古いkernelを組み合わせて動作し続けるケースがあるので正確ではない

ChromeOSはすごい

特にArmベースでWidevineのきちんとしたプロファイルが通って各種動画ストリーミングサービスを問題なく視聴できる環境としてはArmbian系よりもChromeOS系のほうが苦労せずに済むという点から考えてもなかなか強い環境である（あるいは用途を絞り込んでSTB向けAndroidを動かす、という二択）

今後もLinux kernelへ各種コミュニティ開発ドライバが取り込まれていくと最終的にChromeOS Flexがビンテージ/クラシックPC用の最も手軽でアップデートを受け続けられる環境になる可能性がある

まとめ

Appleが1kg未満のMacを新規発売するのと手元12インチMacBookが全台朽ち果てるのとどちらが早いか、来年もご期待ください

冬を乗り切れるか不安になってきたので意識低いホームオートメーションをする

2022-12-22T00:00:00+09:00

最近寒すぎてこの冬を乗り切れるか怪しい

弊宅にはNature Remoが導入済みであり、超簡易的にエアコンのP制御を組みリモートワーク環境の生産性確保を試みているが、契約している電力会社がどんどん燃料調達に関する値上げをしている中ではこの冬エアコンをまともに使える気がしない

そうなると時代は灯油だオイルを燃やして暖を取るほかない

ここで問題になるのがIoT的な電源制御であり、廉価帯の石油ファンヒーターはもちろん上位モデルでも基本的にリモートで電源ONにする機能は入っていないように見受けられる（安全上の配慮、法令によるものと自主規制の組み合わせだろう）

致し方ないので点火は手動でおこなうものとする

問題はいつ点火するかであり、リモートワーカーとしては自分のパフォーマンスが落ちてくる前にこれを適切におこなう必要がある

基本的にリモートワークのパフォーマンスは室温による関数であり、室温をほどよく把握しつづけることがパフォーマンスにつながる

Nature Remoのスマホアプリを開けば室温が分かるが、アプリを四六時中開いているのは効率悪い

室温計を追加購入したくはない、となるとやるべきは作業中のPC上に室温をほどよく表示することである（図1）

図1: Nature Remoで取得した室温をGNOMEで表示する

意識の低いホームオートメーションとはなにか

全世界で自分だけ使えればいい（自分の特殊ニーズを満たせればよい）
全自動は目指さない。自分を操作インタフェースとして使うことで目的を達成できるなら積極的に使う
bashと定番コマンド群でさらっと書く
書いたら書いた通りに動き、簡単に捨てられる

Nature RemoのAPIから室温を取り出す

先人の知見にありがたく乗っかるものとする

https://blog.yuu26.com/nature-remo-api-tutorial/

複数のNature Remo端末を登録している場合はデバイスIDで更にフィルタするのが無難

  TEMPERATURE=`curl -s -X GET "https://api.nature.global/1/devices" -H "Authorization: Bearer $NATURE_TOKEN" \
  | jq ".[] | select(.id == \"$DEVICE_ID\") | .newest_events.te.val"`

こんな感じだろう

APIから取れる値の更新間隔は1分か2分ごとであるように思うが今回はひとまず気にせず30秒間隔でデータを取得しておく

ZenityでGUI表示する

手元のデスクトップ環境はUbuntu 22.04であり、標準のGNOME Desktopで動作している

この環境においてざっくり可視化はどうすればいいか

curlで値を取ってjqで加工する、だけだとターミナルのタブを1枚専有したりいちいち見に行かなきゃいけなくて面倒なのでみんなのzenityでGUI化する

Zenity - プログレスバー

公式ドキュメントが充実しているので機能カタログを読んでいく

数値変化をそこそこ視覚的に分かりやすく表現し、認知の負荷を下げるのが目的であり、やりたいことを実現するには単発プログレスバーを表示しっぱなしにしておけばいい

標準入力をあけっぱなしにして新しい値を適宜受け取るという扱いやすい仕様
行頭に# を入れてやるとラベル更新、なければ数値更新という割り切った仕様も良い
OKとかCancelとかは別に要らないけどわざわざ外すほどでもない
複数の値をプログレスバー表示したい（CO2濃度とか）、となったらまあ適宜ちゃんとやればよい

要求を満たすものはこんな感じ、コマンドからさらっとGUIを制御できるというだけで満点である

(
while :
do
  TEMPERATURE=15
  PROGRESS=0
  echo "$PROGRESS"
  echo "# $TEMPERATURE"
  sleep 30
done
  ) |
zenity --progress \
  --title="Room temperature" \
  --text="fetching..." \
  --percentage=0

入力値を適当にクランプする

プログレスバーを扱う際に面倒なのは想定外の範囲の入力値の処理であり、つまりクランプが必要

bash script類で小数込みの値をクランプするのがまあまあ面倒そう、と調べてみたらawkを使う策が提示されておりすばらしい

https://stackoverflow.com/a/27688507

  P=`awk '$0<15{$0=15}$0>30{$0=30}1' <<< "$TEMPERATURE"`

これで15度から30度の範囲外の値を上限値と下限値へクランプできる

bcで気温をプログレスバーの0-100値へマップする

シンプルな数値計算でもbash組み込みのオペレータで演算すると面倒*1というのは非常に有名事案につき、bcを使う

bcの素晴らしい点は-lオプションにより小数込みの演算を通せるところである

  PROGRESS=`echo "(100/15)*($P-15)" | bc -l`

[*1] bash含めてシェルスクリプトを正しく書くのは想像の何倍も困難だと知っているので厳密な理解をしようという気持ちはとうに放り捨てている

出力微調整やデータの扱いやすさを検討して仕上げる

念のため時刻・温度のペアでログをローカルディレクトリへ書き出すようにしておく
- あとからGoogle Sheetsあたりへ放り投げるようにすればクラウド化もできて完璧
データとしてはTSVにしておくと楽
dateをそのまま使うと行末改行が入るので一旦パラメータに受けて回避してる
- tabの出力はechoに-eオプションが必要
zenityで表示したダイアログ側の後始末をしていないのでダイアログを閉じても最大30秒ほどプロセスが残り、次回の温度取得が走ってから終了するが特に問題ないのでそのままにしておく

スクリプト全文

#!/bin/bash

LOGFILE='/home/user/templog.txt'
NATURE_TOKEN='NATURE_REMO_TOKEN'
DEVICE_ID='DEVICE_UUID'

(
while :
do
  TEMPERATURE=`curl -s -X GET "https://api.nature.global/1/devices" -H "Authorization: Bearer $NATURE_TOKEN" | jq ".[] | select(.id == \"$DEVICE_ID\") | .newest_events.te.val"`
  P=`awk '$0<15{$0=15}$0>30{$0=30}1' <<< "$TEMPERATURE"`
  PROGRESS=`echo "(100/15)*($P-15)" | bc -l`
  echo "$PROGRESS"
  echo "# $TEMPERATURE"
  echo -n `date +%Y-%m-%dT%H:%M:%S` >> $LOGFILE
  echo -e "\t$TEMPERATURE" >> $LOGFILE
  sleep 30
done
  ) |
zenity --progress \
  --title="Room temperature" \
  --text="fetching..." \
  --percentage=0

その他

.NET 7も出たことだしMAUIで組めばいいのでは、と思うところはあるがまだLinuxが公式サポート環境に入っていないので今回はナシである（たぶん問題なくMonoで動く範疇ではある）

最近のUbuntuでDiffImgをビルドする

2021-01-12T12:10:00+09:00

diffは大事。テキストでも画像でも。

OSS画像diffツールの昨今

OSSの画像diffツールとしてはDiffImgが有名。本家プロジェクトは昔懐かしSourceForge（以下SF）にホストされており、近年更新されていない。Ubuntu用のビルドはhttps://launchpad.net/~dhor/+archive/ubuntu/myway?field.series_filter=にあるが、16.04を最後にビルドされていない。このため、20.10（Groovy Gorilla）のような先鋭的Ubuntu環境においては自前でビルドする必要がある*1。

[*1] 先鋭的どころか、18.04（Bionic Beaver）や20.04（Focal Fossa）といった近年のLTS勢でも状況は同じはず

さて、ソースにバグフィックス類の手を加えてコツコツとメンテされているGitHub上のリポジトリが存在する（https://github.com/sandsmark/diffimg）ので、今回はこれを使う。

ビルド環境を整える

ビルドにあたり、依存関係を揃える。DiffImgはQtにがっつり依存しているため、Qtもろもろをインストールする。

$ sudo apt install libopencv-dev libfreeimage-dev qt5-default \
  libqwt-qt5-dev qt5-qmake qttools5-dev-tools

DiffImgのドキュメントにはlibqwt-devを入れろとあるが、Ubuntu 18.04あたりでパッケージの命名ルールが変わったようで、最新版には存在しない。このため、libqwt-qt5-devを指定するのがよい。これに気付かず、ソースからlibqwtをインストールして遠回りをした。

ソースコード取得・ビルド

$ git clone https://github.com/sandsmark/diffimg.git

forkのコード差分を信用すべきではないと考える（まったくもって正しい疑い方だと思う）場合はちゃんと差分を確認するか、SFのコードを拾ってきてほしい。

普段どおりのCMake作法でビルドする。今回はfork版（CMakeでビルドが通るように手を加えられている）を使っているのですんなり行ったけれど、fork版をメンテしているSF版ではすんなりいかないかもしれない。

$ mkdir build
$ cd build/
$ cmake ..
-- The CXX compiler identification is GNU 10.2.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Qwt: /usr/lib/libqwt-qt5.so (found version "6.1.4")
-- Configuring done
-- Generating done
-- Build files have been written to: /home/muo/workspace/diffimg/build
$ make -j
...
[100%] Built target diffimg

インストール

diffimgバイナリが生成されるので、そのまま使うなりsudo make installするなり好きにやる。うまくビルドできていれば、無事に画像diffをとれる（図1）。

$ diffimg i_183.png i_188.png

図1: DiffImgを実行したところ

これで、老眼入りつつある👀でもやっていける。

Amazon’s Choiceマーク付きのFullHD 60fps対応HDMIキャプチャデバイスが治安悪い

2021-01-12T12:10:00+09:00

ZoomやMeetでのリモート会議の場面が増える今日この頃。コンデジ（RX100M5）からPCにHDMI入力して映像を良い感じにするぞ！ということでUSB 3.0接続のHDMIキャプチャデバイスを購入しました。

Chilison HDMI キャプチャーボードゲームキャプチャー USB3.0 ビデオキャプチャカード 1080P60Hz ゲーム実況生配信、画面共有、録画、ライブ会議に適用小型軽量 Nintendo Switch、Xbox One、OBS Studio対応電源不要（アップグレードバージョン）という長い名前の品で、Amazon's Choiceマークつき2,400円ほどです。

図1: Chilison HDMI キャプチャーボード

しばらく前に1,000円未満で買えるお手軽HDMIキャプチャデバイスが流行りましたが、USB 3.0対応品もこれほど安くなったんですね。

商品説明には次の記載があります。

【1080P 60fpsに更新され】HD解像度ビデオ録画とストリーミングの高品質体験を保証するために、USB 3.0インターフェイスを採用し、1080p/60fpsの高品質で録画できます。最大入力解像度：3840x2160 @ 60Hz、最大出力/録画解像度：1920x1080 @ 60Hz。（ご注意：一部の説明書はまた更新されなかったですが、キャプチャーは全部更新済みました、ご不便をかけて申し訳ございませんでした。）

日本語が若干アレですが、ひとまず気にせずやっていきましょう。

そもそもUSB 3.0機器ではない

USB3. 0という名前のUSB 2.0機器

USBコネクタはUSB 3.0-Aに見えます。ちゃんと青いし、3.0の追加端子も見えます（図2）。

図2: USBコネクタ

しかし、lsusb（およびlsusb -t）の結果は次のとおりです。

Bus 006 Device 028: ID 534d:2109 MacroSilicon USB3. 0 capture
...
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
    |__ Port 2: Dev 28, If 1, Class=Video, Driver=uvcvideo, 480M
    |__ Port 2: Dev 28, If 4, Class=Human Interface Device, Driver=usbhid, 480M
    |__ Port 2: Dev 28, If 2, Class=Audio, Driver=snd-usb-audio, 480M
    |__ Port 2: Dev 28, If 0, Class=Video, Driver=uvcvideo, 480M
    |__ Port 2: Dev 28, If 3, Class=Audio, Driver=snd-usb-audio, 480M

初っ端からおかしいです。

残念なお知らせですが、私が買ったHDMIキャプチャデバイスはUSB 3.0対応機器ではなくUSB3. 0という名前のUSB 2.0機器です。親に向かってなんだそのUSB3. 0は、と突っ込みたくなるところですが、冷静に結果を受け止めましょう。

ちなみに、同じデバイスをUSB-Cハブ上のUSB 3.0ポートに挿した場合（カスケード状態）は

Bus 004 Device 026: ID 534d:2109 MacroSilicon USB 2.0 Hub

と出力されます。すわ返品か！？と噴き上がりそうになりますが、ぐっとこらえます。

PCのUSBポートは正常

のっけから結果にインパクトがありすぎて、PC側USBポートの不具合を疑いたくなるところです。なぜ過去の購入者が気付いていないのか、レビューは全部サクラだったのか、全く分かりませんが、ひとまずPC側が正常であることを最低限確認しておきます。まともなUSB 3.0対応UVCカメラの例として、手元にあったIntel RealSense SR300での出力例を示します。

Bus 007 Device 003: ID 8086:0aa5 Intel Corp.
...
/:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    |__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M
        |__ Port 1: Dev 3, If 0, Class=Video, Driver=uvcvideo, 5000M
        |__ Port 1: Dev 3, If 1, Class=Video, Driver=uvcvideo, 5000M
        |__ Port 1: Dev 3, If 2, Class=Video, Driver=uvcvideo, 5000M
        |__ Port 1: Dev 3, If 3, Class=Video, Driver=uvcvideo, 5000M
        |__ Port 1: Dev 3, If 4, Class=Vendor Specific Class, Driver=, 5000M

ちゃんとSuperSpeed対応であることがわかります。前述のUSB-Cハブ以下にぶら下げても同様の結果でした。

キャプチャ対応範囲の仕様を確認する

v4l2-ctlコマンドで調べた結果、キャプチャデバイスとしての仕様は次の通りです。

M-JPEG出力では1920x1080 60fpsまで対応
YUYV 4:2:2（YUV422）ベタ出力では720x480 30fpsまで対応（1920x1080時は5fpsまで）

詳しくは記事末尾の付録に記載したので、興味のある方は「UVCでの対応フォーマット一覧チェック」を参照してください。

動作テスト

今回はJavaScript動作のストップウォッチをPC画面に表示し、それをカメラで撮影してHDMIで取り込みます。PC画面が60fps表示されていることは、あらかじめカメラの録画映像およびスマフォのスローモーション撮影で確認済みです。

1920x1080 60fpsキャプチャできる…?

デバイスの主張を信じると、無圧縮YUV422はともかくM-JPEGなら1080p60を出せるはずです。実際にキャプチャしてみます。

$ ffmpeg -f v4l2 -input_format mjpeg -i /dev/video4 -c:v copy o.mkv

結果のフォーマットを確認すると、次の通りです。

Input #0, video4linux2,v4l2, from '/dev/video4':
  Duration: N/A, start: 210724.995835, bitrate: N/A
    Stream #0:0: Video: mjpeg (Baseline), yuvj422p(pc, bt470bg/unknown/unknown),
    1920x1080, 60 fps, 60 tbr, 1000k tbn, 1000k tbc

なんだ、ちゃんと1920x1080 60fpsと書いてありますね。

1920x1080 60fpsキャプチャできてる（できてない）

疑り深いので、キャプチャしたフレームをいくつか抜き出して確認します。

図3: RX100M5から取り込んだ映像の連続キャプチャ

…。

確かに秒間60枚キャプチャされていますが、同じ画像が2枚ずつ繰り返されています。つまり、実質30fpsのものをわざわざ容量割いて60fpsで記録している状態です。なんてこったい。

念のため、DiffImgで画像差分を確認します。

画像間に差分があれば、図4のように差分が表示されるはずです。

図4: 差分ありの場合の参考画像

結果は、図5のとおり差分なしでした。

図5: 重複フレーム間で画像差分なし

すわ返品か！？と噴き上がりそうになりますが、ぐっとこらえます。

1280x720であれば60fpsキャプチャできる

いろいろと試しているうちに、60fpsきっちり撮れるケースがあることに気付きました。具体的には、Zoomで映像プレビューをかけた後でキャプチャを実行すると、重複フレームのない60fps映像を撮れます。ただし、720p（1280x720）解像度です。

UVCドライバ/v4l2あたりにモード維持機能がある気配ですが、それはさておきキャプチャ時に映像サイズをhd720へ固定してやれば60fpsキャプチャが可能です。FFmpegの場合は次のように指定します。

$ ffmpeg -f v4l2 -framerate 60 -video_size hd720 -input_format mjpeg \
  -i /dev/video4 -c:v copy o.mkv

結果は図6のとおりです。フレーム重複のない、ちゃんとした60fps映像（ただし720p）であることがわかります。

図6: RX100M5から取り込んだ映像の連続キャプチャ（720p）

Chilison HDMI キャプチャーボードについて分かったこと

内部はUSB 2.0動作だが高級感あるUSB 3.0コネクタ（青い！）を使っている
M-JPEGフォーマット 1920x1080 60fpsを流せるがデータ重複のため実際は30fps
- M-JPEGフォーマット 1280x720 60fpsは問題なく流せる

雑に言えば、1,000円未満で売られている品と同等のものを2,500円で買えるというお得な商品です。

われわれ購買者が成熟しないと、いつまで経っても「デバイス名にUSB3. 0って書いてるしコネクタ青いからヨシ！」というアホなことが続くのですね。

ちなみに、製品のQ&Aには次の記載があります。

https://www.amazon.co.jp/ask/questions/Tx1CKNSSTETK4HT/

Q. 購入したら説明書にusb2.0hdmiビデオキャプチャーカードとなっていますけどusb3.0ではないのですか。A. 最近、当店のキャプチャーはUSB2.0をUSB3.0に変更中で、在庫のUSB2.0は全部売り切れないですから、USB2.0とUSB3.0の仕様が同時に販売しています。商品の説明は暫くUSB2.0に使用し、USB2.0の在庫売り切れる時、当店はすぐUSB3.0の説明を変更いたします。今後も、こんなの迷惑をお客様に与えられないように、持続的に改善します。

この返答後に商品ページが更新されており、私が購入した1/10時点で冒頭引用のUSB 3.0対応を謳う内容が掲載されていました。つまり、今回届いた品は購入時点の商品ページで説明されていた「USB 3.0インターフェイスを採用」という文言と一致しない、不良品ということになります。

それ以前の問題として、商品ページにキャプチャ対応仕様について次のように書かれています。

最大入力解像度：3840x2160 @ 60Hz、最大出力/録画解像度：1920x1080 @ 60Hz。（ご注意：商品は全部アップグレード済ましたが、説明書は次回在庫補充された後から全部更新済です。）

しかし、そもそも1080p 60fpsでキャプチャできていない（フレームが常に重複しており30fpsしか出ていない）ので、商品説明に書かれている性能を満足しない不良品と呼ぶしかありません。

すわ返品か！？

不良品を売り続けても条件さえ満たせばAmazon's Choiceマークを取得できるので、購入時にAmazon's Choiceマークは信用しちゃだめですよという話でした。

付録

MacroSilicon 2109?

Chilison HDMI キャプチャーボードは、どのようなコアモジュールを利用しているか公表していません。しかしVendor IDがMacroSilicon該当、Product IDが0x2109である点から安直に想像すると、1,000円未満で売られている超激安HDMIキャプチャデバイスの常連であるMacroSilicon製MS2109搭載機である可能性があります。

上限データレートを推測する

M-JPEGは圧縮度合いによって相当データ量が変わってくるので、YUV422（16bpp）出力の上限に注目します。720x480x30fpsということは、158.2MbpsがこのデバイスのUSB転送上限に近い値と考えてよさそうです。

lsusb -vでインタフェースディスクリプタを読むと

        dwMaxBitRate                196608000

と書かれており、187.5Mbpsがインタフェース上限なので、それなりに整合します。

UVCでの対応フォーマット一覧チェック

v4l2コマンド群で対応フォーマットを調べる手順をメモがてら残します。

$ v4l2-ctl --list-devices
Integrated Camera: Integrated C (usb-0000:05:00.0-2):
        /dev/video0
        /dev/video1
        /dev/video2
        /dev/video3

USB3. 0 capture: USB3. 0 captur (usb-0000:06:00.4-2):
        /dev/video4
        /dev/video5

※video[0-3]はノートPC内蔵のカメラです。

今回のキャプチャデバイスが持つのはvideo[4-5]だと分かるので、video4の対応フォーマットを調べてみます。

$ v4l2-ctl -d /dev/video4 --all
Driver Info:
        Driver name      : uvcvideo
        Card type        : USB3. 0 capture: USB3. 0 captur
        Bus info         : usb-0000:06:00.4-2
        Driver version   : 5.8.18
        Capabilities     : 0x84a00001
                Video Capture
                Metadata Capture
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps      : 0x04200001
                Video Capture
                Streaming
                Extended Pix Format
Priority: 2
Video input : 0 (Camera 1: ok)
Format Video Capture:
        Width/Height      : 1920/1080
        Pixel Format      : 'MJPG' (Motion-JPEG)
        Field             : None
        Bytes per Line    : 0
        Size Image        : 4147200
        Colorspace        : sRGB
        Transfer Function : Default (maps to sRGB)
        YCbCr/HSV Encoding: Default (maps to ITU-R 601)
        Quantization      : Default (maps to Full Range)
        Flags             :
Crop Capability Video Capture:
        Bounds      : Left 0, Top 0, Width 1920, Height 1080
        Default     : Left 0, Top 0, Width 1920, Height 1080
        Pixel Aspect: 1/1
Selection Video Capture: crop_default, Left 0, Top 0, Width 1920, Height 1080, Flags:
Selection Video Capture: crop_bounds, Left 0, Top 0, Width 1920, Height 1080, Flags:
Streaming Parameters Video Capture:
        Capabilities     : timeperframe
        Frames per second: 30.000 (30/1)
        Read buffers     : 0
                     brightness 0x00980900 (int)    : min=-128 max=127 step=1 default=-11 value=-11
                       contrast 0x00980901 (int)    : min=0 max=255 step=1 default=148 value=148
                     saturation 0x00980902 (int)    : min=0 max=255 step=1 default=180 value=180
                            hue 0x00980903 (int)    : min=-128 max=127 step=1 default=0 value=0

MJPEGで1920x1080の出力に対応していますが、30fpsとありますね。すわ返品か！？と噴き上がりそうになりますが、ぐっとこらえます。

対応フォーマット詳細を取得する--list-formats-extというオプションがあります*1。

[*1] https://leico.github.io/TechnicalNote/Linux/webcam-usageがとても役立ちました

$ v4l2-ctl -d /dev/video4 --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
        Type: Video Capture

        [0]: 'MJPG' (Motion-JPEG, compressed)
                Size: Discrete 1920x1080
                        Interval: Discrete 0.017s (60.000 fps)
                        Interval: Discrete 0.033s (30.000 fps)
                        Interval: Discrete 0.040s (25.000 fps)
                        Interval: Discrete 0.050s (20.000 fps)
                        Interval: Discrete 0.100s (10.000 fps)
                Size: Discrete 1600x1200
                        Interval: Discrete 0.017s (60.000 fps)
                        Interval: Discrete 0.033s (30.000 fps)
                        Interval: Discrete 0.040s (25.000 fps)
                        Interval: Discrete 0.050s (20.000 fps)
                        Interval: Discrete 0.100s (10.000 fps)
                Size: Discrete 1360x768
                        Interval: Discrete 0.017s (60.000 fps)
                        Interval: Discrete 0.033s (30.000 fps)
                        Interval: Discrete 0.040s (25.000 fps)
                        Interval: Discrete 0.050s (20.000 fps)
                        Interval: Discrete 0.100s (10.000 fps)
                Size: Discrete 1280x1024
                        Interval: Discrete 0.017s (60.000 fps)
                        Interval: Discrete 0.033s (30.000 fps)
                        Interval: Discrete 0.040s (25.000 fps)
                        Interval: Discrete 0.050s (20.000 fps)
                        Interval: Discrete 0.100s (10.000 fps)
                Size: Discrete 1280x960
                        Interval: Discrete 0.017s (60.000 fps)
                        Interval: Discrete 0.033s (30.000 fps)
                        Interval: Discrete 0.040s (25.000 fps)
                        Interval: Discrete 0.050s (20.000 fps)
                        Interval: Discrete 0.100s (10.000 fps)
                Size: Discrete 1280x720
                        Interval: Discrete 0.017s (60.000 fps)
                        Interval: Discrete 0.020s (50.000 fps)
                        Interval: Discrete 0.033s (30.000 fps)
                        Interval: Discrete 0.050s (20.000 fps)
                        Interval: Discrete 0.100s (10.000 fps)
                Size: Discrete 1024x768
                        Interval: Discrete 0.017s (60.000 fps)
                        Interval: Discrete 0.020s (50.000 fps)
                        Interval: Discrete 0.033s (30.000 fps)
                        Interval: Discrete 0.050s (20.000 fps)
                        Interval: Discrete 0.100s (10.000 fps)
                Size: Discrete 800x600
                        Interval: Discrete 0.017s (60.000 fps)
                        Interval: Discrete 0.020s (50.000 fps)
                        Interval: Discrete 0.033s (30.000 fps)
                        Interval: Discrete 0.050s (20.000 fps)
                        Interval: Discrete 0.100s (10.000 fps)
                Size: Discrete 720x576
                        Interval: Discrete 0.017s (60.000 fps)
                        Interval: Discrete 0.020s (50.000 fps)
                        Interval: Discrete 0.033s (30.000 fps)
                        Interval: Discrete 0.050s (20.000 fps)
                        Interval: Discrete 0.100s (10.000 fps)
                Size: Discrete 720x480
                        Interval: Discrete 0.017s (60.000 fps)
                        Interval: Discrete 0.020s (50.000 fps)
                        Interval: Discrete 0.033s (30.000 fps)
                        Interval: Discrete 0.050s (20.000 fps)
                        Interval: Discrete 0.100s (10.000 fps)
                Size: Discrete 640x480
                        Interval: Discrete 0.017s (60.000 fps)
                        Interval: Discrete 0.020s (50.000 fps)
                        Interval: Discrete 0.033s (30.000 fps)
                        Interval: Discrete 0.050s (20.000 fps)
                        Interval: Discrete 0.100s (10.000 fps)
        [1]: 'YUYV' (YUYV 4:2:2)
                Size: Discrete 1920x1080
                        Interval: Discrete 0.200s (5.000 fps)
                Size: Discrete 1600x1200
                        Interval: Discrete 0.200s (5.000 fps)
                Size: Discrete 1360x768
                        Interval: Discrete 0.125s (8.000 fps)
                Size: Discrete 1280x1024
                        Interval: Discrete 0.125s (8.000 fps)
                Size: Discrete 1280x960
                        Interval: Discrete 0.125s (8.000 fps)
                Size: Discrete 1280x720
                        Interval: Discrete 0.100s (10.000 fps)
                Size: Discrete 1024x768
                        Interval: Discrete 0.100s (10.000 fps)
                Size: Discrete 800x600
                        Interval: Discrete 0.050s (20.000 fps)
                        Interval: Discrete 0.100s (10.000 fps)
                        Interval: Discrete 0.200s (5.000 fps)
                Size: Discrete 720x576
                        Interval: Discrete 0.040s (25.000 fps)
                        Interval: Discrete 0.050s (20.000 fps)
                        Interval: Discrete 0.100s (10.000 fps)
                        Interval: Discrete 0.200s (5.000 fps)
                Size: Discrete 720x480
                        Interval: Discrete 0.033s (30.000 fps)
                        Interval: Discrete 0.050s (20.000 fps)
                        Interval: Discrete 0.100s (10.000 fps)
                        Interval: Discrete 0.200s (5.000 fps)
                Size: Discrete 640x480
                        Interval: Discrete 0.033s (30.000 fps)
                        Interval: Discrete 0.050s (20.000 fps)
                        Interval: Discrete 0.100s (10.000 fps)
                        Interval: Discrete 0.200s (5.000 fps)

長いのでまとめると、

M-JPEG出力では1920x1080 60fpsまで対応
YUYV（YUV2）ベタ出力では720x480 30fpsまで対応（1920x1080時は5fpsまで）

という結果です。

おまけ：連続画像のタイル化

本文中に掲載したような連続画像をタイルで敷き詰めたものは、ImageMagickに含まれるmontageコマンドで作るのが楽。

デフォでは余白が入りすぎるので、こういう感じ。

$ montage i_09[0-8].png -tile 3x3 -geometry +32+32 intermediate.png
$ convert intermediate.png -geometry 600x out.jpg

IPoEでネット帰宅難民になった / Rakuten Miniテザリング環境からフレッツひかりのIPoE環境へSSH/IPv6でインターネット帰宅する

2020-12-14T09:10:00+09:00

遅いネット回線でリモートワークするのは本当にしんどいです。速度改善の方法は色々ありますが、フレッツひかり回線における手軽な策として接続方式をPPPoEからIPoEへ切り替える手法が有名です。

実際、私の手元でもIPoE化によって夕方時間帯の転送速度改善に一定の効果が見られました。それと引き換えに、手持ち機材ではネット帰宅*1できなくなりました。

[*1] 出先からSSHやRDPで自宅内PCへアクセスすること

IPv4とv6とDS-Lite

フレッツひかりのIPoE接続はv6ネイティブです。家庭用ルーターとその下にぶら下がったデバイスはDHCPv6によって割り当てられたIPv6アドレスを使ってインターネットに出ていきます。逆に、そのままではIPv4のネットワークへ出られません。

このため、IPv4側は各種のv6移行技術を利用することになり、私が契約したISPではDS-Liteを利用します。DS-Liteは家庭のルーターとISP側の提供するDS-Liteゲートウェイ（AFTR）との間でIPv6上にv4のトンネルを掘り、そこにv4パケットを流す構造です。

図1: IPoE接続時のインターネットアクセス

そしてここが見落とされがちなのですが、あいにくグローバル側からv4へのインバウンドポートを固定する方法は提供されません。つまり、IPoE環境においてIPv4だけでは外出先から自宅内サーバーへリモートデスクトップでログインしたり、SSH経由でVSCodeのリモート編集をしたりといった現代における自然なインターネット呼吸ができません。

家庭内からインターネット上のホストへとVPN接続を張ることで、外部→内部の通信を受けることは可能ですが、せっかくIPv6アドレスが割り振られているのにそれを使わずトンネル用の外部サーバーを契約するのも癪なので、家庭に転がっている機材を利用してIPv6で家庭内サーバーへとSSHできるようにしてみます*2。

[*2] 自宅内のサーバーへSSHでログインしたら後はなんでも出来るので、ここをゴールとしました

2020年も終わろうとしているのだし、さらっとend-to-endでIPv6経由のインターネット帰宅セットを組めるだろうと実験を始めたら、想像以上にサーバー・クライアント両面でハードルがあったので、それぞれ整理してみました。

元々のネットワーク構成

今回の対応をおこなう前の段階で、自宅のネットワーク機器と用途は次の通りでした。

Google Nest Wi-Fi（家庭内通信用）
TP-Link Archer A6（IPoEルーター用）

図2: ネット帰宅できない状態の構成

PCやスマフォはGoogle Nest Wi-Fiが噴いているアクセスポイントに接続する構造です。

自宅ゲートウェイをOpenWrtで作る

さらばArcher A6（のルーター機能）

今回、IPoE対応でそれなりのスループットが出るルーターとしてTP-Linkの激安Wi-FiルーターArcher A6を購入したのですが、この機材ではどう設定してもIPv6でぶら下がっているホストへのインバウンド通信を通せませんでした。一時期騒がれたNTT本家のひかり電話対応ホームゲートウェイのようなフレッツ網内からインバウンド通信を素通しするマズい状態を回避できるのは嬉しいのですが、ポリシーがちょっと厳しすぎます。Archer A6はDS-Liteを有効にした状態ではND-Proxy（おそらくパケットフィルタの意を含む）が基本的にONでパススルー設定にできず、ND-Proxyをうまいことオフにしつつ手元機材がIPv6アドレスを取れる状態に持っていけないかと試行錯誤しましたがv6力の低さゆえうまくいきませんでした*3。このため、Archer A6のルーター機能は使わないことにしました。

[*3] WAN側からのpingを拒否しても普通にpingは素通しし続けるとか怪しい挙動をするので、ファームウェアの作り込みが甘いのかもしれません。エミュレータを見る限りだとEU版ならワンチャンありそうな気もするけれどJP版はメニュー少ないし謎

ルーターのファームウェアを書き換えることで、求める機能を実現できる可能性はありますが、残念ながらArcher A6の日本版ハード（TP-Link製品は販売地域ごとにハードウェア仕様もファームウェアも異なったりします。無線レギュレーション差を考えると当然といえば当然ですが）のソースコードは本稿執筆時点で未公開でした（図3）*4。

図3: TP-Link社のGPLコードセンターには日本版Archer A6のコード公開なし

[*4] https://www.tp-link.com/jp/support/gpl-code/

念のためTP-Link社へコード開示リクエストを出したうえで、こいつのルーター機能については一旦忘れておきます。代わりに、別途構築するルーターの下にぶら下げてスイッチングハブ兼有線/無線変換器として利用します。

ルーター機能を使わないということはIPoE接続とLAN内へのアドレス配布を担うサーバーが別途必要になりました。

おはようRaspberry Pi 2

Archer A6の標準ファームウェアでは不可能な細かい設定をするために、多くの家庭に数枚は余っていると思われるRaspberry PiシリーズにOpenWrtをインストールします。手元では、ちょうど余っていたRaspberry Pi 2を利用しました。Ethernetが1ポートしかないのでUSB Ethernetアダプタを増設しましたが、USB 2.0のバスにもろもろがぶら下がることになるので、ネットワーク速度はそれなりに制限され、実測値で上下ともに80Mbps程度でした。

Archer A6では300-700Mbps出るので、かなり遅いといえますが、Raspberry Pi 2はあくまでもコンフィグ確認用の機材なので一旦気にしないことにします。

OpenWrtをインストールし、DHCPv6でアドレスを取れたらOpenWrtのリポジトリ（ここがv4-onlyだと詰むところですがv6対応で本当にありがたい）からdsliteパッケージをインストールしてDS-Lite設定をしたり、LuCIをインストールしたりと、割とありがちな環境構築をしていくと、v4/v6でインターネットへ出られる環境が整います。

/64環境と相性最悪なGoogle Nest Wi-Fi

詳しくは別の機会にしますが、今回は宅内のWi-FiルーターにGoogle Nest Wi-Fiを使いたいという事情がありました。この機材自体はIPoE非対応ながら、IPv4/v6デュアルスタックなネットワークにぶら下げることでv6機能が有効化されるという仕様なのですが、OpenWrt側でデュアルスタック化して通常のLinuxマシンからv4/v6のアドレスが共に取得出来る状態になっても「ISPがv6非対応」という非情なメッセージを吐いてv6非対応モードから動いてくれません。

どうもISP側で割り当てられるアドレスが/56の場合*5にはv6対応モードで動作するようなのですが、ひかり電話絶対契約したくない呪いを受けた人間としてはこれを自然に達成することは不可能です。

[*5] ひかり電話を契約するとDHCPv6で/56のアドレスが降ってくることになっています

次善の策としては、OpenWrt側でNAT6設定をしてデカいアドレス空間を見せてやることになります。しかしOpenWrtのNAT6チュートリアルを読みつつ設定を流し込んでみた限りではうまくアドレスを配布出来なかったので、結構厄介そうだなーと一旦投げました。さらに、NAT6ではどのみち家庭内サーバーへのアクセスに際してポートフォワードが必要です。

結局Google Nest Wi-FiはIPv4で動作させ、家庭内ネットワークは原則v4とする方針でほとんど問題ないのでは、と考えました。

OpenWrtのグローバル側ポート開放

前述のとおり、IPoE接続のフレッツひかりにおいてインバウンドを受けられるのはIPv6のみです。いっぽう、Google Nest Wi-Fiの制限のため家庭内の端末はIPv4となってしまいました。

このため、どうにかしてOpenWrtでIPv6を受けて、家庭内へと転送することにします。

図4: OpenWrtのグローバル側ポート開放

まずはデフォルトで著しく開放度の低いファイアウォール設定を変更し、グローバル側でSSH用に使うポート（今回は2022としました）を通せるように/etc/config/firewallへ次の内容を追記します。

config rule
        option name 'inssh'
        option target 'ACCEPT'
        option proto 'tcp'
        option dest_port '2022'
        option src 'wan'

もちろん、LuCIで同等の変更をしてもOKです。

OpenWrtでのポート転送・tcpproxy経由Google Nest Wi-Fiへの通信路確保

続いて、OpenWrtが動作しているルーター機（Raspberry Pi 2）にて、IPv6で受けた通信をIPv4へと翻訳してGoogle Nest Wi-Fiへとポート転送する必要があります。

図5: OpenWrt上でv6→v4転送

プロキシサーバー設定により、Google Nest Wi-Fiの特定ポートまでパケットが届くことになります。

おそらくマイナーなパッケージだと思いますが、OpenWrtのリポジトリにtcpproxyというIPv6対応のTCPプロキシがあるので、これを利用します。/etc/config/tcpproxyを開き、サンプル記述を参考に設定を書きます。

config tcpproxy
  option username 'nobody'
  option groupname 'nogroup'

config listen
  option local_port '2022'
  option remote_addr '192.168.1.100'
  option remote_port '3022'

local_portはOpenWrtがグローバル側から着信させたいポート、remote_addrはGoogle Nest Wi-FiのWAN側アドレス（これはOpenWrtの設定でDHCPの固定割り当てをしておきましょう）を指定します。remote_portは、Google Nest Wi-Fiから自宅内サーバーのSSHポートへとフォワードされる予定のポート（Google Wifiアプリで設定します）を指定します。ややこしいですね。

そして、tcpproxyデーモンの起動タイミングがデフォルトでは早すぎて正常に起動しないので、だいぶ後のほうへと変更します。

# cd /etc/rc.d
# mv S50tcpproxy S97tcpproxy

再起動すれば、tcpproxyデーモンが起動してくることを確認できるはずです。

Google WifiアプリでGoogle Nest Wi-Fi→自宅サーバーのポートフォワード設定をするのも忘れずに。ここまで一通り設定できたら、当該ポートを経由して自宅サーバーへとSSHアクセスできることも確認しておきましょう。

設定のバックアップと書き戻し

デーモン起動タイミングの変更に関連し、LuCIのインタフェースから「設定のバックアップ」を実行して得られる.tar.gzファイル内について注意が必要です。このファイル内にパッケージ情報は残りますがrc.d以下の情報は失われてしまうので、他のルーター機へ設定を持っていく際には書き戻しついでに再度起動順の調整が必要そうです。

カメ専用Wi-Fiアクセスポイント

宅内を全部IPv4へ寄せた結果、もう2020年が終わるというのに静止画カメしか見れないなんて・・・、と辛い気持ちになったので、前述の激安ルーターArcher A6をブリッジモードへ落としてRaspberry Pi 2のLAN側インタフェース直下に配置しました。

図6: カメ専用Wi-Fiアクセスポイント

このアクセスポイントへ接続すればさらっとDHCP/DHCPv6でアドレスを取得でき、カメが動いてくれます*6。かわいいね。

[*6] http://www.kame.net/

前述のGoogle Nest Wi-Fiは、このArcher A6の有線ポートへぶら下がる構造です*7。もちろん、カメが動くのを見る以外に一般のIPv6ネットワークへ出ていくことも出来るので、「あ〜〜〜、なんか今日はIPv4で仕事したくないな！」とIPv4では気分が乗らない日には切り替えて使えます。この環境からはGoogle Nest Wi-Fiでポート転送しているSSHサーバー経由でないと自宅内の他の端末と通信できないので、気分は宅外作業です。

[*7] Google Nest Wi-FiをRaspberry Pi 2の直下にぶら下げたほうが速度面で無駄がなくて良いのでは、と感じるところですが、ただでさえUSB-Ethernetを無理やり増設してWAN/LANポートを確保した状態なので、これ以上Raspberry Pi 2側にポートを生やしたくありませんでした。スイッチを足すならブリッジモードのルータを置いても同じことなので、ここにArcher A6を挟めば一石二鳥という寸法です

Rakuten MiniテザリングでIPv6環境へSSH

楽天モバイルの4G回線はIPv4/v6のデュアルスタックです。このため、ConnectBotのようなアプリを利用すれば前述の環境へとすんなりSSH接続できます。

同様に、Rakuten Miniをテザリング端末としてLinux PCから自宅マシンへのSSHも簡単にできそうな気がします。しかし残念ながら、Rakuten Miniのテザリング環境はIPv4-onlyです（図7）。

図7: Rakuten MiniのWi-Fiテザリング下のPCに割り当てられたアドレス

Androidにおいて、テザリングがIPv6対応か否かはAndroid OS側で規定されておらず端末ベンダー裁量なので、このようなことが起こります*8。

[*8] 4年前にIIJの大内さんが調査されたデータが公開されています。SIMロックフリー端末なら対応、ただしDNSサーバーアドレスが取れない場合あり、など。 https://www.slideshare.net/IIJ_techlog/iijmio-meeting-10-57396555

外出先のPCはIPv4を使いつつ、GCPの実質無料インスタンスを中継してv6アクセス、という方法も考えましたが、残念ながらGCPにおいてv6終端は提供されているものの、Compute Engineからv6インターネットへ出ていくことは出来ませんでした。このため、帰宅ルート確保のためにAndroid端末上でプロキシサーバーを動作させ、Linux PCからはそのプロキシ経由でIPv6の世界へアクセスすることにしました。

Servers Ultimate

Android界にはServers Ultimateという、HTTPサーバーどころかLAMP丸ごとAndroid端末上に立てることすら可能な万能サーバーアプリという狂ったものが存在します。いろいろ試したところ、このアプリでRakuten Mini上にプロキシサーバーを用意する方法が簡単で安定性も高かったので紹介します*9。

Ultimateを謳うだけあって、Servers Ultimateには当然の如くプロキシサーバー機能も含まれています。なんと2つも。

このうちHTTP Proxy Server（図8）は、端末ローカルポートを特定のHTTPサーバー/ポートの組へと転送する、HTTP限定のLocalForwardのようなものです。

図8: HTTP Proxy Server

IPv6テザリングに必要なのはこれではなく、Proxy Server（図9）です。

図9: Proxy Server

[*9] 当初、NetShareというAndroid端末をWi-Fiホットスポット化するアプリに組み込まれているプロキシサーバーの利用を試みましたが、WebブラウザでのIPv6サイト表示は出来るもののSSHへのプロキシアクセスがうまく動作しませんでした。connect-proxyのデバッグ出力を確認する限りでは、送出しているHTTP/1.0のリクエストにNetShare組み込みプロキシサーバーが非対応なのかもしれません

ポートを適当に指定してサーバーを起動します。

あとはこのプロキシを利用してconnect-proxyでSSH接続すれば良いのですが、ひとつ考慮漏れがあります。テザリング環境という事情から、このプロキシはLinux PCから見たゲートウェイ上で動作することになりますが、

Wi-Fiテザリング時、テザリングホスト（Rakuten Mini）側のIPアドレスが固定されない
Wi-FiテザリングとBluetoothテザリングでゲートウェイアドレス帯が異なる

という挙動をします。手元で確認した限り、Bluetoothテザリング時のRakuten Mini側IPアドレスは192.168.44.1に固定されますが、Wi-Fi時には192.168.43.0/24のどこかを適当に確保するようでした。

こうなると、connectコマンド側のパラメータを固定せず、SSHログイン実行時のネットワーク状態にあわせてゲートウェイアドレスを指定するのが無難でしょう。具体的には、ip routeコマンドの出力をフィルタしてデフォルトゲートウェイアドレスを取得します。

$ ip route | grep default | cut --delim=' ' -f3
192.168.43.68

こんな感じですね。この内容を盛り込んだSSHホスト定義を~/.ssh/configに追記すると、

Host nanopi-remote-gw-proxy
  HostName [2xxx::xxxx]
  Port 2022
  ProxyCommand connect -H `ip route | grep default | cut --delim=' ' -f3`:[Servers Ultimateのプロキシポート] %h %p

無事

図10: Rakuten Miniテザリングで自宅IPoEへIPv6 SSH

インターネット帰宅できます。

Bluetoothテザリングのススメ

Rakuten MiniやJelly Proのような小型テザリング端末を使う場合、私はWi-Fiよりも圧倒的にバッテリー持ちのよいBluetoothテザリングを好んで使っています。バッテリー容量の少ない端末でWi-FiテザリングをONにすると3-4時間で電源が切れるというシビれる状態に陥りますが、Bluetoothテザリングなら7-8時間は問題なく使えます。通信速度は数百kbps出ればよいほうですが、ターミナル作業やGoogle Mapsの経路検索ぐらいなら十分快適に利用できます。

テザリングで端末がぶら下がっていない状態なら普通に3-4日間バッテリーが保ったりします（図11）。

図11: テザリング待ち受け状態で25時間経過時点