LinuxのNetworkManagerでWi-FiのAPを切り替え

PCのLinuxは仮にリモート操作で何かやらかしてもモニターを見ながらキーボード・マウスでローカル操作することで大抵は解決できる。
シングルボードコンピュータの場合はそもそもモニターを接続できないのも多いので、リモート操作でネットワークの設定をやらかすなどするとシリアル接続にするかストレージになってるmicroSDカードを抜いてPCにつないで直接書き換えるかなどしないといけないことがある。しかし、最近のLinuxではNetworkManagerで設定するようになってる、USB OTGでシリアル接続できない、microSDをPCにつないでも直接触れないとかいろいろ解決が面倒な場合がある。各種シングルボード用にDebian, Ubuntuを提供しているarmbianでは簡易設定用にarmbian-configなるツールが提供されているのだが、Wi-Fiの設定について言えばarmbian-configは中途半端すぎて使い物にならない。同じLANにある別のSSIDのAPに切り替えたいという至極単純な欲求があったとしてもそれすら満足に叶えてくれない。
そこで、今回はNetworkManagerで別のAPに接続替えを行うという簡単なことのメモ。

やりたいこと: Wi-Fi接続中のLinuxコンピュータをリモートから別のAPに切り替える(NetworkManagerで)

$ nmcli device wifi list
IN-USE  SSID     MODE   CHAN  RATE        SIGNAL  BARS      SECURITY  
*       old-ap   Infra  1     130 Mbit/s  62      ▂▄▆__  WPA1 WPA2 
        new-ap   Infra  1     270 Mbit/s  100     ▂▄▆█  WPA1 WPA2 

まず、周囲で動いている (電波を出している) APのリストを表示する。
SSIDがold-apの方が現在使用しているAPで、new-apはこれから使いたいAP。

$ sudo nmcli device wifi connect new-ap password new-apのpsk
Error: Connection activation failed: (7) Secrets were required, but not provided.
エラーにはなってるけど、これでnew-apのAP情報(プロファイル)自体は登録出来ている。DHCPクライアント用ならプロファイルはこれだけでいい。
このコマンドだとプロファイルのconnection.idとssidが同じになる筈なので扱いやすい。
$ nmcli connection show
NAME                UUID                                  TYPE      DEVICE 
old-ap              e8937948-72fd-414e-91c3-e60c72c3bb55  wifi      wlan0  
new-ap              5d3719fc-f59c-4a09-93a9-5e89bbe72432  wifi      --     
Wired connection 1  2ab1b4e8-2763-376c-84cd-008007b62597  ethernet  --     
old-apとnew-apの両方が登録されていて、old-apがwlan0で使われていて、new-apが使われていないことが判る。
$ sudo nmcli c down old-ap && sudo nmcli c up new-ap && nmcli c s
Connection 'old-ap' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/4)
NAME                UUID                                  TYPE      DEVICE 
new-ap              5d3719fc-f59c-4a09-93a9-5e89bbe72432  wifi      wlan0  
old-ap              e8937948-72fd-414e-91c3-e60c72c3bb55  wifi      --     
Wired connection 1  2ab1b4e8-2763-376c-84cd-008007b62597  ethernet  --     
nmcli cのcはconnectionの省略形。今回は長くならないように省略形で書いた。showもsに省略できる。
ここで、old-apとの接続をダウンさせてnew-apとの接続をアップさせるコマンドを連続する形で実行する。old-apとの接続をダウンだけを実行してしまうとその時点でお手上げになることがある。電源ブッチで再度システムを起動すればold-ap(またはnew-ap)との接続が行われるとは思うけどあまり良くない。
$ sudo nmcli connection delete id old-ap
Connection 'old-ap' (e8937948-72fd-414e-91c3-e60c72c3bb55) successfully deleted.
old-apのプロファイルを削除する。
$ nmcli connection show
NAME                UUID                                  TYPE      DEVICE 
new-ap              5d3719fc-f59c-4a09-93a9-5e89bbe72432  wifi      wlan0  
Wired connection 1  2ab1b4e8-2763-376c-84cd-008007b62597  ethernet  --

new-apの登録だけになっている筈。動作としては確実なので接続したいAPのプロファイルだけ登録した状態にするのがオススメ。

$ sudo nmcli connection modify new-ap connection.autoconnect no
または
$ sudo nmcli connection modify new-ap connection.autoconnect yes
登録済みのプロファイルは1つだけにするのがオススメとは書いたが、そうはできないこともある。
オートコネクトをyesにすると次回のシステム起動時などに自動的にそのAPに接続する。自動接続して欲しくないAPのプロファイルはオートコネクトをnoにしておく。
$ nmcli -p connection show new-ap
===============================================================================
                     Connection profile details (new-ap)
