ConnMan

関連記事

• ネットワーク設定
• ワイヤレスネットワーク設定

ConnMan は組み込みデバイスや早い解決時間で使うために作られたコマンドラインネットワークマネージャです。プラグインアーキテクチャ によるモジュール式になっていますが、ネイティブで DHCP と NTP をサポートもしています。

インストール

connman パッケージをインストールしてください。Wi-Fi や Bluetooth の機能を使うには wpa_supplicant や bluez も必要になります。

connman.service を有効化する前に、既存のネットワーク設定を無効化するようにしてください。

フロントエンド

• cmst — ConnMan の Qt GUI。

https://github.com/andrew-bibb/cmst || cmst

• connman-ncurses — ConnMan のシンプルな ncurses UI。実装されている connman の機能は一部に限られていますが、使えないわけではありません (X がない CUI 環境でも使えます)。wiki を参照。

https://github.com/eurogiciel-oss/connman-json-client || connman-ncurses-git^AUR

• ConnMan-UI — GTK3 クライアントアプレット。

https://github.com/tbursztyka/connman-ui || connman-ui-git^AUR

• connman_dmenu — dmenu 用のクライアント/フロントエンド。

https://github.com/taylorchu/connman_dmenu || connman_dmenu-git^AUR

• Econnman — Enlightenment デスクトップパネルアプレット。

http://www.enlightenment.org || econnman^AUR

• LXQt-Connman-Applet — LXQt デスクトップパネルアプレット。

https://github.com/surlykke/lxqt-connman-applet || lxqt-connman-applet-git^AUR

• connman-gtk — GTK クライアント。

https://github.com/jgke/connman-gtk || connman-gtk^AUR

• 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 のインタラクティブモードに似ています。インタラクティブモードではタブ補完を使うことができ、簡単に接続できます。

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

入力した情報が正しければ、保護されたアクセスポイントに接続できているはずです。

iwd を wpa_supplicant の代わりに使用する

ConnMan は iwd を使用して無線ネットワークに接続できます。connman は wpa_supplicant を見つけると起動するため、wpa_supplicant をアンインストールすることが推奨されています。

なお、IWD ユーザーには ConnMan はおそらく不要です。IWD は自身で ネットワーク設定を処理 できるため、その場合は connmand を停止すべきです。

現在、iwd の -i オプションは、Wi-Fi インターフェイスが connman から隠される原因となるようです。

以下のサービスファイルを作成することで、wpa_supplicant がインストールされているかどうかに関わらず、connman が iwd を使用して無線ネットワークに接続するようにできます。

/etc/systemd/system/connman_iwd.service

[Unit]
Description=Connection service
DefaultDependencies=false
Conflicts=shutdown.target
RequiresMountsFor=/var/lib/connman
After=dbus.service network-pre.target systemd-sysusers.service iwd.service
Before=network.target multi-user.target shutdown.target
Wants=network.target
Requires=iwd.service

[Service]
Type=dbus
BusName=net.connman
Restart=on-failure
ExecStart=/usr/bin/connmand --wifi=iwd_agent -n
StandardOutput=null
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SYS_TIME CAP_SYS_MODULE
ProtectHome=true
ProtectSystem=true

[Install]
WantedBy=multi-user.target

次に、connman_iwd サービスを 有効化および起動します。

iwd を wpa_supplicant の代わりに使用する利点は、ping 時間がより安定し、接続がより信頼性が高いように見えることです。

設定

ユーザーがネットワークに接続すると、設定とプロファイルが自動的に作成されます。ファイルにはパスフレーズや essid などの情報が記述されています。プロファイル設定は /var/lib/connman/ 下のディレクトリに保存されます。全てのネットワークプロファイルを確認したい場合は root シェルから次のコマンドを実行して下さい:

# cat /var/lib/connman/*/settings

ノート: VPN の設定は /var/lib/connman-vpn/ にあります。

テクノロジー

ConnMan は様々なハードウェアインターフェイスを Technologies と呼びます。

利用可能な technologies を確認するには次を実行:

$ connmanctl technologies

以下のワンライナーを使うことでタイプだけを取得できます:

$ connmanctl technologies | awk '/Type/ { print $NF }'

ノート: Type = tech_name フィールドには connmanctl コマンドで使用するテクノロジーのタイプが記されています。

テクノロジーを使用するときはタイプでテクノロジーを指定する必要があります。Technologies は次のコマンドでオンオフを切り替えられます:

$ connmanctl enable technology_type

または:

