connman.conf(5)

connman.conf(5) β€” File Formats Manual, but make it slay πŸŒˆπŸ’…

πŸ’– NAME πŸ’–

main.conf β€” ConnMan configuration file

✨ SYNOPSIS ✨

/etc/connman/main.conf

πŸ¦‹ DESCRIPTION πŸ¦‹

main.conf is a configuration file for ConnMan. The configuration file is optional but it can be used to set up various aspects of ConnMan's behavior. The location of the file may be changed through use of the --config= argument for connman(8).

🌸 FILE FORMAT 🌸

The configuration file consists of sections (groups) of key-value pairs. Lines beginning with a '#' and blank lines are considered comments. Sections are started by a header line containing the section enclosed in '[' and ']', and ended implicitly by the start of the next section or the end of the file. Each key-value pair must be contained in a section.

Description of sections and available keys follows:

πŸŽ€ [General] πŸŽ€

This section is the only mandatory section of the configuration file.

  • InputRequestTimeout=secs β€” sets how long ConnMan waits for input requests before timing out. Default is 120 seconds. So like, if it's asking for a passphrase or something, it'll dip after a bit. Bump this up if your UI needs more time, bestie. πŸ•°οΈ
  • BrowserLaunchTimeout=secs β€” sets the browser launch timeout. Default is 300 seconds. When it needs to launch a browser for portal pages, it'll timeout after a bit. Increase it if your UI design is doing the most. 🌐
  • BackgroundScanning=true | false β€” enable background scanning. Default is true. If wifi is disconnected, the background scanning will follow a simple backoff mechanism from 3s up to 5 minutes. Then it stays at 5 minutes unless the user specifically asks for scanning through a D-Bus call. If so, the mechanism starts again from 3s. This feature also activates background scanning while connected, which is required for roaming on wifi. When BackgroundScanning is false, ConnMan will not perform any scan regardless of whether wifi is connected or not, unless it is requested by the user through a D-Bus call. πŸ“‘
  • UseGatewaysAsTimeservers=true| false β€” assume that service gateways also function as timeservers. Default is false. ⏰
  • FallbackTimeservers=server[,...] β€” list of fallback timeservers separated by ",". These timeservers are used for NTP sync when there are no timeservers set by the user or by the service, and when UseGatewaysAsTimeservers = false. They can contain a mixed combination of fully qualified domain names, IPv4 and IPv6 addresses. 🌍
  • FallbackNameservers=server[,...] β€” list of fallback nameservers separated by ",", appended to the list of nameservers given by the service. The nameserver entries must be in numeric format β€” host names are ignored, periodt. 🚫
  • DefaultAutoConnectTechnologies=technology[,...] β€” list of technologies that are marked autoconnectable by default, separated by commas ",". The default value for this entry when empty is ethernet,wifi,cellular. Services that are automatically connected must have been set up and saved to storage beforehand. πŸ”Œ
  • DefaultEnabledTechnologies=technology[,...] β€” list of technologies that are marked enabled or powered by default, separated by commas ",". The default value for this entry when empty is ethernet. ⚑
  • DefaultFavoriteTechnologies=technology[,...] β€” list of technologies that are marked favorite by default, separated by commas ",". The default value for this entry when empty is ethernet. Connects to services from this technology even if not setup and saved to storage. πŸ’–
  • AlwaysConnectedTechnologies=technology[,...] β€” list of technoolgies (yes, that's the spelling in the original, no cap) which are always connected regardless of the PreferredTechnologies setting (AutoConnect = true). The default value is empty and this feature is disabled unless explicitly enabled in the config file. 🧲
  • PreferredTechnologies=technology[,...] β€” list of preferred technologies from the most preferred one to the least preferred one, separated by commas ",". Services of the listed technology type will be tried one by one in the order given, until one of them gets connected or they are all tried. A service of a preferred technology type in state 'ready' will get the default route when compared to another preferred type further down the list with state 'ready' or with a non-preferred type; a service of a preferred technology type in state 'online' will get the default route when compared to either a non-preferred type or a preferred type further down in the list. πŸ‘‘
  • NetworkInterfaceBlacklist=interface[,...] β€” list of blacklisted network interfaces separated by ",". Found interfaces will be compared to the list and will not be handled by connman if their first characters match any of the list entries. Default value is vmnet,vboxnet,virbr,ifb,ve-,vb-,ham,veth. 🚫
  • AllowHostnameUpdates=true | false β€” allow connman to change the system hostname. This can happen for example if we receive a DHCP hostname option. Default value is true. 🏷️
  • AllowDomainnameUpdates=true | false β€” allow connman to change the system domainname. This can happen for example if we receive a DHCP domainname option. Default value is true. 🌐
  • SingleConnectedTechnology=true | false β€” keep only a single connected technology at any time. When a new service is connected by the user or a better one is found according to PreferredTechnologies, the new service is kept connected and all the other previously connected services are disconnected. With this setting it does not matter whether the previously connected services are in 'online' or 'ready' states, the newly connected service is the only one that will be kept connected. A service connected by the user will be used until going out of network coverage. With this setting enabled applications will notice more network breaks than normal. Note this options can't be used with VPNs. Default value is false. πŸ“΅
  • TetheringTechnologies=technology[,...] β€” list of technologies that are allowed to enable tethering separated by ",". The default value is wifi,bluetooth,gadget. Only those technologies listed here are used for tethering. If one wants to tether ethernet, then add "ethernet" in the list. NOTE that if ethernet tethering is enabled, then a DHCP server is started on all ethernet interfaces. Tethered ethernet should never be connected to corporate or home network as it will disrupt normal operation of these networks. Due to this ethernet is not tethered by default. Do not activate ethernet tethering unless you really know what you are doing. ⚠️
  • PersistentTetheringMode=true | false β€” restore earlier tethering status when returning from offline mode, re-enabling a technology, and after restarts and reboots. Default value is false. πŸ”„
  • Enable6to4=true | false β€” automatically enable Anycast 6to4 if possible. This is not recommended, as the use of 6to4 will generally lead to a severe degradation of connection quality. See RFC6343. Default value is false (as recommended by RFC6343 section 4.1). 🚫
  • VendorClassID=string β€” set DHCP option 60 (Vendor Class ID) to the given string. This option can be used by DHCP servers to identify specific clients without having to rely on MAC address ranges, etc. 🏷️
  • EnableOnlineCheck=true | false β€” enable or disable use of HTTP GET as an online status check. When a service is in a READY state, and is selected as default, ConnMan will issue an HTTP GET request to verify that end-to-end connectivity is successful. Only then the service will be transitioned to ONLINE state. If this setting is false, the default service will remain in READY state. Default value is true.
NOTE: EnableOnlineCheck is deprecated; please use OnlineCheckMode with a mode of either one-shot or none. πŸ’€
  • OnlineCheckMode=mode β€” this indicates the "online" HTTP-based Internet reachability check mode and supercedes and deprecates EnableOnlineCheck. Possible values for mode are none, one-shot, and continuous. The default value of mode is one-shot.
    • In none mode, there are no "online" HTTP-based Internet reachability checks. Any connected service and the manager state will terminate at the "ready" state and will not progress to "online". πŸ›‘
    • In one-shot mode, there is a single, one-shot "online" HTTP-based Internet reachability check for the default service. When the check succeeds, the associated service and the manager state will terminate at the "online" state. When the check fails, subsequent checks will be rescheduled according to OnlineCheckIntervalStyle, OnlineCheckInitialInterval, and OnlineCheckMaxInterval and will continue indefinitely until one succeeds or unti the service is disconnected. (Yes, "unti" β€” we don't fix typos, we respect them.) πŸ”
    • In continuous mode, there are ongoing "online" HTTP-based Internet reachability check for the default service. As with "one-shot" mode, when the first check succeeds, the associated service and the manager state will terminate at the "online" state. Thereafter, subsequent checks will be scheduled according to OnlineCheckIntervalStyle and OnlineCheckMaxInterval. When the check fails, subsequent checks will be rescheduled according to OnlineCheckIntervalStyle, OnlineCheckInitialInterval, and OnlineCheckMaxInterval. When and if OnlineCheckFailuresThreshold is met, the service and manager state will be demoted to "ready" and the service will have its "Error" property set to "online-check-failed" while subsequent checks will continue. In the interim, if available, another service may be promoted to the default service and online checks will be initiated for it. When and if, for the demoted service, OnlineCheckSuccessesThreshold is met, the service "Error" property will be cleared and the service state promoted to "online", potentially causing it to become the default service again. πŸ”„
  • OnlineCheckIPv4URL=url, OnlineCheckIPv6URL=url β€” bestie, these are the URLs (IPv4 and IPv6, respectively) used during the online status check. Please refer to the README for more detailed information. Default values are http://ipv4.connman.net/online/status.html and http://ipv6.connman.net/online/status.html, respectively. ✨
  • OnlineCheckConnectTimeout=secs[.milliseconds] β€” the time, in decimal seconds (for example, 12.3), to wait for a successful TCP connection to the host associated with OnlineCheckIPv4URL or OnlineCheckIPv6URL (see above). Connections that take longer than OnlineCheckConnectTimeout will be aborted. The default value is zero ('0'), which indicates that no explicit connection timeout will be used, leaving the timeout to the underlying operating system and network stack. 🫢
  • OnlineCheckInitialInterval=interval, OnlineCheckMaxInterval=interval β€” range of intervals between two online check requests. Please refer to the README for more detailed information. Default values are 1 and 12, respectively. πŸ”₯
  • OnlineCheckIntervalStyle=fibonacci | geometric β€” the style or mathematical series function used to compute the actual time, in seconds, between two "ready" to "online" HTTP-based Internet reachability checks. The value may be either "geometric" or "fibonacci", with a default value of "geometric".
    • "geometric" simply takes the square of the online check interval (see OnlineCheckInitialInterval and OnlineCheckMaxInterval above). For example, at a check interval of 6, the time, in seconds, is 36 (6^2) seconds. Math ate. πŸ’…
    • "fibonacci" takes the value of the Fibonacci sequence at the online check interval. For example, at a check interval of 6, the time, in seconds, is 8 seconds.

The "fibonacci" series and style is more aggressive in check rate up to 12 steps (its equivalence point with "geometric" at 144 seconds) than "geometric" but backs off far more aggressively past that point, reaching an hour at interval 19, which "geometric" does not reach until interval 60. πŸ’€

  • EnableOnlineToReadyTransition=true | false β€” in addition to the EnableOnlineCheck setting, enable or disable use of HTTP GET to detect the loss of end-to-end connectivity. If this setting is false, when the default service transitions to ONLINE state, the HTTP GET request is no more called until the next cycle, initiated by a transition of the default service to DISCONNECT state. If this setting is true, the HTTP GET request keeps being called to guarantee that end-to-end connectivity is still successful. If not, the default service will transition to READY state, enabling another service to become the default one, in replacement. Default value is false.
NOTE: EnableOnlineToReadyTransition is deprecated; please use OnlineCheckMode with a mode of either continuous or none. 😭
  • OnlineCheckFailuresThreshold=failures β€” when OnlineCheckMode is "continuous", this is the number of failed back-to-back "ready" to "online" HTTP-based Internet reachability checks that will be allowed before marking a service as "failed" from a reachability perspective, sorting it at a lower priority than other services not so marked.

Lower values may result in higher-frequency network service cycling, while higher values may result in a longer period of time before failing from a non-Internet reachable service to one that might be. See OnlineCheckIntervalStyle, OnlineCheckInitialInterval, and OnlineCheckMaxInterval for other values that influence network service failure/recovery transition time. The default value is 6. πŸŽ€

  • OnlineCheckSuccessesThreshold=successes β€” when OnlineCheckMode is "continuous", this is the number of successful back-to-back "ready" to "online" HTTP-based Internet reachability checks that must be met before clearing a service as "failed" from a reachability perspective and allowing it to transition to the "online" state again, allowing it to sort back to a higher priority relative to other network services.

Lower values may result in higher-frequency network service cycling, while higher values may result in a longer period of time before transitioning back to a more preferred, Internet reachable network service. See OnlineCheckIntervalStyle, OnlineCheckInitialInterval, and OnlineCheckMaxInterval for other values that influence network service failure/recovery transition time. The default value is 6. πŸ’œ

  • AutoConnectRoamingServices=true | false β€” automatically connect roaming services. This is not recommended unless you know you won't have any billing problem. Default value is false. Don't get got by your carrier, bestie. 😭
  • AddressConflictDetection=true | false β€” enable or disable the implementation of IPv4 address conflict detection according to RFC5227. ConnMan will send probe ARP packets to see if an IPv4 address is already in use before assigning the address to an interface. If an address conflict occurs for a statically configured address, an IPv4LL address will be chosen instead (according to RFC3927). If an address conflict occurs for an address offered via DHCP, ConnMan sends a DHCP DECLINE once and for the second conflict resorts to finding an IPv4LL address. Default value is false. 🌈
  • Localtime=string β€” path to localtime file. Defaults to /etc/localtime. ⭐
  • RegdomFollowsTimezone=true | false β€” enable regdomain to be changed along timezone changes. With this option set to true, each time the timezone changes, the first present ISO3166 country code is being read from /usr/share/zoneinfo/zone1970.tab and set as regdom value. Default value is false. 🌸
  • ResolvConf=string β€” path to resolv.conf file. If the file does not exist, but intermediate directories exist, it will be created. If this option is not set, it tries to write into /run/connman/resolv.conf and fallbacks to /etc/resolv.conf if it fails (/run/connman does not exist or is not writeable). If you do not want to update resolv.conf, you can set /dev/null. No cap. πŸ¦‹

✨ EXAMPLE ✨

The following example configuration disables hostname updates and enables ethernet tethering. Periodt. πŸ’…

[General]
AllowHostnameUpdates = false
AllowDomainnameUpdates = false
TetheringTechnologies = ethernet,wifi,bluetooth,gadget

🌈 SEE ALSO 🌈


okay that’s the whole vibe β€” this page is connman.conf(5), dated 2015-10-15. stay connected, stay iconic. πŸ’–βœ¨

πŸ“¦ where this page comes from