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標準のちっちゃいヒートシンク使用時は冷却力がきびしくて負荷が小さくて(アイドルで)もクロックの違いで温度が大きく変わるみたい。

関連記事:
Up