$ connmanctl disable technology_type

例えば wifi をオフにするには:

$ connmanctl disable wifi

警告: connman はあらゆる rfkill イベントを乗っ取ります。rfkill や bluetoothctl を使ってデバイスをブロック（あるいはブロックを解除）することはできません。connmanctl enable|disable を使ってください。ただしハードウェアキーは使える可能性があります [1]。

ヒントとテクニック

ホストネームの変更をしない

デフォルトで、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 に接続

WPA2 Enterprise#connman を参照。

ローカル 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 プロキシを再起動してください。

DNS の管理

/etc/resolv.conf

カスタム /etc/resolv.conf を維持しながら DHCP から受け取った DNS サーバーを確認したい場合、上記のファイルに RuntimeDirectory=connman を追記してください(不要であれば ExecStart 行を削除してください)これで、connman は DNS サーバー情報を /var/run/connman/resolv.conf に書き込むようになります。

systemd-resolved を使用する

ConnMan は systemd-resolved のサポートを提供しており、これにより内部 DNS プロキシを置き換え、ネットワークに接続するたびにインターフェースに適切な DNS サーバーと検索ドメインを設定する systemd-resolved 用のモジュールが構成されます。systemd-resolved を使用すると、ConnMan の内部プロキシと Tailscale が /etc/resolv.conf を巡って競合する問題が解決され、両者が resolved と通信することで、Tailscale との互換性が向上します。

このサポートを使用するには、ConnMan を再ビルドする必要があります。パッケージを Arch build system でチェックアウトし、設定フラグ --with-dns-backend=systemd-resolved を設定してパッケージを再ビルドし、修正されたバージョンをインストールします。修正されたパッケージをインストールした後、スタブリゾルバ を /etc/resolv.conf として設定し、その後 connman.service、systemd-resolved.service、および(使用している場合は)tailscale.service を再起動します。

インターフェイスのブラックリスト

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

現在、connman は iwd を使用して Wi-Fi ネットワークのスキャンをサポートしていません。この機能は現時点では wpa_supplicant のみで利用可能です(詳細は https://web.archive.org/web/20220916045152mp_/https://lists.01.org/hyperkitty/list/iwd@lists.01.org/thread/OISUI4LVSZ5UQ5FA6S3IMDKOJN4NYFBZ/ を参照)iwd で Wi-Fi に接続するには、iwd.service を 有効化 および 起動 し、その後 Iwd の手順に従って Wi-Fi に接続するか、#Front-ends のいずれかを使用することもできます。connman 内で Wi-Fi スキャン機能を使用するには、wpa_supplicant をインストールし、iwd.service を停止した後に connman.service を 再起動 してください。

Error /net/connman/technology/wifi: No carrier

次の方法で Wi-Fi を有効にした場合:

$ connmanctl enable wifi

無線スキャンが上記のエラーを引き起こす場合、これは 解決されていないバグ が原因かもしれません。無線の 前提条件 が満たされているにもかかわらず解決しない場合、競合するネットワークマネージャーを無効にし、再起動してからもう一度試してください。

また、これは単に無線インターフェースが rfkill によってブロックされていることが原因かもしれません。これは wpa_supplicant を再起動した後に発生することがあります。rfkill list を使って確認してください。

"Not registered", または "Method "Connect" with signature ... doesn't exist"

コマンドを発行するとき、次のようなエラーが表示される場合があります:

connmanctl プロンプトから:

connmanctl> connect service_id

Error /net/connman/service/SSID: Method "Connect" with signature "" on interface "net.connman.Service" doesn't exist

シェルから:

# connmanctl connect service_id

Error /net/connman/service/service_id: Not registered

これらのエラーは、エージェントが実行されていないために発生します。connmanctl のプロンプトから agent on を実行し、再度試してください。

Error Failed to set hostname/domainname

connman は CAP_SYS_ADMIN が不足しているため、ホスト名やドメイン名の設定に失敗することがあります。

この場合、connman.service(および connman-vpn.service など)を 編集 して、CapabilityBoundingSet 行に CAP_SYS_ADMIN を追加する必要があります。

詳細については、sethostname(2) § ERRORS または setdomainname(2) § ERRORS の 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 が接続チェックを行っています [2] (現時点では 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

File /proc/net/pnp doesn't exist

エラーログにこれが表示される場合、これは connman のバグ [3] が原因であり、無視しても構いません。バグ報告 をご覧ください。

参照

• git リポジトリのドキュメント - 詳しい情報が載っています。