- Generic plugin infrastructure
- Device and network abstraction (with basic storage support)
- IPv4, IPv4-LL (link-local) and DHCP
+ - IPv4 address conflict detection (ACD) according to RFC 5227
- IPv6, DHCPv6 and 6to4 tunnels
- Advanced routing and DNS configuration
- Built-in DNS proxy and intelligent caching
- GCC compiler
- GLib library
- D-Bus library
- - IP-Tables library
+ - IP-Tables library (for tethering support)
- GnuTLS library (optional)
- PolicyKit (optional)
- readline (command line client)
detected and only a runtime dependency. It is not needed to
build ConnMan.
+ --enable-iwd
+
+ Enable support for Wireless daemon for Linux
+
+ The IWD project does not have initial release so far,
+ therefore by default IWD support is not enabled.
+
+ It is safe to enable this option along WiFi support.
+
--disable-pacrunner
Disable support for PACrunner proxy handling
# semodule -i connman-task.pp
in order to enable the dbus access.
+ --with-dns-backend=TYPE
+
+ Enable support for a DNS resolving backend
+
+ Select a DNS backend to use. Supported values are "internal"
+ and "systemd-resolved". If "internal" is selected, ConnMan
+ will be build with a caching DNS proxy. If "systemd-resolved"
+ is selected, ConnMan configures systemd-resolved to do DNS
+ resolving. The default value is "internal".
+
Activating debugging
====================
This last option will enable the support of background scanning while being
connected, which is necessary when roaming on wifi.
-and finally:
-
-CONFIG_AUTOSCAN_EXPONENTIAL=y
-
-This will enable the exact same function as bgscan but while being
-disconnected.
-
It is recommended to use wpa_supplicant 2.x or later.
If wpa_supplicant is configured to D-Bus autostart, then ConnMan will
trigger the autostart of wpa_supplicant. However please keep in mind
that this trigger only happens once. If wpa_supplicant stops or crashes,
ConnMan does not periodically try to autostart it. It is up to systemd or
-similar service management tool to autostart it.
+similar service management tool to autostart it. In case wpa_supplicant
+is not started by ConnMan then make sure option "-u" is used in order
+to enable its D-Bus control interface and ensure ConnMan can communicate
+with it.
VPN
uplink.
+GnuTLS
+======
+
+When using GnuTLS be aware that depending on the configuration of
+GnuTLS does either an lazy or eager initialization of an internal
+entropy pool using /dev/urandom. On eager initialization the loading
+of ConnMan will be delayed by the link loader until the entropy pool
+is filled. On smaller system this can easily delay the startup of
+ConnMan by several seconds (we had reports of 25 seconds and more
+delay).
+
+GnuTLS allows to switch back to lazy evaluation when the environment
+variable GNUTLS_NO_EXPLICIT_INIT. For more details please read
+the man page to gnutls_global_init(3).
+
+
+Online check
+============
+
+ConnMan tries to detect if it has Internet connection or not when
+a service is connected. If the online check succeeds the service
+enters Online state, if not it stays in Ready state. The online
+check is also used to detect whether ConnMan is behind a captive
+portal like when you are in hotel and need to pay for connectivity.
+
+The online check is done by trying to fetch status.html document
+from ipv4.connman.net (for IPv4 connectivity) and ipv6.connman.net
+(for IPv6 connectivity). The used URL looks like this
+http://ipv{4|6}.connman.net/online/status.html
+
+See connman.conf(5) for the EnableOnlineCheck option, if you need to
+disable the feature.
+
+During the online check procedure, ConnMan will temporarily install
+a host route to both the ipv4.connman.net and ipv6.connman.net so that
+the online check query can be directed via the correct network
+interface which the connected service is using. This host route is
+automatically removed when the online check is done. Note that the server
+expressly does not log any connection information, including IPv4/6
+addresses of connecting clients. The server runtime logs cycle in RAM
+memory depending on amount of connections processed.
+
+ConnMan sends this very minimal information in http header when doing
+the online check request (example):
+ Host: ipv4.connman.net
+ User-Agent: ConnMan/1.23 wispr
+ Connection: close
+
+Currently following information is returned from connman.net if
+the connection is successfull (200 OK http response code is returned):
+ Server: nginx
+ Date: Mon, 09 Jun 2014 09:25:42 GMT
+ Content-Type: text/html
+ Connection: close
+ X-ConnMan-Status: online
+
+The X-ConnMan-Status field is used in portal detection, if it is missing
+ConnMan will call RequestBrowser method in net.connman.Agent dbus
+interface to handle the portal login if the portal does not support WISPr.
+See doc/agent-api.txt for more details.
+
+
Information
===========