===============================================================================
connection.id:                          new-ap
connection.uuid:                        5d3719fc-f59c-4a09-93a9-5e89bbe72432
connection.stable-id:                   --
connection.type:                        802-11-wireless
connection.interface-name:              --
connection.autoconnect:                 yes
connection.autoconnect-priority:        0
connection.autoconnect-retries:         -1 (default)
connection.multi-connect:               0 (default)
connection.auth-retries:                -1
connection.timestamp:                   1597841023
connection.read-only:                   no
connection.permissions:                 --
connection.zone:                        --
connection.master:                      --
connection.slave-type:                  --
connection.autoconnect-slaves:          -1 (default)
connection.secondaries:                 --
connection.gateway-ping-timeout:        0
connection.metered:                     unknown
connection.lldp:                        default
connection.mdns:                        -1 (default)
connection.llmnr:                       -1 (default)
-------------------------------------------------------------------------------
802-11-wireless.ssid:                   new-ap
802-11-wireless.mode:                   infrastructure
802-11-wireless.band:                   --
802-11-wireless.channel:                0
802-11-wireless.bssid:                  --
802-11-wireless.rate:                   0
802-11-wireless.tx-power:               0
後略 (結構大量に表示される)
connection.autoconnectが指定した値 yes or no になっていることを確認する。(上の例ではyes)

簡単だけど意外と面倒。

NanoPi NEO3冷却力強化後のUnixBench

NanoPi NEO3のSoCの冷却力を高めたのでこれで全力で動いても大丈夫になった筈。
これまで2回計測したUnixBenchではガッカリな結果だったが・・・

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.3)

   System: nanopineo3: GNU/Linux
   OS: GNU/Linux -- 5.7.10-rockchip64 -- #trunk SMP PREEMPT Mon Jul 27 22:40:16 JST 2020
   Machine: aarch64 (unknown)
   Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
   11:00:01 up 2 days, 23:00,  1 user,  load average: 0.22, 0.53, 0.37; runlevel 5

