AIで日常のちょっとした不便を解消する
2.4GHz帯のWi-Fiアクセスポイントが、もう1台欲しくなった。中古なら2000円も出せば買える。でも手元には、使っていないNanoPi NEO2と、正体不明のBUFFALO製USB Wi-Fi子機があった。
そこで、この余り物2つをCodexに渡してAPを作らせてみた。1回目はbridge設定でSSHを自ら切断してNanoPiが行方不明になり、Armbianを再インストール。失敗内容をそのまま2回目のプロンプトへ反映したら、今度は無事完成した。
できあがったのは、2.4GHz・SSID×2・WPA2・既存LANへのブリッジAP。microSDへの書き込みも抑え、再起動後も自動復帰する。そして消費電力は、ワットチェッカー読みで3Wだった。
つまり今回の話は、「買えば2000円で済むものを、家に余っていた極小SBCと古いUSB子機で作り、面倒なLinux設定はAIにやらせた」というだけである。こういう小さな不便を、AIで潰していくのが最近かなり楽しい。
主役は、かなり貧弱なNanoPi NEO2
今回使ったNanoPi NEO2は、今見るとなかなか潔いスペックである。CPUはAllwinner H5、Cortex-A53の4コア、メモリは512MB、ストレージはmicroSD。Wi-Fiなし、HDMIなし、それでもGigabit Ethernetは付いている。
メモリ512MBというと、最近のPCならブラウザが朝食に食べるくらいの量である。Windows 11を入れようものなら、NanoPi側から「話を聞いていましたか」と問い返されそうだ。
でもアクセスポイントなら話は別。やることは、だいたい有線から来たパケットを無線へ流すことである。生成AIも動画編集もExcelもいらないので、こういう貧弱な機械が急に適材適所になる。
もう一つの材料は、正体不明のBUFFALO子機
引き出しから出てきたのは、小さなBUFFALOのUSB Wi-Fi子機。型番は覚えていないし、いつ買ったのかも分からない。2.4GHz専用だった気がする、くらいの記憶しかない。
今回はそこもCodexに調べさせた。USB IDから判明した正体は、
BUFFALO WLI-UC-GNM2
USB ID: 0411:01ee
Ralink RT3070
だった。Linuxではカーネル標準の rt2800usb で動作し、外部ドライバもDKMSも不要。
さらに調査させると、AP mode、AP/VLAN、HT20、複数BSSにも対応していた。古いUSB子機だけど、今回の2.4GHz AP用途にはかなり当たりだった。
まずArmbianを入れて、Codexに渡す
NanoPi NEO2にはArmbianを入れた。今回の環境はDebian 13 Trixie、Kernel 6.18系。管理用IPは 192.168.0.45 にした。
あとは codex ユーザーを作り、パッケージ導入、systemd、ネットワーク、hostapdなど今回必要な範囲をsudoで操作できるようにする。人間側の準備はここまで。
そしてCodexへ、USB子機の調査からAP構築、microSD書き込み対策、再起動試験まで全部やるよう依頼した。
1回目、橋を架け替えていたら橋がなくなった
CodexはUSB子機の正体、ドライバ、AP能力までは順調に調査した。次にEthernetとWi-Fiを同じLANへ流すため、br0 というLinux bridgeを構築し始めた。
最初はWi-Fiをnetplanから直接bridgeへ入れようとして、
Device does not allow enslaving to a bridge.
Operation not supported
と失敗。Codexは、Wi-FiをhostapdでAP modeにした後、hostapd側の bridge=br0 で参加させるべきだと原因を突き止めた。
そこでネットワーク設定を修正して再適用したら、今度はSSHが切れた。そして戻ってこない。
PING 192.168.0.45
100% packet loss
自分が立っている橋を架け替えていたら、その橋がなくなった。
NanoPi NEO2にはHDMIがなく、UARTもつないでいなかったので遠隔復旧不能。約13分の作業で、無線部分の調査には成功し、NanoPi本体は行方不明になった。
2回目は「必ず帰ってこられる」ようにした
microSDへArmbianを焼き直し、もう一度同じ環境を作った。ただし1回目で、USB子機やドライバについてはほぼ全部分かっている。
そこで2回目のプロンプトでは、ネットワーク変更前に数分後に旧設定へ自動復帰するロールバックを仕込ませた。bridge化した後、SSHが復帰したことを確認するまでは安全装置を解除しない。
さらに工程も分割した。まず end0 だけを br0 に入れて管理IP 192.168.0.45 が維持できることを確認し、その後にhostapdでWi-Fiを追加する。
今度は成功した。
完成した構成
最終的にはこうなった。
既存LAN
|
end0
|
br0
|
+-- NanoPi NEO2
| 192.168.0.45
|
+-- WLI-UC-GNM2
|
+-- SSID 1
+-- SSID 2
end0 もWi-Fiも br0 上でforwarding。NATもNanoPi側DHCPサーバも使わず、家の既存LANをそのままWi-Fi側へ延長している。
1本のRT3070から、同一チャンネル上でSSIDを2本出すこともできた。2.4GHz、20MHz幅、WPA2-PSK、CCMPという、ごく普通のAPである。
普通に動く。これが一番偉い。
設定変更は1ファイルだけ
SSIDやパスワードを変更するたびにhostapdの設定を直接触るのは面倒なので、人間用の設定ファイルを1個だけ作らせた。
/etc/ap-config.conf
変更するときは、
sudo nano /etc/ap-config.conf
保存後、
sudo systemctl restart ap-hostapd
で反映する。半年後に細かい構成を全部忘れても、ここだけ覚えておけばよい。
microSDには、なるべく静かに暮らしてもらう
24時間動かすSBCなので、microSDへの無意味な書き込みも減らした。/tmp と /var/tmp はtmpfs、/var/log はzram、swapもzram。
root filesystemは noatime にし、journaldも永続保存せず /run 上で動かす。ログ上限も16MBにした。
APが正常に動いているなら、昨日の午前3時17分のhostapdログを一生保存しておく理由は特にない。消えてよし。
ちゃんとIoT機器が集まってきた
Linux APなので、iw station dump を使えば接続中のMACアドレス、信号強度、通信速度、接続時間なども見える。
実際に接続してきたMACを調べると、BroadLink系、Espressif系、Amazon系などだった。ほぼIoT機器である。
2.4GHz専用APを作ったら、2.4GHzが好きそうな住民が自然に集まってきた。IoT団地、無事入居開始。
消費電力は3W
最後に今回いちばん重要な消費電力を測った。手元のワットチェッカーは小数点以下が出ないけれど、表示は3W。
NanoPi NEO2本体、USB Wi-Fi子機、Gigabit Ethernet、SSID×2まで全部込み。メモリ512MB、Wi-Fiなし、映像出力なしという貧弱さが、ここではむしろ効いてくる。
年間消費電力量は単純計算で約26kWh。しかも今回は本体もUSB子機も手元に余っていたので、追加購入費はゼロだった。
買えば済む。でも、それでは拾えないものがある
もちろん、中古APを2000円で買えばもっと早い。それは最初から分かっている。
でも家には、性能が低すぎて主役にはなれないSBCや、いつ買ったか分からないUSB子機がいくつも眠っている。そういう物を「これ、何かに使えないかな」と眺めて、面倒な調査と設定だけAIへ押し付ける。
今回、人間が決めたのは**「2.4GHzの省電力APが欲しい」**ということだけ。Codexは実機を調べ、一度失敗し、その失敗内容を二度目の構築へ反映して、最終的には実用品まで持っていった。
AIで日常のちょっとした不便を解消する。今回は、引き出しの余り物2個が、3Wで24時間働くWi-Fiアクセスポイントになった。
木材が余ったら棚を作る。NanoPiが余ったらAPを作る。最近は、日曜大工の材料にコンピューターも入るらしい。
