「ConnMan」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(→‎保護されたアクセスポイントに接続: ==== Using iwd instead of wpa_supplicant ==== を追加)
(→‎接続時に謎のルートが使用される: === File /proc/net/pnp doesn't exist === を追加)
278行目: 278行目:
 
# ip6tables -A OUTPUT -d ipv6.connman.net -j REJECT
 
# ip6tables -A OUTPUT -d ipv6.connman.net -j REJECT
 
# iptables -A OUTPUT -d ipv4.connman.net,ipv6.connman.net -j REJECT
 
# iptables -A OUTPUT -d ipv4.connman.net,ipv6.connman.net -j REJECT
  +
  +
=== File /proc/net/pnp doesn't exist ===
  +
  +
If you see this in your error log it is caused by bug in connman [https://bbs.archlinux.org/viewtopic.php?id=227689#p1766928] and can be ignored. [https://01.org/jira/browse/CM-690 Bug Report]
   
 
== 参照 ==
 
== 参照 ==

2021年11月17日 (水) 15:59時点における版

関連記事

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

インストール

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

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-gitAUR
  • connman-notify — Connman イベント通知クライアント。
https://github.com/wavexx/connman-notify || connman-notifyAUR[リンク切れ: アーカイブ: aur-mirror]
  • ConnMan-UI — GTK3 クライアントアプレット。
https://github.com/tbursztyka/connman-ui || connman-ui-gitAUR
  • connman_dmenu — dmenu 用のクライアント/フロントエンド。
https://github.com/taylorchu/connman_dmenu || connman_dmenu-gitAUR
  • Econnman — Enlightenment デスクトップパネルアプレット。
http://www.enlightenment.org || econnmanAUR
  • LXQt-Connman-Applet — LXQt デスクトップパネルアプレット。
https://github.com/surlykke/lxqt-connman-applet || lxqt-connman-applet-gitAUR
  • qconnman-ui — O.S. Systems で使われている Qt 管理インターフェイス。
https://github.com/OSSystems/qconnman-ui || qconnman-ui-gitAUR[リンク切れ: アーカイブ: aur-mirror]
  • connman-gtk — GTK クライアント。
https://github.com/jgke/connman-gtk || connman-gtkAUR
  • 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 をコマンドモードで実行する方法を説明しています。

ネットワークをスキャンするとき、connmanctltechnologies と呼ばれるシンプルな名前を受け取ります。近辺の 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 addrconnmanctl 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

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

Using iwd instead of wpa_supplicant

ConnMan can use iwd to connect to wireless networks. The package which is available in community already supports using iwd for connecting to wireless networks. As connman will start wpa_supplicant when it finds it, it is recommended to uninstall wpa_supplicant.

Currently the -i-option of iwd seems to cause that the WiFi-interface gets hidden from connman.

Create the following two service files which should cause connman to use iwd to connect to wireless networks, regardless if wpa_supplicant is installed.

/etc/systemd/system/iwd.service
[Unit]
Description=Internet Wireless Daemon (IWD)
Before=network.target
Wants=network.target

[Service]
ExecStart=/usr/lib/iwd/iwd

[Install]
Alias=multi-user.target.wants/iwd.service
/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

Then enable/start the connman_iwd service.

Advantage of using iwd instead of wpa_supplicant is, that the ping times seem to be much more consistent and the connection seems to be more reliable.

設定

ユーザーがネットワークに接続すると、設定とプロファイルが自動的に作成されます。ファイルにはパスフレーズや 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 イベントを乗っ取ります。rfkillbluetoothctl を使ってデバイスをブロック(あるいはブロックを解除)することはできません。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 を使用しようとするのが原因です。BINDdnsmasq から以下のようなログメッセージが確認できる場合:

"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

File /proc/net/pnp doesn't exist

If you see this in your error log it is caused by bug in connman [4] and can be ignored. Bug Report

参照