------------------------------------------------------------------------
Benchmark Run: 金  8月 14 2020 11:00:01 - 11:28:46
0 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables        7656264.5 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     1765.9 MWIPS (9.8 s, 7 samples)
Execl Throughput                                870.2 lps   (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        140216.0 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           39513.3 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        392950.9 KBps  (30.0 s, 2 samples)
Pipe Throughput                              285418.7 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  50954.1 lps   (10.0 s, 7 samples)
Process Creation                               1769.8 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   2341.6 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    608.9 lpm   (60.0 s, 2 samples)
System Call Overhead                         466137.3 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0    7656264.5    656.1
Double-Precision Whetstone                       55.0       1765.9    321.1
Execl Throughput                                 43.0        870.2    202.4
File Copy 1024 bufsize 2000 maxblocks          3960.0     140216.0    354.1
File Copy 256 bufsize 500 maxblocks            1655.0      39513.3    238.8
File Copy 4096 bufsize 8000 maxblocks          5800.0     392950.9    677.5
Pipe Throughput                               12440.0     285418.7    229.4
Pipe-based Context Switching                   4000.0      50954.1    127.4
Process Creation                                126.0       1769.8    140.5
Shell Scripts (1 concurrent)                     42.4       2341.6    552.3
Shell Scripts (8 concurrent)                      6.0        608.9   1014.9
System Call Overhead                          15000.0     466137.3    310.8
                                                                   ========
System Benchmarks Index Score                                         331.3

------------------------------------------------------------------------
Benchmark Run: 金  8月 14 2020 11:28:46 - 11:57:58
0 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables       30564936.4 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     7065.3 MWIPS (9.8 s, 7 samples)
Execl Throughput                               2497.8 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        242698.9 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           65123.7 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        730181.3 KBps  (30.0 s, 2 samples)
Pipe Throughput                             1133962.0 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 165331.0 lps   (10.0 s, 7 samples)
Process Creation                               4611.3 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   4812.3 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    629.3 lpm   (60.2 s, 2 samples)
System Call Overhead                        1818031.4 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   30564936.4   2619.1
Double-Precision Whetstone                       55.0       7065.3   1284.6
Execl Throughput                                 43.0       2497.8    580.9
File Copy 1024 bufsize 2000 maxblocks          3960.0     242698.9    612.9
File Copy 256 bufsize 500 maxblocks            1655.0      65123.7    393.5
File Copy 4096 bufsize 8000 maxblocks          5800.0     730181.3   1258.9
Pipe Throughput                               12440.0    1133962.0    911.5
Pipe-based Context Switching                   4000.0     165331.0    413.3
Process Creation                                126.0       4611.3    366.0
Shell Scripts (1 concurrent)                     42.4       4812.3   1135.0
Shell Scripts (8 concurrent)                      6.0        629.3   1048.9
System Call Overhead                          15000.0    1818031.4   1212.0
                                                                   ========
System Benchmarks Index Score                                         836.9

UnixBenchを走らせる前にCPUのクロックは1.5GHz固定にした。(終了後もそのまま1.5GHz)

インデックスのスコア(黄字)を見ると、シングルで前回の1.1倍、4パラレルで1.4倍。前回は特に4パラレルで異常にスコアが悪かったのでこれで正常感が強い。前回はNanoPi NEO3標準ヒートシンクで放熱ができてなくて、おそらくリミッターがかかる直前ぎりぎりの温度でUnixBenchを走らせ始めてて、そこから僅かに温度が上がったところでクロックが落とされていたということかしら。

CPUクロック変更

/etc/default/cpufrequtils (変更部分)
1
2
MAX_SPEED=1512000
GOVERNOR=performance
クロック上限を1.5GHzに指定してガバナーをパフォーマンス(上限側で固定)にした。
$ sudo systemctl restart cpufrequtils
cpufrequtilsサービスを再起動すると1.5GHz固定になる。(システム起動時などは一時的に他のクロックが使われることがある)

CPU温度推移

温度推移
10:50にCPUクロックを1GHzから1.5GHzに変更。11:00から12:00までUnixBenchが動いている。毎日8:00から16:00にかけて温度の上昇局面なのでそれを考慮するとクロック変更後は5℃ほど温度が上昇している感じ。UnixBench中は急上昇しているがそれでも突出したときで70℃程度なので冷却力を高める前の1.5GHzのアイドル時より良好。冷却が効いているなら負荷が高いとき以外は意外と温度は大きく上がらないといえる。NanoPi NEO3標準のちっちゃいヒートシンク使用時は冷却力がきびしくて負荷が小さくて(アイドルで)もクロックの違いで温度が大きく変わるみたい。

関連記事:

蛍光灯焦げる、そして毒ガス

脱衣室兼洗面所で服を脱いで隣りにある風呂に入っていたら、風呂の扉越しに洗面所の鏡のランプがピカピカ数回点滅したかと思ったら突然少し暗くなった。そして、1分もせずに、風呂の扉を締めているにも関わらず何かが焼け焦げた臭いともう一つ別種類のなんともいえないイヤな臭い。風呂から出るために扉を開けるとさらに強烈に臭う。洗面所の鏡のランプが2つある内の1つが切れていた。密閉の照明ケースでなくてカバーが帯のようになって上下が開放の照明なのでどんなランプが使われているのかは下から丸見えのもの。スパイラル蛍光灯のようだったので寿命は長くはないだろうし球切れにはなるのは仕方がない。しかし、今回の切れ方はちょっと違った。普通は蛍光灯が切れたからといって臭いはしないよね。

芳しい蛍光灯の断末魔 1
ブランドはNEC。12Wの電球型蛍光灯で、管を巻いたスパイラルタイプ。一時期流行って各社出してた記憶はある。基本的にはもう生産中止の筈。

芳しい蛍光灯の断末魔 2
お約束のメイドインチャイナ。調光器付きの器具では使用するなと書かれているが、もちろん洗面所の鏡のところの照明は調光機能付きのものではなくこのEFD15ENを使用するように指定書きが付いたもの。

芳しい蛍光灯の断末魔 3
ベース部分の管が出るところの周辺がメッチャ焦げてる。まぁこのタイプでは多いみたいね。

芳しい蛍光灯の断末魔 4
画面中央。蛍光管に穴が開いてる。どういう風に穴が開いたのかは全く不明だが、焦げ臭さとは違う部屋に充満するイヤな臭いはここから漏れ出たガスらしい。蛍光管のガスには水銀が含まれてて、それは昔と比べて使用量が減ってはいるらしいが、ゼロではない筈。臭いが部屋に充満してた風呂にも流れ込んできたということは水銀も一緒に吸った?

風呂入ってたらガス責めってナチスの収容所じゃないんだから勘弁して欲しい。
LEDにもトラブルはあるとはいえ取って代わられるわな、これじゃ。

蛍光灯というと正直あまり良い思い出がない。
学生時代にナショナルブランドの3本か4本の短いガラス管が筏みたいに並んだタイプで眼が疲れないインバーター付き2段調光っていう当時としてはお高めだった電気スタンドをちょっと奮発して買ったら普通の蛍光灯よりはるかに激しくチカチカしまくってフザケンナって思った。これが最初で最後に買ったナショナル製品になった。

次が、東芝ダイナブックのバックライト。最近はLEDだけどCCFLの頃のやつ。一時期のダイナブックでは冷陰極管自体が切れるのではなくFLインバーターが設計ミスなのかやたらと壊れまくった。バックライトが切れる度に秋葉原のチチブデンキに行って店のおっちゃんに相談して交換用のFLインバーターを購入して自分で取り替えた。FLインバーターは糞高いものではないし作業も難しくはないけどそれでも数が多いのでやっぱりフザケンナって思った。

3つめ、オフィスの掃除で簡易的なハタキのようなものを作ってテキトーにパタパタやってたら間違って天井の蛍光管にコツンと当たった。そしたらパンッってなって上から細かいのが降り注いだ。フザケンナ自分って思った。