diff options
Diffstat (limited to 'docs/api/html/NetworkManager.conf.html')
| -rw-r--r-- | docs/api/html/NetworkManager.conf.html | 236 |
1 files changed, 216 insertions, 20 deletions
diff --git a/docs/api/html/NetworkManager.conf.html b/docs/api/html/NetworkManager.conf.html index 3655be21..e8efb5e7 100644 --- a/docs/api/html/NetworkManager.conf.html +++ b/docs/api/html/NetworkManager.conf.html @@ -7,7 +7,7 @@ <link rel="home" href="index.html" title="NetworkManager Reference Manual"> <link rel="up" href="manpages.html" title="Part I. Manual Pages"> <link rel="prev" href="NetworkManager.html" title="NetworkManager"> -<link rel="next" href="nmcli.html" title="nmcli"> +<link rel="next" href="NetworkManager-dispatcher.html" title="NetworkManager-dispatcher"> <meta name="generator" content="GTK-Doc V1.33.0 (XML mode)"> <link rel="stylesheet" href="style.css" type="text/css"> </head> @@ -17,7 +17,7 @@ <td><a accesskey="h" href="index.html"><img src="home.png" width="16" height="16" border="0" alt="Home"></a></td> <td><a accesskey="u" href="manpages.html"><img src="up.png" width="16" height="16" border="0" alt="Up"></a></td> <td><a accesskey="p" href="NetworkManager.html"><img src="left.png" width="16" height="16" border="0" alt="Prev"></a></td> -<td><a accesskey="n" href="nmcli.html"><img src="right.png" width="16" height="16" border="0" alt="Next"></a></td> +<td><a accesskey="n" href="NetworkManager-dispatcher.html"><img src="right.png" width="16" height="16" border="0" alt="Next"></a></td> </tr></table> <div class="refentry"> <a name="NetworkManager.conf"></a><div class="titlepage"></div> @@ -72,6 +72,12 @@ Certain settings from the configuration can be reloaded at runtime either by sending SIGHUP signal or via D-Bus' Reload call. </p> +<p> + NetworkManager does not require any configuration in <code class="literal">NetworkManager.conf</code>. Depending + on your use case, you may remove all files to restore the default configuration (factory reset). But + note that your distribution or other packages may drop configuration snippets for NetworkManager, such + that they are part of the factory default. + </p> </div> <div class="refsect1"> <a name="id-1.2.3.6"></a><h2>File Format</h2> @@ -91,7 +97,7 @@ below. </p> <p> - Minimal system settings configuration file looks like this: + A simple configuration file looks like this: </p> <pre class="programlisting"> [main] @@ -326,7 +332,9 @@ no-auto-default=* <p><code class="literal">unbound</code>: NetworkManager will talk to unbound and dnssec-triggerd, using "Conditional Forwarding" with DNSSEC support. <code class="filename">/etc/resolv.conf</code> - will be managed by dnssec-trigger daemon.</p> + will be managed by dnssec-trigger daemon. This option is + deprecated. Note that dnssec-trigger ships a NetworkManager dispatcher + script so this DNS plugin is not necessary.</p> <p><code class="literal">none</code>: NetworkManager will not modify resolv.conf. This implies <code class="literal">rc-manager</code> <code class="literal">unmanaged</code></p> @@ -456,6 +464,47 @@ no-auto-default=* index). </p></td> </tr> +<tr> +<td><p><span class="term"><code class="varname">firewall-backend</code></span></p></td> +<td><p> + The firewall backend for configuring masquerading + with shared mode. + Set to either <code class="literal">iptables</code>, <code class="literal">nftables</code> + or <code class="literal">none</code>. + <code class="literal">iptables</code> and <code class="literal">nftables</code> + require <code class="literal">iptables</code> and <code class="literal">nft</code> + application, respectively. + <code class="literal">none</code> means to skip firewall configuration if + the users wish to manage firewall themselves. + If unspecified, it will be auto detected. + </p></td> +</tr> +<tr> +<td><p><span class="term"><code class="varname">iwd-config-path</code></span></p></td> +<td> +<p> + If the value is "auto" (the default), IWD is queried for its + current state directory when it appears on D-Bus -- the + directory where IWD keeps its network configuration files -- + usually /var/lib/iwd. NetworkManager will then attempt to + write copies of new or modified Wi-Fi connection profiles, + converted into the IWD format, into this directory thus making + IWD connection properties editable. NM will overwrite existing + files without preserving their contents. + </p> +<p> + The path can also be overriden by pointing to a specific + existing and writable directory. On the other hand setting + this to an empty string or any other value disables the + profile conversion mechanism. + </p> +<p> + This mechanism allows editing connection profile settings such + as the 802.1x configuration using NetworkManager clients. + Without it such changes have no effect in IWD. + </p> +</td> +</tr> </tbody> </table></div> </div> @@ -489,21 +538,30 @@ no-auto-default=* <tr> <td><p><span class="term"><code class="varname">unmanaged-devices</code></span></p></td> <td> -<p>Set devices that should be ignored by - NetworkManager. - </p> -<p>See <a class="xref" href="NetworkManager.conf.html#device-spec" title="Device List Format">the section called “Device List Format”</a> for the syntax on how to - specify a device. - </p> +<p>Set devices that should be ignored by NetworkManager. + </p> <p> - Example: + A device unmanaged due to this option is strictly + unmanaged and cannot be overruled by using the API like + <span class="command"><strong>nmcli device set $IFNAME managed yes</strong></span>. + Also, a device that is unmanaged for other reasons, like + an udev rule, cannot be made managed with this option (e.g. by + using an <code class="literal">except:</code> specifier). + These two points make it different from the <code class="literal">device*.managed</code> + option which for that reason may be a better choice. + </p> +<p>See <a class="xref" href="NetworkManager.conf.html#device-spec" title="Device List Format">the section called “Device List Format”</a> for the syntax on how to + specify a device. </p> +<p> + Example: + </p> <pre class="programlisting"> unmanaged-devices=interface-name:em4 unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth2 </pre> <p> - </p> + </p> </td> </tr> </tbody> @@ -772,6 +830,10 @@ ipv6.ip6-privacy=0 and 100 for other profiles.</p></td> </tr> <tr> +<td><p><span class="term"><code class="varname">ipv4.required-timeout</code></span></p></td> +<td></td> +</tr> +<tr> <td><p><span class="term"><code class="varname">ipv4.route-metric</code></span></p></td> <td></td> </tr> @@ -815,6 +877,10 @@ ipv6.ip6-privacy=0 </p></td> </tr> <tr> +<td><p><span class="term"><code class="varname">ipv6.required-timeout</code></span></p></td> +<td></td> +</tr> +<tr> <td><p><span class="term"><code class="varname">ipv6.route-metric</code></span></p></td> <td></td> </tr> @@ -1005,19 +1071,32 @@ managed=1 </tr> <tr> <td><p><a name="carrier-wait-timeout"></a><span class="term"><code class="varname">carrier-wait-timeout</code></span></p></td> -<td><p> +<td> +<p> Specify the timeout for waiting for carrier in milliseconds. + The default is 5000 milliseconds. + This setting exists because certain drivers/hardware can take + a long time to detect whether the cable is plugged in. + </p> +<p> When the device loses carrier, NetworkManager does not react immediately. Instead, it waits for this timeout before considering - the link lost. Also, on startup, NetworkManager considers the + the link lost. + </p> +<p> + Also, on startup, NetworkManager considers the device as busy for this time, as long as the device has no carrier. This delays startup-complete signal and NetworkManager-wait-online. Configuring this too high means to block NetworkManager-wait-online - longer then necessary. Configuring it too low, means that NetworkManager - will declare startup-complete, although carrier is about to come - and auto-activation to kick in. - The default is 5000 milliseconds. - </p></td> + longer than necessary when booting with cable unplugged. Configuring + it too low, means that NetworkManager will declare startup-complete too + soon, although carrier is about to come and auto-activation to kick in. + Note that if a profile only has static IP configuration or Layer 3 configuration + disabled, then it can already autoconnect without carrier on the device. + Once such a profile reaches full activated state, startup-complete + is considered as reached even if the device has no carrier yet. + </p> +</td> </tr> <tr> <td><p><a name="ignore-carrier"></a><span class="term"><code class="varname">ignore-carrier</code></span></p></td> @@ -1056,6 +1135,63 @@ managed=1 </td> </tr> <tr> +<td><p><a name="keep-configuration"></a><span class="term"><code class="varname">keep-configuration</code></span></p></td> +<td> +<p> + On startup, NetworkManager tries to not interfere with + interfaces that are already configured. It does so by + generating a in-memory connection based on the interface + current configuration. + </p> +<p> + If this generated connection matches one of the existing + persistent connections, the persistent connection gets + activated. If there is no match, the generated + connection gets activated as "external", which means + that the connection is considered as active, but + NetworkManager doesn't actually touch the interface. + </p> +<p> + It is possible to disable this behavior by setting + <code class="literal">keep-configuration</code> to + <code class="literal">no</code>. In this way, on startup + NetworkManager always tries to activate the most + suitable persistent connection (the one with highest + autoconnect-priority or, in case of a tie, the one + activated most recently). + </p> +<p> + Note that when NetworkManager gets restarted, it stores + the previous state in + <code class="filename">/run/NetworkManager</code>; in particular + it saves the UUID of the connection that was previously + active so that it can be activated again after the + restart. Therefore, + <code class="literal">keep-configuration</code> does not have + any effect on service restart. + </p> +</td> +</tr> +<tr> +<td><p><a name="allowed-connections"></a><span class="term"><code class="varname">allowed-connections</code></span></p></td> +<td> +<p> + A list of connections that can be activated on the + device. See <a class="xref" href="NetworkManager.conf.html#connection-spec" title="Connection List Format">the section called “Connection List Format”</a> for the + syntax to specify a connection. If this option is not + specified, all connections can be potentially activated + on the device, provided that the connection type and + other settings match. + </p> +<p> + A notable use case for this is to filter which + connections can be activated based on how they were + created; see the <code class="literal">origin</code> keyword in + <a class="xref" href="NetworkManager.conf.html#connection-spec" title="Connection List Format">the section called “Connection List Format”</a>. + </p> +</td> +</tr> +<tr> <td><p><span class="term"><code class="varname">wifi.scan-rand-mac-address</code></span></p></td> <td><p> Configures MAC address randomization of a Wi-Fi device during @@ -1092,7 +1228,7 @@ managed=1 If <code class="literal">wifi.backend</code> is <code class="literal">iwd</code>, setting this to <code class="literal">false</code> forces IWD's autoconnect mechanism to be disabled for this device and connections will only be initiated by NetworkManager whether - commaned by a client or automatically. Leaving it <code class="literal">true</code> (default) + commanded by a client or automatically. Leaving it <code class="literal">true</code> (default) stops NetworkManager from automatically initiating connections and allows IWD to use its network ranking and scanning logic to decide the best networks to autoconnect to next. Connections' <code class="literal">autoconnect-priority</code>, @@ -1573,6 +1709,66 @@ interface-name:vboxnet*,except:interface-name:vboxnet2 <p> </p> </div> +<hr> +<div class="refsect2"> +<a name="connection-spec"></a><h3>Connection List Format</h3> +<p> + Connections can be specified using the following format: + </p> +<p> + </p> +<div class="variablelist"><table border="0" class="variablelist"> +<colgroup> +<col align="left" valign="top"> +<col> +</colgroup> +<tbody> +<tr> +<td><p><span class="term">*</span></p></td> +<td><p>Matches every connection.</p></td> +</tr> +<tr> +<td><p><span class="term">uuid:UUID</span></p></td> +<td><p>Match the connection by UUID, for example + <code class="literal">"uuid:83037490-1d17-4986-a397-01f1db3a7fc2"</code></p></td> +</tr> +<tr> +<td><p><span class="term">id=ID</span></p></td> +<td><p>Match the connection by name.</p></td> +</tr> +<tr> +<td><p><span class="term">origin:ORIGIN</span></p></td> +<td><p>Match the connection by origin, stored in the + <code class="literal">org.freedesktop.NetworkManager.origin</code> tag of the user setting. For example, use + <code class="literal">"except:origin:nm-initrd-generator"</code> to forbid activation of connections created by the + initrd generator.</p></td> +</tr> +<tr> +<td><p><span class="term">except:SPEC</span></p></td> +<td> +<p>Negative match of a connection. A negative match has higher priority then the positive + matches above.</p> +<p>If there is a list consisting only of negative matches, the behavior is the same as if there is also + match-all. That means, if none of all the negative matches is satisfied, the overall result is still a + positive match.</p> +</td> +</tr> +<tr> +<td><p><span class="term">SPEC[,;]SPEC</span></p></td> +<td> +<p>Multiple specs can be concatenated with commas or semicolons. The order does not matter as + matches are either inclusive or negative (<code class="literal">except:</code>), with negative matches having higher + priority.</p> +<p>Backslash is supported to escape the separators ';' and ',', and to express special characters such as + newline ('\n'), tabulator ('\t'), whitespace ('\s') and backslash ('\\'). Whitespace is not a separator but + will be trimmed between two specs (unless escaped as '\s').</p> +</td> +</tr> +</tbody> +</table></div> +<p> + </p> +</div> </div> <div class="refsect1"> <a name="id-1.2.3.19"></a><h2>See Also</h2> |