ConnMan
ConnMan は解決時間が高速な組み込みデバイスで使うために作られたコマンドラインネットワークマネージャです。プラグインアーキテクチャ によるモジュール式になっていますが、ネイティブで DHCP と NTP をサポートもしています。
インストール
connman パッケージをインストールしてください。Wi-Fi や Bluetooth の機能を使うには wpa_supplicant や bluez も必要になります。
connman.service
を有効化する前に、既存のネットワーク設定を無効化するようにしてください。
デスクトップクライアント
- cmst — ConnMan の Qt GUI。
- connman-ncurses — ConnMan のシンプルな ncurses UI。実装されている connman の機能は一部に限られていますが、使えないわけではありません (X がない CUI 環境でも使えます)。wiki を参照。
- connman-notify — Connman イベント通知クライアント。
- https://github.com/wavexx/connman-notify || connman-notifyAUR[リンク切れ: アーカイブ: aur-mirror]
- ConnMan-UI — GTK3 クライアントアプレット。
- connman_dmenu — dmenu 用のクライアント/フロントエンド。
- Econnman — Enlightenment デスクトップパネルアプレット。
- LXQt-Connman-Applet — LXQt デスクトップパネルアプレット。
- qconnman-ui — O.S. Systems で使われている Qt 管理インターフェイス。
- https://github.com/OSSystems/qconnman-ui || qconnman-ui-gitAUR[リンク切れ: アーカイブ: aur-mirror]
- connman-gtk — GTK クライアント。
- gnome-extension-connman — Connman の Gnome3 拡張。connman-gtk をインストールしなくても一部の機能が使えます。
- https://github.com/jgke/gnome-extension-connman || https://extensions.gnome.org/extension/981/connman-extension/
使用方法
ConnMan には標準のコマンドラインクライアント connmanctl
が付属しています。connmanctl
は2つのモードで動作します:
- コマンドモードでは、
connmanctl
に引数を付けてコマンドを実行します。systemctl と似ています。 - インタラクティブモードでは、
connmanctl
に何も引数を付けずに起動します。プロンプトがconnmanctl>
に変化し、ユーザーがコマンドを入力するのを待機します。python のインタラクティブモードに似ています。インタラクティブモードではタブ補完を使うことができ、簡単に接続できます。
有線
ConnMan は自動的に有線接続を管理します。
Wi-Fi
Wi-Fi の有効化と無効化
Wi-Fi が有効になっているかどうか確認するには connmanctl technologies
を実行して Powered: True/False
と表示された行をチェックしてください。Wi-Fi を有効にするには connmanctl enable wifi
を実行し、無効にする場合は connmanctl disable wifi
を実行します。ノートパソコンの場合 Fn
キーを使って Wi-Fi の電源を入れてください。もしくは ip link set <interface> up
を実行してみてください。
オープンなアクセスポイントに接続
このセクションでは connmanctl
をコマンドモードで実行する方法を説明しています。
ネットワークをスキャンするとき、connmanctl
は technologies と呼ばれるシンプルな名前を受け取ります。近辺の Wi-Fi ネットワークをスキャンするには:
$ connmanctl scan wifi
スキャンを実行した後に、利用可能なネットワークを確認するには (出力例):
$ connmanctl services
*AO MyNetwork wifi_dc85de828967_68756773616d_managed_psk OtherNET wifi_dc85de828967_38303944616e69656c73_managed_psk AnotherOne wifi_dc85de828967_3257495245363836_managed_wep FourthNetwork wifi_dc85de828967_4d7572706879_managed_wep AnOpenNetwork wifi_dc85de828967_4d6568657272696e_managed_none
オープンなネットワークに接続するには、2番目のフィールドに wifi_
から始まる文字列を指定します:
$ connmanctl connect wifi_dc85de828967_4d6568657272696e_managed_none
これでネットワークに接続されるはずです。ip addr
や connmanctl state
で確認してください。
保護されたアクセスポイントに接続
パスワードで保護されたアクセスポイントを使う場合、ConnMan デーモンに情報 (パスワードやパスフレーズ) を渡す必要があります。
このセクションのコマンドを使うときは connmanctl
をインタラクティブモードで実行します。agent
コマンドを使用するにはインタラクティブモードが必須です。インタラクティブモードを起動するには次を入力:
$ connmanctl
オープンなアクセスポイントと同じように設定を進めます。まずは Wi-Fi の technologies をスキャン:
connmanctl> scan wifi
サービスを確認:
connmanctl> services
エージェントを登録してユーザーのリクエストを処理する必要があります。コマンドは:
connmanctl> agent on
それから保護されたサービスに接続します。タブ補完を使えば簡単に接続できます。例えば、上の例にある OtherNET に接続する場合、以下を実行:
connmanctl> connect wifi_dc85de828967_38303944616e69656c73_managed_psk
エージェントは接続を確立するのに必要な情報を要求します。接続するネットワークのタイプによって、要求される情報は大きく変わってきます。また、エージェントが必要とする情報に関するデータが以下のように出力されます:
Agent RequestInput wifi_dc85de828967_38303944616e69656c73_managed_psk Passphrase = [ Type=psk, Requirement=mandatory ] Passphrase?
要求されている情報 (上の例の場合はパスフレーズ) を入力してから、次を実行:
connmanctl> quit
入力した情報が正しければ、保護されたアクセスポイントに接続できているはずです。
設定
ユーザーがネットワークに接続すると、設定とプロファイルが自動的に作成されます。ファイルにはパスフレーズや essid などの情報が記述されています。プロファイル設定は /var/lib/connman/
下のディレクトリに保存されます。全てのネットワークプロファイルを確認したい場合は root シェルから次のコマンドを実行して下さい:
# cat /var/lib/connman/*/settings
テクノロジー
ConnMan は様々なハードウェアインターフェイスを Technologies と呼びます。
利用可能な technologies を確認するには次を実行:
$ connmanctl technologies
以下のワンライナーを使うことでタイプだけを取得できます:
$ connmanctl technologies | awk '/Type/ { print $NF }'
テクノロジーを使用するときはタイプでテクノロジーを指定する必要があります。Technologies は次のコマンドでオンオフを切り替えられます:
$ connmanctl enable technology_type
または:
$ connmanctl disable technology_type
例えば wifi をオフにするには:
$ connmanctl disable wifi
ヒントとテクニック
ホストネームの変更をしない
デフォルトで、ConnMan はネットワークごとに transient hostname を変更します。これによって X authority で問題が生まれてしまうことがあります: ConnMan は変更したホストネームが xauth のマジッククッキーを作成するのに使われた名前と異なる場合、新しいウィンドウを作成することが不可能になります。その場合 "No protocol specified" や "Can't open display: :0.0" などのエラーメッセージが表示されます。手動でホストネームを再設定することで解決しますが、恒久的な解決策としては、そもそも ConnMan がホストネームを変更できないようにしてしまうほかありません。/etc/connman/main.conf
に以下を追加してください:
[General] AllowHostnameUpdates=false
このファイルを変更した後は connman.service
を再起動してください。
テスト目的の場合、journal を確認しながらネットワークケーブルを何度か接続してみて何が起こるのか確認することを推奨します。
ワイヤレスよりもイーサネットを優先する
デフォルトでは ConnMan はワイヤレスよりもイーサネットを優先することはありません。そのため、イーサネット接続ができるときでも速度が遅い無線ネットワークが使われてしまう可能性があります。/etc/connman/main.conf
に以下を追加することでイーサネットを優先させることができます:
[General] PreferredTechnologies=ethernet,wifi
ワイヤレスとイーサネットどちらか片方の接続だけを使う
ConnMan では同時にイーサネットとワイヤレスの両方に接続することができます。これによってイーサネットに接続しても wifi 接続を維持することができます。しかしながら、場合によってはどちらか片方の接続だけをアクティブにしたいということもあるでしょう。/etc/connman/main.conf
に以下を追加することで片方の接続だけを有効にできます:
[General] SingleConnectedTechnology=true
eduroam に接続
ローカル DNS サーバーとの衝突を回避する
ローカルで DNS サーバーを動かしている場合、Connman をインストールした後にポート 53 (TCP や UDP) を使用しようとすると問題が発生します。Connman に独自の DNS プロキシが含まれいて、ポート 53 を使用しようとするのが原因です。BIND や dnsmasq から以下のようなログメッセージが確認できる場合:
"named[529]: could not listen on UDP socket: address in use"
おそらくそれが問題となっています。どのアプリケーションがポートを listen しているか確認したいときは、root で ss -tulpn
を実行してみてください。
systemd のサービスファイルのオプションを -r
や --nodnsproxy
で上書きすることでコマンドを修正することができます。/etc/systemd/system/connman.service.d/
フォルダを作成して disable_dns_proxy.conf
ファイルを追加してください:
[Service] ExecStart= ExecStart=/usr/bin/connmand -n --nodnsproxy
このファイルを追加した後は、systemd デーモンをリロードしてから connman.service
と DNS プロキシを再起動してください。
インターフェイスのブラックリスト
Docker などが仮想インターフェイスを作成する場合、接続が切れたときに Connman は物理的なアダプダではなく仮想インターフェイスで接続を試行してしまう可能性があります。使用させたくないインターフェイスをブラックリストに入れることで簡単に回避することができます。Connman はデフォルトで "vmnet", "vboxnet", "virbr", "ifb" から始まるインターフェイスをブラックリストに指定するので、これらのインターフェイスを設定する必要はありません。
systemd や udev が enp4s0
のような予測可能なインターフェイス名を使用し始める前に connman が eth#
や wlan#
を使用してしまう係合状態も、インターフェイスの名前をブラックリストに入れることで回避できます。伝統的 (予測不可能) なインターフェイスのプレフィックスをブラックリストに指定することで、名前が変更されるまで connman は接続を待機します。
ブラックリストを指定するには /etc/connman/main.conf
に以下を記述してください:
[General] NetworkInterfaceBlacklist=vmnet,vboxnet,virbr,ifb,docker,veth,eth,wlan
connman.service
を再起動すると Econnman などの GUI ツールでも veth#######
インターフェイスが表示されなくなります。
トラブルシューティング
Error /net/connman/technology/wifi: Not supported
wpa_supplicant をインストールしてから connman.service
を再起動してください。
Error /net/connman/technology/wifi: No carrier
エラーによってワイヤレスネットワークのスキャンが失敗する場合、おそらく未解決のバグが原因です [2]。無線の 条件 を満たしても問題が解決しない場合、他のネットワークマネージャを無効化して再起動してからもう一度試してみてください。
rfkill によって無線インターフェイスがブロックされているだけの可能性もあります。wpa_supplicant を再起動した後に発生します。rfkill list
を使って確認してください。
ホストネーム/ドメインネームの設定が失敗する
CAP_SYS_ADMIN 権限がないために connman によるホストネームやドメインネームの設定が失敗することがあります。
connman.service
(あるいは connman-vpn.service
など) を編集して CapabilityBoundingSet 行に CAP_SYS_ADMIN を追加してください。
詳しくは sethostname(2) や setdomainname(2) の EPERM を参照。
接続時に謎のルートが使用される
以下のように、接続を行ったときに謎のルートがログエントリに表示される場合:
... connmand[473]: wlp2s0 {add} route 82.165.8.211 gw 10.20.30.4 scope 0 <UNIVERSE> connmand[473]: wlp2s0 {del} route 82.165.8.211 gw 10.20.30.4 scope 0 <UNIVERSE> ...
おそらく ipv4.connman.net ホストを使って Connman が接続チェックを行っています [3] (現時点では IP アドレス 82.165.8.211
に辿り着きます)。詳しくは Connman README を参照してください。
チェックの宛先ホストを設定するオプションは存在しませんが、ファイアウォールのルールでチェックをブロックしても接続自体は問題ありません (キャプティブポータルがない限り):
# ip6tables -A OUTPUT -d ipv6.connman.net -j REJECT # iptables -A OUTPUT -d ipv4.connman.net,ipv6.connman.net -j REJECT
参照
- git リポジトリのドキュメント - 詳しい情報が載っています。