https://wiki.archlinux.org/api.php?action=feedcontributions&user=Tobbebobbe&feedformat=atomArchWiki - User contributions [en]2024-03-29T08:14:01ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=NetworkManager&diff=652666NetworkManager2021-02-17T13:47:51Z<p>Tobbebobbe: /* Automatically connect to VPN */ typo</p>
<hr />
<div>[[Category:Network managers]]<br />
[[Category:Red Hat]]<br />
[[cs:NetworkManager]]<br />
[[de:Networkmanager]]<br />
[[es:NetworkManager]]<br />
[[fr:NetworkManager]]<br />
[[it:NetworkManager]]<br />
[[ja:NetworkManager]]<br />
[[pt:NetworkManager]]<br />
[[zh-hans:NetworkManager]]<br />
{{Related articles start}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related articles end}}<br />
[https://wiki.gnome.org/Projects/NetworkManager/ NetworkManager] is a program for providing detection and configuration for systems to automatically connect to networks. NetworkManager's functionality can be useful for both wireless and wired networks. For wireless networks, NetworkManager prefers known wireless networks and has the ability to switch to the most reliable network. NetworkManager-aware applications can switch from online and offline mode. NetworkManager also prefers wired connections over wireless ones, has support for modem connections and certain types of VPN. NetworkManager was originally developed by Red Hat and now is hosted by the [[GNOME]] project.<br />
<br />
{{Expansion|Clear text storage of secrets is not limited to just Wi-Fi passwords. The secrets are stored in files (and folder) only accesible to root.}}<br />
<br />
{{Warning|By default, Wi-Fi passwords are stored in clear text, see [[#Encrypted Wi-Fi passwords]].}}<br />
<br />
== Installation ==<br />
<br />
NetworkManager can be [[install]]ed with the package {{Pkg|networkmanager}}, which contains a daemon, a command line interface ({{ic|nmcli}}) and a curses‐based interface ({{ic|nmtui}}). <br />
<br />
=== Enable NetworkManager ===<br />
<br />
After installation, you should [[start/enable]] {{ic|NetworkManager.service}}. Once the NetworkManager daemon is started, it will automatically connect to any available "system connections" that have already been configured. Any "user connections" or unconfigured connections will need ''nmcli'' or an applet to configure and connect.<br />
<br />
{{Note|If [[systemd-resolved]] is not [[started]], an error message will start flooding your logs. See [[#Unit dbus-org.freedesktop.resolve1.service not found]] for more info.}}<br />
<br />
=== Additional interfaces ===<br />
<br />
* {{Pkg|nm-connection-editor}} for a graphical user interface,<br />
* {{Pkg|network-manager-applet}} for a system tray applet ({{ic|nm-applet}}).<br />
<br />
{{Note|You must ensure that no other service that wants to configure the network is running; in fact, multiple networking services will conflict. You can find a list of the currently running services with {{ic|1=systemctl --type=service}} and then [[stop]] them. See [[#Configuration]] to enable the NetworkManager service.}}<br />
<br />
=== Mobile broadband support ===<br />
<br />
[[Install]] {{Pkg|modemmanager}}, {{Pkg|mobile-broadband-provider-info}} and {{Pkg|usb_modeswitch}} packages for mobile broadband connection support. See [[USB 3G Modem#NetworkManager]] for details.<br />
<br />
=== PPPoE / DSL support ===<br />
<br />
[[Install]] {{Pkg|rp-pppoe}} package for PPPoE / DSL connection support. To actually add PPPoE connection, use {{ic|1=nm-connection-editor}} and add new DSL/PPPoE connection.<br />
<br />
=== VPN support ===<br />
<br />
NetworkManager since version 1.16 has native support for [[WireGuard]], all it needs is the {{ic|wireguard}} kernel module. Read the [https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-networkmanager/ WireGuard in NetworkManager blog post] for details.<br />
<br />
Support for other VPN types is based on a plug-in system. They are provided in the following packages:<br />
<br />
* {{Pkg|networkmanager-openconnect}} for [[OpenConnect]]<br />
* [[networkmanager-openvpn]] for [[OpenVPN]]<br />
* {{Pkg|networkmanager-pptp}} for [[PPTP Client]]<br />
* {{Pkg|networkmanager-vpnc}} for [[Vpnc]]<br />
* {{Pkg|networkmanager-strongswan}} for [[strongSwan]]<br />
* {{AUR|networkmanager-fortisslvpn-git}}<br />
* {{AUR|networkmanager-iodine-git}}<br />
* {{AUR|networkmanager-libreswan}}<br />
* {{Pkg|networkmanager-l2tp}}<br />
* {{AUR|networkmanager-ssh-git}}<br />
* {{Pkg|network-manager-sstp}}<br />
<br />
{{Warning|1=There are a lot of [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues?search=VPN&state=opened bugs] (and [https://bugzilla.gnome.org/buglist.cgi?bug_status=__open__&content=VPN&product=NetworkManager old bugs]) related to VPN support. Check the daemon processes options set via the GUI correctly and double-check with each package release.}}<br />
<br />
{{Note|To have fully functioning DNS resolution when using VPN, you should set up [[#DNS caching and conditional forwarding|conditional forwarding]].}}<br />
<br />
== Usage ==<br />
<br />
NetworkManager comes with {{man|1|nmcli}} and {{man|1|nmtui}}.<br />
<br />
=== nmcli examples ===<br />
<br />
List nearby Wi-Fi networks:<br />
<br />
$ nmcli device wifi list<br />
<br />
Connect to a Wi-Fi network:<br />
<br />
$ nmcli device wifi connect ''SSID_or_BSSID'' password ''password''<br />
<br />
Connect to a hidden Wi-Fi network:<br />
<br />
$ nmcli device wifi connect ''SSID_or_BSSID'' password ''password'' hidden yes<br />
<br />
Connect to a Wi-Fi on the {{ic|wlan1}} interface:<br />
<br />
$ nmcli device wifi connect ''SSID_or_BSSID'' password ''password'' ifname wlan1 ''profile_name''<br />
<br />
Disconnect an interface:<br />
<br />
$ nmcli device disconnect ifname eth0<br />
<br />
Get a list of connections with their names, UUIDs, types and backing devices:<br />
<br />
$ nmcli connection show<br />
<br />
Activate a connection (i.e. connect to a network with an existing profile):<br />
<br />
$ nmcli connection up ''name_or_uuid''<br />
<br />
Delete a connection:<br />
<br />
$ nmcli connection delete ''name_or_uuid''<br />
<br />
See a list of network devices and their state:<br />
<br />
$ nmcli device<br />
<br />
Turn off Wi-Fi:<br />
<br />
$ nmcli radio wifi off<br />
<br />
=== Edit a connection ===<br />
<br />
For a comprehensive list of settings, see {{man|5|nm-settings}}.<br />
<br />
Firstly you need to get list of connections:<br />
<br />
{{hc|$ nmcli connection|<nowiki><br />
NAME UUID TYPE DEVICE<br />
Wired connection 2 e7054040-a421-3bef-965d-bb7d60b7cecf ethernet enp5s0<br />
Wired connection 1 997f2782-f0fc-301d-bfba-15421a2735d8 ethernet enp0s25<br />
MY-HOME-WIFI-5G 92a0f7b3-2eba-49ab-a899-24d83978f308 wifi --<br />
</nowiki>}}<br />
<br />
Here you can use the first column as connection-id used later. In this example we pick {{ic|Wired connection 2}} as a connection-id.<br />
<br />
You have three methods to configure a connection {{ic|Wired connection 2}} after it has been created:<br />
<br />
; nmcli interactive editor<br />
: {{ic|nmcli connection edit 'Wired connection 2'}}.<br> Usage is well documented from the editor.<br />
<br />
; nmcli command line interface<br />
: {{ic|nmcli connection modify 'Wired connection 2' ''setting''.''property'' ''value''}}. See {{man|1|nmcli}} for usage. For example you can change its IPv4 route metric to 200 using {{ic|nmcli connection modify 'Wired connection 2' ipv4.route-metric 200}} command.<br />
To remove a setting pass an empty field ("") to it like this:<br />
: {{ic|nmcli connection modify 'Wired connection 2' ''setting''.''property'' ""}}<br />
<br />
; Connection file<br />
: In {{ic|/etc/NetworkManager/system-connections/}}, modify the corresponding {{ic|Wired connection 2.nmconnection}} file .<br> Do not forget to reload the configuration file with {{ic|nmcli connection reload}}.<br />
<br />
== Front-ends ==<br />
<br />
To configure and have easy access to NetworkManager, most users will want to install an applet. This GUI front-end usually resides in the system tray (or notification area) and allows network selection and configuration of NetworkManager. Various desktop environments have their own applet. Otherwise you can use [[#nm-applet]].<br />
<br />
=== GNOME ===<br />
<br />
[[GNOME]] has a built-in tool, accessible from the Network settings.<br />
<br />
=== KDE Plasma ===<br />
<br />
[[Install]] the {{Pkg|plasma-nm}} package. After that, add it to the KDE taskbar via the ''Panel options > Add widgets > Networks'' menu.<br />
<br />
=== nm-applet ===<br />
<br />
{{Pkg|network-manager-applet}} is a GTK 3 front-end which works under Xorg environments with a systray.<br />
<br />
To store connection secrets install and configure [[GNOME/Keyring]].<br />
<br />
Be aware that after enabling the tick-box option {{ic|Make available to other users}} for a connection, NetworkManager stores the password in plain-text, though the respective file is accessible only to root (or other users via {{ic|nm-applet}}). See [[#Encrypted Wi-Fi passwords]].<br />
<br />
In order to run {{ic|nm-applet}} without a systray, you can use {{Pkg|trayer}} or {{Pkg|stalonetray}}. For example, you can add a script like this one in your path:<br />
<br />
{{hc|nmgui|<nowiki><br />
#!/bin/sh<br />
nm-applet 2>&1 > /dev/null &<br />
stalonetray 2>&1 > /dev/null<br />
killall nm-applet<br />
</nowiki>}}<br />
<br />
When you close the ''stalonetray'' window, it closes {{ic|nm-applet}} too, so no extra memory is used once you are done with network settings.<br />
<br />
The applet can show notifications for events such as connecting to or disconnecting from a WiFi network. For these notifications to display, ensure that you have a notification server installed - see [[Desktop notifications]]. If you use the applet without a notification server, you might see some messages in stdout/stderr, and the app might hang. See [https://bugzilla.gnome.org/show_bug.cgi?id=788313].<br />
<br />
In order to run {{ic|nm-applet}} with such notifications disabled, start the applet with the following command:<br />
<br />
$ nm-applet --no-agent<br />
<br />
{{Tip|{{ic|nm-applet}} might be started automatically with a [[XDG Autostart|autostart desktop file]], to add the --no-agent option modify the Exec line there, i.e.<br />
<br />
{{bc|1=Exec=nm-applet --no-agent}}<br />
<br />
}}<br />
<br />
{{Warning|On [[i3]], if nm-applet is started with the {{ic|--no-agent}} option, it is not possible to connect to a new encrypted WiFi network by clicking on the item list because no password input dialogue window will pop out. [[journal]] will show {{ic|no secrets: No agents were available for this request}}.}}<br />
<br />
==== Appindicator ====<br />
<br />
As of version 1.18.0 Appindicator support is [https://github.com/archlinux/svntogit-packages/commit/7640a2bd557fe84813207ef4d5e35bb5aece6c54 available] in the official {{Pkg|network-manager-applet}} package. To use nm-applet in an Appindicator environment start the applet with the following command:<br />
<br />
$ nm-applet --indicator<br />
<br />
=== networkmanager-dmenu ===<br />
<br />
Alternatively there is {{AUR|networkmanager-dmenu-git}} which is a small script to manage NetworkManager connections with [[dmenu]] or [[rofi]] instead of {{ic|nm-applet}}. It provides all essential features such as connection to existing NetworkManager wifi or wired connections, connect to new wifi connections, requests passphrase if required, connect to existing VPN connections, enable/disable networking, launch ''nm-connection-editor'' GUI, connect to Bluetooth networks.<br />
<br />
== Configuration ==<br />
<br />
NetworkManager will require some additional steps to be able run properly. Make sure you have configured {{ic|/etc/hosts}} as described in [[Network configuration#Set the hostname]] section.<br />
<br />
NetworkManager has a global configuration file at {{ic|/etc/NetworkManager/NetworkManager.conf}}. Additional configuration files can be placed in {{ic|/etc/NetworkManager/conf.d/}}. Usually no configuration needs to be done to the global defaults.<br />
<br />
After editing a configuration file, the changes can be applied by running:<br />
<br />
# nmcli general reload<br />
<br />
=== Enable NetworkManager Wait Online ===<br />
<br />
{{Out of date|{{ic|NetworkManager.service}} has {{ic|1=Also=NetworkManager-wait-online.service}} in the {{ic|[Install]}} section.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/167e42a87e97ed7fb26a4263c22f1774716ac51b] If {{ic|NetworkManager.service}} was [[enable]]d before the change, it needs to be [[enable|reenabled]].}}<br />
<br />
If you have services which fail if they are started before the network is up, you may use {{ic|NetworkManager-wait-online.service}} in addition to {{ic|NetworkManager.service}}. This is, however, rarely necessary because most networked daemons start up okay, even if the network has not been configured yet.<br />
<br />
In some cases, the service will still fail to start successfully on boot due to the timeout setting in {{ic|/usr/lib/systemd/system/NetworkManager-wait-online.service}} being too short. Change the default timeout from 30 to a higher value.<br />
<br />
=== Set up PolicyKit permissions ===<br />
<br />
See [[General troubleshooting#Session permissions]] for setting up a working session.<br />
<br />
With a working session, you have several options for granting the necessary privileges to NetworkManager:<br />
<br />
* ''Option 1.'' Run a [[Polkit]] authentication agent when you log in, such as {{ic|/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1}} (part of {{Pkg|polkit-gnome}}). You will be prompted for your password whenever you add or remove a network connection.<br />
* ''Option 2.'' [[Users and groups#Group management|Add]] yourself to the {{ic|wheel}} group. You will not have to enter your password, but your user account may be granted other permissions as well, such as the ability to use [[sudo]] without entering the root password.<br />
* ''Option 3.'' [[Users and groups#Group management|Add]] yourself to the {{ic|network}} group and create the following file:<br />
<br />
{{hc|/etc/polkit-1/rules.d/50-org.freedesktop.NetworkManager.rules|<nowiki><br />
polkit.addRule(function(action, subject) {<br />
if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0 && subject.isInGroup("network")) {<br />
return polkit.Result.YES;<br />
}<br />
});<br />
</nowiki>}}<br />
<br />
: All users in the {{ic|network}} group will be able to add and remove networks without a password. This will not work under [[systemd]] if you do not have an active session with ''systemd-logind''.<br />
<br />
=== Proxy settings ===<br />
<br />
NetworkManager does not directly handle proxy settings, but if you are using [[GNOME]] or [[KDE]], you could use [http://marin.jb.free.fr/proxydriver/ proxydriver] which handles proxy settings using NetworkManager's information. proxydriver is found in the package {{AUR|proxydriver}}.<br />
<br />
In order for ''proxydriver'' to be able to change the proxy settings, you would need to execute this command, as part of the GNOME startup process (see [[GNOME#Autostart]]).<br />
<br />
xhost +si:localuser:''username''<br />
<br />
See also [[Proxy settings]].<br />
<br />
=== Checking connectivity ===<br />
<br />
NetworkManager can try to reach a page on Internet when connecting to a network. {{Pkg|networkmanager}} is configured by default in {{ic|/usr/lib/NetworkManager/conf.d/20-connectivity.conf}} to check connectivity to archlinux.org. To use a different webserver or disable connectivity checking create {{ic|/etc/NetworkManager/conf.d/20-connectivity.conf}}, see {{man|5|NetworkManager.conf|CONNECTIVITY SECTION}}. Below is an example of using GNOME servers (it does not require the use of [[GNOME]]):<br />
<br />
{{hc|/etc/NetworkManager/conf.d/20-connectivity.conf|<nowiki><br />
[connectivity]<br />
uri=http://nmcheck.gnome.org/check_network_status.txt<br />
</nowiki>}}<br />
<br />
{{Note|Although automatic connectivity checks are a potential privacy leak, the official archlinux.org default connectivity URL is committed to not logging any access. See [https://gitlab.archlinux.org/archlinux/infrastructure/-/commit/68fbaca2ef9f31f624f117899848f4288d6b39d1].}}<br />
<br />
=== Captive portals ===<br />
<br />
{{Style|Complex scripts should not be maintained on the wiki.}}<br />
<br />
For those behind a [[Wikipedia:Captive portal|captive portal]], the desktop manager may automatically open a window asking for credentials. If your desktop does not, you can use {{Pkg|capnet-assist}} package (however, it currently it has a broken NetworkManager dispatcher script). Alternatively, you can create a NetworkManager dispatcher script with the following content:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/90-open_captive_portal|<nowiki><br />
#!/bin/sh -e<br />
# Script to dispatch NetworkManager events<br />
#<br />
# Runs shows a login webpage on walled garden networks.<br />
# See NetworkManager(8) for further documentation of the dispatcher events.<br />
<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin<br />
<br />
if [ -x "/usr/bin/logger" ]; then<br />
logger="/usr/bin/logger -s -t captive-portal"<br />
else<br />
logger=":"<br />
fi<br />
<br />
wait_for_process() {<br />
PNAME=$1<br />
while [ -z "$(/usr/bin/pgrep $PNAME)" ]; do<br />
sleep 3;<br />
done<br />
}<br />
<br />
#launch the browser, but on boot we need to wait that nm-applet starts<br />
start_browser() {<br />
local user="$1"<br />
local display="$2"<br />
<br />
export DISPLAY="$display"<br />
wait_for_process nm-applet<br />
<br />
export XAUTHORITY="/home/$user/.Xauthority"<br />
<br />
$logger "Running browser as '$user' with display '$display' to login in captive portal"<br />
sudo -u "$user" --preserve-env=DISPLAY,XAUTHORITY -H xdg-open http://capnet.elementary.io 2>&1 > /dev/null<br />
}<br />
<br />
# Run the right scripts<br />
case "$2" in<br />
connectivity-change)<br />
$logger -p user.debug "dispatcher script triggered on connectivity change: $CONNECTIVITY_STATE"<br />
if [ "$CONNECTIVITY_STATE" = "PORTAL" ]; then<br />
# Match last column of who's output with ' :[at least one digit] '<br />
who | awk '$NF ~ /\(:[0-9]+\)/ { print $1 " " substr($NF, 2, length($NF)-2) };' | \<br />
while read user display; do<br />
start_browser $user $display || $logger -p user.err "Failed for user: '$user' display: '$display'"<br />
done<br />
fi<br />
;;<br />
*)<br />
# In a down phase<br />
exit 0<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
You will need to [[restart]] {{ic|NetworkManager.service}} or reboot for this to start working. Once you do, the dispatcher script should open a login window once it detects you are behind a captive portal.<br />
<br />
Another solution is {{AUR|captive-browser-git}} based on Google Chrome.<br />
<br />
=== DHCP client ===<br />
<br />
By default NetworkManager uses its internal DHCP client. The internal DHCPv4 plugin is based on the [https://nettools.github.io/n-dhcp4/ nettools' n-dhcp4] library, while the internal DHCPv6 plugin is made from code based on systemd-networkd.<br />
<br />
To use ISC’s DHCP client, [[install]] {{Pkg|dhclient}}. To change the DHCP client backend, set the option {{ic|1=main.dhcp=''dhcp_client_name''}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}. E.g.:<br />
<br />
{{hc|1=/etc/NetworkManager/conf.d/dhcp-client.conf|2=<br />
[main]<br />
dhcp=dhclient<br />
}}<br />
<br />
{{Note|<br />
* Do not enable the systemd units shipped with the {{Pkg|dhclient}} and {{Pkg|dhcpcd}} packages. They will conflict with NetworkManager, see the note in [[#Installation]] for details.<br />
* NetworkManger does not support dhcpcd ≥ 9.0.0. See {{Bug|66231}}.<br />
}}<br />
<br />
=== DNS management ===<br />
<br />
NetworkManager's DNS management is described in the GNOME project's wiki page—[https://wiki.gnome.org/Projects/NetworkManager/DNS Projects/NetworkManager/DNS].<br />
<br />
==== DNS caching and conditional forwarding ====<br />
<br />
NetworkManager has a plugin to enable DNS caching and conditional forwarding ([https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/143 previously] called "split DNS" in NetworkManager's documentation) using [[dnsmasq]] or [[systemd-resolved]]. The advantages of this setup is that DNS lookups will be cached, shortening resolve times, and DNS lookups of VPN hosts will be routed to the relevant VPN's DNS servers. This is especially useful if you are connected to more than one VPN.<br />
<br />
===== dnsmasq =====<br />
<br />
Make sure {{Pkg|dnsmasq}} has been installed. Then set {{ic|1=main.dns=dnsmasq}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=dnsmasq<br />
}}<br />
<br />
Now run {{ic|nmcli general reload}} as root. NetworkManager will automatically start dnsmasq and add {{ic|127.0.0.1}} to {{ic|/etc/resolv.conf}}. The original DNS servers can be found in {{ic|/run/NetworkManager/no-stub-resolv.conf}}. You can verify dnsmasq is being used by doing the same DNS lookup twice with {{ic|drill example.com}} and verifying the server and query times.<br />
<br />
{{Note|<br />
* You do not need to start {{ic|dnsmasq.service}} or edit {{ic|/etc/dnsmasq.conf}}. NetworkManager will start dnsmasq without using the systemd service and without reading the dnsmasq's default configuration file(s).<br />
* The dnsmasq instance started by NetworkManager will bind to {{ic|127.0.0.1:53}}, you cannot run any other software (including {{ic|dnsmasq.service}}) on the same address and port.<br />
}}<br />
<br />
====== Custom dnsmasq configuration ======<br />
<br />
Custom configurations can be created for ''dnsmasq'' by creating configuration files in {{ic|/etc/NetworkManager/dnsmasq.d/}}. For example, to change the size of the DNS cache (which is stored in RAM):<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/cache.conf|2=<br />
cache-size=1000<br />
}}<br />
<br />
You can check the configuration file syntax with:<br />
<br />
dnsmasq --test --conf-file=/dev/null --conf-dir=/etc/NetworkManager/dnsmasq.d<br />
<br />
See {{man|8|dnsmasq}} for all available options.<br />
<br />
====== IPv6 ======<br />
<br />
{{Accuracy|This does not solve the issue because NetworkManager does not add {{ic|::1}} to {{ic|/etc/resolv.conf}}. Unless {{ic|@::1}} is manually passed to drill, it will still fail with {{ic|Error: error sending query: No (valid) nameservers defined in the resolver}}.}}<br />
<br />
Enabling {{ic|dnsmasq}} in NetworkManager may break IPv6-only DNS lookups (i.e. {{ic|drill -6 [hostname]}}) which would otherwise work. In order to resolve this, creating the following file will configure ''dnsmasq'' to also listen to the IPv6 loopback:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/ipv6-listen.conf|2=<br />
listen-address=::1<br />
}}<br />
<br />
In addition, {{ic|dnsmasq}} also does not prioritize upstream IPv6 DNS. Unfortunately NetworkManager does not do this ([https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/936712 Ubuntu Bug]). A workaround would be to disable IPv4 DNS in the NetworkManager config, assuming one exists.<br />
<br />
====== DNSSEC ======<br />
<br />
The dnsmasq instance started by NetworkManager by default will not validate [[DNSSEC]] since it is started with the {{ic|--proxy-dnssec}} option. It will trust whatever DNSSEC information it gets from the upstream DNS server.<br />
<br />
For dnsmasq to properly validate DNSSEC, thus breaking DNS resolution with name servers that do not support it, create the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/dnssec.conf|2=<br />
conf-file=/usr/share/dnsmasq/trust-anchors.conf<br />
dnssec<br />
}}<br />
<br />
===== systemd-resolved =====<br />
<br />
{{Expansion|NetworkManager 1.16 adds a new setting {{ic|main.systemd-resolved}}[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383] (enabled by default). It unconditionally sends DNS configuration to systemd-resolved. Related to "Preserving resolv.conf" from [[systemd-resolved#DNS]]?}}<br />
<br />
NetworkManager can use [[systemd-resolved]] as a DNS resolver and cache. Make sure that ''systemd-resolved'' is properly configured and that {{ic|systemd-resolved.service}} is [[started]] before using it.<br />
<br />
systemd-resolved will be used automatically if {{ic|/etc/resolv.conf}} is a [[Systemd-resolved#DNS|symlink]] to {{ic|/run/systemd/resolve/stub-resolv.conf}}, {{ic|/run/systemd/resolve/resolv.conf}} or {{ic|/usr/lib/systemd/resolv.conf}}.<br />
<br />
You can enable it explicitly by setting {{ic|1=main.dns=systemd-resolved}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=systemd-resolved<br />
}}<br />
<br />
===== DNS resolver with an openresolv subscriber =====<br />
<br />
If [[openresolv]] has a subscriber for your local [[DNS resolver]], set up the subscriber and [[#Use openresolv|configure NetworkManager to use openresolv]].<br />
<br />
Because NetworkManager advertises a single "interface" to ''resolvconf'', it is not possible to implement conditional forwarding between two NetworkManager connections. See [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 NetworkManager issue 153].<br />
<br />
This can be partially mitigated if you set {{ic|1=private_interfaces="*"}} in {{ic|/etc/resolvconf.conf}}[https://roy.marples.name/projects/openresolv/configuration/]. Any queries for domains that are not in search domain list will not get forwarded. They will be handled according to the local resolver's configuration, for example, forwarded to another DNS server or resolved recursively from the DNS root.<br />
<br />
==== Custom DNS servers ====<br />
<br />
===== Setting custom global DNS servers =====<br />
<br />
To set DNS servers for all connections, specify them in {{man|5|NetworkManager.conf}} using the syntax {{ic|1=servers=''serveripaddress1'',''serveripaddress2'',''serveripaddress3''}} in a section named {{ic|[global-dns-domain-*]}}. For example:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns-servers.conf|2=<br />
[global-dns-domain-*]<br />
servers=::1,127.0.0.1<br />
}}<br />
<br />
{{Note|<br />
* If you use [[#DNS caching and conditional forwarding|NetworkManager's dnsmasq or systemd-resolved plugin]] or [[#DNS resolver with an openresolv subscriber|openresolv subscribers]], then do not specify loopback addresses with the {{ic|1=servers=}} option, it can break DNS resolution.<br />
* The specified servers do not get sent to [[systemd-resolved]], the connection's DNS servers are used instead.<br />
}}<br />
<br />
===== Setting custom DNS servers in a connection =====<br />
<br />
====== Setting custom DNS servers in a connection (GUI) ======<br />
<br />
Setup will depend on the type of front-end used; the process usually involves right-clicking on the applet, editing (or creating) a profile, and then choosing DHCP type as ''Automatic (specify addresses)''. The DNS addresses will need to be entered and are usually in this form: {{ic|127.0.0.1, ''DNS-server-one'', ...}}.<br />
<br />
====== Setting custom DNS servers in a connection (nmcli / connection file) ======<br />
<br />
To setup DNS Servers per connection, you can use the {{ic|dns}} field (and the associated {{ic|dns-search}} and {{ic|dns-options}}) in the [[#Edit a connection|connection settings]]. <br />
<br />
If {{ic|method}} is set to {{ic|auto}} (when you use DHCP), you need to set {{ic|ignore-auto-dns}} to {{ic|yes}}.<br />
<br />
==== /etc/resolv.conf ====<br />
<br />
NetworkManager's {{ic|/etc/resolv.conf}} management mode is configured with the {{ic|main.rc-manager}} setting. The default {{ic|auto}} mode chooses how {{ic|/etc/resolv.conf}} is managed in the following order:<br />
<br />
* If {{ic|/etc/resolv.conf}} is [[File permissions and attributes#File attributes|immutable]], then the file [[#Unmanaged /etc/resolv.conf|is not touched at all]]. This is the equivalent of {{ic|1=main.rc-manager=unmanaged}}.<br />
* If {{ic|/etc/resolv.conf}} is a symlink to {{ic|/run/systemd/resolve/stub-resolv.conf}}, {{ic|/run/systemd/resolve/resolv.conf}} or {{ic|/usr/lib/systemd/resolv.conf}}, then [[#systemd-resolved|systemd-resolved is used]]. This is the equivalent of {{ic|1=main.rc-manager=systemd-resolved}}.<br />
* If {{ic|/usr/bin/resolvconf}} exists, then [[#Use openresolv|resolvconf is used]]. This is the equivalent of {{ic|1=main.rc-manager=resolvconf}}.<br />
* If {{ic|/etc/resolv.conf}} is a regular file, then NetworkManager writes to it directly. This is the equivalent of {{ic|1=main.rc-manager=file}}.<br />
<br />
Further details are provided in the {{man|5|NetworkManager.conf}} man page.<br />
<br />
{{Tip|Using openresolv allows NetworkManager to coexists with other ''resolvconf'' supporting software or, for example, to run a local DNS caching and split-DNS resolver for which openresolv has a [[openresolv#Subscribers|subscriber]]. Note that conditional forwarding is [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 not yet fully supported] when using NetworkManager with openresolv.}}<br />
<br />
''NetworkManager'' also offers hooks via so called dispatcher scripts that can be used to alter the {{ic|/etc/resolv.conf}} after network changes. See [[#Network services with NetworkManager dispatcher]] and {{man|8|NetworkManager}} for more information.<br />
<br />
{{Note|<br />
* If NetworkManager is configured to use either [[#dnsmasq|dnsmasq]] or [[#systemd-resolved|systemd-resolved]], then the appropriate loopback addresses will be written to {{ic|/etc/resolv.conf}}.<br />
* The {{ic|resolv.conf}} file NetworkManager writes or would write to {{ic|/etc/resolv.conf}} can be found at {{ic|/run/NetworkManager/resolv.conf}}.<br />
* A {{ic|resolv.conf}} file with the acquired name servers and search domains can be found at {{ic|/run/NetworkManager/no-stub-resolv.conf}}.<br />
}}<br />
<br />
===== Unmanaged /etc/resolv.conf =====<br />
<br />
To stop NetworkManager from touching {{ic|/etc/resolv.conf}}, set {{ic|1=main.dns=none}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=none<br />
}}<br />
<br />
{{Tip|You might also want to set {{ic|1=main.systemd-resolved=false}}, so that NetworkManager does not send the DNS configuration to [[systemd-resolved]].}}<br />
<br />
{{Note|See [[#DNS caching and conditional forwarding]], to configure NetworkManager using other DNS backends like [[dnsmasq]] and [[systemd-resolved]], instead of using {{ic|1=main.dns=none}}.}}<br />
<br />
After that {{ic|/etc/resolv.conf}} might be a broken symlink that you will need to remove. Then, just create a new {{ic|/etc/resolv.conf}} file.<br />
<br />
===== Use openresolv =====<br />
<br />
{{Tip|NetworkManager will automatically use ''resolvconf'' unless {{ic|/etc/resolv.conf}} is immutable or a symlink to one of systemd-resolved's {{ic|resolv.conf}} files.}}<br />
<br />
{{Note|NetworkManager does not support using systemd-resolved's ''resolvconf'' interface ({{man|1|resolvectl|COMPATIBILITY WITH RESOLVCONF(8)}}) which is provided by {{Pkg|systemd-resolvconf}}.<br />
* Do not set {{ic|1=main.rc-manager=resolvconf}} when using [[systemd-resolved]], instead make sure to [[systemd-resolved#DNS|correctly create the /etc/resolv.conf symlink]] or [[#systemd-resolved|configure NetworkManager to use systemd-resolved explicitly]].<br />
* Make sure the {{Pkg|systemd-resolvconf}} package is not installed when systemd-resolved is not used. Unless {{ic|systemd-resolved.service}} started, it will break all networking software (not just NetworkManager) that use resolvconf.<br />
}}<br />
<br />
To explicitly configure NetworkManager to use [[openresolv]], set {{ic|1=main.rc-manager=resolvconf}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/rc-manager.conf|2=<br />
[main]<br />
rc-manager=resolvconf<br />
}}<br />
<br />
=== Firewall ===<br />
<br />
You can assign a [[firewalld]] zone based on your current connection. For example a restrictive firewall when at work, and a less restrictive one when at home.<br />
<br />
This can also be done with [[#Network services with NetworkManager dispatcher|NetworkManager dispatcher]].<br />
<br />
== Network services with NetworkManager dispatcher ==<br />
<br />
There are quite a few network services that you will not want running until NetworkManager brings up an interface. NetworkManager has the ability to start services when you connect to a network and stop them when you disconnect (e.g. when using [[NFS]], [[SMB]] and [[NTPd]]).<br />
<br />
To activate the feature you need to [[enable]] and [[start]] the {{ic|NetworkManager-dispatcher.service}}.<br />
<br />
Once the service is active, scripts can be added to the {{ic|/etc/NetworkManager/dispatcher.d}} directory.<br />
<br />
Scripts must be owned by '''root''', otherwise the dispatcher will not execute them. For added security, set group [[ownership]] to root as well:<br />
<br />
# chown root:root /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
Make sure the file has correct permissions:<br />
<br />
# chmod 755 /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
The scripts will be run in alphabetical order at connection time, and in reverse alphabetical order at disconnect time. To ensure what order they come up in, it is common to use numerical characters prior to the name of the script (e.g. {{ic|10-portmap}} or {{ic|30-netfs}} (which ensures that the ''portmapper'' is up before NFS mounts are attempted).<br />
<br />
Scripts will receive the following arguments:<br />
<br />
* '''Interface name:''' e.g. {{ic|eth0}}<br />
* '''Interface status:''' ''up'' or ''down''<br />
* '''VPN status:''' ''vpn-up'' or ''vpn-down''<br />
<br />
{{Warning|If you connect to foreign or public networks, be aware of what services you are starting and what servers you expect to be available for them to connect to. You could make a security hole by starting the wrong services while connected to a public network.}}<br />
<br />
=== Avoiding the dispatcher timeout ===<br />
<br />
If the above is working, then this section is not relevant. However, there is a general problem related to running dispatcher scripts which take longer to be executed. Initially an internal timeout of three seconds only was used. If the called script did not complete in time, it was killed. Later the timeout was extended to about 20 seconds (see the [https://bugzilla.redhat.com/show_bug.cgi?id=982734 Bugtracker] for more information). If the timeout still creates the problem, a work around may be to modify the dispatcher service file {{ic|/usr/lib/systemd/system/NetworkManager-dispatcher.service}} to remain active after exit: <br />
<br />
{{hc|/etc/systemd/system/NetworkManager-dispatcher.service.d/remain_after_exit.conf|2=<br />
[Service]<br />
RemainAfterExit=yes<br />
}}<br />
<br />
Now start and enable the modified {{ic|NetworkManager-dispatcher}} service.<br />
<br />
{{Warning|Adding the {{ic|RemainAfterExit}} line to it will prevent the dispatcher from closing. Unfortunately, the dispatcher '''has''' to close before it can run your scripts again. With it the dispatcher will not time out but it also will not close, which means that the scripts will only run once per boot. Therefore, do not add the line unless the timeout is definitely causing a problem.}}<br />
<br />
=== Dispatcher examples ===<br />
<br />
==== Mount remote folder with sshfs ====<br />
<br />
As the script is run in a very restrictive environment, you have to export {{ic|SSH_AUTH_SOCK}} in order to connect to your SSH agent. There are different ways to accomplish this, see [https://bbs.archlinux.org/viewtopic.php?pid=1042030#p1042030 this message] for more information. The example below works with [[GNOME Keyring]], and will ask you for the password if not unlocked already. In case NetworkManager connects automatically on login, it is likely ''gnome-keyring'' has not yet started and the export will fail (hence the sleep). The {{ic|UUID}} to match can be found with the command {{ic|nmcli connection status}} or {{ic|nmcli connection list}}. <br />
<br />
{{bc|<nowiki><br />
#!/bin/sh<br />
USER='username'<br />
REMOTE='user@host:/remote/path'<br />
LOCAL='/local/path'<br />
<br />
interface=$1 status=$2<br />
if [ "$CONNECTION_UUID" = "</nowiki>''uuid''<nowiki>" ]; then<br />
case $status in<br />
up)<br />
SSH_AUTH_SOCK=$(find /tmp -maxdepth 1 -type s -user "$USER" -name 'ssh')<br />
export SSH_AUTH_SOCK<br />
su "$USER" -c "sshfs $REMOTE $LOCAL"<br />
;;<br />
down)<br />
fusermount -u "$LOCAL"<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
==== Mounting of SMB shares ====<br />
<br />
Some [[SMB]] shares are only available on certain networks or locations (e.g. at home). You can use the dispatcher to only mount SMB shares that are present at your current location.<br />
<br />
The following script will check if we connected to a specific network and mount shares accordingly:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-mount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
# Find the connection UUID with "nmcli connection show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
if [ "$2" = "up" ]; then<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
mount /your/mount/point & <br />
# add more shares as needed<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The following script will unmount all SMB shares before a software initiated disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/pre-down.d/30-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|Make sure this script is located in the {{ic|pre-down.d}} sub-directory as shown above, otherwise it will unmount all shares on any connection state change.}}<br />
<br />
The following script will attempt to unmount all SMB shares following an unexpected disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/40-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
if [ "$2" = "down" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|<br />
* Since NetworkManager 0.9.8, the ''pre-down'' and ''down'' events are not executed on shutdown or restart, see [https://bugzilla.gnome.org/show_bug.cgi?id&#61;701242 this bug report] for more info.<br />
* The previous ''umount'' scripts are still prone to leaving applications actually accessing the mount to 'hang'.<br />
}}<br />
<br />
An alternative is to use the script as seen in [[NFS#Using a NetworkManager dispatcher]]:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-smb.sh|<nowiki><br />
#!/bin/bash<br />
<br />
# Find the connection UUID with "nmcli con show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
WANTED_CON_UUID="CHANGE-ME-NOW-9c7eff15-010a-4b1c-a786-9b4efa218ba9"<br />
<br />
if [[ "$CONNECTION_UUID" == "$WANTED_CON_UUID" ]]; then<br />
<br />
# Script parameter $1: NetworkManager connection name, not used<br />
# Script parameter $2: dispatched event<br />
<br />
case "$2" in<br />
"up")<br />
mount -a -t cifs<br />
;;<br />
"pre-down");&<br />
"vpn-pre-down")<br />
umount -l -a -t cifs >/dev/null<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|This script ignores mounts with the {{ic|noauto}} option, remove this mount option or use {{ic|auto}} to allow the dispatcher to manage these mounts.}}<br />
<br />
Create a symlink inside {{ic|/etc/NetworkManager/dispatcher.d/pre-down/}} to catch the {{ic|pre-down}} events:<br />
<br />
# ln -s ../30-smb.sh /etc/NetworkManager/dispatcher.d/pre-down.d/30-smb.sh<br />
<br />
==== Mounting of NFS shares ====<br />
<br />
See [[NFS#Using a NetworkManager dispatcher]].<br />
<br />
==== Use dispatcher to automatically toggle wireless depending on LAN cable being plugged in ====<br />
<br />
The idea is to only turn Wi-Fi on when the LAN cable is unplugged (for example when detaching from a laptop dock), and for Wi-Fi to be automatically disabled, once a LAN cable is plugged in again. <br />
<br />
Create the following dispatcher script[https://superuser.com/questions/233448/disable-wlan-if-wired-cable-network-is-available], replacing {{ic|1=LAN_interface}} with yours.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/wlan_auto_toggle.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$1" = "LAN_interface" ]; then<br />
case "$2" in<br />
up)<br />
nmcli radio wifi off<br />
;;<br />
down)<br />
nmcli radio wifi on<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|You can get a list of interfaces using [[#nmcli examples|nmcli]]. The ethernet (LAN) interfaces start with {{ic|en}}, e.g. {{ic|1=enp0s5}}}}<br />
<br />
==== Use dispatcher to connect to a VPN after a network connection is established ====<br />
<br />
In this example we want to connect automatically to a previously defined VPN connection after connecting to a specific Wi-Fi network. First thing to do is to create the dispatcher script that defines what to do after we are connected to the network.<br />
<br />
{{Note|This script will require {{Pkg|wireless_tools}} in order to use {{ic|iwgetid}}.}}<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME"<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you would like to attempt to automatically connect to VPN for all Wi-Fi networks, you can use the following definition of the ESSID: {{ic|1=ESSID=$(iwgetid -r)}}. Remember to set the script's permissions [[#Network services with NetworkManager dispatcher|accordingly]]. <br />
<br />
Trying to connect with the above script may still fail with {{ic|NetworkManager-dispatcher.service}} complaining about 'no valid VPN secrets', because of [https://developer.gnome.org/NetworkManager/0.9/secrets-flags.html the way VPN secrets are stored]. Fortunately, there are different options to give the above script access to your VPN password.<br />
<br />
1: One of them requires editing the VPN connection configuration file to make NetworkManager store the secrets by itself rather than inside a keyring [https://bugzilla.redhat.com/show_bug.cgi?id=710552 that will be inaccessible for root]: open up {{ic|/etc/NetworkManager/system-connections/''name of your VPN connection''}} and change the {{ic|password-flags}} and {{ic|secret-flags}} from {{ic|1}} to {{ic|0}}.<br />
<br />
If that alone does not work, you may have to create a {{ic|passwd-file}} in a safe location with the same permissions and ownership as the dispatcher script, containing the following:<br />
<br />
{{hc|/path/to/passwd-file|<br />
vpn.secrets.password:YOUR_PASSWORD<br />
}}<br />
<br />
The script must be changed accordingly, so that it gets the password from the file:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME" passwd-file /path/to/passwd-file<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
2: Alternatively, change the {{ic|password-flags}} and put the password directly in the configuration file adding the section {{ic|vpn-secrets}}:<br />
<br />
[vpn]<br />
....<br />
password-flags=0<br />
<br />
[vpn-secrets]<br />
password=''your_password''<br />
<br />
{{Note|It may now be necessary to re-open the NetworkManager connection editor and save the VPN passwords/secrets again.}}<br />
<br />
==== Use dispatcher to disable IPv6 on VPN provider connections ====<br />
<br />
Many [[:Category:VPN providers|commercial VPN providers]] support only IPv4. That means all IPv6 traffic bypasses the VPN and renders it virtually useless. To avoid this, dispatcher can be used to disable all IPv6 traffic for the time a VPN connection is up.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/10-vpn-ipv6|<nowiki><br />
#!/bin/sh<br />
<br />
case "$2" in<br />
vpn-up)<br />
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
vpn-down)<br />
echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
==== OpenNTPD ====<br />
<br />
See [[OpenNTPD#Using NetworkManager dispatcher]].<br />
<br />
== Testing ==<br />
<br />
NetworkManager applets are designed to load upon login so no further configuration should be necessary for most users. If you have already disabled your previous network settings and disconnected from your network, you can now test if NetworkManager will work. The first step is to [[start]] {{ic|NetworkManager.service}}.<br />
<br />
Some applets will provide you with a {{ic|.desktop}} file so that the NetworkManager applet can be loaded through the application menu. If it does not, you are going to either have to discover the command to use or logout and login again to start the applet. Once the applet is started, it will likely begin polling network connections with for auto-configuration with a DHCP server.<br />
<br />
To start the GNOME applet in non-xdg-compliant window managers like [[awesome]]:<br />
<br />
nm-applet --sm-disable &<br />
<br />
For static IP addresses, you will have to configure NetworkManager to understand them. The process usually involves right-clicking the applet and selecting something like 'Edit Connections'.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Encrypted Wi-Fi passwords ===<br />
<br />
By default, NetworkManager stores passwords in clear text in the connection files at {{ic|/etc/NetworkManager/system-connections/}}. To print the stored passwords, use the following command:<br />
<br />
# grep -r '^psk=' /etc/NetworkManager/system-connections/<br />
<br />
The passwords are accessible to the root user in the filesystem and to users with access to settings via the GUI (e.g. {{ic|nm-applet}}). <br />
<br />
It is preferable to save the passwords in encrypted form in a keyring instead of clear text. The downside of using a keyring is that the connections have to be set up for each user.<br />
<br />
==== Using GNOME Keyring ====<br />
<br />
The keyring daemon has to be started and the keyring needs to be unlocked for the following to work.<br />
<br />
Furthermore, NetworkManager needs to be configured not to store the password for all users. Using GNOME {{ic|nm-applet}}, run {{ic|nm-connection-editor}} from a terminal, select a network connection, click {{ic|Edit}}, select the {{ic|Wifi-Security}} tab and click on the right icon of password and check {{ic|Store the password only for this user}}.<br />
<br />
==== Using KDE Wallet ====<br />
<br />
Using KDE's {{Pkg|plasma-nm}}, click the applet, click on the top right {{ic|Settings}} icon, click on a network connection, in the {{ic|General settings}} tab, untick {{ic|all users may connect to this network}}. If the option is ticked, the passwords will still be stored in clear text, even if a keyring daemon is running.<br />
<br />
If the option was selected previously and you un-tick it, you may have to use the {{ic|reset}} option first to make the password disappear from the file. Alternatively, delete the connection first and set it up again.<br />
<br />
=== Sharing internet connection over Wi-Fi ===<br />
<br />
You can share your internet connection (e.g. 3G or wired) with a few clicks. Please note that a [[firewall]] may interfere with internet sharing.<br />
<br />
You will need a Wi-Fi card which supports AP mode, see [[Software access point#Wi-Fi device must support AP mode]] for details.<br />
<br />
[[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
<br />
Create the shared connection:<br />
<br />
* Click on applet and choose ''Create new wireless network''.<br />
* Follow wizard (choose WPA2 or higher, be sure to use at least 8 character long password, lower lengths will fail).<br />
** Choose either [[Fedora:Features/RealHotspot|Hotspot]] or Ad-hoc as Wi-Fi mode.<br />
<br />
The connection will be saved and remain stored for the next time you need it.<br />
<br />
{{Note|Android does not support connecting to Ad-hoc networks. To share a connection with Android use infrastructure mode (i.e. set Wi-Fi mode to "Hotspot").}}<br />
<br />
=== Sharing internet connection over Ethernet ===<br />
<br />
Scenario: your device has internet connection over wi-fi and you want to share the internet connection to other devices over ethernet.<br />
<br />
Requirements:<br />
<br />
* [[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
* Your internet connected device and the other devices are connected over a suitable ethernet cable (this usually means a cross over cable or a switch in between).<br />
* Internet sharing is not blocked by a [[firewall]].<br />
<br />
Steps:<br />
<br />
{{Style|{{Pkg|nm-connection-editor}} is not a dependency of {{Pkg|networkmanager}} and needs to be installed separately.}}<br />
<br />
* Run {{ic|nm-connection-editor}} from terminal.<br />
* Add a new ethernet connection.<br />
* Give it some sensible name. For example "Shared Internet"<br />
* Go to "IPv4 Settings".<br />
* For "Method:" select "Shared to other computers".<br />
* Save<br />
<br />
Now you should have a new option "Shared Internet" under the Wired connections in NetworkManager.<br />
<br />
=== Checking if networking is up inside a cron job or script ===<br />
<br />
{{Out of date|''nm-tool'' was remove from NetworkManager for long time now[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/bb8c75bd536d4f8fb80a4366025a279078f0ec81]. ''nmcli'' should be used instead.}}<br />
<br />
Some ''cron'' jobs require networking to be up to succeed. You may wish to avoid running these jobs when the network is down. To accomplish this, add an '''if''' test for networking that queries NetworkManager's ''nm-tool'' and checks the state of networking. The test shown here succeeds if any interface is up, and fails if they are all down. This is convenient for laptops that might be hardwired, might be on wireless, or might be off the network.<br />
<br />
{{bc|<nowiki><br />
if [ $(nm-tool|grep State|cut -f2 -d' ') == "connected" ]; then<br />
#Whatever you want to do if the network is online<br />
else<br />
#Whatever you want to do if the network is offline - note, this and the else above are optional<br />
fi<br />
</nowiki>}}<br />
<br />
This useful for a {{ic|cron.hourly}} script that runs ''fpupdate'' for the F-Prot virus scanner signature update, as an example. Another way it might be useful, with a little modification, is to differentiate between networks using various parts of the output from ''nm-tool''; for example, since the active wireless network is denoted with an asterisk, you could grep for the network name and then grep for a literal asterisk.<br />
<br />
=== Connect to network with secret on boot ===<br />
<br />
By default, NetworkManager will not connect to networks requiring a secret automatically on boot. This is because it locks such connections to the user who makes it by default, only connecting after they have logged in. To change this, do the following:<br />
<br />
# Right click on the {{ic|nm-applet}} icon in your panel and select Edit Connections and open the Wireless tab<br />
# Select the connection you want to work with and click the Edit button<br />
# Check the boxes “Connect Automatically” and “Available to all users”<br />
# Additionally, ensure that under "Wi-Fi Security", "Store password for all users (not encrypted)" is selected<br />
<br />
Log out and log back in to complete.<br />
<br />
=== OpenConnect with password in KWallet ===<br />
<br />
While you may type both values at connection time, {{Pkg|plasma-nm}} 0.9.3.2-1 and above are capable of retrieving OpenConnect username and password directly from [[KWallet]].<br />
<br />
Open "KDE Wallet Manager" and look up your OpenConnect VPN connection under "Network Management|Maps". Click "Show values" and <br />
enter your credentials in key "VpnSecrets" in this form (replace ''username'' and ''password'' accordingly):<br />
<br />
form:main:username%SEP%''username''%SEP%form:main:password%SEP%''password''<br />
<br />
Next time you connect, username and password should appear in the "VPN secrets" dialog box.<br />
<br />
=== Ignore specific devices ===<br />
<br />
Sometimes it may be desired that NetworkManager ignores specific devices and does not try to configure addresses and routes for them. You can quickly and easily ignore devices by MAC or interface-name by using the following in {{ic|/etc/NetworkManager/conf.d/unmanaged.conf}}:<br />
<br />
[keyfile]<br />
unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth0<br />
<br />
After editing the file, run {{ic|nmcli general reload}} as root. Afterwards you should be able to configure interfaces without NetworkManager altering what you have set.<br />
<br />
=== Configuring MAC address randomization ===<br />
<br />
{{Note|1=Disabling MAC address randomization may be needed to get (stable) link connection [https://bbs.archlinux.org/viewtopic.php?id=220101] and/or networks that restrict devices based on their MAC Address or have a limit network capacity.}}<br />
<br />
MAC randomization can be used for increased privacy by not disclosing your real MAC address to the network.<br />
<br />
NetworkManager supports two types MAC Address Randomization: randomization during scanning, and for network connections. Both modes can be configured by modifying {{ic|/etc/NetworkManager/NetworkManager.conf}} or by creating a separate configuration file in {{ic|/etc/NetworkManager/conf.d/}} which is recommended since the aforementioned config file may be overwritten by NetworkManager.<br />
<br />
Randomization during Wi-Fi scanning is enabled by default, but it may be disabled by adding the following lines to {{ic|/etc/NetworkManager/NetworkManager.conf}} or a dedicated configuration file under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device]<br />
wifi.scan-rand-mac-address=no<br />
}}<br />
<br />
MAC randomization for network connections can be set to different modes for both wireless and ethernet interfaces. See the [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details on the different modes. <br />
<br />
In terms of MAC randomization the most important modes are {{ic|stable}} and {{ic|random}}. {{ic|stable}} generates a random MAC address when you connect to a new network and associates the two permanently. This means that you will use the same MAC address every time you connect to that network. In contrast, {{ic|random}} will generate a new MAC address every time you connect to a network, new or previously known. You can configure the MAC randomization by adding the desired configuration under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device-mac-randomization]<br />
# "yes" is already the default for scanning<br />
wifi.scan-rand-mac-address=yes<br />
<br />
[connection-mac-randomization]<br />
# Randomize MAC for every ethernet connection<br />
ethernet.cloned-mac-address=random<br />
# Generate a random MAC for each WiFi and associate the two permanently.<br />
wifi.cloned-mac-address=stable<br />
}}<br />
<br />
See the following [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details.<br />
<br />
=== Enable IPv6 Privacy Extensions ===<br />
<br />
See [[IPv6#NetworkManager]].<br />
<br />
=== Working with wired connections ===<br />
<br />
By default, NetworkManager generates a connection profile for each wired ethernet connection it finds. At the point when generating the connection, it does not know whether there will be more ethernet adapters available. Hence, it calls the first wired connection "Wired connection 1". You can avoid generating this connection, by configuring {{ic|no-auto-default}} (see {{man|5|NetworkManager.conf}}), or by simply deleting it. Then NetworkManager will remember not to generate a connection for this interface again.<br />
<br />
You can also edit the connection (and persist it to disk) or delete it. NetworkManager will not re-generate a new connection. Then you can change the name to whatever you want. You can use something like nm-connection-editor for this task.<br />
<br />
=== Using iwd as the Wi-Fi backend ===<br />
<br />
{{Note|1=Consider [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues?scope=all&utf8=%E2%9C%93&state=opened&search=iwd existing issues] before switching to iwd.}}<br />
<br />
Enable the [https://iwd.wiki.kernel.org/networkmanager experimental] [[iwd]] backend creating the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_backend.conf|2=<br />
[device]<br />
wifi.backend=iwd<br />
}}<br />
<br />
Alternatively, you can install {{AUR|networkmanager-iwd}}, a modified package configured to build ''NetworkManager'' working exclusively with ''iwd'', with the main difference being that ''iwd'' is required and ''wpa_supplicant'' can be uninstalled after building.<br />
<br />
=== Running in a network namespace ===<br />
<br />
If you would like to run NetworkManager inside a network namespace (e.g., to manage a specific device which should be use by selected applications), bring the device down before moving it to the namespace:<br />
<br />
$ ip link set dev ''MY_DEVICE'' down<br />
$ ip link set dev ''MY_DEVICE'' netns ''MY_NAMESPACE''<br />
$ ip netns exec ''MY_NAMESPACE'' NetworkManager<br />
...<br />
$ ip netns exec ''MY_NAMESPACE'' killall NetworkManager<br />
<br />
otherwise NetworkManager will later fail to establish the connection with a {{ic|device is strictly unmanaged}} error.<br />
<br />
=== Automatically connect to VPN ===<br />
<br />
NetworkManager can be set to automatically connect to a VPN when connecting to the internet, on a per network basis. The VPN connection itself can be added in GNOME's NetworkManager front-end, but to make it automatically use the VPN {{ic|nmcli}} must be used. Other front-ends might not have this limitation.<br />
<br />
First, make sure to make the VPN connection available to all users. In the GNOME this is a matter of checking a box under the {{ic|details}} tab. Under the {{ic|Identity}} tab, in the password field, click the icon on the right side in the field, and set it to {{ic|Store the password for all users}}.<br />
<br />
Then find the UUID of the VPN connection, and add that to {{ic|connection.secondaries}} of the Internet connection:<br />
<br />
# UUID=$(nmcli --get-values connection.uuid connection show ''name-of-VPN-connection'')<br />
# nmcli connection modify ''name-of-Internet-connection'' connection.secondaries "$UUID"<br />
<br />
Now when NetworkManager is restarted and you connect to the Internet connection you have configured, you should automatically get connected to the VPN.<br />
<br />
== Troubleshooting ==<br />
<br />
=== No prompt for password of secured Wi-Fi networks ===<br />
<br />
When trying to connect to a secured Wi-Fi network, no prompt for a password is shown and no connection is established. This happens when no keyring package is installed. An easy solution is to install {{Pkg|gnome-keyring}}. If you want the passwords to be stored in encrypted form, follow [[GNOME Keyring]] to set up the ''gnome-keyring-daemon''.<br />
<br />
=== Network management disabled ===<br />
<br />
When NetworkManager shuts down but the pid (state) file is not removed, you will see a {{ic|Network management disabled}} message. If this happens, remove the file manually:<br />
<br />
# rm /var/lib/NetworkManager/NetworkManager.state<br />
<br />
=== Problems with internal DHCP client ===<br />
<br />
If you have problems with getting an IP address using the internal DHCP client, consider using another DHCP client, see [[#DHCP client]] for instructions. This workaround might solve problems in big wireless networks like eduroam.<br />
<br />
=== DHCP problems with dhclient ===<br />
<br />
If you have problems with getting an IP address via DHCP, try to add the following to your {{ic|/etc/dhclient.conf}}:<br />
<br />
interface "eth0" {<br />
send dhcp-client-identifier 01:''aa:bb:cc:dd:ee:ff'';<br />
}<br />
<br />
Where {{ic|''aa:bb:cc:dd:ee:ff''}} is the MAC address of this NIC. The MAC address can be found using the {{ic|ip link show ''interface''}} command from the {{Pkg|iproute2}} package.<br />
<br />
=== 3G modem not detected ===<br />
<br />
See [[USB 3G Modem#NetworkManager]].<br />
<br />
=== Switching off WLAN on laptops ===<br />
<br />
Sometimes NetworkManager will not work when you disable your Wi-Fi adapter with a switch on your laptop and try to enable it again afterwards. This is often a problem with ''rfkill''. To check if the driver notifies ''rfkill'' about the wireless adapter's status, use:<br />
<br />
$ watch -n1 rfkill list all<br />
<br />
If one identifier stays blocked after you switch on the adapter you could try to manually unblock it with (where X is the number of the identifier provided by the above output):<br />
<br />
# rfkill event unblock X<br />
<br />
=== Static IP address settings revert to DHCP ===<br />
<br />
Due to an unresolved bug, when changing default connections to a static IP address, {{ic|nm-applet}} may not properly store the configuration change, and will revert to automatic DHCP.<br />
<br />
To work around this issue you have to edit the default connection (e.g. "Auto eth0") in {{ic|nm-applet}}, change the connection name (e.g. "my eth0"), uncheck the "Available to all users" checkbox, change your static IP address settings as desired, and click '''Apply'''. This will save a new connection with the given name.<br />
<br />
Next, you will want to make the default connection not connect automatically. To do so, run {{ic|nm-connection-editor}} ('''not''' as root). In the connection editor, edit the default connection (e.g. "Auto eth0") and uncheck "Connect automatically". Click '''Apply''' and close the connection editor.<br />
<br />
=== Cannot edit connections as normal user ===<br />
<br />
See [[#Set up PolicyKit permissions]].<br />
<br />
=== Forget hidden wireless network ===<br />
<br />
Since hidden networks are not displayed in the selection list of the Wireless view, they cannot be forgotten (removed) with the GUI. You can delete one with the following command:<br />
<br />
# rm /etc/NetworkManager/system-connections/''SSID''<br />
<br />
This works for any other connection.<br />
<br />
=== VPN not working in GNOME ===<br />
<br />
When setting up OpenConnect or vpnc connections in NetworkManager while using GNOME, you will sometimes never see the dialog box pop up and the following error appears in {{ic|/var/log/errors.log}}:<br />
<br />
localhost NetworkManager[399]: <error> [1361719690.10506] [nm-vpn-connection.c:1405] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.<br />
<br />
This is caused by the GNOME NM Applet expecting dialog scripts to be at {{ic|/usr/lib/gnome-shell}}, when NetworkManager's packages put them in {{ic|/usr/lib/networkmanager}}.<br />
As a "temporary" fix (this bug has been around for a while now), make the following symlink(s):<br />
<br />
* For OpenConnect: {{ic|ln -s /usr/lib/networkmanager/nm-openconnect-auth-dialog /usr/lib/gnome-shell/}}<br />
* For VPNC (i.e. Cisco VPN): {{ic|ln -s /usr/lib/networkmanager/nm-vpnc-auth-dialog /usr/lib/gnome-shell/}}<br />
<br />
This may need to be done for any other NM VPN plugins as well, but these are the two most common.<br />
<br />
=== Unable to connect to visible European wireless networks ===<br />
<br />
WLAN chips are shipped with a default [[Wireless network configuration#Respecting the regulatory domain|regulatory domain]]. If your access point does not operate within these limitations, you will not be able to connect to the network. Fixing this is easy:<br />
<br />
# [[Install]] {{Pkg|crda}}<br />
# Uncomment the correct Country Code in {{ic|/etc/conf.d/wireless-regdom}}<br />
# Reboot the system, because the setting is only read on boot<br />
<br />
=== Automatic connect to VPN on boot is not working ===<br />
<br />
The problem occurs when the system (i.e. NetworkManager running as the root user) tries to establish a VPN connection, but the password is not accessible because it is stored in the GNOME keyring of a particular user. <br />
<br />
A solution is to keep the password to your VPN in plaintext, as described in step (2.) of [[#Use dispatcher to connect to a VPN after a network connection is established]]. <br />
<br />
You do not need to use the dispatcher described in step (1.) to auto-connect anymore, if you use the new "auto-connect VPN" option from the {{ic|nm-applet}} GUI.<br />
<br />
=== Systemd Bottleneck ===<br />
<br />
Over time the log files ({{ic|/var/log/journal}}) can become very large. This can have a big impact on boot performance when using NetworkManager, see: [[Systemd#Boot time increasing over time]].<br />
<br />
=== Regular network disconnects, latency and lost packets (WiFi) ===<br />
<br />
NetworkManager does a scan every 2 minutes.<br />
<br />
Some WiFi drivers have issues when scanning for base stations whilst connected/associated. Symptoms include VPN disconnects/reconnects and lost packets, web pages failing to load and then refresh fine.<br />
<br />
Running {{ic|journalctl -f}} will indicate that this is taking place, messages like the following will be contained in the logs at regular intervals.<br />
<br />
NetworkManager[410]: <info> (wlp3s0): roamed from BSSID 00:14:48:11:20:CF (my-wifi-name) to (none) ((none))<br />
<br />
There is a patched version of NetworkManager which should prevent this type of scanning: {{AUR|networkmanager-noscan}}.<br />
<br />
Alternatively, if roaming is not important, the periodic scanning behavior can be disabled by locking the BSSID of the access point in the WiFi connection profile.<br />
<br />
=== Unable to turn on wi-fi with Lenovo laptop (IdeaPad, Legion, etc.) ===<br />
<br />
There is an issue with the {{ic|ideapad_laptop}} module on some Lenovo models due to the wi-fi driver incorrectly reporting a soft block. The card can still be manipulated with {{ic|netctl}}, but managers like NetworkManager break. You can verify that this is the problem by checking the output of {{ic|rfkill list}} after toggling your hardware switch and seeing that the soft block persists.<br />
<br />
{{Accuracy|Try to use {{ic|rfkill.default_state}} and {{ic|rfkill.master_switch_mode}} (see [https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt kernel-parameters.txt]) to fix the rfkill problem.}}<br />
<br />
[[modprobe|Unloading]] the {{ic|ideapad_laptop}} module should fix this. ('''warning''': this may disable the laptop keyboard and touchpad also!).<br />
<br />
=== Turn off hostname sending ===<br />
<br />
NetworkManager by default sends the hostname to the DHCP server. Hostname sending can only be disabled per connection not globally ([https://bugzilla.gnome.org/show_bug.cgi?id=768076 GNOME Bug 768076]).<br />
<br />
To disable sending your hostname to the DHCP server for a specific connection, add the following to your network connection file:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''your_connection_file''|2=<br />
...<br />
[ipv4]<br />
dhcp-send-hostname=false<br />
...<br />
[ipv6]<br />
dhcp-send-hostname=false<br />
...<br />
}}<br />
<br />
=== nm-applet disappears in i3wm ===<br />
<br />
If you use the {{ic|xfce4-notifyd.service}} for notifications you must [[edit]] the unit and add the following:<br />
<br />
{{hc|/etc/systemd/user/xfce4-notifyd.service.d/display_env.conf|2=<br />
[Service]<br />
Environment="DISPLAY=:0.0"<br />
}}<br />
<br />
After reloading the daemons [[restart]] {{ic|xfce4-notifyd.service}}. Exit i3 and start it back up again and the applet should show on the tray.<br />
<br />
=== nm-applet tray icons display wrongly ===<br />
<br />
Currently the tray icons of nm-applet are drawn on top of one another, i.e. the icon displaying wireless strength might show on top of the icon indicating no wired connection.<br />
This is apparently a GTK3 bug/problem: https://gitlab.gnome.org/GNOME/gtk/issues/1280 .<br />
<br />
A patched version of GTK3 exists in AUR, which apparently fixes the tray icon bug: {{AUR|gtk3-mushrooms}} .<br />
<br />
=== Unit dbus-org.freedesktop.resolve1.service not found ===<br />
<br />
If {{ic|systemd-resolved.service}} is not started, NetworkManager will try to start it using D-Bus and fail:<br />
<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
dbus-daemon[991]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
<br />
This is because NetworkManager will try to send DNS information to [[systemd-resolved]] regardless of the {{ic|1=main.dns=}} setting in {{man|5|NetworkManager.conf}}.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383]<br />
<br />
This can be disabled with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/no-systemd-resolved.conf|2=<br />
[main]<br />
systemd-resolved=false<br />
}}<br />
<br />
See {{Bug|62138}}.<br />
<br />
=== Secrets were required, but not provided ===<br />
<br />
If you attempt to connect to a network using {{ic|nmcli device wifi connect ''SSID'' password ''password''}} and received the following error:<br />
<br />
Error: Connection activation failed: (7) Secrets were required, but not provided<br />
<br />
The error can be resolved by deleting the connection profile and creating a new one:<br />
<br />
$ nmcli connection delete ''SSID''<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
=== WPA Enterprise connection with NetworkManager ===<br />
<br />
If you try to connect to an WPA Enterprise network like 'eduroam' with NetworkManager with the [[iwd]] backend then you will get the following error from NetworkManager:<br />
<br />
Connection 'eduroam' is not avialable on device wlan0 because profile is not compatible with device (802.1x connections must have IWD provisioning files)<br />
<br />
This is because NetworkManager can not configure a WPA Enterprise network. Therefore you have to configure it using an iwd config file {{ic|/var/lib/iwd/''essid''.8021x}} like described in [[iwd#WPA Enterprise]].<br />
<br />
=== Failed to request VPN secrets ===<br />
<br />
If you get this error:<br />
Failed to request VPN secrets #1: No agents were available for this request.<br />
<br />
It is either because the password is empty or you have to [[#Set up PolicyKit permissions|set up PolicyKit permissions]].<br />
<br />
== See also ==<br />
<br />
* [https://blogs.gnome.org/dcbw/2015/02/16/networkmanager-for-administrators-part-1/ NetworkManager for Administrators Part 1]<br />
* [[Wikipedia:NetworkManager]]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=NetworkManager&diff=648700NetworkManager2021-01-11T09:44:03Z<p>Tobbebobbe: /* Edit a connection */ Added example on how to remove a setting since it is unclear</p>
<hr />
<div>[[Category:Network managers]]<br />
[[Category:Red Hat]]<br />
[[cs:NetworkManager]]<br />
[[de:Networkmanager]]<br />
[[es:NetworkManager]]<br />
[[fr:NetworkManager]]<br />
[[it:NetworkManager]]<br />
[[ja:NetworkManager]]<br />
[[pt:NetworkManager]]<br />
[[zh-hans:NetworkManager]]<br />
{{Related articles start}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related articles end}}<br />
[https://wiki.gnome.org/Projects/NetworkManager/ NetworkManager] is a program for providing detection and configuration for systems to automatically connect to networks. NetworkManager's functionality can be useful for both wireless and wired networks. For wireless networks, NetworkManager prefers known wireless networks and has the ability to switch to the most reliable network. NetworkManager-aware applications can switch from online and offline mode. NetworkManager also prefers wired connections over wireless ones, has support for modem connections and certain types of VPN. NetworkManager was originally developed by Red Hat and now is hosted by the [[GNOME]] project.<br />
<br />
{{Expansion|Clear text storage of secrets is not limited to just Wi-Fi passwords. The secrets are stored in files (and folder) only accesible to root.}}<br />
<br />
{{Warning|By default, Wi-Fi passwords are stored in clear text, see [[#Encrypted Wi-Fi passwords]].}}<br />
<br />
== Installation ==<br />
<br />
NetworkManager can be [[install]]ed with the package {{Pkg|networkmanager}}, which contains a daemon, a command line interface ({{ic|nmcli}}) and a curses‐based interface ({{ic|nmtui}}). <br />
<br />
=== Enable NetworkManager ===<br />
<br />
After installation, you should [[start/enable]] {{ic|NetworkManager.service}}. Once the NetworkManager daemon is started, it will automatically connect to any available "system connections" that have already been configured. Any "user connections" or unconfigured connections will need ''nmcli'' or an applet to configure and connect.<br />
<br />
{{Note|If [[systemd-resolved]] is not [[started]], an error message will start flooding your logs. See [[#Unit dbus-org.freedesktop.resolve1.service not found]] for more info.}}<br />
<br />
=== Additional interfaces ===<br />
<br />
* {{Pkg|nm-connection-editor}} for a graphical user interface,<br />
* {{Pkg|network-manager-applet}} for a system tray applet ({{ic|nm-applet}}).<br />
<br />
{{Note|You must ensure that no other service that wants to configure the network is running; in fact, multiple networking services will conflict. You can find a list of the currently running services with {{ic|1=systemctl --type=service}} and then [[stop]] them. See [[#Configuration]] to enable the NetworkManager service.}}<br />
<br />
=== Mobile broadband support ===<br />
<br />
[[Install]] {{Pkg|modemmanager}}, {{Pkg|mobile-broadband-provider-info}} and {{Pkg|usb_modeswitch}} packages for mobile broadband connection support. See [[USB 3G Modem#NetworkManager]] for details.<br />
<br />
=== PPPoE / DSL support ===<br />
<br />
[[Install]] {{Pkg|rp-pppoe}} package for PPPoE / DSL connection support. To actually add PPPoE connection, use {{ic|1=nm-connection-editor}} and add new DSL/PPPoE connection.<br />
<br />
=== VPN support ===<br />
<br />
NetworkManager since version 1.16 has native support for [[WireGuard]], all it needs is the {{ic|wireguard}} kernel module. Read the [https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-networkmanager/ WireGuard in NetworkManager blog post] for details.<br />
<br />
Support for other VPN types is based on a plug-in system. They are provided in the following packages:<br />
<br />
* {{Pkg|networkmanager-openconnect}} for [[OpenConnect]]<br />
* [[networkmanager-openvpn]] for [[OpenVPN]]<br />
* {{Pkg|networkmanager-pptp}} for [[PPTP Client]]<br />
* {{Pkg|networkmanager-vpnc}} for [[Vpnc]]<br />
* {{Pkg|networkmanager-strongswan}} for [[strongSwan]]<br />
* {{AUR|networkmanager-fortisslvpn-git}}<br />
* {{AUR|networkmanager-iodine-git}}<br />
* {{AUR|networkmanager-libreswan}}<br />
* {{AUR|networkmanager-l2tp}}<br />
* {{AUR|networkmanager-ssh-git}}<br />
* {{Pkg|network-manager-sstp}}<br />
<br />
{{Warning|1=There are a lot of [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues?search=VPN&state=opened bugs] (and [https://bugzilla.gnome.org/buglist.cgi?bug_status=__open__&content=VPN&product=NetworkManager old bugs]) related to VPN support. Check the daemon processes options set via the GUI correctly and double-check with each package release.}}<br />
<br />
{{Note|To have fully functioning DNS resolution when using VPN, you should set up [[#DNS caching and conditional forwarding|conditional forwarding]].}}<br />
<br />
== Usage ==<br />
<br />
NetworkManager comes with {{man|1|nmcli}} and {{man|1|nmtui}}.<br />
<br />
=== nmcli examples ===<br />
<br />
List nearby wifi networks:<br />
<br />
$ nmcli device wifi list<br />
<br />
Connect to a wifi network:<br />
<br />
$ nmcli device wifi connect ''SSID_or_BSSID'' password ''password''<br />
<br />
Connect to a hidden network:<br />
<br />
$ nmcli device wifi connect ''SSID_or_BSSID'' password ''password'' hidden yes<br />
<br />
Connect to a wifi on the {{ic|wlan1}} wifi interface:<br />
<br />
$ nmcli device wifi connect ''SSID_or_BSSID'' password ''password'' ifname wlan1 ''profile_name''<br />
<br />
Disconnect an interface:<br />
<br />
$ nmcli device disconnect ifname eth0<br />
<br />
Reconnect an interface marked as disconnected:<br />
<br />
$ nmcli connection up uuid ''UUID''<br />
<br />
Get a list of UUIDs:<br />
<br />
$ nmcli connection show<br />
<br />
See a list of network devices and their state:<br />
<br />
$ nmcli device<br />
<br />
Turn off wifi:<br />
<br />
$ nmcli radio wifi off<br />
<br />
=== Edit a connection ===<br />
<br />
For a comprehensive list of settings, see {{man|5|nm-settings}}.<br />
<br />
Firstly you need to get list of connections:<br />
<br />
{{hc|$ nmcli connection|<nowiki><br />
NAME UUID TYPE DEVICE<br />
Wired connection 2 e7054040-a421-3bef-965d-bb7d60b7cecf ethernet enp5s0<br />
Wired connection 1 997f2782-f0fc-301d-bfba-15421a2735d8 ethernet enp0s25<br />
MY-HOME-WIFI-5G 92a0f7b3-2eba-49ab-a899-24d83978f308 wifi --<br />
</nowiki>}}<br />
<br />
Here you can use the first column as connection-id used later. In this example we pick {{ic|Wired connection 2}} as a connection-id.<br />
<br />
You have three methods to configure a connection {{ic|Wired connection 2}} after it has been created:<br />
<br />
; nmcli interactive editor<br />
: {{ic|nmcli connection edit 'Wired connection 2'}}.<br> Usage is well documented from the editor.<br />
<br />
; nmcli command line interface<br />
: {{ic|nmcli connection modify 'Wired connection 2' ''setting''.''property'' ''value''}}. See {{man|1|nmcli}} for usage. For example you can change its IPv4 route metric to 200 using {{ic|nmcli connection modify 'Wired connection 2' ipv4.route-metric 200}} command.<br />
To remove a setting pass an empty field ("") to it like this:<br />
: {{ic|nmcli connection modify 'Wired connection 2' ''setting''.''property'' ''""''}}<br />
<br />
; Connection file<br />
: In {{ic|/etc/NetworkManager/system-connections/}}, modify the corresponding {{ic|Wired connection 2.nmconnection}} file .<br> Do not forget to reload the configuration file with {{ic|nmcli connection reload}}.<br />
<br />
== Front-ends ==<br />
<br />
To configure and have easy access to NetworkManager, most users will want to install an applet. This GUI front-end usually resides in the system tray (or notification area) and allows network selection and configuration of NetworkManager. Various desktop environments have their own applet. Otherwise you can use [[#nm-applet]].<br />
<br />
=== GNOME ===<br />
<br />
[[GNOME]] has a built-in tool, accessible from the Network settings.<br />
<br />
=== KDE Plasma ===<br />
<br />
[[Install]] the {{Pkg|plasma-nm}} package. After that, add it to the KDE taskbar via the ''Panel options > Add widgets > Networks'' menu.<br />
<br />
=== nm-applet ===<br />
<br />
{{Pkg|network-manager-applet}} is a GTK 3 front-end which works under Xorg environments with a systray.<br />
<br />
To store connection secrets install and configure [[GNOME/Keyring]].<br />
<br />
Be aware that after enabling the tick-box option {{ic|Make available to other users}} for a connection, NetworkManager stores the password in plain-text, though the respective file is accessible only to root (or other users via {{ic|nm-applet}}). See [[#Encrypted Wi-Fi passwords]].<br />
<br />
In order to run {{ic|nm-applet}} without a systray, you can use {{Pkg|trayer}} or {{Pkg|stalonetray}}. For example, you can add a script like this one in your path:<br />
<br />
{{hc|nmgui|<nowiki><br />
#!/bin/sh<br />
nm-applet 2>&1 > /dev/null &<br />
stalonetray 2>&1 > /dev/null<br />
killall nm-applet<br />
</nowiki>}}<br />
<br />
When you close the ''stalonetray'' window, it closes {{ic|nm-applet}} too, so no extra memory is used once you are done with network settings.<br />
<br />
The applet can show notifications for events such as connecting to or disconnecting from a WiFi network. For these notifications to display, ensure that you have a notification server installed - see [[Desktop notifications]]. If you use the applet without a notification server, you might see some messages in stdout/stderr, and the app might hang. See [https://bugzilla.gnome.org/show_bug.cgi?id=788313].<br />
<br />
In order to run {{ic|nm-applet}} with such notifications disabled, start the applet with the following command:<br />
<br />
$ nm-applet --no-agent<br />
<br />
{{Tip|{{ic|nm-applet}} might be started automatically with a [[XDG Autostart|autostart desktop file]], to add the --no-agent option modify the Exec line there, i.e.<br />
<br />
{{bc|1=Exec=nm-applet --no-agent}}<br />
<br />
}}<br />
<br />
{{Warning|On [[i3]], if nm-applet is started with the {{ic|--no-agent}} option, it is not possible to connect to a new encrypted WiFi network by clicking on the item list because no password input dialogue window will pop out. [[journal]] will show {{ic|no secrets: No agents were available for this request}}.}}<br />
<br />
==== Appindicator ====<br />
<br />
As of version 1.18.0 Appindicator support is [https://github.com/archlinux/svntogit-packages/commit/7640a2bd557fe84813207ef4d5e35bb5aece6c54 available] in the official {{Pkg|network-manager-applet}} package. To use nm-applet in an Appindicator environment start the applet with the following command:<br />
<br />
$ nm-applet --indicator<br />
<br />
=== networkmanager-dmenu ===<br />
<br />
Alternatively there is {{AUR|networkmanager-dmenu-git}} which is a small script to manage NetworkManager connections with [[dmenu]] or [[rofi]] instead of {{ic|nm-applet}}. It provides all essential features such as connection to existing NetworkManager wifi or wired connections, connect to new wifi connections, requests passphrase if required, connect to existing VPN connections, enable/disable networking, launch ''nm-connection-editor'' GUI, connect to Bluetooth networks.<br />
<br />
== Configuration ==<br />
<br />
NetworkManager will require some additional steps to be able run properly. Make sure you have configured {{ic|/etc/hosts}} as described in [[Network configuration#Set the hostname]] section.<br />
<br />
NetworkManager has a global configuration file at {{ic|/etc/NetworkManager/NetworkManager.conf}}. Additional configuration files can be placed in {{ic|/etc/NetworkManager/conf.d/}}. Usually no configuration needs to be done to the global defaults.<br />
<br />
After editing a configuration file, the changes can be applied by running:<br />
<br />
# nmcli general reload<br />
<br />
=== Enable NetworkManager Wait Online ===<br />
<br />
{{Out of date|{{ic|NetworkManager.service}} has {{ic|1=Also=NetworkManager-wait-online.service}} in the {{ic|[Install]}} section.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/167e42a87e97ed7fb26a4263c22f1774716ac51b] If {{ic|NetworkManager.service}} was [[enable]]d before the change, it needs to be [[enable|reenabled]].}}<br />
<br />
If you have services which fail if they are started before the network is up, you may use {{ic|NetworkManager-wait-online.service}} in addition to {{ic|NetworkManager.service}}. This is, however, rarely necessary because most networked daemons start up okay, even if the network has not been configured yet.<br />
<br />
In some cases, the service will still fail to start successfully on boot due to the timeout setting in {{ic|/usr/lib/systemd/system/NetworkManager-wait-online.service}} being too short. Change the default timeout from 30 to a higher value.<br />
<br />
=== Set up PolicyKit permissions ===<br />
<br />
See [[General troubleshooting#Session permissions]] for setting up a working session.<br />
<br />
With a working session, you have several options for granting the necessary privileges to NetworkManager:<br />
<br />
* ''Option 1.'' Run a [[Polkit]] authentication agent when you log in, such as {{ic|/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1}} (part of {{Pkg|polkit-gnome}}). You will be prompted for your password whenever you add or remove a network connection.<br />
* ''Option 2.'' [[Users and groups#Group management|Add]] yourself to the {{ic|wheel}} group. You will not have to enter your password, but your user account may be granted other permissions as well, such as the ability to use [[sudo]] without entering the root password.<br />
* ''Option 3.'' [[Users and groups#Group management|Add]] yourself to the {{ic|network}} group and create the following file:<br />
<br />
{{hc|/etc/polkit-1/rules.d/50-org.freedesktop.NetworkManager.rules|<nowiki><br />
polkit.addRule(function(action, subject) {<br />
if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0 && subject.isInGroup("network")) {<br />
return polkit.Result.YES;<br />
}<br />
});<br />
</nowiki>}}<br />
<br />
: All users in the {{ic|network}} group will be able to add and remove networks without a password. This will not work under [[systemd]] if you do not have an active session with ''systemd-logind''.<br />
<br />
=== Proxy settings ===<br />
<br />
NetworkManager does not directly handle proxy settings, but if you are using [[GNOME]] or [[KDE]], you could use [http://marin.jb.free.fr/proxydriver/ proxydriver] which handles proxy settings using NetworkManager's information. proxydriver is found in the package {{AUR|proxydriver}}.<br />
<br />
In order for ''proxydriver'' to be able to change the proxy settings, you would need to execute this command, as part of the GNOME startup process (see [[GNOME#Autostart]]).<br />
<br />
xhost +si:localuser:''username''<br />
<br />
See also [[Proxy settings]].<br />
<br />
=== Checking connectivity ===<br />
<br />
NetworkManager can try to reach a page on Internet when connecting to a network. {{Pkg|networkmanager}} is configured by default in {{ic|/usr/lib/NetworkManager/conf.d/20-connectivity.conf}} to check connectivity to archlinux.org. To use a different webserver or disable connectivity checking create {{ic|/etc/NetworkManager/conf.d/20-connectivity.conf}}, see {{man|5|NetworkManager.conf|CONNECTIVITY SECTION}}. Below is an example of using GNOME servers (it does not require the use of [[GNOME]]):<br />
<br />
{{hc|/etc/NetworkManager/conf.d/20-connectivity.conf|<nowiki><br />
[connectivity]<br />
uri=http://nmcheck.gnome.org/check_network_status.txt<br />
</nowiki>}}<br />
<br />
{{Note|Although automatic connectivity checks are a potential privacy leak, the official archlinux.org default connectivity URL is committed to not logging any access. See [https://gitlab.archlinux.org/archlinux/infrastructure/-/commit/68fbaca2ef9f31f624f117899848f4288d6b39d1].}}<br />
<br />
=== Captive portals ===<br />
<br />
{{Style|Complex scripts should not be maintained on the wiki.}}<br />
<br />
For those behind a [[Wikipedia:Captive portal|captive portal]], the desktop manager may automatically open a window asking for credentials. If your desktop does not, you can use {{Pkg|capnet-assist}} package (however, it currently it has a broken NetworkManager dispatcher script). Alternatively, you can create a NetworkManager dispatcher script with the following content:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/90-open_captive_portal|<nowiki><br />
#!/bin/sh -e<br />
# Script to dispatch NetworkManager events<br />
#<br />
# Runs shows a login webpage on walled garden networks.<br />
# See NetworkManager(8) for further documentation of the dispatcher events.<br />
<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin<br />
<br />
if [ -x "/usr/bin/logger" ]; then<br />
logger="/usr/bin/logger -s -t captive-portal"<br />
else<br />
logger=":"<br />
fi<br />
<br />
wait_for_process() {<br />
PNAME=$1<br />
while [ -z "$(/usr/bin/pgrep $PNAME)" ]; do<br />
sleep 3;<br />
done<br />
}<br />
<br />
#launch the browser, but on boot we need to wait that nm-applet starts<br />
start_browser() {<br />
local user="$1"<br />
local display="$2"<br />
<br />
export DISPLAY="$display"<br />
wait_for_process nm-applet<br />
<br />
export XAUTHORITY="/home/$user/.Xauthority"<br />
<br />
$logger "Running browser as '$user' with display '$display' to login in captive portal"<br />
sudo -u "$user" --preserve-env=DISPLAY,XAUTHORITY -H xdg-open http://capnet.elementary.io 2>&1 > /dev/null<br />
}<br />
<br />
# Run the right scripts<br />
case "$2" in<br />
connectivity-change)<br />
$logger -p user.debug "dispatcher script triggered on connectivity change: $CONNECTIVITY_STATE"<br />
if [ "$CONNECTIVITY_STATE" = "PORTAL" ]; then<br />
# Match last column of who's output with ' :[at least one digit] '<br />
who | awk '$NF ~ /\(:[0-9]+\)/ { print $1 " " substr($NF, 2, length($NF)-2) };' | \<br />
while read user display; do<br />
start_browser $user $display || $logger -p user.err "Failed for user: '$user' display: '$display'"<br />
done<br />
fi<br />
;;<br />
*)<br />
# In a down phase<br />
exit 0<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
You will need to [[restart]] {{ic|NetworkManager.service}} or reboot for this to start working. Once you do, the dispatcher script should open a login window once it detects you are behind a captive portal.<br />
<br />
Another solution is {{AUR|captive-browser-git}} based on Google Chrome.<br />
<br />
=== DHCP client ===<br />
<br />
By default NetworkManager uses its internal DHCP client. The internal DHCPv4 plugin is based on the [https://nettools.github.io/n-dhcp4/ nettools' n-dhcp4] library, while the internal DHCPv6 plugin is made from code based on systemd-networkd.<br />
<br />
To use ISC’s DHCP client, [[install]] {{Pkg|dhclient}}. To change the DHCP client backend, set the option {{ic|1=main.dhcp=''dhcp_client_name''}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}. E.g.:<br />
<br />
{{hc|1=/etc/NetworkManager/conf.d/dhcp-client.conf|2=<br />
[main]<br />
dhcp=dhclient<br />
}}<br />
<br />
{{Note|<br />
* Do not enable the systemd units shipped with the {{Pkg|dhclient}} and {{Pkg|dhcpcd}} packages. They will conflict with NetworkManager, see the note in [[#Installation]] for details.<br />
* NetworkManger does not support dhcpcd ≥ 9.0.0. See {{Bug|66231}}.<br />
}}<br />
<br />
=== DNS management ===<br />
<br />
NetworkManager's DNS management is described in the GNOME project's wiki page—[https://wiki.gnome.org/Projects/NetworkManager/DNS Projects/NetworkManager/DNS].<br />
<br />
==== DNS caching and conditional forwarding ====<br />
<br />
NetworkManager has a plugin to enable DNS caching and conditional forwarding ([https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/143 previously] called "split DNS" in NetworkManager's documentation) using [[dnsmasq]] or [[systemd-resolved]]. The advantages of this setup is that DNS lookups will be cached, shortening resolve times, and DNS lookups of VPN hosts will be routed to the relevant VPN's DNS servers. This is especially useful if you are connected to more than one VPN.<br />
<br />
===== dnsmasq =====<br />
<br />
Make sure {{Pkg|dnsmasq}} has been installed. Then set {{ic|1=main.dns=dnsmasq}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=dnsmasq<br />
}}<br />
<br />
Now run {{ic|nmcli general reload}} as root. NetworkManager will automatically start dnsmasq and add {{ic|127.0.0.1}} to {{ic|/etc/resolv.conf}}. The original DNS servers can be found in {{ic|/run/NetworkManager/no-stub-resolv.conf}}. You can verify dnsmasq is being used by doing the same DNS lookup twice with {{ic|drill example.com}} and verifying the server and query times.<br />
<br />
{{Note|<br />
* You do not need to start {{ic|dnsmasq.service}} or edit {{ic|/etc/dnsmasq.conf}}. NetworkManager will start dnsmasq without using the systemd service and without reading the dnsmasq's default configuration file(s).<br />
* The dnsmasq instance started by NetworkManager will bind to {{ic|127.0.0.1:53}}, you cannot run any other software (including {{ic|dnsmasq.service}}) on the same address and port.<br />
}}<br />
<br />
====== Custom dnsmasq configuration ======<br />
<br />
Custom configurations can be created for ''dnsmasq'' by creating configuration files in {{ic|/etc/NetworkManager/dnsmasq.d/}}. For example, to change the size of the DNS cache (which is stored in RAM):<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/cache.conf|2=<br />
cache-size=1000<br />
}}<br />
<br />
You can check the configuration file syntax with:<br />
<br />
dnsmasq --test --conf-file=/dev/null --conf-dir=/etc/NetworkManager/dnsmasq.d<br />
<br />
See {{man|8|dnsmasq}} for all available options.<br />
<br />
====== IPv6 ======<br />
<br />
{{Accuracy|This does not solve the issue because NetworkManager does not add {{ic|::1}} to {{ic|/etc/resolv.conf}}. Unless {{ic|@::1}} is manually passed to drill, it will still fail with {{ic|Error: error sending query: No (valid) nameservers defined in the resolver}}.}}<br />
<br />
Enabling {{ic|dnsmasq}} in NetworkManager may break IPv6-only DNS lookups (i.e. {{ic|drill -6 [hostname]}}) which would otherwise work. In order to resolve this, creating the following file will configure ''dnsmasq'' to also listen to the IPv6 loopback:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/ipv6-listen.conf|2=<br />
listen-address=::1<br />
}}<br />
<br />
In addition, {{ic|dnsmasq}} also does not prioritize upstream IPv6 DNS. Unfortunately NetworkManager does not do this ([https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/936712 Ubuntu Bug]). A workaround would be to disable IPv4 DNS in the NetworkManager config, assuming one exists.<br />
<br />
====== DNSSEC ======<br />
<br />
The dnsmasq instance started by NetworkManager by default will not validate [[DNSSEC]] since it is started with the {{ic|--proxy-dnssec}} option. It will trust whatever DNSSEC information it gets from the upstream DNS server.<br />
<br />
For dnsmasq to properly validate DNSSEC, thus breaking DNS resolution with name servers that do not support it, create the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/dnssec.conf|2=<br />
conf-file=/usr/share/dnsmasq/trust-anchors.conf<br />
dnssec<br />
}}<br />
<br />
===== systemd-resolved =====<br />
<br />
{{Expansion|NetworkManager 1.16 adds a new setting {{ic|main.systemd-resolved}}[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383] (enabled by default). It unconditionally sends DNS configuration to systemd-resolved. Related to "Preserving resolv.conf" from [[systemd-resolved#DNS]]?}}<br />
<br />
NetworkManager can use [[systemd-resolved]] as a DNS resolver and cache. Make sure that ''systemd-resolved'' is properly configured and that {{ic|systemd-resolved.service}} is [[started]] before using it.<br />
<br />
systemd-resolved will be used automatically if {{ic|/etc/resolv.conf}} is a [[Systemd-resolved#DNS|symlink]] to {{ic|/run/systemd/resolve/stub-resolv.conf}}, {{ic|/run/systemd/resolve/resolv.conf}} or {{ic|/usr/lib/systemd/resolv.conf}}.<br />
<br />
You can enable it explicitly by setting {{ic|1=main.dns=systemd-resolved}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=systemd-resolved<br />
}}<br />
<br />
===== DNS resolver with an openresolv subscriber =====<br />
<br />
If [[openresolv]] has a subscriber for your local [[DNS resolver]], set up the subscriber and [[#Use openresolv|configure NetworkManager to use openresolv]].<br />
<br />
Because NetworkManager advertises a single "interface" to ''resolvconf'', it is not possible to implement conditional forwarding between two NetworkManager connections. See [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 NetworkManager issue 153].<br />
<br />
This can be partially mitigated if you set {{ic|1=private="*"}} in {{ic|/etc/resolvconf.conf}}[https://roy.marples.name/projects/openresolv/configuration.html]. Any queries for domains that are not in search domain list will not get forwarded. They will be handled according to the local resolver's configuration, for example, forwarded to another DNS server or resolved recursively from the DNS root.<br />
<br />
==== Custom DNS servers ====<br />
<br />
===== Setting custom global DNS servers =====<br />
<br />
To set DNS servers for all connections, specify them in {{man|5|NetworkManager.conf}} using the syntax {{ic|1=servers=''serveripaddress1'',''serveripaddress2'',''serveripaddress3''}} in a section named {{ic|[global-dns-domain-*]}}. For example:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns-servers.conf|2=<br />
[global-dns-domain-*]<br />
servers=::1,127.0.0.1<br />
}}<br />
<br />
{{Note|<br />
* If you use [[#DNS caching and conditional forwarding|NetworkManager's dnsmasq or systemd-resolved plugin]] or [[#DNS resolver with an openresolv subscriber|openresolv subscribers]], then do not specify loopback addresses with the {{ic|1=servers=}} option, it can break DNS resolution.<br />
* The specified servers do not get sent to [[systemd-resolved]], the connection's DNS servers are used instead.<br />
}}<br />
<br />
===== Setting custom DNS servers in a connection =====<br />
<br />
====== Setting custom DNS servers in a connection (GUI) ======<br />
<br />
Setup will depend on the type of front-end used; the process usually involves right-clicking on the applet, editing (or creating) a profile, and then choosing DHCP type as ''Automatic (specify addresses)''. The DNS addresses will need to be entered and are usually in this form: {{ic|127.0.0.1, ''DNS-server-one'', ...}}.<br />
<br />
====== Setting custom DNS servers in a connection (nmcli / connection file) ======<br />
<br />
To setup DNS Servers per connection, you can use the {{ic|dns}} field (and the associated {{ic|dns-search}} and {{ic|dns-options}}) in the [[#Edit a connection|connection settings]]. <br />
<br />
If {{ic|method}} is set to {{ic|auto}} (when you use DHCP), you need to set {{ic|ignore-auto-dns}} to {{ic|yes}}.<br />
<br />
==== /etc/resolv.conf ====<br />
<br />
NetworkManager's {{ic|/etc/resolv.conf}} management mode is configured with the {{ic|main.rc-manager}} setting. The default {{ic|auto}} mode chooses how {{ic|/etc/resolv.conf}} is managed in the following order:<br />
<br />
* If {{ic|/etc/resolv.conf}} is [[File permissions and attributes#File attributes|immutable]], then the file [[#Unmanaged /etc/resolv.conf|is not touched at all]]. This is the equivalent of {{ic|1=main.rc-manager=unmanaged}}.<br />
* If {{ic|/etc/resolv.conf}} is a symlink to {{ic|/run/systemd/resolve/stub-resolv.conf}}, {{ic|/run/systemd/resolve/resolv.conf}} or {{ic|/usr/lib/systemd/resolv.conf}}, then [[#systemd-resolved|systemd-resolved is used]]. This is the equivalent of {{ic|1=main.rc-manager=systemd-resolved}}.<br />
* If {{ic|/usr/bin/resolvconf}} exists, then [[#Use openresolv|resolvconf is used]]. This is the equivalent of {{ic|1=main.rc-manager=resolvconf}}.<br />
* If {{ic|/etc/resolv.conf}} is a regular file, then NetworkManager writes to it directly. This is the equivalent of {{ic|1=main.rc-manager=file}}.<br />
<br />
Further details are provided in the {{man|5|NetworkManager}} man page.<br />
<br />
{{Tip|Using openresolv allows NetworkManager to coexists with other ''resolvconf'' supporting software or, for example, to run a local DNS caching and split-DNS resolver for which openresolv has a [[openresolv#Subscribers|subscriber]]. Note that conditional forwarding is [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 not yet fully supported] when using NetworkManager with openresolv.}}<br />
<br />
''NetworkManager'' also offers hooks via so called dispatcher scripts that can be used to alter the {{ic|/etc/resolv.conf}} after network changes. See [[#Network services with NetworkManager dispatcher]] and {{man|8|NetworkManager}} for more information.<br />
<br />
{{Note|<br />
* If NetworkManager is configured to use either [[#dnsmasq|dnsmasq]] or [[#systemd-resolved|systemd-resolved]], then the appropriate loopback addresses will be written to {{ic|/etc/resolv.conf}}.<br />
* The {{ic|resolv.conf}} file NetworkManager writes or would write to {{ic|/etc/resolv.conf}} can be found at {{ic|/run/NetworkManager/resolv.conf}}.<br />
* A {{ic|resolv.conf}} file with the acquired name servers and search domains can be found at {{ic|/run/NetworkManager/no-stub-resolv.conf}}.<br />
}}<br />
<br />
===== Unmanaged /etc/resolv.conf =====<br />
<br />
To stop NetworkManager from touching {{ic|/etc/resolv.conf}}, set {{ic|1=main.dns=none}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=none<br />
}}<br />
<br />
{{Tip|You might also want to set {{ic|1=main.systemd-resolved=false}}, so that NetworkManager does not send the DNS configuration to [[systemd-resolved]].}}<br />
<br />
{{Note|See [[#DNS caching and conditional forwarding]], to configure NetworkManager using other DNS backends like [[dnsmasq]] and [[systemd-resolved]], instead of using {{ic|1=main.dns=none}}.}}<br />
<br />
After that {{ic|/etc/resolv.conf}} might be a broken symlink that you will need to remove. Then, just create a new {{ic|/etc/resolv.conf}} file.<br />
<br />
===== Use openresolv =====<br />
<br />
{{Tip|NetworkManager will automatically use ''resolvconf'' unless {{ic|/etc/resolv.conf}} is immutable or a symlink to one of systemd-resolved's {{ic|resolv.conf}} files.}}<br />
<br />
{{Note|NetworkManager does not support using systemd-resolved's ''resolvconf'' interface ({{man|1|resolvectl|COMPATIBILITY WITH RESOLVCONF(8)}}) which is provided by {{Pkg|systemd-resolvconf}}.<br />
* Do not set {{ic|1=rc-manager=resolvconf}} when using [[systemd-resolved]], , instead make sure to [[systemd-resolved#DNS|correctly create the /etc/resolv.conf symlink]] or [[#systemd-resolved|configure NetworkManager to use systemd-resolved explicitly]].<br />
* Make sure the {{Pkg|systemd-resolvconf}} package is not installed when systemd-resolved is not used. Unless {{ic|systemd-resolved.service}} started, it will break all networking software (not just NetworkManager) that use resolvconf.<br />
}}<br />
<br />
To explicitly configure NetworkManager to use [[openresolv]], set {{ic|1=main.rc-manager=resolvconf}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/rc-manager.conf|2=<br />
[main]<br />
rc-manager=resolvconf<br />
}}<br />
<br />
=== Firewall ===<br />
<br />
You can assign a [[firewalld]] zone based on your current connection. For example a restrictive firewall when at work, and a less restrictive one when at home.<br />
<br />
This can also be done with [[#Network services with NetworkManager dispatcher|NetworkManager dispatcher]].<br />
<br />
== Network services with NetworkManager dispatcher ==<br />
<br />
There are quite a few network services that you will not want running until NetworkManager brings up an interface. NetworkManager has the ability to start services when you connect to a network and stop them when you disconnect (e.g. when using [[NFS]], [[SMB]] and [[NTPd]]).<br />
<br />
To activate the feature you need to [[enable]] and [[start]] the {{ic|NetworkManager-dispatcher.service}}.<br />
<br />
Once the service is active, scripts can be added to the {{ic|/etc/NetworkManager/dispatcher.d}} directory.<br />
<br />
Scripts must be owned by '''root''', otherwise the dispatcher will not execute them. For added security, set group [[ownership]] to root as well:<br />
<br />
# chown root:root /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
Make sure the file has correct permissions:<br />
<br />
# chmod 755 /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
The scripts will be run in alphabetical order at connection time, and in reverse alphabetical order at disconnect time. To ensure what order they come up in, it is common to use numerical characters prior to the name of the script (e.g. {{ic|10-portmap}} or {{ic|30-netfs}} (which ensures that the ''portmapper'' is up before NFS mounts are attempted).<br />
<br />
Scripts will receive the following arguments:<br />
<br />
* '''Interface name:''' e.g. {{ic|eth0}}<br />
* '''Interface status:''' ''up'' or ''down''<br />
* '''VPN status:''' ''vpn-up'' or ''vpn-down''<br />
<br />
{{Warning|If you connect to foreign or public networks, be aware of what services you are starting and what servers you expect to be available for them to connect to. You could make a security hole by starting the wrong services while connected to a public network.}}<br />
<br />
=== Avoiding the dispatcher timeout ===<br />
<br />
If the above is working, then this section is not relevant. However, there is a general problem related to running dispatcher scripts which take longer to be executed. Initially an internal timeout of three seconds only was used. If the called script did not complete in time, it was killed. Later the timeout was extended to about 20 seconds (see the [https://bugzilla.redhat.com/show_bug.cgi?id=982734 Bugtracker] for more information). If the timeout still creates the problem, a work around may be to modify the dispatcher service file {{ic|/usr/lib/systemd/system/NetworkManager-dispatcher.service}} to remain active after exit: <br />
<br />
{{hc|/etc/systemd/system/NetworkManager-dispatcher.service.d/remain_after_exit.conf|2=<br />
[Service]<br />
RemainAfterExit=yes<br />
}}<br />
<br />
Now start and enable the modified {{ic|NetworkManager-dispatcher}} service.<br />
<br />
{{Warning|Adding the {{ic|RemainAfterExit}} line to it will prevent the dispatcher from closing. Unfortunately, the dispatcher '''has''' to close before it can run your scripts again. With it the dispatcher will not time out but it also will not close, which means that the scripts will only run once per boot. Therefore, do not add the line unless the timeout is definitely causing a problem.}}<br />
<br />
=== Dispatcher examples ===<br />
<br />
==== Mount remote folder with sshfs ====<br />
<br />
As the script is run in a very restrictive environment, you have to export {{ic|SSH_AUTH_SOCK}} in order to connect to your SSH agent. There are different ways to accomplish this, see [https://bbs.archlinux.org/viewtopic.php?pid=1042030#p1042030 this message] for more information. The example below works with [[GNOME Keyring]], and will ask you for the password if not unlocked already. In case NetworkManager connects automatically on login, it is likely ''gnome-keyring'' has not yet started and the export will fail (hence the sleep). The {{ic|UUID}} to match can be found with the command {{ic|nmcli connection status}} or {{ic|nmcli connection list}}. <br />
<br />
{{bc|<nowiki><br />
#!/bin/sh<br />
USER='username'<br />
REMOTE='user@host:/remote/path'<br />
LOCAL='/local/path'<br />
<br />
interface=$1 status=$2<br />
if [ "$CONNECTION_UUID" = "</nowiki>''uuid''<nowiki>" ]; then<br />
case $status in<br />
up)<br />
SSH_AUTH_SOCK=$(find /tmp -maxdepth 1 -type s -user "$USER" -name 'ssh')<br />
export SSH_AUTH_SOCK<br />
su "$USER" -c "sshfs $REMOTE $LOCAL"<br />
;;<br />
down)<br />
fusermount -u "$LOCAL"<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
==== Mounting of SMB shares ====<br />
<br />
Some [[SMB]] shares are only available on certain networks or locations (e.g. at home). You can use the dispatcher to only mount SMB shares that are present at your current location.<br />
<br />
The following script will check if we connected to a specific network and mount shares accordingly:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-mount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
# Find the connection UUID with "nmcli connection show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
if [ "$2" = "up" ]; then<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
mount /your/mount/point & <br />
# add more shares as needed<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The following script will unmount all SMB shares before a software initiated disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/pre-down.d/30-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|Make sure this script is located in the {{ic|pre-down.d}} sub-directory as shown above, otherwise it will unmount all shares on any connection state change.}}<br />
<br />
The following script will attempt to unmount all SMB shares following an unexpected disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/40-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
if [ "$2" = "down" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|<br />
* Since NetworkManager 0.9.8, the ''pre-down'' and ''down'' events are not executed on shutdown or restart, see [https://bugzilla.gnome.org/show_bug.cgi?id&#61;701242 this bug report] for more info.<br />
* The previous ''umount'' scripts are still prone to leaving applications actually accessing the mount to 'hang'.<br />
}}<br />
<br />
An alternative is to use the script as seen in [[NFS#Using a NetworkManager dispatcher]]:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-smb.sh|<nowiki><br />
#!/bin/bash<br />
<br />
# Find the connection UUID with "nmcli con show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
WANTED_CON_UUID="CHANGE-ME-NOW-9c7eff15-010a-4b1c-a786-9b4efa218ba9"<br />
<br />
if [[ "$CONNECTION_UUID" == "$WANTED_CON_UUID" ]]; then<br />
<br />
# Script parameter $1: NetworkManager connection name, not used<br />
# Script parameter $2: dispatched event<br />
<br />
case "$2" in<br />
"up")<br />
mount -a -t cifs<br />
;;<br />
"pre-down");&<br />
"vpn-pre-down")<br />
umount -l -a -t cifs >/dev/null<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|This script ignores mounts with the {{ic|noauto}} option, remove this mount option or use {{ic|auto}} to allow the dispatcher to manage these mounts.}}<br />
<br />
Create a symlink inside {{ic|/etc/NetworkManager/dispatcher.d/pre-down/}} to catch the {{ic|pre-down}} events:<br />
<br />
# ln -s ../30-smb.sh /etc/NetworkManager/dispatcher.d/pre-down.d/30-smb.sh<br />
<br />
==== Mounting of NFS shares ====<br />
<br />
See [[NFS#Using a NetworkManager dispatcher]].<br />
<br />
==== Use dispatcher to automatically toggle wireless depending on LAN cable being plugged in ====<br />
<br />
The idea is to only turn Wi-Fi on when the LAN cable is unplugged (for example when detaching from a laptop dock), and for Wi-Fi to be automatically disabled, once a LAN cable is plugged in again. <br />
<br />
Create the following dispatcher script[https://superuser.com/questions/233448/disable-wlan-if-wired-cable-network-is-available], replacing {{ic|1=LAN_interface}} with yours.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/wlan_auto_toggle.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$1" = "LAN_interface" ]; then<br />
case "$2" in<br />
up)<br />
nmcli radio wifi off<br />
;;<br />
down)<br />
nmcli radio wifi on<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|You can get a list of interfaces using [[#nmcli examples|nmcli]]. The ethernet (LAN) interfaces start with {{ic|en}}, e.g. {{ic|1=enp0s5}}}}<br />
<br />
==== Use dispatcher to connect to a VPN after a network connection is established ====<br />
<br />
In this example we want to connect automatically to a previously defined VPN connection after connecting to a specific Wi-Fi network. First thing to do is to create the dispatcher script that defines what to do after we are connected to the network.<br />
<br />
{{Note|This script will require {{Pkg|wireless_tools}} in order to use {{ic|iwgetid}}.}}<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME"<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you would like to attempt to automatically connect to VPN for all Wi-Fi networks, you can use the following definition of the ESSID: {{ic|1=ESSID=$(iwgetid -r)}}. Remember to set the script's permissions [[#Network services with NetworkManager dispatcher|accordingly]]. <br />
<br />
Trying to connect with the above script may still fail with {{ic|NetworkManager-dispatcher.service}} complaining about 'no valid VPN secrets', because of [https://developer.gnome.org/NetworkManager/0.9/secrets-flags.html the way VPN secrets are stored]. Fortunately, there are different options to give the above script access to your VPN password.<br />
<br />
1: One of them requires editing the VPN connection configuration file to make NetworkManager store the secrets by itself rather than inside a keyring [https://bugzilla.redhat.com/show_bug.cgi?id=710552 that will be inaccessible for root]: open up {{ic|/etc/NetworkManager/system-connections/''name of your VPN connection''}} and change the {{ic|password-flags}} and {{ic|secret-flags}} from {{ic|1}} to {{ic|0}}.<br />
<br />
If that alone does not work, you may have to create a {{ic|passwd-file}} in a safe location with the same permissions and ownership as the dispatcher script, containing the following:<br />
<br />
{{hc|/path/to/passwd-file|<br />
vpn.secrets.password:YOUR_PASSWORD<br />
}}<br />
<br />
The script must be changed accordingly, so that it gets the password from the file:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME" passwd-file /path/to/passwd-file<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
2: Alternatively, change the {{ic|password-flags}} and put the password directly in the configuration file adding the section {{ic|vpn-secrets}}:<br />
<br />
[vpn]<br />
....<br />
password-flags=0<br />
<br />
[vpn-secrets]<br />
password=''your_password''<br />
<br />
{{Note|It may now be necessary to re-open the NetworkManager connection editor and save the VPN passwords/secrets again.}}<br />
<br />
==== Use dispatcher to disable IPv6 on VPN provider connections ====<br />
<br />
Many [[:Category:VPN providers|commercial VPN providers]] support only IPv4. That means all IPv6 traffic bypasses the VPN and renders it virtually useless. To avoid this, dispatcher can be used to disable all IPv6 traffic for the time a VPN connection is up.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/10-vpn-ipv6|<nowiki><br />
#!/bin/sh<br />
<br />
case "$2" in<br />
vpn-up)<br />
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
vpn-down)<br />
echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
==== OpenNTPD ====<br />
<br />
See [[OpenNTPD#Using NetworkManager dispatcher]].<br />
<br />
== Testing ==<br />
<br />
NetworkManager applets are designed to load upon login so no further configuration should be necessary for most users. If you have already disabled your previous network settings and disconnected from your network, you can now test if NetworkManager will work. The first step is to [[start]] {{ic|NetworkManager.service}}.<br />
<br />
Some applets will provide you with a {{ic|.desktop}} file so that the NetworkManager applet can be loaded through the application menu. If it does not, you are going to either have to discover the command to use or logout and login again to start the applet. Once the applet is started, it will likely begin polling network connections with for auto-configuration with a DHCP server.<br />
<br />
To start the GNOME applet in non-xdg-compliant window managers like [[awesome]]:<br />
<br />
nm-applet --sm-disable &<br />
<br />
For static IP addresses, you will have to configure NetworkManager to understand them. The process usually involves right-clicking the applet and selecting something like 'Edit Connections'.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Encrypted Wi-Fi passwords ===<br />
<br />
By default, NetworkManager stores passwords in clear text in the connection files at {{ic|/etc/NetworkManager/system-connections/}}. To print the stored passwords, use the following command:<br />
<br />
# grep -r '^psk=' /etc/NetworkManager/system-connections/<br />
<br />
The passwords are accessible to the root user in the filesystem and to users with access to settings via the GUI (e.g. {{ic|nm-applet}}). <br />
<br />
It is preferable to save the passwords in encrypted form in a keyring instead of clear text. The downside of using a keyring is that the connections have to be set up for each user.<br />
<br />
==== Using GNOME Keyring ====<br />
<br />
The keyring daemon has to be started and the keyring needs to be unlocked for the following to work.<br />
<br />
Furthermore, NetworkManager needs to be configured not to store the password for all users. Using GNOME {{ic|nm-applet}}, run {{ic|nm-connection-editor}} from a terminal, select a network connection, click {{ic|Edit}}, select the {{ic|Wifi-Security}} tab and click on the right icon of password and check {{ic|Store the password only for this user}}.<br />
<br />
==== Using KDE Wallet ====<br />
<br />
Using KDE's {{Pkg|plasma-nm}}, click the applet, click on the top right {{ic|Settings}} icon, click on a network connection, in the {{ic|General settings}} tab, untick {{ic|all users may connect to this network}}. If the option is ticked, the passwords will still be stored in clear text, even if a keyring daemon is running.<br />
<br />
If the option was selected previously and you un-tick it, you may have to use the {{ic|reset}} option first to make the password disappear from the file. Alternatively, delete the connection first and set it up again.<br />
<br />
=== Sharing internet connection over Wi-Fi ===<br />
<br />
You can share your internet connection (e.g. 3G or wired) with a few clicks. Please note that a [[firewall]] may interfere with internet sharing.<br />
<br />
You will need a Wi-Fi card which supports AP mode, see [[Software access point#Wi-Fi device must support AP mode]] for details.<br />
<br />
[[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
<br />
Create the shared connection:<br />
<br />
* Click on applet and choose ''Create new wireless network''.<br />
* Follow wizard (choose WPA2 or higher, be sure to use at least 8 character long password, lower lengths will fail).<br />
** Choose either [[Fedora:Features/RealHotspot|Hotspot]] or Ad-hoc as Wi-Fi mode.<br />
<br />
The connection will be saved and remain stored for the next time you need it.<br />
<br />
{{Note|Android does not support connecting to Ad-hoc networks. To share a connection with Android use infrastructure mode (i.e. set Wi-Fi mode to "Hotspot").}}<br />
<br />
=== Sharing internet connection over Ethernet ===<br />
<br />
Scenario: your device has internet connection over wi-fi and you want to share the internet connection to other devices over ethernet.<br />
<br />
Requirements:<br />
<br />
* [[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
* Your internet connected device and the other devices are connected over a suitable ethernet cable (this usually means a cross over cable or a switch in between).<br />
* Internet sharing is not blocked by a [[firewall]].<br />
<br />
Steps:<br />
<br />
{{Style|{{Pkg|nm-connection-editor}} is not a dependency of {{Pkg|networkmanager}} and needs to be installed separately.}}<br />
<br />
* Run {{ic|nm-connection-editor}} from terminal.<br />
* Add a new ethernet connection.<br />
* Give it some sensible name. For example "Shared Internet"<br />
* Go to "IPv4 Settings".<br />
* For "Method:" select "Shared to other computers".<br />
* Save<br />
<br />
Now you should have a new option "Shared Internet" under the Wired connections in NetworkManager.<br />
<br />
=== Checking if networking is up inside a cron job or script ===<br />
<br />
{{Out of date|''nm-tool'' was remove from NetworkManager for long time now[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/bb8c75bd536d4f8fb80a4366025a279078f0ec81]. ''nmcli'' should be used instead.}}<br />
<br />
Some ''cron'' jobs require networking to be up to succeed. You may wish to avoid running these jobs when the network is down. To accomplish this, add an '''if''' test for networking that queries NetworkManager's ''nm-tool'' and checks the state of networking. The test shown here succeeds if any interface is up, and fails if they are all down. This is convenient for laptops that might be hardwired, might be on wireless, or might be off the network.<br />
<br />
{{bc|<nowiki><br />
if [ $(nm-tool|grep State|cut -f2 -d' ') == "connected" ]; then<br />
#Whatever you want to do if the network is online<br />
else<br />
#Whatever you want to do if the network is offline - note, this and the else above are optional<br />
fi<br />
</nowiki>}}<br />
<br />
This useful for a {{ic|cron.hourly}} script that runs ''fpupdate'' for the F-Prot virus scanner signature update, as an example. Another way it might be useful, with a little modification, is to differentiate between networks using various parts of the output from ''nm-tool''; for example, since the active wireless network is denoted with an asterisk, you could grep for the network name and then grep for a literal asterisk.<br />
<br />
=== Connect to network with secret on boot ===<br />
<br />
By default, NetworkManager will not connect to networks requiring a secret automatically on boot. This is because it locks such connections to the user who makes it by default, only connecting after they have logged in. To change this, do the following:<br />
<br />
# Right click on the {{ic|nm-applet}} icon in your panel and select Edit Connections and open the Wireless tab<br />
# Select the connection you want to work with and click the Edit button<br />
# Check the boxes “Connect Automatically” and “Available to all users”<br />
# Additionally, ensure that under "Wi-Fi Security", "Store password for all users (not encrypted)" is selected<br />
<br />
Log out and log back in to complete.<br />
<br />
=== OpenConnect with password in KWallet ===<br />
<br />
While you may type both values at connection time, {{Pkg|plasma-nm}} 0.9.3.2-1 and above are capable of retrieving OpenConnect username and password directly from [[KWallet]].<br />
<br />
Open "KDE Wallet Manager" and look up your OpenConnect VPN connection under "Network Management|Maps". Click "Show values" and <br />
enter your credentials in key "VpnSecrets" in this form (replace ''username'' and ''password'' accordingly):<br />
<br />
form:main:username%SEP%''username''%SEP%form:main:password%SEP%''password''<br />
<br />
Next time you connect, username and password should appear in the "VPN secrets" dialog box.<br />
<br />
=== Ignore specific devices ===<br />
<br />
Sometimes it may be desired that NetworkManager ignores specific devices and does not try to configure addresses and routes for them. You can quickly and easily ignore devices by MAC or interface-name by using the following in {{ic|/etc/NetworkManager/conf.d/unmanaged.conf}}:<br />
<br />
[keyfile]<br />
unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth0<br />
<br />
After editing the file, run {{ic|nmcli general reload}} as root. Afterwards you should be able to configure interfaces without NetworkManager altering what you have set.<br />
<br />
=== Configuring MAC address randomization ===<br />
<br />
{{Note|1=Disabling MAC address randomization may be needed to get (stable) link connection [https://bbs.archlinux.org/viewtopic.php?id=220101] and/or networks that restrict devices based on their MAC Address or have a limit network capacity.}}<br />
<br />
MAC randomization can be used for increased privacy by not disclosing your real MAC address to the network.<br />
<br />
NetworkManager supports two types MAC Address Randomization: randomization during scanning, and for network connections. Both modes can be configured by modifying {{ic|/etc/NetworkManager/NetworkManager.conf}} or by creating a separate configuration file in {{ic|/etc/NetworkManager/conf.d/}} which is recommended since the aforementioned config file may be overwritten by NetworkManager.<br />
<br />
Randomization during Wi-Fi scanning is enabled by default, but it may be disabled by adding the following lines to {{ic|/etc/NetworkManager/NetworkManager.conf}} or a dedicated configuration file under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device]<br />
wifi.scan-rand-mac-address=no<br />
}}<br />
<br />
MAC randomization for network connections can be set to different modes for both wireless and ethernet interfaces. See the [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details on the different modes. <br />
<br />
In terms of MAC randomization the most important modes are {{ic|stable}} and {{ic|random}}. {{ic|stable}} generates a random MAC address when you connect to a new network and associates the two permanently. This means that you will use the same MAC address every time you connect to that network. In contrast, {{ic|random}} will generate a new MAC address every time you connect to a network, new or previously known. You can configure the MAC randomization by adding the desired configuration under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device-mac-randomization]<br />
# "yes" is already the default for scanning<br />
wifi.scan-rand-mac-address=yes<br />
<br />
[connection-mac-randomization]<br />
# Randomize MAC for every ethernet connection<br />
ethernet.cloned-mac-address=random<br />
# Generate a random MAC for each WiFi and associate the two permanently.<br />
wifi.cloned-mac-address=stable<br />
}}<br />
<br />
See the following [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details.<br />
<br />
=== Enable IPv6 Privacy Extensions ===<br />
<br />
See [[IPv6#NetworkManager]].<br />
<br />
=== Working with wired connections ===<br />
<br />
By default, NetworkManager generates a connection profile for each wired ethernet connection it finds. At the point when generating the connection, it does not know whether there will be more ethernet adapters available. Hence, it calls the first wired connection "Wired connection 1". You can avoid generating this connection, by configuring {{ic|no-auto-default}} (see {{man|5|NetworkManager.conf}}), or by simply deleting it. Then NetworkManager will remember not to generate a connection for this interface again.<br />
<br />
You can also edit the connection (and persist it to disk) or delete it. NetworkManager will not re-generate a new connection. Then you can change the name to whatever you want. You can use something like nm-connection-editor for this task.<br />
<br />
=== Using iwd as the Wi-Fi backend ===<br />
<br />
{{Note|1=Consider [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues?scope=all&utf8=%E2%9C%93&state=opened&search=iwd existing issues] before switching to iwd.}}<br />
<br />
Enable the [https://iwd.wiki.kernel.org/networkmanager experimental] [[iwd]] backend creating the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_backend.conf|2=<br />
[device]<br />
wifi.backend=iwd<br />
}}<br />
<br />
Alternatively, you can install {{AUR|networkmanager-iwd}}, a modified package configured to build ''NetworkManager'' working exclusively with ''iwd'', with the main difference being that ''iwd'' is required and ''wpa_supplicant'' can be uninstalled after building.<br />
<br />
=== Running in a network namespace ===<br />
<br />
If you would like to run NetworkManager inside a network namespace (e.g., to manage a specific device which should be use by selected applications), bring the device down before moving it to the namespace:<br />
<br />
$ ip link set dev ''MY_DEVICE'' down<br />
$ ip link set dev ''MY_DEVICE'' netns ''MY_NAMESPACE''<br />
$ ip netns exec ''MY_NAMESPACE'' NetworkManager<br />
...<br />
$ ip netns exec ''MY_NAMESPACE'' killall NetworkManager<br />
<br />
otherwise NetworkManager will later fail to establish the connection with a {{ic|device is strictly unmanaged}} error.<br />
<br />
=== Automatically connect to VPN ===<br />
<br />
NetworkManager can be set to automatically connect to a VPN when connecting to the internet, on a per network basis. The VPN connection itself can be added in GNOME's NetworkManager font-end, but to make it automatically use the VPN {{ic|nmcli}} must be used. Other front-ends might not have this limitation.<br />
<br />
First, make sure to make the VPN connection available to all users. In the GNOME this is a matter of checking a box under the {{ic|details}} tab. Under the {{ic|Identity}} tab, in the password field, click the icon on the right side in the field, and set it to {{ic|Store the password for all users}}.<br />
<br />
Then find the UUID of the VPN connection, and add that to {{ic|connection.secondaries}} of the Internet connection:<br />
<br />
# UUID=$(nmcli --get-values connection.uuid connection show ''name-of-VPN-connection'')<br />
# nmcli connection modify ''name-of-Internet-connection'' connection.secondaries "$UUID"<br />
<br />
Now when NetworkManager is restarted and you connect to the Internet connection you have configured, you should automatically get connected to the VPN.<br />
<br />
== Troubleshooting ==<br />
<br />
=== No prompt for password of secured Wi-Fi networks ===<br />
<br />
When trying to connect to a secured Wi-Fi network, no prompt for a password is shown and no connection is established. This happens when no keyring package is installed. An easy solution is to install {{Pkg|gnome-keyring}}. If you want the passwords to be stored in encrypted form, follow [[GNOME Keyring]] to set up the ''gnome-keyring-daemon''.<br />
<br />
=== Network management disabled ===<br />
<br />
When NetworkManager shuts down but the pid (state) file is not removed, you will see a {{ic|Network management disabled}} message. If this happens, remove the file manually:<br />
<br />
# rm /var/lib/NetworkManager/NetworkManager.state<br />
<br />
=== Problems with internal DHCP client ===<br />
<br />
If you have problems with getting an IP address using the internal DHCP client, consider using another DHCP client, see [[#DHCP client]] for instructions. This workaround might solve problems in big wireless networks like eduroam.<br />
<br />
=== DHCP problems with dhclient ===<br />
<br />
If you have problems with getting an IP address via DHCP, try to add the following to your {{ic|/etc/dhclient.conf}}:<br />
<br />
interface "eth0" {<br />
send dhcp-client-identifier 01:''aa:bb:cc:dd:ee:ff'';<br />
}<br />
<br />
Where {{ic|''aa:bb:cc:dd:ee:ff''}} is the MAC address of this NIC. The MAC address can be found using the {{ic|ip link show ''interface''}} command from the {{Pkg|iproute2}} package.<br />
<br />
=== 3G modem not detected ===<br />
<br />
See [[USB 3G Modem#NetworkManager]].<br />
<br />
=== Switching off WLAN on laptops ===<br />
<br />
Sometimes NetworkManager will not work when you disable your Wi-Fi adapter with a switch on your laptop and try to enable it again afterwards. This is often a problem with ''rfkill''. To check if the driver notifies ''rfkill'' about the wireless adapter's status, use:<br />
<br />
$ watch -n1 rfkill list all<br />
<br />
If one identifier stays blocked after you switch on the adapter you could try to manually unblock it with (where X is the number of the identifier provided by the above output):<br />
<br />
# rfkill event unblock X<br />
<br />
=== Static IP address settings revert to DHCP ===<br />
<br />
Due to an unresolved bug, when changing default connections to a static IP address, {{ic|nm-applet}} may not properly store the configuration change, and will revert to automatic DHCP.<br />
<br />
To work around this issue you have to edit the default connection (e.g. "Auto eth0") in {{ic|nm-applet}}, change the connection name (e.g. "my eth0"), uncheck the "Available to all users" checkbox, change your static IP address settings as desired, and click '''Apply'''. This will save a new connection with the given name.<br />
<br />
Next, you will want to make the default connection not connect automatically. To do so, run {{ic|nm-connection-editor}} ('''not''' as root). In the connection editor, edit the default connection (e.g. "Auto eth0") and uncheck "Connect automatically". Click '''Apply''' and close the connection editor.<br />
<br />
=== Cannot edit connections as normal user ===<br />
<br />
See [[#Set up PolicyKit permissions]].<br />
<br />
=== Forget hidden wireless network ===<br />
<br />
Since hidden networks are not displayed in the selection list of the Wireless view, they cannot be forgotten (removed) with the GUI. You can delete one with the following command:<br />
<br />
# rm /etc/NetworkManager/system-connections/''SSID''<br />
<br />
This works for any other connection.<br />
<br />
=== VPN not working in GNOME ===<br />
<br />
When setting up OpenConnect or vpnc connections in NetworkManager while using GNOME, you will sometimes never see the dialog box pop up and the following error appears in {{ic|/var/log/errors.log}}:<br />
<br />
localhost NetworkManager[399]: <error> [1361719690.10506] [nm-vpn-connection.c:1405] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.<br />
<br />
This is caused by the GNOME NM Applet expecting dialog scripts to be at {{ic|/usr/lib/gnome-shell}}, when NetworkManager's packages put them in {{ic|/usr/lib/networkmanager}}.<br />
As a "temporary" fix (this bug has been around for a while now), make the following symlink(s):<br />
<br />
* For OpenConnect: {{ic|ln -s /usr/lib/networkmanager/nm-openconnect-auth-dialog /usr/lib/gnome-shell/}}<br />
* For VPNC (i.e. Cisco VPN): {{ic|ln -s /usr/lib/networkmanager/nm-vpnc-auth-dialog /usr/lib/gnome-shell/}}<br />
<br />
This may need to be done for any other NM VPN plugins as well, but these are the two most common.<br />
<br />
=== Unable to connect to visible European wireless networks ===<br />
<br />
WLAN chips are shipped with a default [[Wireless network configuration#Respecting the regulatory domain|regulatory domain]]. If your access point does not operate within these limitations, you will not be able to connect to the network. Fixing this is easy:<br />
<br />
# [[Install]] {{Pkg|crda}}<br />
# Uncomment the correct Country Code in {{ic|/etc/conf.d/wireless-regdom}}<br />
# Reboot the system, because the setting is only read on boot<br />
<br />
=== Automatic connect to VPN on boot is not working ===<br />
<br />
The problem occurs when the system (i.e. NetworkManager running as the root user) tries to establish a VPN connection, but the password is not accessible because it is stored in the GNOME keyring of a particular user. <br />
<br />
A solution is to keep the password to your VPN in plaintext, as described in step (2.) of [[#Use dispatcher to connect to a VPN after a network connection is established]]. <br />
<br />
You do not need to use the dispatcher described in step (1.) to auto-connect anymore, if you use the new "auto-connect VPN" option from the {{ic|nm-applet}} GUI.<br />
<br />
=== Systemd Bottleneck ===<br />
<br />
Over time the log files ({{ic|/var/log/journal}}) can become very large. This can have a big impact on boot performance when using NetworkManager, see: [[Systemd#Boot time increasing over time]].<br />
<br />
=== Regular network disconnects, latency and lost packets (WiFi) ===<br />
<br />
NetworkManager does a scan every 2 minutes.<br />
<br />
Some WiFi drivers have issues when scanning for base stations whilst connected/associated. Symptoms include VPN disconnects/reconnects and lost packets, web pages failing to load and then refresh fine.<br />
<br />
Running {{ic|journalctl -f}} will indicate that this is taking place, messages like the following will be contained in the logs at regular intervals.<br />
<br />
NetworkManager[410]: <info> (wlp3s0): roamed from BSSID 00:14:48:11:20:CF (my-wifi-name) to (none) ((none))<br />
<br />
There is a patched version of NetworkManager which should prevent this type of scanning: {{AUR|networkmanager-noscan}}.<br />
<br />
Alternatively, if roaming is not important, the periodic scanning behavior can be disabled by locking the BSSID of the access point in the WiFi connection profile.<br />
<br />
=== Unable to turn on wi-fi with Lenovo laptop (IdeaPad, Legion, etc.) ===<br />
<br />
There is an issue with the {{ic|ideapad_laptop}} module on some Lenovo models due to the wi-fi driver incorrectly reporting a soft block. The card can still be manipulated with {{ic|netctl}}, but managers like NetworkManager break. You can verify that this is the problem by checking the output of {{ic|rfkill list}} after toggling your hardware switch and seeing that the soft block persists.<br />
<br />
{{Accuracy|Try to use {{ic|rfkill.default_state}} and {{ic|rfkill.master_switch_mode}} (see [https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt kernel-parameters.txt]) to fix the rfkill problem.}}<br />
<br />
[[modprobe|Unloading]] the {{ic|ideapad_laptop}} module should fix this. ('''warning''': this may disable the laptop keyboard and touchpad also!).<br />
<br />
=== Turn off hostname sending ===<br />
<br />
NetworkManager by default sends the hostname to the DHCP server. Hostname sending can only be disabled per connection not globally ([https://bugzilla.gnome.org/show_bug.cgi?id=768076 GNOME Bug 768076]).<br />
<br />
To disable sending your hostname to the DHCP server for a specific connection, add the following to your network connection file:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''your_connection_file''|2=<br />
...<br />
[ipv4]<br />
dhcp-send-hostname=false<br />
...<br />
[ipv6]<br />
dhcp-send-hostname=false<br />
...<br />
}}<br />
<br />
=== nm-applet disappears in i3wm ===<br />
<br />
If you use the {{ic|xfce4-notifyd.service}} for notifications you must [[edit]] the unit and add the following:<br />
<br />
{{hc|/etc/systemd/user/xfce4-notifyd.service.d/display_env.conf|2=<br />
[Service]<br />
Environment="DISPLAY=:0.0"<br />
}}<br />
<br />
After reloading the daemons [[restart]] {{ic|xfce4-notifyd.service}}. Exit i3 and start it back up again and the applet should show on the tray.<br />
<br />
=== nm-applet tray icons display wrongly ===<br />
<br />
Currently the tray icons of nm-applet are drawn on top of one another, i.e. the icon displaying wireless strength might show on top of the icon indicating no wired connection.<br />
This is apparently a GTK3 bug/problem: https://gitlab.gnome.org/GNOME/gtk/issues/1280 .<br />
<br />
A patched version of GTK3 exists in AUR, which apparently fixes the tray icon bug: {{AUR|gtk3-mushrooms}} .<br />
<br />
=== Unit dbus-org.freedesktop.resolve1.service not found ===<br />
<br />
If {{ic|systemd-resolved.service}} is not started, NetworkManager will try to start it using D-Bus and fail:<br />
<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
dbus-daemon[991]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
<br />
This is because NetworkManager will try to send DNS information to [[systemd-resolved]] regardless of the {{ic|1=main.dns=}} setting in {{man|5|NetworkManager.conf}}.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383]<br />
<br />
This can be disabled with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/no-systemd-resolved.conf|2=<br />
[main]<br />
systemd-resolved=false<br />
}}<br />
<br />
See {{Bug|62138}}.<br />
<br />
=== Secrets were required, but not provided ===<br />
<br />
If you attempt to connect to a network using {{ic|nmcli device wifi connect ''SSID'' password ''password''}} and received the following error:<br />
<br />
Error: Connection activation failed: (7) Secrets were required, but not provided<br />
<br />
The error can be resolved by deleting the connection profile and creating a new one:<br />
<br />
$ nmcli connection delete ''SSID''<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
=== WPA Enterprise connection with NetworkManager ===<br />
<br />
If you try to connect to an WPA Enterprise network like 'eduroam' with NetworkManager with the [[iwd]] backend then you will get the following error from NetworkManager:<br />
<br />
Connection 'eduroam' is not avialable on device wlan0 because profile is not compatible with device (802.1x connections must have IWD provisioning files)<br />
<br />
This is because NetworkManager can not configure a WPA Enterprise network. Therefore you have to configure it using an iwd config file {{ic|/var/lib/iwd/''essid''.8021x}} like described in [[iwd#WPA Enterprise]].<br />
<br />
=== Failed to request VPN secrets ===<br />
<br />
If you get this error:<br />
Failed to request VPN secrets #1: No agents were available for this request.<br />
<br />
It is either because the password is empty or you have to [[#Set up PolicyKit permissions|set up PolicyKit permissions]].<br />
<br />
== See also ==<br />
<br />
* [https://blogs.gnome.org/dcbw/2015/02/16/networkmanager-for-administrators-part-1/ NetworkManager for Administrators Part 1]<br />
* [[Wikipedia:NetworkManager]]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Gamemode&diff=640223Gamemode2020-11-01T09:08:27Z<p>Tobbebobbe: formatting</p>
<hr />
<div>[[Category:Gaming]]<br />
<br />
[https://github.com/FeralInteractive/gamemode Gamemode] is a daemon/lib combo for Linux that allows games to request a set of optimisations be temporarily applied to the host OS and/or a game process.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|gamemode}} and {{Pkg|lib32-gamemode}} packages.<br />
<br />
== Configuration ==<br />
<br />
Create and configure a gamemode.ini file. An example [https://github.com/FeralInteractive/gamemode/blob/master/example/gamemode.ini gamemode.ini file can be found here]. Save it in {{ic|/etc/}}, {{ic|$HOME/.config/}} or {{ic|/usr/share/gamemode/}}. <br />
<br />
You may want to make sure that {{ic|desiredgov}} is set to {{ic|performance}} and maybe increase the {{ic|renice}} to 10 or so for higher priority for your game.<br />
<br />
== Running ==<br />
<br />
To run games with gamemode start it like this:<br />
<br />
$ gamemoderun ./game<br />
<br />
When you have started your game you can verify that gamemode is running with the command:<br />
<br />
$ gamemoded -s<br />
<br />
=== Steam ===<br />
<br />
To make sure [[Steam]] starts a game with gamemode, right click the game, select {{ic|Properties...}}, then {{ic|Launch Options}} and enter:<br />
<br />
gamemoderun %command%</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Gaming&diff=640222Gaming2020-11-01T09:05:32Z<p>Tobbebobbe: /* Utilities */ improved explanation</p>
<hr />
<div>[[Category:Gaming]]<br />
[[da:List of games]]<br />
[[es:List of games]]<br />
[[it:List of games]]<br />
[[ja:ゲーム]]<br />
[[lt:Games]]<br />
[[ru:Gaming]]<br />
[[zh-hans:List of games]]<br />
{{Related articles start}}<br />
{{Related|List of games}}<br />
{{Related|Video game platform emulators}}<br />
{{Related|Xorg}}<br />
{{Related articles end}}<br />
<br />
This page contains information about running games and related system configuration tips.<br />
<br />
== Game environments ==<br />
<br />
Different environments exist to play games in Linux:<br />
<br />
* Native – games written for Linux.<br />
* Web – games running in a web browser.<br />
** HTML5 games use canvas and WebGL technologies and work in all modern browsers.<br />
** [[Flash]]-based – you need to install the plugin to play.<br />
* [[Video game platform emulators]] – required for running software designed for other architectures and systems.<br />
* [[Wine]] – Windows compatibility layer, allows to run Windows applications on Unix-like operating systems.<br />
* [[Virtual machine]]s – can be used to install compatible operating systems (such as Windows). [[VirtualBox]] has good 3D support. As an extension of this, if you have compatible hardware you can consider VGA passthrough to a Windows KVM guest, keyword is [https://www.kernel.org/doc/html/latest/driver-api/vfio.html "virtual function I/O" (VFIO)], or [[PCI passthrough via OVMF]].<br />
<br />
== Getting games ==<br />
<br />
Just because games are available for Linux doesn't mean that they are native, they might be pre-packaged with Wine or DOSBox.<br />
<br />
For list of games packaged for Arch in [[official repositories]] / the [[AUR]] see [[List of games]].<br />
<br />
* {{App|Flathub|Central [[Flatpak]] repository, has small but growing game section.|https://flathub.org/apps/category/Game|{{Pkg|flatpak}}, {{Pkg|discover}}, {{Pkg|gnome-software}}}}<br />
* {{App|[[Wikipedia:GOG.com|GOG.com]]|DRM-free game store.|https://www.gog.com|{{AUR|lgogdownloader}}, {{AUR|wyvern}}}}<br />
* {{App|[[Wikipedia:itch.io|itch.io]]|Indie game store.|https://itch.io|{{AUR|itch}}}}<br />
* {{App|Legendary| A free and open-source replacement for the Epic Games Launcher. |https://github.com/derrod/legendary|{{AUR|legendary}}}}<br />
* {{App|[[Wikipedia:Lutris|Lutris]]|Open gaming platform for Linux. Gets games from GOG, Steam, Battle.net, Origin, Uplay and many other sources. Lutris utilizes various [https://lutris.net/runners runners] to launch the games with fully customizable configuration options. |https://lutris.net|{{Pkg|lutris}}}}<br />
* {{App|[[Steam]]|Digital distribution and communications platform developed by Valve.|https://store.steampowered.com|{{Pkg|steam}}}}<br />
* {{App|Athenaeum| A libre replacement to Steam. |https://gitlab.com/librebob/athenaeum|{{AUR|athenaeum-git}}}}<br />
* {{App|Play.it|Automates the build of native packages. Also supports [[Wine]], [[DOSBox]] and ScummVM games.|https://www.dotslashplay.it/|{{AUR|play.it}}, {{AUR|play.it-git}}}}<br />
<br />
== Running games ==<br />
<br />
Certain games or game types may need special configuration to run or to run as expected.<br />
For the most part, games will work right out of the box in Arch Linux with possibly better performance than on other distributions due to compile time optimizations. However, some special setups may require a bit of configuration or scripting to make games run as smoothly as desired.<br />
<br />
=== Multi-screen setups ===<br />
<br />
Running a multi-screen setup may lead to problems with fullscreen games. In such a case, [[#Starting games in a separate X server|running a second X server]] is one possible solution. Another solution may be found in the [[NVIDIA#Gaming using TwinView|NVIDIA article]] (may also apply to non-NVIDIA users).<br />
<br />
=== Keyboard grabbing ===<br />
<br />
Many games grab the keyboard, noticeably preventing you from switching windows (also known as alt-tabbing).<br />
<br />
Some SDL games (e.g. Guacamelee) let you disable grabbing by pressing {{ic|Ctrl-g}}.<br />
<br />
{{Note|SDL is known to sometimes not be able to grab the input system. In such a case, it may succeed in grabbing it after a few seconds of waiting.}}<br />
<br />
=== Starting games in a separate X server ===<br />
<br />
In some cases like those mentioned above, it may be necessary or desired to run a second X server. Running a second X server has multiple advantages such as better performance, the ability to "tab" out of your game by using {{ic|Ctrl+Alt+F7}}/{{ic|Ctrl+Alt+F8}}, no crashing your primary X session (which may have open work on) in case a game conflicts with the graphics driver. The new X server will be akin a remote access login for the ALSA, so your user need to be part of the {{ic|audio}} group to be able to hear any sound.<br />
<br />
To start a second X server (using the free first person shooter game [http://www.xonotic.org/ Xonotic] as an example) you can simply do: <br />
$ xinit /usr/bin/xonotic-glx -- :1 vt$XDG_VTNR<br />
This can further be spiced up by using a separate X configuration file:<br />
$ xinit /usr/bin/xonotic-glx -- :1 -xf86config xorg-game.conf vt$XDG_VTNR<br />
A good reason to provide an alternative ''xorg.conf'' here may be that your primary configuration makes use of NVIDIA's Twinview which would render your 3D games like Xonotic in the middle of your multiscreen setup, spanned across all screens. This is undesirable, thus starting a second X with an alternative config where the second screen is disabled is advised. Please note, that the X config file location is relative to the /etc/X11 directory.<br />
<br />
A game starting script making use of Openbox for your home directory or {{ic|/usr/local/bin}} may look like this:<br />
<br />
{{hc|~/game.sh|<nowiki><br />
if [ $# -ge 1 ]; then<br />
game="$(which $1)"<br />
openbox="$(which openbox)"<br />
tmpgame="/tmp/tmpgame.sh"<br />
DISPLAY=:1.0<br />
echo -e "${openbox} &\n${game}" > ${tmpgame}<br />
echo "starting ${game}"<br />
xinit ${tmpgame} -- :1 -xf86config xorg-game.conf || exit 1<br />
else<br />
echo "not a valid argument"<br />
fi<br />
</nowiki>}}<br />
<br />
So after a {{ic|chmod +x}} you would be able to use this script like:<br />
<br />
$ ~/game.sh xonotic-glx<br />
<br />
{{Note|If you want to avoid loading configs from /etc/X11/xorg.conf.d, you should also use the -configdir option, pointing to an empty directory.}}<br />
<br />
=== Adjusting mouse detections ===<br />
<br />
For games that require exceptional amount of mouse skill, adjusting the [[mouse polling rate]] can help improve accuracy.<br />
<br />
=== Binaural Audio with OpenAL ===<br />
<br />
For games using [[Wikipedia:OpenAL|OpenAL]], if you use headphones you may get much better positional audio using OpenAL's [[Wikipedia:Head-related transfer function|HRTF]] filters. To enable, run the following command:<br />
<br />
echo "hrtf = true" >> ~/.alsoftrc<br />
<br />
Alternatively, install {{AUR|openal-hrtf}} from the AUR, and edit the options in /etc/openal/alsoftrc.conf<br />
<br />
For Source games, the ingame setting `dsp_slow_cpu` must be set to `1` to enable HRTF, otherwise the game will enable its own processing instead. You will also either need to set up Steam to use native runtime, or link its copy of openal.so to your own local copy. For completeness, also use the following options:<br />
<br />
dsp_slow_cpu 1 # Disable in-game spatialiazation<br />
snd_spatialize_roundrobin 1 # Disable spatialization 1.0*100% of sounds<br />
dsp_enhance_stereo 0 # Disable DSP sound effects. You may want to leave this on, if you find it does not interfere with your perception of the sound effects.<br />
snd_pitchquality 1 # Use high quality sounds<br />
<br />
=== Tuning PulseAudio ===<br />
<br />
If you are using [[PulseAudio]], you may wish to tweak some default settings to make sure it is running optimally.<br />
<br />
==== Enabling realtime priority and negative nice level ====<br />
<br />
Pulseaudio is built to be run with realtime priority, being an audio daemon. However, because of security risks of it locking up the system, it is scheduled as a regular thread by default. To adjust this, first make sure you are in the {{ic|audio}} group. Then, uncomment and edit the following lines in {{ic|/etc/pulse/daemon.conf}}:<br />
<br />
{{hc|1=/etc/pulse/daemon.conf|2=<br />
high-priority = yes<br />
nice-level = -11<br />
<br />
realtime-scheduling = yes<br />
realtime-priority = 5}}<br />
<br />
and restart pulseaudio.<br />
<br />
==== Using higher quality remixing for better sound ====<br />
<br />
PulseAudio on Arch uses speex-float-1 by default to remix channels, which is considered a 'medium-low' quality remixing. If your system can handle the extra load, you may benefit from setting it to one of the following instead:<br />
<br />
resample-method = speex-float-10<br />
<br />
==== Matching hardware buffers to Pulse's buffering ====<br />
<br />
Matching the buffers can reduce stuttering and increase performance marginally. See [http://forums.linuxmint.com/viewtopic.php?f=42&t=44862 here] for more details.<br />
<br />
=== Double check your CPU frequency scaling settings ===<br />
<br />
If your system is currently configured to properly insert its own cpu frequency scaling driver, the system sets the default governor to Ondemand. By default, this governor only adjusts the clock if the system is utilizing 95% of its CPU, and then only for a very short period of time. This saves power and reduces heat, but has a noticeable impact on performance. You can instead only have the system downclock when it is idle, by tuning the system governor. To do so, see [[Cpufrequtils#Tuning the ondemand governor]]. Recent Intel CPU (SandyBridge +) use frequency scaling driver `intel_pstate` that does not work with ondemand governor. You can switch from "powersave" (default) to "performance", but the difference is minimal.<br />
<br />
== Remote gaming ==<br />
<br />
[[Wikipedia:Cloud gaming|Cloud gaming]] has gained a lot of popularity in the last few years, because of low client-side hardware requirements. The only important thing is stable internet connection (over the ethernet cable or 5 GHz WiFi recommended) with a minimum speed of 5–10 Mbit/s (depending on the video quality and framerate).<br />
<br />
{{Note|Most of the services that work in browser usually mean to be only compatible with {{AUR|google-chrome}}.}}<br />
<br />
{| class="wikitable sortable" style="text-align: center;"<br />
! Service<br />
! class="unsortable" | Installer<br />
! In browser client<br />
! Use your own host<br />
! Offers host renting<br />
! Full desktop support<br />
! Controller support<br />
! class="unsortable" | Remarks<br />
|-<br />
| [https://dixper.gg/ Dixper] || {{-}} || {{Yes}} || {{Y|Windows-only}} || ? || ? || ? || {{-}}<br />
|-<br />
| [https://moonlight-stream.org/ Moonlight] || {{AUR|moonlight-qt}} || {{No}} || {{Y|Windows-only}} || {{No}} || {{Yes}} || {{Yes}} || This is only a client. Host machine needs GeForce experience installed.<br />
|-<br />
| [https://ui.parsecgaming.com/ Parsec] || {{AUR|parsec-bin}} || {{Yes}} (experimental) || {{Y|Windows-only}} || {{No}} || {{Yes}} || {{Yes}} || Cloud hosting [https://support.parsecgaming.com/hc/en-us/articles/360031038112-Cloud-Computer-Update no longer available]<br />
|-<br />
| [https://playkey.net/ Playkey] || {{AUR|playkey-linux}} || ? || ? || ? || ? || ? || {{-}}<br />
|-<br />
| style="white-space:nowrap" | [https://www.playstation.com/en-gb/explore/playstation-now/ps-now-on-pc/ PlayStation Now] || Runs under [[Wine]] or [[Steam]]'s proton || {{No}} || {{No}} || {{-}} || {{No}} || {{Yes}} || Play PS4, PS3 and PS2 games on PC. Alternatively, you can use [[Video game platform emulators|emulators]].<br />
|-<br />
| [https://rainway.com/ Rainway] || Coming in 2019 Q3 || {{Yes}} || {{Y|Windows-only}} || {{No}} || {{Yes}} || ? || {{-}}<br />
|-<br />
| [https://shadow.tech/ Shadow] || '''Stable:''' {{AUR|shadow-tech}} <br> '''Beta''': {{AUR|shadow-beta}} || {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} || Controller support is dependent on USB over IP, and currently AVC only as HEVC isn't supported<br />
|-<br />
| [[Steam#Steam_Remote_Play|Steam Remote Play]] || Part of {{pkg|steam}} || {{No}} || {{Yes}} || {{No}} || {{No}} || {{Yes}} || {{-}}<br />
|-<br />
| [https://vortex.gg/ Vortex] || {{-}} || {{Yes}} || {{No}} || {{-}} || {{No}} || ? || {{-}}<br />
|}<br />
<br />
== Improving performance ==<br />
<br />
See also main article: [[Improving performance]]. For Wine programs, see [[Wine#Performance]].<br />
<br />
=== Utilities ===<br />
<br />
==== Gamemode ====<br />
[https://wiki.archlinux.org/index.php/Gamemode Gamemode] is a Daemon/lib combo for Linux that allows games to request a set of optimisations be temporarily applied to the host OS. This can improve game performance. See separate Arch Wiki page for installation and configuation of [[gamemode]]<br />
<br />
=== ACO compiler ===<br />
<br />
{{Note|The method shown below '''only''' works on AMD GPUs running the '''[[AMDGPU]]''' drivers.}}<br />
See [[AMDGPU#ACO compiler]]<br />
<br />
=== Fsync patch ===<br />
<br />
See [[Steam#Fsync patch]].<br />
<br />
=== Improving frame rates and responsiveness with scheduling policies ===<br />
<br />
Most games can benefit if given the correct scheduling policies for the kernel to prioritize the task. These policies should ideally be set per-thread by the application itself.<br />
<br />
For programs which do not implement scheduling policies on their own, application known as {{Pkg|schedtool}}, and its associated daemon {{AUR|schedtoold}} can handle many of these tasks automatically.<br />
<br />
To edit what programs relieve what policies, simply edit {{ic|/etc/schedtoold.conf}} and add the program followed by the ''schedtool'' arguments desired.<br />
<br />
==== Policies ====<br />
<br />
{{ic|SCHED_ISO}} (only implemented in BFS/MuQSSPDS schedulers found in -pf and -ck [[kernel]]s) – will not only allow the process to use a maximum of 80 percent of the CPU, but will attempt to reduce latency and stuttering wherever possible. Most if not all games will benefit from this:<br />
<br />
bit.trip.runner -I<br />
<br />
{{ic|SCHED_FIFO}} provides an alternative, that can even work better. You should test to see if your applications run more smoothly with {{ic|SCHED_FIFO}}, in which case by all means use it instead. Be warned though, as {{ic|SCHED_FIFO}} runs the risk of starving the system! Use this in cases where -I is used below:<br />
<br />
bit.trip.runner -F -p 15<br />
<br />
==== Nice levels ====<br />
<br />
Secondly, the nice level sets which tasks are processed first, in ascending order. A nice level of -4 is recommended for most multimedia tasks, including games:<br />
<br />
bit.trip.runner -n -4<br />
<br />
==== Core affinity ====<br />
<br />
There is some confusion in development as to whether the driver should be multithreading, or the program. Allowing both the driver and program to simultaneously multithread can result in significant performance reductions, such as framerate loss and increased risk of crashes. Examples of this include a number of modern games, and any Wine program which is running with [[Wikipedia:OpenGL Shading Language|GLSL]] enabled. To select a single core and allow only the driver to handle this process, simply use the {{ic|-a 0x''#''}} flag, where ''#'' is the core number, e.g.:<br />
<br />
bit.trip.runner -a 0x1<br />
<br />
uses first core.<br />
<br />
Some CPUs are hyperthreaded and have only 2 or 4 cores but show up as 4 or 8, and are best accounted for:<br />
<br />
bit.trip.runner -a 0x5<br />
<br />
which use virtual cores 0101, or 1 and 3.<br />
<br />
==== General case ====<br />
<br />
For most games which require high framerates and low latency, usage of all of these flags seems to work best. Affinity should be checked per-program, however, as most native games can understand the correct usage.<br />
For a general case:<br />
<br />
bit.trip.runner -I -n -4<br />
Amnesia.bin64 -I -n -4<br />
hl2.exe -I -n -4 -a 0x1 #Wine with GLSL enabled<br />
<br />
etc.<br />
<br />
==== Optimus, and other helping programs ====<br />
<br />
As a general rule, any other process which the game requires to operate should be reniced to a level above that of the game itself. Strangely, Wine has a problem known as ''reverse scheduling'', it can often have benefits when the more important processes are set to a higher nice level. Wineserver also seems unconditionally to benefit from {{ic|SCHED_FIFO}}, since it rarely consumes the whole CPU and needs higher prioritization when possible.<br />
<br />
optirun -I -n -5<br />
wineserver -F -p 20 -n 19<br />
steam.exe -I -n -5<br />
<br />
== Peripherals ==<br />
=== Mouse ===<br />
You might want to set your [[mouse acceleration]] to control your mouse more accurately.<br />
<br />
If your mouse have more than 3 buttons, you might want to see [[Mouse buttons]].<br />
<br />
If you are using a gaming mouse (especially Logitech and Steelseries), you may want configure your mouse such as DPI, LED... using {{Pkg|piper}}. See [https://github.com/libratbag/libratbag/tree/master/data/devices this page] for a full list of supported devices.<br />
<br />
== See also ==<br />
* [https://www.reddit.com/r/linux_gaming/] - Forum on reddit.com with gaming on linux as its topic, subpages: [https://www.reddit.com/r/linux_gaming/wiki/index Wiki], [https://www.reddit.com/r/linux_gaming/wiki/faq FAQ].</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Gaming&diff=640221Gaming2020-11-01T09:02:05Z<p>Tobbebobbe: /* Utilities */ formatting</p>
<hr />
<div>[[Category:Gaming]]<br />
[[da:List of games]]<br />
[[es:List of games]]<br />
[[it:List of games]]<br />
[[ja:ゲーム]]<br />
[[lt:Games]]<br />
[[ru:Gaming]]<br />
[[zh-hans:List of games]]<br />
{{Related articles start}}<br />
{{Related|List of games}}<br />
{{Related|Video game platform emulators}}<br />
{{Related|Xorg}}<br />
{{Related articles end}}<br />
<br />
This page contains information about running games and related system configuration tips.<br />
<br />
== Game environments ==<br />
<br />
Different environments exist to play games in Linux:<br />
<br />
* Native – games written for Linux.<br />
* Web – games running in a web browser.<br />
** HTML5 games use canvas and WebGL technologies and work in all modern browsers.<br />
** [[Flash]]-based – you need to install the plugin to play.<br />
* [[Video game platform emulators]] – required for running software designed for other architectures and systems.<br />
* [[Wine]] – Windows compatibility layer, allows to run Windows applications on Unix-like operating systems.<br />
* [[Virtual machine]]s – can be used to install compatible operating systems (such as Windows). [[VirtualBox]] has good 3D support. As an extension of this, if you have compatible hardware you can consider VGA passthrough to a Windows KVM guest, keyword is [https://www.kernel.org/doc/html/latest/driver-api/vfio.html "virtual function I/O" (VFIO)], or [[PCI passthrough via OVMF]].<br />
<br />
== Getting games ==<br />
<br />
Just because games are available for Linux doesn't mean that they are native, they might be pre-packaged with Wine or DOSBox.<br />
<br />
For list of games packaged for Arch in [[official repositories]] / the [[AUR]] see [[List of games]].<br />
<br />
* {{App|Flathub|Central [[Flatpak]] repository, has small but growing game section.|https://flathub.org/apps/category/Game|{{Pkg|flatpak}}, {{Pkg|discover}}, {{Pkg|gnome-software}}}}<br />
* {{App|[[Wikipedia:GOG.com|GOG.com]]|DRM-free game store.|https://www.gog.com|{{AUR|lgogdownloader}}, {{AUR|wyvern}}}}<br />
* {{App|[[Wikipedia:itch.io|itch.io]]|Indie game store.|https://itch.io|{{AUR|itch}}}}<br />
* {{App|Legendary| A free and open-source replacement for the Epic Games Launcher. |https://github.com/derrod/legendary|{{AUR|legendary}}}}<br />
* {{App|[[Wikipedia:Lutris|Lutris]]|Open gaming platform for Linux. Gets games from GOG, Steam, Battle.net, Origin, Uplay and many other sources. Lutris utilizes various [https://lutris.net/runners runners] to launch the games with fully customizable configuration options. |https://lutris.net|{{Pkg|lutris}}}}<br />
* {{App|[[Steam]]|Digital distribution and communications platform developed by Valve.|https://store.steampowered.com|{{Pkg|steam}}}}<br />
* {{App|Athenaeum| A libre replacement to Steam. |https://gitlab.com/librebob/athenaeum|{{AUR|athenaeum-git}}}}<br />
* {{App|Play.it|Automates the build of native packages. Also supports [[Wine]], [[DOSBox]] and ScummVM games.|https://www.dotslashplay.it/|{{AUR|play.it}}, {{AUR|play.it-git}}}}<br />
<br />
== Running games ==<br />
<br />
Certain games or game types may need special configuration to run or to run as expected.<br />
For the most part, games will work right out of the box in Arch Linux with possibly better performance than on other distributions due to compile time optimizations. However, some special setups may require a bit of configuration or scripting to make games run as smoothly as desired.<br />
<br />
=== Multi-screen setups ===<br />
<br />
Running a multi-screen setup may lead to problems with fullscreen games. In such a case, [[#Starting games in a separate X server|running a second X server]] is one possible solution. Another solution may be found in the [[NVIDIA#Gaming using TwinView|NVIDIA article]] (may also apply to non-NVIDIA users).<br />
<br />
=== Keyboard grabbing ===<br />
<br />
Many games grab the keyboard, noticeably preventing you from switching windows (also known as alt-tabbing).<br />
<br />
Some SDL games (e.g. Guacamelee) let you disable grabbing by pressing {{ic|Ctrl-g}}.<br />
<br />
{{Note|SDL is known to sometimes not be able to grab the input system. In such a case, it may succeed in grabbing it after a few seconds of waiting.}}<br />
<br />
=== Starting games in a separate X server ===<br />
<br />
In some cases like those mentioned above, it may be necessary or desired to run a second X server. Running a second X server has multiple advantages such as better performance, the ability to "tab" out of your game by using {{ic|Ctrl+Alt+F7}}/{{ic|Ctrl+Alt+F8}}, no crashing your primary X session (which may have open work on) in case a game conflicts with the graphics driver. The new X server will be akin a remote access login for the ALSA, so your user need to be part of the {{ic|audio}} group to be able to hear any sound.<br />
<br />
To start a second X server (using the free first person shooter game [http://www.xonotic.org/ Xonotic] as an example) you can simply do: <br />
$ xinit /usr/bin/xonotic-glx -- :1 vt$XDG_VTNR<br />
This can further be spiced up by using a separate X configuration file:<br />
$ xinit /usr/bin/xonotic-glx -- :1 -xf86config xorg-game.conf vt$XDG_VTNR<br />
A good reason to provide an alternative ''xorg.conf'' here may be that your primary configuration makes use of NVIDIA's Twinview which would render your 3D games like Xonotic in the middle of your multiscreen setup, spanned across all screens. This is undesirable, thus starting a second X with an alternative config where the second screen is disabled is advised. Please note, that the X config file location is relative to the /etc/X11 directory.<br />
<br />
A game starting script making use of Openbox for your home directory or {{ic|/usr/local/bin}} may look like this:<br />
<br />
{{hc|~/game.sh|<nowiki><br />
if [ $# -ge 1 ]; then<br />
game="$(which $1)"<br />
openbox="$(which openbox)"<br />
tmpgame="/tmp/tmpgame.sh"<br />
DISPLAY=:1.0<br />
echo -e "${openbox} &\n${game}" > ${tmpgame}<br />
echo "starting ${game}"<br />
xinit ${tmpgame} -- :1 -xf86config xorg-game.conf || exit 1<br />
else<br />
echo "not a valid argument"<br />
fi<br />
</nowiki>}}<br />
<br />
So after a {{ic|chmod +x}} you would be able to use this script like:<br />
<br />
$ ~/game.sh xonotic-glx<br />
<br />
{{Note|If you want to avoid loading configs from /etc/X11/xorg.conf.d, you should also use the -configdir option, pointing to an empty directory.}}<br />
<br />
=== Adjusting mouse detections ===<br />
<br />
For games that require exceptional amount of mouse skill, adjusting the [[mouse polling rate]] can help improve accuracy.<br />
<br />
=== Binaural Audio with OpenAL ===<br />
<br />
For games using [[Wikipedia:OpenAL|OpenAL]], if you use headphones you may get much better positional audio using OpenAL's [[Wikipedia:Head-related transfer function|HRTF]] filters. To enable, run the following command:<br />
<br />
echo "hrtf = true" >> ~/.alsoftrc<br />
<br />
Alternatively, install {{AUR|openal-hrtf}} from the AUR, and edit the options in /etc/openal/alsoftrc.conf<br />
<br />
For Source games, the ingame setting `dsp_slow_cpu` must be set to `1` to enable HRTF, otherwise the game will enable its own processing instead. You will also either need to set up Steam to use native runtime, or link its copy of openal.so to your own local copy. For completeness, also use the following options:<br />
<br />
dsp_slow_cpu 1 # Disable in-game spatialiazation<br />
snd_spatialize_roundrobin 1 # Disable spatialization 1.0*100% of sounds<br />
dsp_enhance_stereo 0 # Disable DSP sound effects. You may want to leave this on, if you find it does not interfere with your perception of the sound effects.<br />
snd_pitchquality 1 # Use high quality sounds<br />
<br />
=== Tuning PulseAudio ===<br />
<br />
If you are using [[PulseAudio]], you may wish to tweak some default settings to make sure it is running optimally.<br />
<br />
==== Enabling realtime priority and negative nice level ====<br />
<br />
Pulseaudio is built to be run with realtime priority, being an audio daemon. However, because of security risks of it locking up the system, it is scheduled as a regular thread by default. To adjust this, first make sure you are in the {{ic|audio}} group. Then, uncomment and edit the following lines in {{ic|/etc/pulse/daemon.conf}}:<br />
<br />
{{hc|1=/etc/pulse/daemon.conf|2=<br />
high-priority = yes<br />
nice-level = -11<br />
<br />
realtime-scheduling = yes<br />
realtime-priority = 5}}<br />
<br />
and restart pulseaudio.<br />
<br />
==== Using higher quality remixing for better sound ====<br />
<br />
PulseAudio on Arch uses speex-float-1 by default to remix channels, which is considered a 'medium-low' quality remixing. If your system can handle the extra load, you may benefit from setting it to one of the following instead:<br />
<br />
resample-method = speex-float-10<br />
<br />
==== Matching hardware buffers to Pulse's buffering ====<br />
<br />
Matching the buffers can reduce stuttering and increase performance marginally. See [http://forums.linuxmint.com/viewtopic.php?f=42&t=44862 here] for more details.<br />
<br />
=== Double check your CPU frequency scaling settings ===<br />
<br />
If your system is currently configured to properly insert its own cpu frequency scaling driver, the system sets the default governor to Ondemand. By default, this governor only adjusts the clock if the system is utilizing 95% of its CPU, and then only for a very short period of time. This saves power and reduces heat, but has a noticeable impact on performance. You can instead only have the system downclock when it is idle, by tuning the system governor. To do so, see [[Cpufrequtils#Tuning the ondemand governor]]. Recent Intel CPU (SandyBridge +) use frequency scaling driver `intel_pstate` that does not work with ondemand governor. You can switch from "powersave" (default) to "performance", but the difference is minimal.<br />
<br />
== Remote gaming ==<br />
<br />
[[Wikipedia:Cloud gaming|Cloud gaming]] has gained a lot of popularity in the last few years, because of low client-side hardware requirements. The only important thing is stable internet connection (over the ethernet cable or 5 GHz WiFi recommended) with a minimum speed of 5–10 Mbit/s (depending on the video quality and framerate).<br />
<br />
{{Note|Most of the services that work in browser usually mean to be only compatible with {{AUR|google-chrome}}.}}<br />
<br />
{| class="wikitable sortable" style="text-align: center;"<br />
! Service<br />
! class="unsortable" | Installer<br />
! In browser client<br />
! Use your own host<br />
! Offers host renting<br />
! Full desktop support<br />
! Controller support<br />
! class="unsortable" | Remarks<br />
|-<br />
| [https://dixper.gg/ Dixper] || {{-}} || {{Yes}} || {{Y|Windows-only}} || ? || ? || ? || {{-}}<br />
|-<br />
| [https://moonlight-stream.org/ Moonlight] || {{AUR|moonlight-qt}} || {{No}} || {{Y|Windows-only}} || {{No}} || {{Yes}} || {{Yes}} || This is only a client. Host machine needs GeForce experience installed.<br />
|-<br />
| [https://ui.parsecgaming.com/ Parsec] || {{AUR|parsec-bin}} || {{Yes}} (experimental) || {{Y|Windows-only}} || {{No}} || {{Yes}} || {{Yes}} || Cloud hosting [https://support.parsecgaming.com/hc/en-us/articles/360031038112-Cloud-Computer-Update no longer available]<br />
|-<br />
| [https://playkey.net/ Playkey] || {{AUR|playkey-linux}} || ? || ? || ? || ? || ? || {{-}}<br />
|-<br />
| style="white-space:nowrap" | [https://www.playstation.com/en-gb/explore/playstation-now/ps-now-on-pc/ PlayStation Now] || Runs under [[Wine]] or [[Steam]]'s proton || {{No}} || {{No}} || {{-}} || {{No}} || {{Yes}} || Play PS4, PS3 and PS2 games on PC. Alternatively, you can use [[Video game platform emulators|emulators]].<br />
|-<br />
| [https://rainway.com/ Rainway] || Coming in 2019 Q3 || {{Yes}} || {{Y|Windows-only}} || {{No}} || {{Yes}} || ? || {{-}}<br />
|-<br />
| [https://shadow.tech/ Shadow] || '''Stable:''' {{AUR|shadow-tech}} <br> '''Beta''': {{AUR|shadow-beta}} || {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} || Controller support is dependent on USB over IP, and currently AVC only as HEVC isn't supported<br />
|-<br />
| [[Steam#Steam_Remote_Play|Steam Remote Play]] || Part of {{pkg|steam}} || {{No}} || {{Yes}} || {{No}} || {{No}} || {{Yes}} || {{-}}<br />
|-<br />
| [https://vortex.gg/ Vortex] || {{-}} || {{Yes}} || {{No}} || {{-}} || {{No}} || ? || {{-}}<br />
|}<br />
<br />
== Improving performance ==<br />
<br />
See also main article: [[Improving performance]]. For Wine programs, see [[Wine#Performance]].<br />
<br />
=== Utilities ===<br />
<br />
* <br />
[https://wiki.archlinux.org/index.php/Gamemode Gamemode] Daemon/lib combo for Linux that allows games to request a set of optimisations be temporarily applied to the host OS.|https://github.com/FeralInteractive/gamemode|{{Pkg|gamemode}}, {{Pkg|lib32-gamemode}}<br />
<br />
=== ACO compiler ===<br />
<br />
{{Note|The method shown below '''only''' works on AMD GPUs running the '''[[AMDGPU]]''' drivers.}}<br />
See [[AMDGPU#ACO compiler]]<br />
<br />
=== Fsync patch ===<br />
<br />
See [[Steam#Fsync patch]].<br />
<br />
=== Improving frame rates and responsiveness with scheduling policies ===<br />
<br />
Most games can benefit if given the correct scheduling policies for the kernel to prioritize the task. These policies should ideally be set per-thread by the application itself.<br />
<br />
For programs which do not implement scheduling policies on their own, application known as {{Pkg|schedtool}}, and its associated daemon {{AUR|schedtoold}} can handle many of these tasks automatically.<br />
<br />
To edit what programs relieve what policies, simply edit {{ic|/etc/schedtoold.conf}} and add the program followed by the ''schedtool'' arguments desired.<br />
<br />
==== Policies ====<br />
<br />
{{ic|SCHED_ISO}} (only implemented in BFS/MuQSSPDS schedulers found in -pf and -ck [[kernel]]s) – will not only allow the process to use a maximum of 80 percent of the CPU, but will attempt to reduce latency and stuttering wherever possible. Most if not all games will benefit from this:<br />
<br />
bit.trip.runner -I<br />
<br />
{{ic|SCHED_FIFO}} provides an alternative, that can even work better. You should test to see if your applications run more smoothly with {{ic|SCHED_FIFO}}, in which case by all means use it instead. Be warned though, as {{ic|SCHED_FIFO}} runs the risk of starving the system! Use this in cases where -I is used below:<br />
<br />
bit.trip.runner -F -p 15<br />
<br />
==== Nice levels ====<br />
<br />
Secondly, the nice level sets which tasks are processed first, in ascending order. A nice level of -4 is recommended for most multimedia tasks, including games:<br />
<br />
bit.trip.runner -n -4<br />
<br />
==== Core affinity ====<br />
<br />
There is some confusion in development as to whether the driver should be multithreading, or the program. Allowing both the driver and program to simultaneously multithread can result in significant performance reductions, such as framerate loss and increased risk of crashes. Examples of this include a number of modern games, and any Wine program which is running with [[Wikipedia:OpenGL Shading Language|GLSL]] enabled. To select a single core and allow only the driver to handle this process, simply use the {{ic|-a 0x''#''}} flag, where ''#'' is the core number, e.g.:<br />
<br />
bit.trip.runner -a 0x1<br />
<br />
uses first core.<br />
<br />
Some CPUs are hyperthreaded and have only 2 or 4 cores but show up as 4 or 8, and are best accounted for:<br />
<br />
bit.trip.runner -a 0x5<br />
<br />
which use virtual cores 0101, or 1 and 3.<br />
<br />
==== General case ====<br />
<br />
For most games which require high framerates and low latency, usage of all of these flags seems to work best. Affinity should be checked per-program, however, as most native games can understand the correct usage.<br />
For a general case:<br />
<br />
bit.trip.runner -I -n -4<br />
Amnesia.bin64 -I -n -4<br />
hl2.exe -I -n -4 -a 0x1 #Wine with GLSL enabled<br />
<br />
etc.<br />
<br />
==== Optimus, and other helping programs ====<br />
<br />
As a general rule, any other process which the game requires to operate should be reniced to a level above that of the game itself. Strangely, Wine has a problem known as ''reverse scheduling'', it can often have benefits when the more important processes are set to a higher nice level. Wineserver also seems unconditionally to benefit from {{ic|SCHED_FIFO}}, since it rarely consumes the whole CPU and needs higher prioritization when possible.<br />
<br />
optirun -I -n -5<br />
wineserver -F -p 20 -n 19<br />
steam.exe -I -n -5<br />
<br />
== Peripherals ==<br />
=== Mouse ===<br />
You might want to set your [[mouse acceleration]] to control your mouse more accurately.<br />
<br />
If your mouse have more than 3 buttons, you might want to see [[Mouse buttons]].<br />
<br />
If you are using a gaming mouse (especially Logitech and Steelseries), you may want configure your mouse such as DPI, LED... using {{Pkg|piper}}. See [https://github.com/libratbag/libratbag/tree/master/data/devices this page] for a full list of supported devices.<br />
<br />
== See also ==<br />
* [https://www.reddit.com/r/linux_gaming/] - Forum on reddit.com with gaming on linux as its topic, subpages: [https://www.reddit.com/r/linux_gaming/wiki/index Wiki], [https://www.reddit.com/r/linux_gaming/wiki/faq FAQ].</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Gaming&diff=640220Gaming2020-11-01T09:01:36Z<p>Tobbebobbe: /* Utilities */ linked game mode</p>
<hr />
<div>[[Category:Gaming]]<br />
[[da:List of games]]<br />
[[es:List of games]]<br />
[[it:List of games]]<br />
[[ja:ゲーム]]<br />
[[lt:Games]]<br />
[[ru:Gaming]]<br />
[[zh-hans:List of games]]<br />
{{Related articles start}}<br />
{{Related|List of games}}<br />
{{Related|Video game platform emulators}}<br />
{{Related|Xorg}}<br />
{{Related articles end}}<br />
<br />
This page contains information about running games and related system configuration tips.<br />
<br />
== Game environments ==<br />
<br />
Different environments exist to play games in Linux:<br />
<br />
* Native – games written for Linux.<br />
* Web – games running in a web browser.<br />
** HTML5 games use canvas and WebGL technologies and work in all modern browsers.<br />
** [[Flash]]-based – you need to install the plugin to play.<br />
* [[Video game platform emulators]] – required for running software designed for other architectures and systems.<br />
* [[Wine]] – Windows compatibility layer, allows to run Windows applications on Unix-like operating systems.<br />
* [[Virtual machine]]s – can be used to install compatible operating systems (such as Windows). [[VirtualBox]] has good 3D support. As an extension of this, if you have compatible hardware you can consider VGA passthrough to a Windows KVM guest, keyword is [https://www.kernel.org/doc/html/latest/driver-api/vfio.html "virtual function I/O" (VFIO)], or [[PCI passthrough via OVMF]].<br />
<br />
== Getting games ==<br />
<br />
Just because games are available for Linux doesn't mean that they are native, they might be pre-packaged with Wine or DOSBox.<br />
<br />
For list of games packaged for Arch in [[official repositories]] / the [[AUR]] see [[List of games]].<br />
<br />
* {{App|Flathub|Central [[Flatpak]] repository, has small but growing game section.|https://flathub.org/apps/category/Game|{{Pkg|flatpak}}, {{Pkg|discover}}, {{Pkg|gnome-software}}}}<br />
* {{App|[[Wikipedia:GOG.com|GOG.com]]|DRM-free game store.|https://www.gog.com|{{AUR|lgogdownloader}}, {{AUR|wyvern}}}}<br />
* {{App|[[Wikipedia:itch.io|itch.io]]|Indie game store.|https://itch.io|{{AUR|itch}}}}<br />
* {{App|Legendary| A free and open-source replacement for the Epic Games Launcher. |https://github.com/derrod/legendary|{{AUR|legendary}}}}<br />
* {{App|[[Wikipedia:Lutris|Lutris]]|Open gaming platform for Linux. Gets games from GOG, Steam, Battle.net, Origin, Uplay and many other sources. Lutris utilizes various [https://lutris.net/runners runners] to launch the games with fully customizable configuration options. |https://lutris.net|{{Pkg|lutris}}}}<br />
* {{App|[[Steam]]|Digital distribution and communications platform developed by Valve.|https://store.steampowered.com|{{Pkg|steam}}}}<br />
* {{App|Athenaeum| A libre replacement to Steam. |https://gitlab.com/librebob/athenaeum|{{AUR|athenaeum-git}}}}<br />
* {{App|Play.it|Automates the build of native packages. Also supports [[Wine]], [[DOSBox]] and ScummVM games.|https://www.dotslashplay.it/|{{AUR|play.it}}, {{AUR|play.it-git}}}}<br />
<br />
== Running games ==<br />
<br />
Certain games or game types may need special configuration to run or to run as expected.<br />
For the most part, games will work right out of the box in Arch Linux with possibly better performance than on other distributions due to compile time optimizations. However, some special setups may require a bit of configuration or scripting to make games run as smoothly as desired.<br />
<br />
=== Multi-screen setups ===<br />
<br />
Running a multi-screen setup may lead to problems with fullscreen games. In such a case, [[#Starting games in a separate X server|running a second X server]] is one possible solution. Another solution may be found in the [[NVIDIA#Gaming using TwinView|NVIDIA article]] (may also apply to non-NVIDIA users).<br />
<br />
=== Keyboard grabbing ===<br />
<br />
Many games grab the keyboard, noticeably preventing you from switching windows (also known as alt-tabbing).<br />
<br />
Some SDL games (e.g. Guacamelee) let you disable grabbing by pressing {{ic|Ctrl-g}}.<br />
<br />
{{Note|SDL is known to sometimes not be able to grab the input system. In such a case, it may succeed in grabbing it after a few seconds of waiting.}}<br />
<br />
=== Starting games in a separate X server ===<br />
<br />
In some cases like those mentioned above, it may be necessary or desired to run a second X server. Running a second X server has multiple advantages such as better performance, the ability to "tab" out of your game by using {{ic|Ctrl+Alt+F7}}/{{ic|Ctrl+Alt+F8}}, no crashing your primary X session (which may have open work on) in case a game conflicts with the graphics driver. The new X server will be akin a remote access login for the ALSA, so your user need to be part of the {{ic|audio}} group to be able to hear any sound.<br />
<br />
To start a second X server (using the free first person shooter game [http://www.xonotic.org/ Xonotic] as an example) you can simply do: <br />
$ xinit /usr/bin/xonotic-glx -- :1 vt$XDG_VTNR<br />
This can further be spiced up by using a separate X configuration file:<br />
$ xinit /usr/bin/xonotic-glx -- :1 -xf86config xorg-game.conf vt$XDG_VTNR<br />
A good reason to provide an alternative ''xorg.conf'' here may be that your primary configuration makes use of NVIDIA's Twinview which would render your 3D games like Xonotic in the middle of your multiscreen setup, spanned across all screens. This is undesirable, thus starting a second X with an alternative config where the second screen is disabled is advised. Please note, that the X config file location is relative to the /etc/X11 directory.<br />
<br />
A game starting script making use of Openbox for your home directory or {{ic|/usr/local/bin}} may look like this:<br />
<br />
{{hc|~/game.sh|<nowiki><br />
if [ $# -ge 1 ]; then<br />
game="$(which $1)"<br />
openbox="$(which openbox)"<br />
tmpgame="/tmp/tmpgame.sh"<br />
DISPLAY=:1.0<br />
echo -e "${openbox} &\n${game}" > ${tmpgame}<br />
echo "starting ${game}"<br />
xinit ${tmpgame} -- :1 -xf86config xorg-game.conf || exit 1<br />
else<br />
echo "not a valid argument"<br />
fi<br />
</nowiki>}}<br />
<br />
So after a {{ic|chmod +x}} you would be able to use this script like:<br />
<br />
$ ~/game.sh xonotic-glx<br />
<br />
{{Note|If you want to avoid loading configs from /etc/X11/xorg.conf.d, you should also use the -configdir option, pointing to an empty directory.}}<br />
<br />
=== Adjusting mouse detections ===<br />
<br />
For games that require exceptional amount of mouse skill, adjusting the [[mouse polling rate]] can help improve accuracy.<br />
<br />
=== Binaural Audio with OpenAL ===<br />
<br />
For games using [[Wikipedia:OpenAL|OpenAL]], if you use headphones you may get much better positional audio using OpenAL's [[Wikipedia:Head-related transfer function|HRTF]] filters. To enable, run the following command:<br />
<br />
echo "hrtf = true" >> ~/.alsoftrc<br />
<br />
Alternatively, install {{AUR|openal-hrtf}} from the AUR, and edit the options in /etc/openal/alsoftrc.conf<br />
<br />
For Source games, the ingame setting `dsp_slow_cpu` must be set to `1` to enable HRTF, otherwise the game will enable its own processing instead. You will also either need to set up Steam to use native runtime, or link its copy of openal.so to your own local copy. For completeness, also use the following options:<br />
<br />
dsp_slow_cpu 1 # Disable in-game spatialiazation<br />
snd_spatialize_roundrobin 1 # Disable spatialization 1.0*100% of sounds<br />
dsp_enhance_stereo 0 # Disable DSP sound effects. You may want to leave this on, if you find it does not interfere with your perception of the sound effects.<br />
snd_pitchquality 1 # Use high quality sounds<br />
<br />
=== Tuning PulseAudio ===<br />
<br />
If you are using [[PulseAudio]], you may wish to tweak some default settings to make sure it is running optimally.<br />
<br />
==== Enabling realtime priority and negative nice level ====<br />
<br />
Pulseaudio is built to be run with realtime priority, being an audio daemon. However, because of security risks of it locking up the system, it is scheduled as a regular thread by default. To adjust this, first make sure you are in the {{ic|audio}} group. Then, uncomment and edit the following lines in {{ic|/etc/pulse/daemon.conf}}:<br />
<br />
{{hc|1=/etc/pulse/daemon.conf|2=<br />
high-priority = yes<br />
nice-level = -11<br />
<br />
realtime-scheduling = yes<br />
realtime-priority = 5}}<br />
<br />
and restart pulseaudio.<br />
<br />
==== Using higher quality remixing for better sound ====<br />
<br />
PulseAudio on Arch uses speex-float-1 by default to remix channels, which is considered a 'medium-low' quality remixing. If your system can handle the extra load, you may benefit from setting it to one of the following instead:<br />
<br />
resample-method = speex-float-10<br />
<br />
==== Matching hardware buffers to Pulse's buffering ====<br />
<br />
Matching the buffers can reduce stuttering and increase performance marginally. See [http://forums.linuxmint.com/viewtopic.php?f=42&t=44862 here] for more details.<br />
<br />
=== Double check your CPU frequency scaling settings ===<br />
<br />
If your system is currently configured to properly insert its own cpu frequency scaling driver, the system sets the default governor to Ondemand. By default, this governor only adjusts the clock if the system is utilizing 95% of its CPU, and then only for a very short period of time. This saves power and reduces heat, but has a noticeable impact on performance. You can instead only have the system downclock when it is idle, by tuning the system governor. To do so, see [[Cpufrequtils#Tuning the ondemand governor]]. Recent Intel CPU (SandyBridge +) use frequency scaling driver `intel_pstate` that does not work with ondemand governor. You can switch from "powersave" (default) to "performance", but the difference is minimal.<br />
<br />
== Remote gaming ==<br />
<br />
[[Wikipedia:Cloud gaming|Cloud gaming]] has gained a lot of popularity in the last few years, because of low client-side hardware requirements. The only important thing is stable internet connection (over the ethernet cable or 5 GHz WiFi recommended) with a minimum speed of 5–10 Mbit/s (depending on the video quality and framerate).<br />
<br />
{{Note|Most of the services that work in browser usually mean to be only compatible with {{AUR|google-chrome}}.}}<br />
<br />
{| class="wikitable sortable" style="text-align: center;"<br />
! Service<br />
! class="unsortable" | Installer<br />
! In browser client<br />
! Use your own host<br />
! Offers host renting<br />
! Full desktop support<br />
! Controller support<br />
! class="unsortable" | Remarks<br />
|-<br />
| [https://dixper.gg/ Dixper] || {{-}} || {{Yes}} || {{Y|Windows-only}} || ? || ? || ? || {{-}}<br />
|-<br />
| [https://moonlight-stream.org/ Moonlight] || {{AUR|moonlight-qt}} || {{No}} || {{Y|Windows-only}} || {{No}} || {{Yes}} || {{Yes}} || This is only a client. Host machine needs GeForce experience installed.<br />
|-<br />
| [https://ui.parsecgaming.com/ Parsec] || {{AUR|parsec-bin}} || {{Yes}} (experimental) || {{Y|Windows-only}} || {{No}} || {{Yes}} || {{Yes}} || Cloud hosting [https://support.parsecgaming.com/hc/en-us/articles/360031038112-Cloud-Computer-Update no longer available]<br />
|-<br />
| [https://playkey.net/ Playkey] || {{AUR|playkey-linux}} || ? || ? || ? || ? || ? || {{-}}<br />
|-<br />
| style="white-space:nowrap" | [https://www.playstation.com/en-gb/explore/playstation-now/ps-now-on-pc/ PlayStation Now] || Runs under [[Wine]] or [[Steam]]'s proton || {{No}} || {{No}} || {{-}} || {{No}} || {{Yes}} || Play PS4, PS3 and PS2 games on PC. Alternatively, you can use [[Video game platform emulators|emulators]].<br />
|-<br />
| [https://rainway.com/ Rainway] || Coming in 2019 Q3 || {{Yes}} || {{Y|Windows-only}} || {{No}} || {{Yes}} || ? || {{-}}<br />
|-<br />
| [https://shadow.tech/ Shadow] || '''Stable:''' {{AUR|shadow-tech}} <br> '''Beta''': {{AUR|shadow-beta}} || {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} || Controller support is dependent on USB over IP, and currently AVC only as HEVC isn't supported<br />
|-<br />
| [[Steam#Steam_Remote_Play|Steam Remote Play]] || Part of {{pkg|steam}} || {{No}} || {{Yes}} || {{No}} || {{No}} || {{Yes}} || {{-}}<br />
|-<br />
| [https://vortex.gg/ Vortex] || {{-}} || {{Yes}} || {{No}} || {{-}} || {{No}} || ? || {{-}}<br />
|}<br />
<br />
== Improving performance ==<br />
<br />
See also main article: [[Improving performance]]. For Wine programs, see [[Wine#Performance]].<br />
<br />
=== Utilities ===<br />
<br />
* <br />
[https://wiki.archlinux.org/index.php/Gamemode Gamemode]|Daemon/lib combo for Linux that allows games to request a set of optimisations be temporarily applied to the host OS.|https://github.com/FeralInteractive/gamemode|{{Pkg|gamemode}}, {{Pkg|lib32-gamemode}}<br />
<br />
=== ACO compiler ===<br />
<br />
{{Note|The method shown below '''only''' works on AMD GPUs running the '''[[AMDGPU]]''' drivers.}}<br />
See [[AMDGPU#ACO compiler]]<br />
<br />
=== Fsync patch ===<br />
<br />
See [[Steam#Fsync patch]].<br />
<br />
=== Improving frame rates and responsiveness with scheduling policies ===<br />
<br />
Most games can benefit if given the correct scheduling policies for the kernel to prioritize the task. These policies should ideally be set per-thread by the application itself.<br />
<br />
For programs which do not implement scheduling policies on their own, application known as {{Pkg|schedtool}}, and its associated daemon {{AUR|schedtoold}} can handle many of these tasks automatically.<br />
<br />
To edit what programs relieve what policies, simply edit {{ic|/etc/schedtoold.conf}} and add the program followed by the ''schedtool'' arguments desired.<br />
<br />
==== Policies ====<br />
<br />
{{ic|SCHED_ISO}} (only implemented in BFS/MuQSSPDS schedulers found in -pf and -ck [[kernel]]s) – will not only allow the process to use a maximum of 80 percent of the CPU, but will attempt to reduce latency and stuttering wherever possible. Most if not all games will benefit from this:<br />
<br />
bit.trip.runner -I<br />
<br />
{{ic|SCHED_FIFO}} provides an alternative, that can even work better. You should test to see if your applications run more smoothly with {{ic|SCHED_FIFO}}, in which case by all means use it instead. Be warned though, as {{ic|SCHED_FIFO}} runs the risk of starving the system! Use this in cases where -I is used below:<br />
<br />
bit.trip.runner -F -p 15<br />
<br />
==== Nice levels ====<br />
<br />
Secondly, the nice level sets which tasks are processed first, in ascending order. A nice level of -4 is recommended for most multimedia tasks, including games:<br />
<br />
bit.trip.runner -n -4<br />
<br />
==== Core affinity ====<br />
<br />
There is some confusion in development as to whether the driver should be multithreading, or the program. Allowing both the driver and program to simultaneously multithread can result in significant performance reductions, such as framerate loss and increased risk of crashes. Examples of this include a number of modern games, and any Wine program which is running with [[Wikipedia:OpenGL Shading Language|GLSL]] enabled. To select a single core and allow only the driver to handle this process, simply use the {{ic|-a 0x''#''}} flag, where ''#'' is the core number, e.g.:<br />
<br />
bit.trip.runner -a 0x1<br />
<br />
uses first core.<br />
<br />
Some CPUs are hyperthreaded and have only 2 or 4 cores but show up as 4 or 8, and are best accounted for:<br />
<br />
bit.trip.runner -a 0x5<br />
<br />
which use virtual cores 0101, or 1 and 3.<br />
<br />
==== General case ====<br />
<br />
For most games which require high framerates and low latency, usage of all of these flags seems to work best. Affinity should be checked per-program, however, as most native games can understand the correct usage.<br />
For a general case:<br />
<br />
bit.trip.runner -I -n -4<br />
Amnesia.bin64 -I -n -4<br />
hl2.exe -I -n -4 -a 0x1 #Wine with GLSL enabled<br />
<br />
etc.<br />
<br />
==== Optimus, and other helping programs ====<br />
<br />
As a general rule, any other process which the game requires to operate should be reniced to a level above that of the game itself. Strangely, Wine has a problem known as ''reverse scheduling'', it can often have benefits when the more important processes are set to a higher nice level. Wineserver also seems unconditionally to benefit from {{ic|SCHED_FIFO}}, since it rarely consumes the whole CPU and needs higher prioritization when possible.<br />
<br />
optirun -I -n -5<br />
wineserver -F -p 20 -n 19<br />
steam.exe -I -n -5<br />
<br />
== Peripherals ==<br />
=== Mouse ===<br />
You might want to set your [[mouse acceleration]] to control your mouse more accurately.<br />
<br />
If your mouse have more than 3 buttons, you might want to see [[Mouse buttons]].<br />
<br />
If you are using a gaming mouse (especially Logitech and Steelseries), you may want configure your mouse such as DPI, LED... using {{Pkg|piper}}. See [https://github.com/libratbag/libratbag/tree/master/data/devices this page] for a full list of supported devices.<br />
<br />
== See also ==<br />
* [https://www.reddit.com/r/linux_gaming/] - Forum on reddit.com with gaming on linux as its topic, subpages: [https://www.reddit.com/r/linux_gaming/wiki/index Wiki], [https://www.reddit.com/r/linux_gaming/wiki/faq FAQ].</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Gaming&diff=640219Gaming2020-11-01T08:59:59Z<p>Tobbebobbe: /* Improving performance */ linked to gamemode page</p>
<hr />
<div>[[Category:Gaming]]<br />
[[da:List of games]]<br />
[[es:List of games]]<br />
[[it:List of games]]<br />
[[ja:ゲーム]]<br />
[[lt:Games]]<br />
[[ru:Gaming]]<br />
[[zh-hans:List of games]]<br />
{{Related articles start}}<br />
{{Related|List of games}}<br />
{{Related|Video game platform emulators}}<br />
{{Related|Xorg}}<br />
{{Related articles end}}<br />
<br />
This page contains information about running games and related system configuration tips.<br />
<br />
== Game environments ==<br />
<br />
Different environments exist to play games in Linux:<br />
<br />
* Native – games written for Linux.<br />
* Web – games running in a web browser.<br />
** HTML5 games use canvas and WebGL technologies and work in all modern browsers.<br />
** [[Flash]]-based – you need to install the plugin to play.<br />
* [[Video game platform emulators]] – required for running software designed for other architectures and systems.<br />
* [[Wine]] – Windows compatibility layer, allows to run Windows applications on Unix-like operating systems.<br />
* [[Virtual machine]]s – can be used to install compatible operating systems (such as Windows). [[VirtualBox]] has good 3D support. As an extension of this, if you have compatible hardware you can consider VGA passthrough to a Windows KVM guest, keyword is [https://www.kernel.org/doc/html/latest/driver-api/vfio.html "virtual function I/O" (VFIO)], or [[PCI passthrough via OVMF]].<br />
<br />
== Getting games ==<br />
<br />
Just because games are available for Linux doesn't mean that they are native, they might be pre-packaged with Wine or DOSBox.<br />
<br />
For list of games packaged for Arch in [[official repositories]] / the [[AUR]] see [[List of games]].<br />
<br />
* {{App|Flathub|Central [[Flatpak]] repository, has small but growing game section.|https://flathub.org/apps/category/Game|{{Pkg|flatpak}}, {{Pkg|discover}}, {{Pkg|gnome-software}}}}<br />
* {{App|[[Wikipedia:GOG.com|GOG.com]]|DRM-free game store.|https://www.gog.com|{{AUR|lgogdownloader}}, {{AUR|wyvern}}}}<br />
* {{App|[[Wikipedia:itch.io|itch.io]]|Indie game store.|https://itch.io|{{AUR|itch}}}}<br />
* {{App|Legendary| A free and open-source replacement for the Epic Games Launcher. |https://github.com/derrod/legendary|{{AUR|legendary}}}}<br />
* {{App|[[Wikipedia:Lutris|Lutris]]|Open gaming platform for Linux. Gets games from GOG, Steam, Battle.net, Origin, Uplay and many other sources. Lutris utilizes various [https://lutris.net/runners runners] to launch the games with fully customizable configuration options. |https://lutris.net|{{Pkg|lutris}}}}<br />
* {{App|[[Steam]]|Digital distribution and communications platform developed by Valve.|https://store.steampowered.com|{{Pkg|steam}}}}<br />
* {{App|Athenaeum| A libre replacement to Steam. |https://gitlab.com/librebob/athenaeum|{{AUR|athenaeum-git}}}}<br />
* {{App|Play.it|Automates the build of native packages. Also supports [[Wine]], [[DOSBox]] and ScummVM games.|https://www.dotslashplay.it/|{{AUR|play.it}}, {{AUR|play.it-git}}}}<br />
<br />
== Running games ==<br />
<br />
Certain games or game types may need special configuration to run or to run as expected.<br />
For the most part, games will work right out of the box in Arch Linux with possibly better performance than on other distributions due to compile time optimizations. However, some special setups may require a bit of configuration or scripting to make games run as smoothly as desired.<br />
<br />
=== Multi-screen setups ===<br />
<br />
Running a multi-screen setup may lead to problems with fullscreen games. In such a case, [[#Starting games in a separate X server|running a second X server]] is one possible solution. Another solution may be found in the [[NVIDIA#Gaming using TwinView|NVIDIA article]] (may also apply to non-NVIDIA users).<br />
<br />
=== Keyboard grabbing ===<br />
<br />
Many games grab the keyboard, noticeably preventing you from switching windows (also known as alt-tabbing).<br />
<br />
Some SDL games (e.g. Guacamelee) let you disable grabbing by pressing {{ic|Ctrl-g}}.<br />
<br />
{{Note|SDL is known to sometimes not be able to grab the input system. In such a case, it may succeed in grabbing it after a few seconds of waiting.}}<br />
<br />
=== Starting games in a separate X server ===<br />
<br />
In some cases like those mentioned above, it may be necessary or desired to run a second X server. Running a second X server has multiple advantages such as better performance, the ability to "tab" out of your game by using {{ic|Ctrl+Alt+F7}}/{{ic|Ctrl+Alt+F8}}, no crashing your primary X session (which may have open work on) in case a game conflicts with the graphics driver. The new X server will be akin a remote access login for the ALSA, so your user need to be part of the {{ic|audio}} group to be able to hear any sound.<br />
<br />
To start a second X server (using the free first person shooter game [http://www.xonotic.org/ Xonotic] as an example) you can simply do: <br />
$ xinit /usr/bin/xonotic-glx -- :1 vt$XDG_VTNR<br />
This can further be spiced up by using a separate X configuration file:<br />
$ xinit /usr/bin/xonotic-glx -- :1 -xf86config xorg-game.conf vt$XDG_VTNR<br />
A good reason to provide an alternative ''xorg.conf'' here may be that your primary configuration makes use of NVIDIA's Twinview which would render your 3D games like Xonotic in the middle of your multiscreen setup, spanned across all screens. This is undesirable, thus starting a second X with an alternative config where the second screen is disabled is advised. Please note, that the X config file location is relative to the /etc/X11 directory.<br />
<br />
A game starting script making use of Openbox for your home directory or {{ic|/usr/local/bin}} may look like this:<br />
<br />
{{hc|~/game.sh|<nowiki><br />
if [ $# -ge 1 ]; then<br />
game="$(which $1)"<br />
openbox="$(which openbox)"<br />
tmpgame="/tmp/tmpgame.sh"<br />
DISPLAY=:1.0<br />
echo -e "${openbox} &\n${game}" > ${tmpgame}<br />
echo "starting ${game}"<br />
xinit ${tmpgame} -- :1 -xf86config xorg-game.conf || exit 1<br />
else<br />
echo "not a valid argument"<br />
fi<br />
</nowiki>}}<br />
<br />
So after a {{ic|chmod +x}} you would be able to use this script like:<br />
<br />
$ ~/game.sh xonotic-glx<br />
<br />
{{Note|If you want to avoid loading configs from /etc/X11/xorg.conf.d, you should also use the -configdir option, pointing to an empty directory.}}<br />
<br />
=== Adjusting mouse detections ===<br />
<br />
For games that require exceptional amount of mouse skill, adjusting the [[mouse polling rate]] can help improve accuracy.<br />
<br />
=== Binaural Audio with OpenAL ===<br />
<br />
For games using [[Wikipedia:OpenAL|OpenAL]], if you use headphones you may get much better positional audio using OpenAL's [[Wikipedia:Head-related transfer function|HRTF]] filters. To enable, run the following command:<br />
<br />
echo "hrtf = true" >> ~/.alsoftrc<br />
<br />
Alternatively, install {{AUR|openal-hrtf}} from the AUR, and edit the options in /etc/openal/alsoftrc.conf<br />
<br />
For Source games, the ingame setting `dsp_slow_cpu` must be set to `1` to enable HRTF, otherwise the game will enable its own processing instead. You will also either need to set up Steam to use native runtime, or link its copy of openal.so to your own local copy. For completeness, also use the following options:<br />
<br />
dsp_slow_cpu 1 # Disable in-game spatialiazation<br />
snd_spatialize_roundrobin 1 # Disable spatialization 1.0*100% of sounds<br />
dsp_enhance_stereo 0 # Disable DSP sound effects. You may want to leave this on, if you find it does not interfere with your perception of the sound effects.<br />
snd_pitchquality 1 # Use high quality sounds<br />
<br />
=== Tuning PulseAudio ===<br />
<br />
If you are using [[PulseAudio]], you may wish to tweak some default settings to make sure it is running optimally.<br />
<br />
==== Enabling realtime priority and negative nice level ====<br />
<br />
Pulseaudio is built to be run with realtime priority, being an audio daemon. However, because of security risks of it locking up the system, it is scheduled as a regular thread by default. To adjust this, first make sure you are in the {{ic|audio}} group. Then, uncomment and edit the following lines in {{ic|/etc/pulse/daemon.conf}}:<br />
<br />
{{hc|1=/etc/pulse/daemon.conf|2=<br />
high-priority = yes<br />
nice-level = -11<br />
<br />
realtime-scheduling = yes<br />
realtime-priority = 5}}<br />
<br />
and restart pulseaudio.<br />
<br />
==== Using higher quality remixing for better sound ====<br />
<br />
PulseAudio on Arch uses speex-float-1 by default to remix channels, which is considered a 'medium-low' quality remixing. If your system can handle the extra load, you may benefit from setting it to one of the following instead:<br />
<br />
resample-method = speex-float-10<br />
<br />
==== Matching hardware buffers to Pulse's buffering ====<br />
<br />
Matching the buffers can reduce stuttering and increase performance marginally. See [http://forums.linuxmint.com/viewtopic.php?f=42&t=44862 here] for more details.<br />
<br />
=== Double check your CPU frequency scaling settings ===<br />
<br />
If your system is currently configured to properly insert its own cpu frequency scaling driver, the system sets the default governor to Ondemand. By default, this governor only adjusts the clock if the system is utilizing 95% of its CPU, and then only for a very short period of time. This saves power and reduces heat, but has a noticeable impact on performance. You can instead only have the system downclock when it is idle, by tuning the system governor. To do so, see [[Cpufrequtils#Tuning the ondemand governor]]. Recent Intel CPU (SandyBridge +) use frequency scaling driver `intel_pstate` that does not work with ondemand governor. You can switch from "powersave" (default) to "performance", but the difference is minimal.<br />
<br />
== Remote gaming ==<br />
<br />
[[Wikipedia:Cloud gaming|Cloud gaming]] has gained a lot of popularity in the last few years, because of low client-side hardware requirements. The only important thing is stable internet connection (over the ethernet cable or 5 GHz WiFi recommended) with a minimum speed of 5–10 Mbit/s (depending on the video quality and framerate).<br />
<br />
{{Note|Most of the services that work in browser usually mean to be only compatible with {{AUR|google-chrome}}.}}<br />
<br />
{| class="wikitable sortable" style="text-align: center;"<br />
! Service<br />
! class="unsortable" | Installer<br />
! In browser client<br />
! Use your own host<br />
! Offers host renting<br />
! Full desktop support<br />
! Controller support<br />
! class="unsortable" | Remarks<br />
|-<br />
| [https://dixper.gg/ Dixper] || {{-}} || {{Yes}} || {{Y|Windows-only}} || ? || ? || ? || {{-}}<br />
|-<br />
| [https://moonlight-stream.org/ Moonlight] || {{AUR|moonlight-qt}} || {{No}} || {{Y|Windows-only}} || {{No}} || {{Yes}} || {{Yes}} || This is only a client. Host machine needs GeForce experience installed.<br />
|-<br />
| [https://ui.parsecgaming.com/ Parsec] || {{AUR|parsec-bin}} || {{Yes}} (experimental) || {{Y|Windows-only}} || {{No}} || {{Yes}} || {{Yes}} || Cloud hosting [https://support.parsecgaming.com/hc/en-us/articles/360031038112-Cloud-Computer-Update no longer available]<br />
|-<br />
| [https://playkey.net/ Playkey] || {{AUR|playkey-linux}} || ? || ? || ? || ? || ? || {{-}}<br />
|-<br />
| style="white-space:nowrap" | [https://www.playstation.com/en-gb/explore/playstation-now/ps-now-on-pc/ PlayStation Now] || Runs under [[Wine]] or [[Steam]]'s proton || {{No}} || {{No}} || {{-}} || {{No}} || {{Yes}} || Play PS4, PS3 and PS2 games on PC. Alternatively, you can use [[Video game platform emulators|emulators]].<br />
|-<br />
| [https://rainway.com/ Rainway] || Coming in 2019 Q3 || {{Yes}} || {{Y|Windows-only}} || {{No}} || {{Yes}} || ? || {{-}}<br />
|-<br />
| [https://shadow.tech/ Shadow] || '''Stable:''' {{AUR|shadow-tech}} <br> '''Beta''': {{AUR|shadow-beta}} || {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} || Controller support is dependent on USB over IP, and currently AVC only as HEVC isn't supported<br />
|-<br />
| [[Steam#Steam_Remote_Play|Steam Remote Play]] || Part of {{pkg|steam}} || {{No}} || {{Yes}} || {{No}} || {{No}} || {{Yes}} || {{-}}<br />
|-<br />
| [https://vortex.gg/ Vortex] || {{-}} || {{Yes}} || {{No}} || {{-}} || {{No}} || ? || {{-}}<br />
|}<br />
<br />
== Improving performance ==<br />
<br />
See also main article: [[Improving performance]]. For Wine programs, see [[Wine#Performance]].<br />
<br />
=== Utilities ===<br />
<br />
* {{App|[[GameMode]]|Daemon/lib combo for Linux that allows games to request a set of optimisations be temporarily applied to the host OS.|https://github.com/FeralInteractive/gamemode|{{Pkg|gamemode}}, {{Pkg|lib32-gamemode}}}}<br />
<br />
=== ACO compiler ===<br />
<br />
{{Note|The method shown below '''only''' works on AMD GPUs running the '''[[AMDGPU]]''' drivers.}}<br />
See [[AMDGPU#ACO compiler]]<br />
<br />
=== Fsync patch ===<br />
<br />
See [[Steam#Fsync patch]].<br />
<br />
=== Improving frame rates and responsiveness with scheduling policies ===<br />
<br />
Most games can benefit if given the correct scheduling policies for the kernel to prioritize the task. These policies should ideally be set per-thread by the application itself.<br />
<br />
For programs which do not implement scheduling policies on their own, application known as {{Pkg|schedtool}}, and its associated daemon {{AUR|schedtoold}} can handle many of these tasks automatically.<br />
<br />
To edit what programs relieve what policies, simply edit {{ic|/etc/schedtoold.conf}} and add the program followed by the ''schedtool'' arguments desired.<br />
<br />
==== Policies ====<br />
<br />
{{ic|SCHED_ISO}} (only implemented in BFS/MuQSSPDS schedulers found in -pf and -ck [[kernel]]s) – will not only allow the process to use a maximum of 80 percent of the CPU, but will attempt to reduce latency and stuttering wherever possible. Most if not all games will benefit from this:<br />
<br />
bit.trip.runner -I<br />
<br />
{{ic|SCHED_FIFO}} provides an alternative, that can even work better. You should test to see if your applications run more smoothly with {{ic|SCHED_FIFO}}, in which case by all means use it instead. Be warned though, as {{ic|SCHED_FIFO}} runs the risk of starving the system! Use this in cases where -I is used below:<br />
<br />
bit.trip.runner -F -p 15<br />
<br />
==== Nice levels ====<br />
<br />
Secondly, the nice level sets which tasks are processed first, in ascending order. A nice level of -4 is recommended for most multimedia tasks, including games:<br />
<br />
bit.trip.runner -n -4<br />
<br />
==== Core affinity ====<br />
<br />
There is some confusion in development as to whether the driver should be multithreading, or the program. Allowing both the driver and program to simultaneously multithread can result in significant performance reductions, such as framerate loss and increased risk of crashes. Examples of this include a number of modern games, and any Wine program which is running with [[Wikipedia:OpenGL Shading Language|GLSL]] enabled. To select a single core and allow only the driver to handle this process, simply use the {{ic|-a 0x''#''}} flag, where ''#'' is the core number, e.g.:<br />
<br />
bit.trip.runner -a 0x1<br />
<br />
uses first core.<br />
<br />
Some CPUs are hyperthreaded and have only 2 or 4 cores but show up as 4 or 8, and are best accounted for:<br />
<br />
bit.trip.runner -a 0x5<br />
<br />
which use virtual cores 0101, or 1 and 3.<br />
<br />
==== General case ====<br />
<br />
For most games which require high framerates and low latency, usage of all of these flags seems to work best. Affinity should be checked per-program, however, as most native games can understand the correct usage.<br />
For a general case:<br />
<br />
bit.trip.runner -I -n -4<br />
Amnesia.bin64 -I -n -4<br />
hl2.exe -I -n -4 -a 0x1 #Wine with GLSL enabled<br />
<br />
etc.<br />
<br />
==== Optimus, and other helping programs ====<br />
<br />
As a general rule, any other process which the game requires to operate should be reniced to a level above that of the game itself. Strangely, Wine has a problem known as ''reverse scheduling'', it can often have benefits when the more important processes are set to a higher nice level. Wineserver also seems unconditionally to benefit from {{ic|SCHED_FIFO}}, since it rarely consumes the whole CPU and needs higher prioritization when possible.<br />
<br />
optirun -I -n -5<br />
wineserver -F -p 20 -n 19<br />
steam.exe -I -n -5<br />
<br />
== Peripherals ==<br />
=== Mouse ===<br />
You might want to set your [[mouse acceleration]] to control your mouse more accurately.<br />
<br />
If your mouse have more than 3 buttons, you might want to see [[Mouse buttons]].<br />
<br />
If you are using a gaming mouse (especially Logitech and Steelseries), you may want configure your mouse such as DPI, LED... using {{Pkg|piper}}. See [https://github.com/libratbag/libratbag/tree/master/data/devices this page] for a full list of supported devices.<br />
<br />
== See also ==<br />
* [https://www.reddit.com/r/linux_gaming/] - Forum on reddit.com with gaming on linux as its topic, subpages: [https://www.reddit.com/r/linux_gaming/wiki/index Wiki], [https://www.reddit.com/r/linux_gaming/wiki/faq FAQ].</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Gamemode&diff=640218Gamemode2020-11-01T08:58:18Z<p>Tobbebobbe: linked to steam</p>
<hr />
<div>[[Category:Gaming]]<br />
<br />
[https://github.com/FeralInteractive/gamemode Gamemode] is a daemon/lib combo for Linux that allows games to request a set of optimisations be temporarily applied to the host OS and/or a game process.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|gamemode}} and {{Pkg|lib32-gamemode}} packages.<br />
<br />
== Configuration ==<br />
<br />
Create and configure a gamemode.ini file. An example [https://github.com/FeralInteractive/gamemode/blob/master/example/gamemode.ini gamemode.ini file can be found here]. Save it in {{ic|/etc/}}, {{ic|$HOME/.config/}} or {{ic|/usr/share/gamemode/}}. <br />
<br />
You may want to make sure that {{ic|desiredgov}} is set to {{ic|performance}} and maybe increase the {{ic|renice}} to 10 or so for higher priority for your game.<br />
<br />
== Running ==<br />
<br />
To run games with gamemode start it like this:<br />
<br />
$ gamemoderun ./game<br />
<br />
When you have started your game you can verify that gamemode is running with the command:<br />
<br />
$ gamemoded -s<br />
<br />
=== Steam ===<br />
<br />
To make sure [[Steam]] starts a game with gamemode, right click the game, select Properties..., then Launch Options and enter:<br />
<br />
gamemoderun %command%</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Gamemode&diff=640217Gamemode2020-11-01T08:56:55Z<p>Tobbebobbe: /* Running */ corrected formatting</p>
<hr />
<div>[[Category:Gaming]]<br />
<br />
[https://github.com/FeralInteractive/gamemode Gamemode] is a daemon/lib combo for Linux that allows games to request a set of optimisations be temporarily applied to the host OS and/or a game process.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|gamemode}} and {{Pkg|lib32-gamemode}} packages.<br />
<br />
== Configuration ==<br />
<br />
Create and configure a gamemode.ini file. An example [https://github.com/FeralInteractive/gamemode/blob/master/example/gamemode.ini gamemode.ini file can be found here]. Save it in {{ic|/etc/}}, {{ic|$HOME/.config/}} or {{ic|/usr/share/gamemode/}}. <br />
<br />
You may want to make sure that {{ic|desiredgov}} is set to {{ic|performance}} and maybe increase the {{ic|renice}} to 10 or so for higher priority for your game.<br />
<br />
== Running ==<br />
<br />
To run games with gamemode start it like this:<br />
<br />
$ gamemoderun ./game<br />
<br />
When you have started your game you can verify that gamemode is running with the command:<br />
<br />
$ gamemoded -s<br />
<br />
=== Steam ===<br />
<br />
To make sure Steam starts a game with gamemode, right click the game, select Properties..., then Launch Options and enter:<br />
<br />
gamemoderun %command%</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Gamemode&diff=640216Gamemode2020-11-01T08:54:47Z<p>Tobbebobbe: Initiated page</p>
<hr />
<div>[[Category:Gaming]]<br />
<br />
[https://github.com/FeralInteractive/gamemode Gamemode] is a daemon/lib combo for Linux that allows games to request a set of optimisations be temporarily applied to the host OS and/or a game process.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|gamemode}} and {{Pkg|lib32-gamemode}} packages.<br />
<br />
== Configuration ==<br />
<br />
Create and configure a gamemode.ini file. An example [https://github.com/FeralInteractive/gamemode/blob/master/example/gamemode.ini gamemode.ini file can be found here]. Save it in {{ic|/etc/}}, {{ic|$HOME/.config/}} or {{ic|/usr/share/gamemode/}}. <br />
<br />
You may want to make sure that {{ic|desiredgov}} is set to {{ic|performance}} and maybe increase the {{ic|renice}} to 10 or so for higher priority for your game.<br />
<br />
== Running ==<br />
<br />
To run games with gamemode start it like this:<br />
<br />
$ gamemoderun <game><br />
<br />
When you have started your game you can verify that gamemode is running with the command:<br />
<br />
$ gamemoded -s<br />
<br />
=== Steam ===<br />
<br />
To make sure Steam starts a game with gamemode, right click the game, select Properties..., then Launch Options and enter:<br />
<br />
gamemoderun %command%</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Gaming&diff=640215Gaming2020-11-01T08:30:58Z<p>Tobbebobbe: /* Utilities */ Removed link to youtube-video on how to configure game mode since it has been outdated</p>
<hr />
<div>[[Category:Gaming]]<br />
[[da:List of games]]<br />
[[es:List of games]]<br />
[[it:List of games]]<br />
[[ja:ゲーム]]<br />
[[lt:Games]]<br />
[[ru:Gaming]]<br />
[[zh-hans:List of games]]<br />
{{Related articles start}}<br />
{{Related|List of games}}<br />
{{Related|Video game platform emulators}}<br />
{{Related|Xorg}}<br />
{{Related articles end}}<br />
<br />
This page contains information about running games and related system configuration tips.<br />
<br />
== Game environments ==<br />
<br />
Different environments exist to play games in Linux:<br />
<br />
* Native – games written for Linux.<br />
* Web – games running in a web browser.<br />
** HTML5 games use canvas and WebGL technologies and work in all modern browsers.<br />
** [[Flash]]-based – you need to install the plugin to play.<br />
* [[Video game platform emulators]] – required for running software designed for other architectures and systems.<br />
* [[Wine]] – Windows compatibility layer, allows to run Windows applications on Unix-like operating systems.<br />
* [[Virtual machine]]s – can be used to install compatible operating systems (such as Windows). [[VirtualBox]] has good 3D support. As an extension of this, if you have compatible hardware you can consider VGA passthrough to a Windows KVM guest, keyword is [https://www.kernel.org/doc/html/latest/driver-api/vfio.html "virtual function I/O" (VFIO)], or [[PCI passthrough via OVMF]].<br />
<br />
== Getting games ==<br />
<br />
Just because games are available for Linux doesn't mean that they are native, they might be pre-packaged with Wine or DOSBox.<br />
<br />
For list of games packaged for Arch in [[official repositories]] / the [[AUR]] see [[List of games]].<br />
<br />
* {{App|Flathub|Central [[Flatpak]] repository, has small but growing game section.|https://flathub.org/apps/category/Game|{{Pkg|flatpak}}, {{Pkg|discover}}, {{Pkg|gnome-software}}}}<br />
* {{App|[[Wikipedia:GOG.com|GOG.com]]|DRM-free game store.|https://www.gog.com|{{AUR|lgogdownloader}}, {{AUR|wyvern}}}}<br />
* {{App|[[Wikipedia:itch.io|itch.io]]|Indie game store.|https://itch.io|{{AUR|itch}}}}<br />
* {{App|Legendary| A free and open-source replacement for the Epic Games Launcher. |https://github.com/derrod/legendary|{{AUR|legendary}}}}<br />
* {{App|[[Wikipedia:Lutris|Lutris]]|Open gaming platform for Linux. Gets games from GOG, Steam, Battle.net, Origin, Uplay and many other sources. Lutris utilizes various [https://lutris.net/runners runners] to launch the games with fully customizable configuration options. |https://lutris.net|{{Pkg|lutris}}}}<br />
* {{App|[[Steam]]|Digital distribution and communications platform developed by Valve.|https://store.steampowered.com|{{Pkg|steam}}}}<br />
* {{App|Athenaeum| A libre replacement to Steam. |https://gitlab.com/librebob/athenaeum|{{AUR|athenaeum-git}}}}<br />
* {{App|Play.it|Automates the build of native packages. Also supports [[Wine]], [[DOSBox]] and ScummVM games.|https://www.dotslashplay.it/|{{AUR|play.it}}, {{AUR|play.it-git}}}}<br />
<br />
== Running games ==<br />
<br />
Certain games or game types may need special configuration to run or to run as expected.<br />
For the most part, games will work right out of the box in Arch Linux with possibly better performance than on other distributions due to compile time optimizations. However, some special setups may require a bit of configuration or scripting to make games run as smoothly as desired.<br />
<br />
=== Multi-screen setups ===<br />
<br />
Running a multi-screen setup may lead to problems with fullscreen games. In such a case, [[#Starting games in a separate X server|running a second X server]] is one possible solution. Another solution may be found in the [[NVIDIA#Gaming using TwinView|NVIDIA article]] (may also apply to non-NVIDIA users).<br />
<br />
=== Keyboard grabbing ===<br />
<br />
Many games grab the keyboard, noticeably preventing you from switching windows (also known as alt-tabbing).<br />
<br />
Some SDL games (e.g. Guacamelee) let you disable grabbing by pressing {{ic|Ctrl-g}}.<br />
<br />
{{Note|SDL is known to sometimes not be able to grab the input system. In such a case, it may succeed in grabbing it after a few seconds of waiting.}}<br />
<br />
=== Starting games in a separate X server ===<br />
<br />
In some cases like those mentioned above, it may be necessary or desired to run a second X server. Running a second X server has multiple advantages such as better performance, the ability to "tab" out of your game by using {{ic|Ctrl+Alt+F7}}/{{ic|Ctrl+Alt+F8}}, no crashing your primary X session (which may have open work on) in case a game conflicts with the graphics driver. The new X server will be akin a remote access login for the ALSA, so your user need to be part of the {{ic|audio}} group to be able to hear any sound.<br />
<br />
To start a second X server (using the free first person shooter game [http://www.xonotic.org/ Xonotic] as an example) you can simply do: <br />
$ xinit /usr/bin/xonotic-glx -- :1 vt$XDG_VTNR<br />
This can further be spiced up by using a separate X configuration file:<br />
$ xinit /usr/bin/xonotic-glx -- :1 -xf86config xorg-game.conf vt$XDG_VTNR<br />
A good reason to provide an alternative ''xorg.conf'' here may be that your primary configuration makes use of NVIDIA's Twinview which would render your 3D games like Xonotic in the middle of your multiscreen setup, spanned across all screens. This is undesirable, thus starting a second X with an alternative config where the second screen is disabled is advised. Please note, that the X config file location is relative to the /etc/X11 directory.<br />
<br />
A game starting script making use of Openbox for your home directory or {{ic|/usr/local/bin}} may look like this:<br />
<br />
{{hc|~/game.sh|<nowiki><br />
if [ $# -ge 1 ]; then<br />
game="$(which $1)"<br />
openbox="$(which openbox)"<br />
tmpgame="/tmp/tmpgame.sh"<br />
DISPLAY=:1.0<br />
echo -e "${openbox} &\n${game}" > ${tmpgame}<br />
echo "starting ${game}"<br />
xinit ${tmpgame} -- :1 -xf86config xorg-game.conf || exit 1<br />
else<br />
echo "not a valid argument"<br />
fi<br />
</nowiki>}}<br />
<br />
So after a {{ic|chmod +x}} you would be able to use this script like:<br />
<br />
$ ~/game.sh xonotic-glx<br />
<br />
{{Note|If you want to avoid loading configs from /etc/X11/xorg.conf.d, you should also use the -configdir option, pointing to an empty directory.}}<br />
<br />
=== Adjusting mouse detections ===<br />
<br />
For games that require exceptional amount of mouse skill, adjusting the [[mouse polling rate]] can help improve accuracy.<br />
<br />
=== Binaural Audio with OpenAL ===<br />
<br />
For games using [[Wikipedia:OpenAL|OpenAL]], if you use headphones you may get much better positional audio using OpenAL's [[Wikipedia:Head-related transfer function|HRTF]] filters. To enable, run the following command:<br />
<br />
echo "hrtf = true" >> ~/.alsoftrc<br />
<br />
Alternatively, install {{AUR|openal-hrtf}} from the AUR, and edit the options in /etc/openal/alsoftrc.conf<br />
<br />
For Source games, the ingame setting `dsp_slow_cpu` must be set to `1` to enable HRTF, otherwise the game will enable its own processing instead. You will also either need to set up Steam to use native runtime, or link its copy of openal.so to your own local copy. For completeness, also use the following options:<br />
<br />
dsp_slow_cpu 1 # Disable in-game spatialiazation<br />
snd_spatialize_roundrobin 1 # Disable spatialization 1.0*100% of sounds<br />
dsp_enhance_stereo 0 # Disable DSP sound effects. You may want to leave this on, if you find it does not interfere with your perception of the sound effects.<br />
snd_pitchquality 1 # Use high quality sounds<br />
<br />
=== Tuning PulseAudio ===<br />
<br />
If you are using [[PulseAudio]], you may wish to tweak some default settings to make sure it is running optimally.<br />
<br />
==== Enabling realtime priority and negative nice level ====<br />
<br />
Pulseaudio is built to be run with realtime priority, being an audio daemon. However, because of security risks of it locking up the system, it is scheduled as a regular thread by default. To adjust this, first make sure you are in the {{ic|audio}} group. Then, uncomment and edit the following lines in {{ic|/etc/pulse/daemon.conf}}:<br />
<br />
{{hc|1=/etc/pulse/daemon.conf|2=<br />
high-priority = yes<br />
nice-level = -11<br />
<br />
realtime-scheduling = yes<br />
realtime-priority = 5}}<br />
<br />
and restart pulseaudio.<br />
<br />
==== Using higher quality remixing for better sound ====<br />
<br />
PulseAudio on Arch uses speex-float-1 by default to remix channels, which is considered a 'medium-low' quality remixing. If your system can handle the extra load, you may benefit from setting it to one of the following instead:<br />
<br />
resample-method = speex-float-10<br />
<br />
==== Matching hardware buffers to Pulse's buffering ====<br />
<br />
Matching the buffers can reduce stuttering and increase performance marginally. See [http://forums.linuxmint.com/viewtopic.php?f=42&t=44862 here] for more details.<br />
<br />
=== Double check your CPU frequency scaling settings ===<br />
<br />
If your system is currently configured to properly insert its own cpu frequency scaling driver, the system sets the default governor to Ondemand. By default, this governor only adjusts the clock if the system is utilizing 95% of its CPU, and then only for a very short period of time. This saves power and reduces heat, but has a noticeable impact on performance. You can instead only have the system downclock when it is idle, by tuning the system governor. To do so, see [[Cpufrequtils#Tuning the ondemand governor]]. Recent Intel CPU (SandyBridge +) use frequency scaling driver `intel_pstate` that does not work with ondemand governor. You can switch from "powersave" (default) to "performance", but the difference is minimal.<br />
<br />
== Remote gaming ==<br />
<br />
[[Wikipedia:Cloud gaming|Cloud gaming]] has gained a lot of popularity in the last few years, because of low client-side hardware requirements. The only important thing is stable internet connection (over the ethernet cable or 5 GHz WiFi recommended) with a minimum speed of 5–10 Mbit/s (depending on the video quality and framerate).<br />
<br />
{{Note|Most of the services that work in browser usually mean to be only compatible with {{AUR|google-chrome}}.}}<br />
<br />
{| class="wikitable sortable" style="text-align: center;"<br />
! Service<br />
! class="unsortable" | Installer<br />
! In browser client<br />
! Use your own host<br />
! Offers host renting<br />
! Full desktop support<br />
! Controller support<br />
! class="unsortable" | Remarks<br />
|-<br />
| [https://dixper.gg/ Dixper] || {{-}} || {{Yes}} || {{Y|Windows-only}} || ? || ? || ? || {{-}}<br />
|-<br />
| [https://moonlight-stream.org/ Moonlight] || {{AUR|moonlight-qt}} || {{No}} || {{Y|Windows-only}} || {{No}} || {{Yes}} || {{Yes}} || This is only a client. Host machine needs GeForce experience installed.<br />
|-<br />
| [https://ui.parsecgaming.com/ Parsec] || {{AUR|parsec-bin}} || {{Yes}} (experimental) || {{Y|Windows-only}} || {{No}} || {{Yes}} || {{Yes}} || Cloud hosting [https://support.parsecgaming.com/hc/en-us/articles/360031038112-Cloud-Computer-Update no longer available]<br />
|-<br />
| [https://playkey.net/ Playkey] || {{AUR|playkey-linux}} || ? || ? || ? || ? || ? || {{-}}<br />
|-<br />
| style="white-space:nowrap" | [https://www.playstation.com/en-gb/explore/playstation-now/ps-now-on-pc/ PlayStation Now] || Runs under [[Wine]] or [[Steam]]'s proton || {{No}} || {{No}} || {{-}} || {{No}} || {{Yes}} || Play PS4, PS3 and PS2 games on PC. Alternatively, you can use [[Video game platform emulators|emulators]].<br />
|-<br />
| [https://rainway.com/ Rainway] || Coming in 2019 Q3 || {{Yes}} || {{Y|Windows-only}} || {{No}} || {{Yes}} || ? || {{-}}<br />
|-<br />
| [https://shadow.tech/ Shadow] || '''Stable:''' {{AUR|shadow-tech}} <br> '''Beta''': {{AUR|shadow-beta}} || {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} || Controller support is dependent on USB over IP, and currently AVC only as HEVC isn't supported<br />
|-<br />
| [[Steam#Steam_Remote_Play|Steam Remote Play]] || Part of {{pkg|steam}} || {{No}} || {{Yes}} || {{No}} || {{No}} || {{Yes}} || {{-}}<br />
|-<br />
| [https://vortex.gg/ Vortex] || {{-}} || {{Yes}} || {{No}} || {{-}} || {{No}} || ? || {{-}}<br />
|}<br />
<br />
== Improving performance ==<br />
<br />
See also main article: [[Improving performance]]. For Wine programs, see [[Wine#Performance]].<br />
<br />
=== Utilities ===<br />
<br />
* {{App|GameMode|Daemon/lib combo for Linux that allows games to request a set of optimisations be temporarily applied to the host OS.|https://github.com/FeralInteractive/gamemode|{{Pkg|gamemode}}, {{Pkg|lib32-gamemode}}}}<br />
<br />
=== ACO compiler ===<br />
<br />
{{Note|The method shown below '''only''' works on AMD GPUs running the '''[[AMDGPU]]''' drivers.}}<br />
See [[AMDGPU#ACO compiler]]<br />
<br />
=== Fsync patch ===<br />
<br />
See [[Steam#Fsync patch]].<br />
<br />
=== Improving frame rates and responsiveness with scheduling policies ===<br />
<br />
Most games can benefit if given the correct scheduling policies for the kernel to prioritize the task. These policies should ideally be set per-thread by the application itself.<br />
<br />
For programs which do not implement scheduling policies on their own, application known as {{Pkg|schedtool}}, and its associated daemon {{AUR|schedtoold}} can handle many of these tasks automatically.<br />
<br />
To edit what programs relieve what policies, simply edit {{ic|/etc/schedtoold.conf}} and add the program followed by the ''schedtool'' arguments desired.<br />
<br />
==== Policies ====<br />
<br />
{{ic|SCHED_ISO}} (only implemented in BFS/MuQSSPDS schedulers found in -pf and -ck [[kernel]]s) – will not only allow the process to use a maximum of 80 percent of the CPU, but will attempt to reduce latency and stuttering wherever possible. Most if not all games will benefit from this:<br />
<br />
bit.trip.runner -I<br />
<br />
{{ic|SCHED_FIFO}} provides an alternative, that can even work better. You should test to see if your applications run more smoothly with {{ic|SCHED_FIFO}}, in which case by all means use it instead. Be warned though, as {{ic|SCHED_FIFO}} runs the risk of starving the system! Use this in cases where -I is used below:<br />
<br />
bit.trip.runner -F -p 15<br />
<br />
==== Nice levels ====<br />
<br />
Secondly, the nice level sets which tasks are processed first, in ascending order. A nice level of -4 is recommended for most multimedia tasks, including games:<br />
<br />
bit.trip.runner -n -4<br />
<br />
==== Core affinity ====<br />
<br />
There is some confusion in development as to whether the driver should be multithreading, or the program. Allowing both the driver and program to simultaneously multithread can result in significant performance reductions, such as framerate loss and increased risk of crashes. Examples of this include a number of modern games, and any Wine program which is running with [[Wikipedia:OpenGL Shading Language|GLSL]] enabled. To select a single core and allow only the driver to handle this process, simply use the {{ic|-a 0x''#''}} flag, where ''#'' is the core number, e.g.:<br />
<br />
bit.trip.runner -a 0x1<br />
<br />
uses first core.<br />
<br />
Some CPUs are hyperthreaded and have only 2 or 4 cores but show up as 4 or 8, and are best accounted for:<br />
<br />
bit.trip.runner -a 0x5<br />
<br />
which use virtual cores 0101, or 1 and 3.<br />
<br />
==== General case ====<br />
<br />
For most games which require high framerates and low latency, usage of all of these flags seems to work best. Affinity should be checked per-program, however, as most native games can understand the correct usage.<br />
For a general case:<br />
<br />
bit.trip.runner -I -n -4<br />
Amnesia.bin64 -I -n -4<br />
hl2.exe -I -n -4 -a 0x1 #Wine with GLSL enabled<br />
<br />
etc.<br />
<br />
==== Optimus, and other helping programs ====<br />
<br />
As a general rule, any other process which the game requires to operate should be reniced to a level above that of the game itself. Strangely, Wine has a problem known as ''reverse scheduling'', it can often have benefits when the more important processes are set to a higher nice level. Wineserver also seems unconditionally to benefit from {{ic|SCHED_FIFO}}, since it rarely consumes the whole CPU and needs higher prioritization when possible.<br />
<br />
optirun -I -n -5<br />
wineserver -F -p 20 -n 19<br />
steam.exe -I -n -5<br />
<br />
== Peripherals ==<br />
=== Mouse ===<br />
You might want to set your [[mouse acceleration]] to control your mouse more accurately.<br />
<br />
If your mouse have more than 3 buttons, you might want to see [[Mouse buttons]].<br />
<br />
If you are using a gaming mouse (especially Logitech and Steelseries), you may want configure your mouse such as DPI, LED... using {{Pkg|piper}}. See [https://github.com/libratbag/libratbag/tree/master/data/devices this page] for a full list of supported devices.<br />
<br />
== See also ==<br />
* [https://www.reddit.com/r/linux_gaming/] - Forum on reddit.com with gaming on linux as its topic, subpages: [https://www.reddit.com/r/linux_gaming/wiki/index Wiki], [https://www.reddit.com/r/linux_gaming/wiki/faq FAQ].</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&diff=639446Dm-crypt/Encrypting an entire system2020-10-23T06:44:52Z<p>Tobbebobbe: /* Configuring the boot loader */ Added statement that GRUB_ENABLE_CRYPTODISK needs to be set to "y"</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Data-at-rest encryption]]<br />
[[Category:Installation process]]<br />
[[de:Systemverschlüsselung mit dm-crypt]]<br />
[[es:Dm-crypt (Español)/Encrypting an entire system]]<br />
[[ja:Dm-crypt/システム全体の暗号化]]<br />
[[pl:Dm-crypt (Polski)/Encrypting an entire system]]<br />
[[pt:Dm-crypt (Português)/Encrypting an entire system]]<br />
The following are examples of common scenarios of full system encryption with ''dm-crypt''. They explain all the adaptations that need to be done to the normal [[Installation guide|installation procedure]]. All the necessary tools are on the [https://www.archlinux.org/download/ installation image].<br />
<br />
== Overview ==<br />
<br />
Securing a root filesystem is where ''dm-crypt'' excels, feature and performance-wise. Unlike selectively encrypting non-root filesystems, an encrypted root filesystem can conceal information such as which programs are installed, the usernames of all user accounts, and common data-leakage vectors such as [[mlocate]] and {{ic|/var/log/}}. Furthermore, an encrypted root filesystem makes tampering with the system far more difficult, as everything except the [[boot loader]] and (usually) the kernel is encrypted.<br />
<br />
All scenarios illustrated in the following share these advantages, other pros and cons differentiating them are summarized below:<br />
<br />
{| class="wikitable"<br />
! Scenarios<br />
! Advantages<br />
! Disadvantages<br />
|----------------------------------------------------------<br />
| [[#LUKS on a partition]]<br />
shows a basic and straightforward set-up for a fully LUKS encrypted root.<br />
|<br />
* Simple partitioning and setup<br />
|<br />
* Inflexible; disk-space to be encrypted has to be pre-allocated<br />
|----------------------------------------------------------<br />
| [[#LVM on LUKS]]<br />
achieves partitioning flexibility by using LVM inside a single LUKS encrypted partition.<br />
|<br />
* Simple partitioning with knowledge of LVM<br />
* Only one key required to unlock all volumes (e.g. easy resume-from-disk setup)<br />
* Volume layout not transparent when locked<br />
* Easiest method to allow [[dm-crypt/Swap encryption#With suspend-to-disk support|suspension to disk]]<br />
|<br />
* LVM adds an additional mapping layer and hook<br />
* Less useful, if a singular volume should receive a separate key<br />
|----------------------------------------------------------<br />
| [[#LUKS on LVM]]<br />
uses dm-crypt only after the LVM is setup.<br />
|<br />
* LVM can be used to have encrypted volumes span multiple disks<br />
* Easy mix of un-/encrypted volume groups<br />
|<br />
* Complex; changing volumes requires changing encryption mappers too<br />
* Volumes require individual keys<br />
* LVM layout is transparent when locked<br />
|----------------------------------------------------------<br />
| [[#LUKS on software RAID]]<br />
uses dm-crypt only after RAID is setup.<br />
|<br />
* Analogous to LUKS on LVM<br />
|<br />
* Analogous to LUKS on LVM<br />
|----------------------------------------------------------<br />
| [[#Plain dm-crypt]]<br />
uses dm-crypt plain mode, i.e. without a LUKS header and its options for multiple keys. <br>This scenario also employs USB devices for {{ic|/boot}} and key storage, which may be applied to the other scenarios.<br />
|<br />
* Data resilience for cases where a LUKS header may be damaged<br />
* Allows [[Wikipedia:Disk encryption#Full disk encryption|Full Disk Encryption]]<br />
* Helps addressing [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)|problems]] with SSDs<br />
|<br />
* High care to all encryption parameters is required<br />
* Single encryption key and no option to change it<br />
|----------------------------------------------------------<br />
| [[#Encrypted boot partition (GRUB)]]<br />
shows how to encrypt the boot partition using the GRUB bootloader. <br> This scenario also employs an EFI system partition, which may be applied to the other scenarios.<br />
|<br />
* Same advantages as the scenario the installation is based on (LVM on LUKS for this particular example)<br />
* Less data is left unencrypted, i.e. the boot loader and the EFI system partition, if present<br />
|<br />
* Same disadvantages as the scenario the installation is based on (LVM on LUKS for this particular example)<br />
* More complicated configuration<br />
* Not supported by other boot loaders<br />
|----------------------------------------------------------<br />
| [[#Btrfs subvolumes with swap]]<br />
shows how to encrypt a [[Btrfs]] system, including the {{ic|/boot}} directory, also adding a partition for swap, on UEFI hardware.<br />
|<br />
* Similar advantages as [[#Encrypted boot partition (GRUB)]]<br />
* Availability of Btrfs' features<br />
|<br />
* Similar disadvantages as [[#Encrypted boot partition (GRUB)]]<br />
|}<br />
<br />
While all above scenarios provide much greater protection from outside threats than encrypted secondary filesystems, they also share a common disadvantage: any user in possession of the encryption key is able to decrypt the entire drive, and therefore can access other users' data. If that is of concern, it is possible to use a combination of blockdevice and stacked filesystem encryption and reap the advantages of both. See [[Data-at-rest encryption]] to plan ahead.<br />
<br />
See [[dm-crypt/Drive preparation#Partitioning]] for a general overview of the partitioning strategies used in the scenarios.<br />
<br />
Another area to consider is whether to set up an encrypted swap partition and what kind. See [[dm-crypt/Swap encryption]] for alternatives.<br />
<br />
If you anticipate to protect the system's data not only against physical theft, but also have a requirement of precautions against logical tampering, see [[dm-crypt/Specialties#Securing the unencrypted boot partition]] for further possibilities after following one of the scenarios.<br />
<br />
For [[solid state drive]]s you might want to consider enabling TRIM support, but be warned, there are potential security implications. See [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]] for more information.<br />
<br />
{{Warning|<br />
* In any scenario, never use file system repair software such as [[fsck]] directly on an encrypted volume, or it will destroy any means to recover the key used to decrypt your files. Such tools must be used on the decrypted (opened) device instead.<br />
* For the LUKS2 format:<br />
** No released version of [[GRUB]] supports LUKS2; see [https://savannah.gnu.org/bugs/?55093] and [[GRUB#Encrypted /boot]] for details. Use LUKS1 on partitions that GRUB needs to access.<br />
** The LUKS2 format has a high RAM usage per design, defaulting to 1GB per encrypted mapper. Machines with low RAM and/or multiple LUKS2 partitions unlocked in parallel may error on boot. See the {{ic|--pbkdf-memory}} option to control memory usage.[https://gitlab.com/cryptsetup/cryptsetup/issues/372]<br />
}}<br />
<br />
== LUKS on a partition ==<br />
<br />
This example covers a full system encryption with ''dm-crypt'' + LUKS in a simple partition layout:<br />
<br />
{{Text art|<nowiki><br />
+-----------------------+------------------------+-----------------------+<br />
| Boot partition | LUKS2 encrypted system | Optional free space |<br />
| | partition | for additional |<br />
| | | partitions to be set |<br />
| /boot | / | up later |<br />
| | | |<br />
| | /dev/mapper/cryptroot | |<br />
| |------------------------| |<br />
| /dev/sda1 | /dev/sda2 | |<br />
+-----------------------+------------------------+-----------------------+<br />
</nowiki>}}<br />
<br />
The first steps can be performed directly after booting the Arch Linux install image.<br />
<br />
=== Preparing the disk ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
Then create the needed partitions, at least one for {{ic|/}} (e.g. {{ic|/dev/sda2}}) and {{ic|/boot}} ({{ic|/dev/sda1}}). See [[Partitioning]].<br />
<br />
=== Preparing non-boot partitions ===<br />
<br />
The following commands create and mount the encrypted root partition. They correspond to the procedure described in detail in [[dm-crypt/Encrypting a non-root file system#Partition]] (which, despite the title, ''can'' be applied to root partitions, as long as [[#Configuring mkinitcpio|mkinitcpio]] and the [[#Configuring the boot loader|boot loader]] are correctly configured).<br />
If you want to use particular non-default encryption options (e.g. cipher, key length), see the [[dm-crypt/Device encryption#Encryption options for LUKS mode|encryption options]] before executing the first command:<br />
<br />
# cryptsetup -y -v luksFormat /dev/sda2<br />
# cryptsetup open /dev/sda2 cryptroot<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
Check the mapping works as intended:<br />
<br />
# umount /mnt<br />
# cryptsetup close cryptroot<br />
# cryptsetup open /dev/sda2 cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
If you created separate partitions (e.g. {{ic|/home}}), these steps have to be adapted and repeated for all of them, ''except'' for {{ic|/boot}}. See [[dm-crypt/Encrypting a non-root file system#Automated unlocking and mounting]] on how to handle additional partitions at boot.<br />
<br />
Note that each blockdevice requires its own passphrase. This may be inconvenient, because it results in a separate passphrase to be input during boot. An alternative is to use a keyfile stored in the system partition to unlock the separate partition via {{ic|crypttab}}. See [[dm-crypt/Device encryption#Using LUKS to format partitions with a keyfile]] for instructions.<br />
<br />
=== Preparing the boot partition ===<br />
<br />
What you do have to setup is a non-encrypted {{ic|/boot}} partition, which is needed for a encrypted root. For an ordinary boot partition on BIOS systems, for example, execute:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
or for an [[EFI system partition]] on UEFI systems:<br />
<br />
# mkfs.fat -F32 /dev/sda1<br />
<br />
Afterwards create the directory for the mountpoint and mount the partition:<br />
<br />
# mkdir /mnt/boot<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== Mounting the devices ===<br />
<br />
At [[Installation guide#Mount the file systems]] you will have to mount the mapped devices, not the actual partitions. Of course {{ic|/boot}}, which is not encrypted, will still have to be mounted directly.<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Add the {{ic|keyboard}}, {{ic|keymap}} and {{ic|encrypt}} hooks to [[mkinitcpio.conf]]. If the default US keymap is fine for you, you can omit the {{ic|keymap}} hook.<br />
<br />
HOOKS=(base '''udev''' autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt''' filesystems fsck)<br />
<br />
If using the [[sd-encrypt]] hook with the systemd-based initramfs, the following needs to be set instead:<br />
<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' filesystems fsck)<br />
<br />
Depending on which other hooks are used, the order may be relevant. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to unlock the encrypted root partition at boot, the following [[kernel parameters]] need to be set by the boot loader:<br />
<br />
cryptdevice=UUID=''device-UUID'':cryptroot root=/dev/mapper/cryptroot<br />
<br />
If using the [[sd-encrypt]] hook, the following need to be set instead:<br />
<br />
rd.luks.name=''device-UUID''=cryptroot root=/dev/mapper/cryptroot<br />
<br />
See [[dm-crypt/System configuration#Boot loader]] for details.<br />
<br />
The {{ic|''device-UUID''}} refers to the UUID of {{ic|/dev/sda2}}. See [[Persistent block device naming]] for details.<br />
<br />
For Grub you also need to set GRUB_ENABLE_CRYPTODISK to "y".<br />
<br />
== LVM on LUKS ==<br />
<br />
The straightforward method is to set up [[LVM]] on top of the encrypted partition instead of the other way round. Technically the LVM is setup inside one big encrypted blockdevice. Hence, the LVM is not transparent until the blockdevice is unlocked and the underlying volume structure is scanned and mounted during boot.<br />
<br />
The disk layout in this example is:<br />
<br />
{{Text art|<nowiki><br />
+-----------------------------------------------------------------------+ +----------------+<br />
| Logical volume 1 | Logical volume 2 | Logical volume 3 | | Boot partition |<br />
| | | | | |<br />
| [SWAP] | / | /home | | /boot |<br />
| | | | | |<br />
| /dev/MyVolGroup/swap | /dev/MyVolGroup/root | /dev/MyVolGroup/home | | |<br />
|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _| | (may be on |<br />
| | | other device) |<br />
| LUKS2 encrypted partition | | |<br />
| /dev/sda1 | | /dev/sdb1 |<br />
+-----------------------------------------------------------------------+ +----------------+<br />
</nowiki>}}<br />
<br />
{{Note|While using the {{ic|encrypt}} hook this method does not allow you to span the logical volumes over multiple disks; either use the [[sd-encrypt]] or see [[dm-crypt/Specialties#Modifying the encrypt hook for multiple partitions]].}}<br />
<br />
{{Tip|Two variants of this setup:<br />
* Instructions at [[dm-crypt/Specialties#Encrypted system using a detached LUKS header]] use this setup with a detached LUKS header on a USB device to achieve a two factor authentication with it.<br />
* Instructions at [[dm-crypt/Specialties#Encrypted /boot and a detached LUKS header on USB]] use this setup with a detached LUKS header, encrypted {{ic|/boot}} partition, and encrypted keyfile all on a USB device.<br />
}}<br />
<br />
=== Preparing the disk ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
{{Tip|When using the [[GRUB]] boot loader for BIOS booting from a [[GPT]] disk, create a [[BIOS boot partition]].}}<br />
<br />
Create a partition to be mounted at {{ic|/boot}} with a size of 200 MiB or more.<br />
<br />
{{Tip|UEFI systems can use the [[EFI system partition]] for {{ic|/boot}}.}}<br />
<br />
Create a partition which will later contain the encrypted container.<br />
<br />
Create the LUKS encrypted container at the "system" partition. Enter the chosen password twice.<br />
<br />
# cryptsetup luksFormat /dev/sda1<br />
<br />
For more information about the available cryptsetup options see the [[dm-crypt/Device encryption#Encryption options for LUKS mode|LUKS encryption options]] prior to above command.<br />
<br />
Open the container:<br />
<br />
# cryptsetup open /dev/sda1 cryptlvm<br />
<br />
The decrypted container is now available at {{ic|/dev/mapper/cryptlvm}}.<br />
<br />
=== Preparing the logical volumes ===<br />
<br />
Create a physical volume on top of the opened LUKS container:<br />
<br />
# pvcreate /dev/mapper/cryptlvm<br />
<br />
Create the volume group named {{ic|MyVolGroup}} (or whatever you want), adding the previously created physical volume to it:<br />
<br />
# vgcreate MyVolGroup /dev/mapper/cryptlvm<br />
<br />
Create all your logical volumes on the volume group:<br />
<br />
# lvcreate -L 8G MyVolGroup -n swap<br />
# lvcreate -L 32G MyVolGroup -n root<br />
# lvcreate -l 100%FREE MyVolGroup -n home<br />
<br />
Format your filesystems on each logical volume:<br />
<br />
# mkfs.ext4 /dev/MyVolGroup/root<br />
# mkfs.ext4 /dev/MyVolGroup/home<br />
# mkswap /dev/MyVolGroup/swap<br />
<br />
Mount your filesystems:<br />
<br />
# mount /dev/MyVolGroup/root /mnt<br />
# mkdir /mnt/home<br />
# mount /dev/MyVolGroup/home /mnt/home<br />
# swapon /dev/MyVolGroup/swap<br />
<br />
=== Preparing the boot partition ===<br />
<br />
The bootloader loads the kernel, [[initramfs]], and its own configuration files from the {{ic|/boot}} directory. Any filesystem on a disk that can be read by the bootloader is eligible.<br />
<br />
Create a [[filesystem]] on the partition intended for {{ic|/boot}}:<br />
<br />
# mkfs.ext4 /dev/sdb1<br />
<br />
{{Tip|When opting to keep {{ic|/boot}} on an [[EFI system partition]] the recommended formatting is<br />
<br />
# mkfs.fat -F32 /dev/sdb1<br />
<br />
}}<br />
<br />
Create the directory {{ic|/mnt/boot}}:<br />
<br />
# mkdir /mnt/boot<br />
<br />
Mount the partition to {{ic|/mnt/boot}}:<br />
<br />
# mount /dev/sdb1 /mnt/boot<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Make sure the {{Pkg|lvm2}} package is [[install]]ed and add the {{ic|keyboard}}, {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:<br />
<br />
HOOKS=(base '''udev''' autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
If using the [[sd-encrypt]] hook with the systemd-based initramfs, the following needs to be set instead:<br />
<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' '''sd-lvm2''' filesystems fsck)<br />
<br />
See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to unlock the encrypted root partition at boot, the following kernel parameter needs to be set by the boot loader:<br />
<br />
cryptdevice=UUID=''device-UUID'':cryptlvm root=/dev/MyVolGroup/root<br />
<br />
If using the [[sd-encrypt]] hook or [[dracut]], the following need to be set instead:<br />
<br />
rd.luks.name=''device-UUID''=cryptlvm root=/dev/MyVolGroup/root<br />
<br />
The {{ic|''device-UUID''}} refers to the UUID of {{ic|/dev/sda1}}. See [[Persistent block device naming]] for details.<br />
<br />
See [[dm-crypt/System configuration#Boot loader]] for details.<br />
<br />
== LUKS on LVM ==<br />
<br />
To use encryption on top of [[LVM]], the LVM volumes are set up first and then used as the base for the encrypted partitions. This way, a mixture of encrypted and non-encrypted volumes/partitions is possible as well.<br />
{{tip|Unlike [[#LVM on LUKS]], this method allows normally spanning the logical volumes over multiple disks. }}<br />
<br />
The following short example creates a LUKS on LVM setup and mixes in the use of a key-file for the /home partition and temporary crypt volumes for {{ic|/tmp}} and {{ic|/swap}}. The latter is considered desirable from a security perspective, because no potentially sensitive temporary data survives the reboot, when the encryption is re-initialised. If you are experienced with LVM, you will be able to ignore/replace LVM and other specifics according to your plan.<br />
<br />
If you want to span a logical volume over multiple disks that have already been set up, or expand the logical volume for {{ic|/home}} (or any other volume), a procedure to do so is described in [[dm-crypt/Specialties#Expanding LVM on multiple disks]]. It is important to note that the LUKS encrypted container has to be resized as well.<br />
<br />
{{Expansion|The intro of this scenario needs some adjustment now that a comparison has been added to [[#Overview]]. A suggested structure is to make it similar to the [[#LUKS on a partition]] intro.}}<br />
<br />
=== Preparing the disk ===<br />
<br />
Partitioning scheme:<br />
<br />
{{Text art|<nowiki><br />
+----------------+-------------------------------------------------------------------------------------------------+<br />
| Boot partition | dm-crypt plain encrypted volume | LUKS2 encrypted volume | LUKS2 encrypted volume |<br />
| | | | |<br />
| /boot | [SWAP] | / | /home |<br />
| | | | |<br />
| | /dev/mapper/swap | /dev/mapper/root | /dev/mapper/home |<br />
| |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|<br />
| | Logical volume 1 | Logical volume 2 | Logical volume 3 |<br />
| | /dev/MyVolGroup/cryptswap | /dev/MyVolGroup/cryptroot | /dev/MyVolGroup/crypthome |<br />
| |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|<br />
| | |<br />
| /dev/sda1 | /dev/sda2 |<br />
+----------------+-------------------------------------------------------------------------------------------------+<br />
</nowiki>}}<br />
<br />
Randomise {{ic|/dev/sda2}} according to [[dm-crypt/Drive preparation#dm-crypt wipe on an empty disk or partition]].<br />
<br />
=== Preparing the logical volumes ===<br />
<br />
# pvcreate /dev/sda2<br />
# vgcreate MyVolGroup /dev/sda2<br />
# lvcreate -L 32G -n cryptroot MyVolGroup<br />
# lvcreate -L 500M -n cryptswap MyVolGroup<br />
# lvcreate -L 500M -n crypttmp MyVolGroup<br />
# lvcreate -l 100%FREE -n crypthome MyVolGroup<br />
<br />
# cryptsetup luksFormat /dev/MyVolGroup/cryptroot<br />
# cryptsetup open /dev/MyVolGroup/cryptroot root<br />
# mkfs.ext4 /dev/mapper/root<br />
# mount /dev/mapper/root /mnt<br />
<br />
More information about the encryption options can be found in [[dm-crypt/Device encryption#Encryption options for LUKS mode]].<br />
Note that {{ic|/home}} will be encrypted in [[#Encrypting logical volume /home]].<br />
<br />
{{Tip|If you ever have to access the encrypted root from the Arch-ISO, the above {{ic|open}} action will allow you to after the [[LVM#Logical Volumes do not show up|LVM shows up]].}}<br />
<br />
=== Preparing the boot partition ===<br />
<br />
# dd if=/dev/zero of=/dev/sda1 bs=1M status=progress<br />
# mkfs.ext4 /dev/sda1<br />
# mkdir /mnt/boot<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Make sure the {{Pkg|lvm2}} package is [[install]]ed and add the {{ic|keyboard}}, {{ic|lvm2}} and {{ic|encrypt}} hooks to [[mkinitcpio.conf]]:<br />
<br />
HOOKS=(base '''udev''' autodetect '''keyboard''' '''keymap''' consolefont modconf block '''lvm2''' '''encrypt''' filesystems fsck)<br />
<br />
If using the [[sd-encrypt]] hook with the systemd-based initramfs, the following needs to be set instead:<br />
<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' '''sd-lvm2''' filesystems fsck)<br />
<br />
See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to unlock the encrypted root partition at boot, the following [[kernel parameters]] need to be set by the boot loader:<br />
<br />
cryptdevice=UUID=''device-UUID'':root root=/dev/mapper/root<br />
<br />
If using the [[sd-encrypt]] hook, the following need to be set instead:<br />
<br />
rd.luks.name=''device-UUID''=root root=/dev/mapper/root<br />
<br />
The {{ic|''device-UUID''}} refers to the UUID of {{ic|/dev/MyVolGroup/cryptroot}}. See [[Persistent block device naming]] for details.<br />
<br />
See [[dm-crypt/System configuration#Boot loader]] for details.<br />
<br />
=== Configuring fstab and crypttab ===<br />
<br />
Both [[crypttab]] and [[fstab]] entries are required to both unlock the device and mount the filesystems, respectively. The following lines will re-encrypt the temporary filesystems on each reboot:<br />
<br />
{{hc|/etc/crypttab|2=<br />
swap /dev/MyVolGroup/cryptswap /dev/urandom swap,cipher=aes-xts-plain64,size=256<br />
tmp /dev/MyVolGroup/crypttmp /dev/urandom tmp,cipher=aes-xts-plain64,size=256<br />
}}<br />
<br />
{{hc|/etc/fstab|<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/sda1 /boot ext4 defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
=== Encrypting logical volume /home ===<br />
<br />
Since this scenario uses LVM as the primary and dm-crypt as secondary mapper, each encrypted logical volume requires its own encryption. Yet, unlike the temporary filesystems configured with volatile encryption above, the logical volume for {{ic|/home}} should of course be persistent. The following assumes you have rebooted into the installed system, otherwise you have to adjust paths.<br />
To save on entering a second passphrase at boot, a [[dm-crypt/Device encryption#Keyfiles|keyfile]] is created:<br />
<br />
# mkdir -m 700 /etc/luks-keys<br />
# dd if=/dev/random of=/etc/luks-keys/home bs=1 count=256 status=progress<br />
<br />
The logical volume is encrypted with it:<br />
<br />
# cryptsetup luksFormat -v /dev/MyVolGroup/crypthome /etc/luks-keys/home<br />
# cryptsetup -d /etc/luks-keys/home open /dev/MyVolGroup/crypthome home<br />
# mkfs.ext4 /dev/mapper/home<br />
# mount /dev/mapper/home /home<br />
<br />
The encrypted mount is configured in both [[crypttab]] and [[fstab]]:<br />
<br />
{{hc|/etc/crypttab|<br />
home /dev/MyVolGroup/crypthome /etc/luks-keys/home<br />
}}<br />
<br />
{{hc|/etc/fstab|<br />
/dev/mapper/home /home ext4 defaults 0 2<br />
}}<br />
<br />
== LUKS on software RAID ==<br />
<br />
This example is based on a real-world setup for a workstation class laptop equipped with two SSDs of equal size, and an additional HDD for bulk storage. The end result is LUKS1 based full disk encryption (including {{ic|/boot}}) for all drives, with the SSDs in a [[RAID|RAID0]] array, and keyfiles used to unlock all encryption after [[GRUB]] is given a correct passphrase at boot.<br />
<br />
This setup utilizes a very simplistic partitioning scheme, with all the available RAID storage being mounted at {{ic|/}} (no separate {{ic|/boot}} partition), and the decrypted HDD being mounted at {{ic|/data}}.<br />
<br />
Please note that regular [[System backup|backups]] are very important in this setup. If either of the SSDs fail, the data contained in the RAID array will be practically impossible to recover. You may wish to select a different [[RAID#Standard RAID levels|RAID level]] if fault tolerance is important to you. <br />
<br />
The encryption is not deniable in this setup.<br />
<br />
For the sake of the instructions below, the following block devices are used:<br />
<br />
/dev/sda = first SSD<br />
/dev/sdb = second SSD<br />
/dev/sdc = HDD<br />
<br />
{{Text art|<nowiki><br />
+---------------------+---------------------------+---------------------------+ +---------------------+---------------------------+---------------------------+ +---------------------------+<br />
| BIOS boot partition | EFI system partition | LUKS1 encrypted volume | | BIOS boot partition | EFI system partition | LUKS1 encrypted volume | | LUKS2 encrypted volume |<br />
| | | | | | | | | |<br />
| | /efi | / | | | /efi | / | | /data |<br />
| | | | | | | | | |<br />
| | | /dev/mapper/cryptroot | | | | /dev/mapper/cryptroot | | |<br />
| +---------------------------+---------------------------+ | +---------------------------+---------------------------+ | |<br />
| | RAID1 array (part 1 of 2) | RAID0 array (part 1 of 2) | | | RAID1 array (part 2 of 2) | RAID0 array (part 2 of 2) | | |<br />
| | | | | | | | | |<br />
| | /dev/md/ESP | /dev/md/root | | | /dev/md/ESP | /dev/md/root | | /dev/mapper/cryptdata |<br />
| +---------------------------+---------------------------+ | +---------------------------+---------------------------+ +---------------------------+<br />
| /dev/sda1 | /dev/sda2 | /dev/sda3 | | /dev/sdb1 | /dev/sdb2 | /dev/sdb3 | | /dev/sdc1 |<br />
+---------------------+---------------------------+---------------------------+ +---------------------+---------------------------+---------------------------+ +---------------------------+<br />
</nowiki>}}<br />
<br />
Be sure to substitute them with the appropriate device designations for your setup, as they may be different.<br />
<br />
=== Preparing the disks ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
For [[GRUB#BIOS systems|BIOS systems]] with GPT, create a [[BIOS boot partition]] with size of 1 MiB for GRUB to store the second stage of BIOS bootloader. Do not mount the partition.<br />
<br />
For [[GRUB#UEFI systems|UEFI systems]] create an [[EFI system partition]] with an appropriate size, it will later be mounted at {{ic|/efi}}.<br />
<br />
In the remaining space on the drive create a partition ({{ic|/dev/sda3}} in this example) for "Linux RAID". Choose partition type ID {{ic|fd}} for MBR or partition type GUID {{ic|A19D880F-05FC-4D3B-A006-743F0F84911E}} for GPT.<br />
<br />
Once partitions have been created on {{ic|/dev/sda}}, the following commands can be used to clone them to {{ic|/dev/sdb}}.<br />
<br />
# sfdisk -d /dev/sda > sda.dump<br />
# sfdisk /dev/sdb < sda.dump<br />
<br />
The HDD is prepared with a single Linux partition covering the whole drive at {{ic|/dev/sdc1}}.<br />
<br />
=== Building the RAID array ===<br />
<br />
Create the RAID array for the SSDs.<br />
<br />
{{Note|<br />
* All parts of an EFI system partition RAID array must be individually usable, that means that ESP can only placed in a RAID1 array.<br />
* The RAID superblock must be placed at the end of the EFI system partition using {{ic|1=--metadata=1.0}}, otherwise the firmware will not be able to access the partition.<br />
}}<br />
<br />
# mdadm --create --verbose --level=1 --metadata=1.0 --raid-devices=2 /dev/md/ESP /dev/sda2 /dev/sdb2<br />
<br />
This example utilizes RAID0 for root, you may wish to substitute a different level based on your preferences or requirements.<br />
<br />
# mdadm --create --verbose --level=0 --metadata=1.2 --raid-devices=2 /dev/md/root /dev/sda3 /dev/sdb3<br />
<br />
=== Preparing the block devices ===<br />
<br />
As explained in [[dm-crypt/Drive preparation]], the devices are wiped with random data utilizing {{ic|/dev/zero}} and a crypt device with a random key. Alternatively, you could use {{ic|dd}} with {{ic|/dev/random}} or {{ic|/dev/urandom}}, though it will be much slower.<br />
<br />
# cryptsetup open --type plain /dev/md/root container --key-file /dev/random<br />
# dd if=/dev/zero of=/dev/mapper/container bs=1M status=progress<br />
# cryptsetup close container<br />
<br />
And repeat above for the HDD ({{ic|/dev/sdc1}} in this example).<br />
<br />
Set up encryption for {{ic|/dev/md/root}}:<br />
<br />
{{Warning|No released version of GRUB supports LUKS2; see [[GRUB#Encrypted /boot]] for details. Use LUKS1 ({{ic|1=--type luks1}}) on partitions that GRUB needs to access.}}<br />
<br />
# cryptsetup -y -v luksFormat --type luks1 /dev/md/root<br />
# cryptsetup open /dev/md/root cryptroot<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
And repeat for the HDD:<br />
<br />
# cryptsetup -y -v luksFormat /dev/sdc1<br />
# cryptsetup open /dev/sdc1 cryptdata<br />
# mkfs.ext4 /dev/mapper/cryptdata<br />
# mkdir /mnt/data<br />
# mount /dev/mapper/cryptdata /mnt/data<br />
<br />
For UEFI systems, set up the EFI system partition:<br />
<br />
# mkfs.fat -F32 /dev/md/ESP<br />
# mount /dev/md/ESP /mnt/efi<br />
<br />
=== Configuring GRUB ===<br />
<br />
Configure [[GRUB]] for the LUKS1 encrypted system by editing {{ic|/etc/default/grub}} with the following:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/md/root:cryptroot"<br />
GRUB_ENABLE_CRYPTODISK=y<br />
<br />
See [[dm-crypt/System configuration#Boot loader]] and [[GRUB#Encrypted /boot]] for details.<br />
<br />
Complete the GRUB install to both SSDs (in reality, installing only to {{ic|/dev/sda}} will work).<br />
<br />
# grub-install --target=i386-pc /dev/sda<br />
# grub-install --target=i386-pc /dev/sdb<br />
# grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=== Creating the keyfiles ===<br />
<br />
The next steps save you from entering your passphrase twice when you boot the system (once so GRUB can unlock the LUKS1 device, and second time once the initramfs assumes control of the system). This is done by creating a [[dm-crypt/Device encryption#Keyfiles|keyfile]] for the encryption and adding it to the initramfs image to allow the encrypt hook to unlock the root device. See [[dm-crypt/Device encryption#With a keyfile embedded in the initramfs]] for details.<br />
<br />
* Create the [[dm-crypt/Device encryption#Keyfiles|keyfile]] and add the key to {{ic|/dev/md/root}}.<br />
* Create another keyfile for the HDD ({{ic|/dev/sdc1}}) so it can also be unlocked at boot. For convenience, leave the passphrase created above in place as this can make recovery easier if you ever need it. Edit {{ic|/etc/crypttab}} to decrypt the HDD at boot. See [[Dm-crypt/System configuration#Unlocking with a keyfile]].<br />
<br />
=== Configuring the system ===<br />
<br />
Edit [[fstab]] to mount the cryptroot and cryptdata block devices and the ESP:<br />
<br />
/dev/mapper/cryptroot / ext4 rw,noatime 0 1<br />
/dev/mapper/cryptdata /data ext4 defaults 0 2<br />
/dev/md/ESP /efi vfat rw,relatime,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,tz=UTC,errors=remount-ro 0 2<br />
<br />
Save the RAID configuration:<br />
<br />
# mdadm --detail --scan >> /etc/mdadm.conf<br />
<br />
Edit [[mkinitcpio.conf]] to include your keyfile and add the proper hooks:<br />
<br />
FILES=(/crypto_keyfile.bin)<br />
HOOKS=(base udev autodetect '''keyboard''' '''keymap''' consolefont modconf block '''mdadm_udev''' '''encrypt''' filesystems fsck)<br />
<br />
See [[dm-crypt/System configuration#mkinitcpio]] for details.<br />
<br />
== Plain dm-crypt ==<br />
<br />
Contrary to LUKS, dm-crypt ''plain'' mode does not require a header on the encrypted device: this scenario exploits this feature to set up a system on an unpartitioned, encrypted disk that will be indistinguishable from a disk filled with random data, which could allow [[Wikipedia:Deniable encryption|deniable encryption]]. See also [[wikipedia:Disk encryption#Full disk encryption]].<br />
<br />
Note that if full-disk encryption is not required, the methods using LUKS described in the sections above are better options for both system encryption and encrypted partitions. LUKS features like key management with multiple passphrases/key-files or re-encrypting a device in-place are unavailable with ''plain'' mode.<br />
<br />
''Plain'' dm-crypt encryption can be more resilient to damage than LUKS, because it does not rely on an encryption master-key which can be a single-point of failure if damaged. However, using ''plain'' mode also requires more manual configuration of encryption options to achieve the same cryptographic strength. See also [[Data-at-rest encryption#Cryptographic metadata]]. Using ''plain'' mode could also be considered if concerned with the problems explained in [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]].<br />
<br />
{{Tip|If headerless encryption is your goal but you are unsure about the lack of key-derivation with ''plain'' mode, then two alternatives are:<br />
* [[dm-crypt/Specialties#Encrypted system using a detached LUKS header|dm-crypt LUKS mode with a detached header]] by using the ''cryptsetup'' {{ic|--header}} option. It cannot be used with the standard ''encrypt'' hook, but the hook may be modified.<br />
* [[tcplay]] which offers headerless encryption but with the PBKDF2 function.<br />
}}<br />
<br />
The scenario uses two USB sticks:<br />
<br />
* one for the boot device, which also allows storing the options required to open/unlock the plain encrypted device in the boot loader configuration, since typing them on each boot would be error prone;<br />
* another for the encryption key file, assuming it stored as raw bits so that to the eyes of an unaware attacker who might get the usbkey the encryption key will appear as random data instead of being visible as a normal file. See also [[Wikipedia:Security through obscurity]], follow [[dm-crypt/Device encryption#Keyfiles]] to prepare the keyfile.<br />
<br />
The disk layout is:<br />
<br />
{{Text art|<nowiki><br />
+----------------------+----------------------+----------------------+ +----------------+ +----------------+<br />
| Logical volume 1 | Logical volume 2 | Logical volume 3 | | Boot device | | Encryption key |<br />
| | | | | | | file storage |<br />
| / | [SWAP] | /home | | /boot | | (unpartitioned |<br />
| | | | | | | in example) |<br />
| /dev/MyVolGroup/root | /dev/MyVolGroup/swap | /dev/MyVolGroup/home | | /dev/sdb1 | | /dev/sdc |<br />
|----------------------+----------------------+----------------------| |----------------| |----------------|<br />
| disk drive /dev/sda encrypted using plain mode and LVM | | USB stick 1 | | USB stick 2 |<br />
+--------------------------------------------------------------------+ +----------------+ +----------------+<br />
</nowiki>}}<br />
<br />
{{Tip|<br />
* It is also possible to use a single USB key physical device:<br />
** By putting the key on another partition (/dev/sdb2) of the USB storage device (/dev/sdb).<br />
** By copying the keyfile to the initramfs directly. An example keyfile {{ic|/etc/keyfile}} gets copied to the initramfs image by setting {{ic|1=FILES=(/etc/keyfile)}} in {{ic|/etc/mkinitcpio.conf}}. The way to instruct the {{ic|encrypt}} hook to read the keyfile in the initramfs image is using {{ic|rootfs:}} prefix before the filename, e.g. {{ic|1=cryptkey=rootfs:/etc/keyfile}}.<br />
* Another option is using a passphrase with good [[Security#Choosing secure passwords|entropy]].<br />
}}<br />
<br />
=== Preparing the disk ===<br />
<br />
It is vital that the mapped device is filled with random data. In particular this applies to the scenario use case we apply here.<br />
<br />
See [[dm-crypt/Drive preparation]] and [[dm-crypt/Drive preparation#dm-crypt specific methods]]<br />
<br />
=== Preparing the non-boot partitions ===<br />
<br />
See [[dm-crypt/Device encryption#Encryption options for plain mode]] for details.<br />
<br />
Using the device {{ic|/dev/sda}}, with the aes-xts cipher with a 512 bit key size and using a keyfile we have the following options for this scenario:<br />
<br />
# cryptsetup --cipher=aes-xts-plain64 --offset=0 --key-file=/dev/sdc --key-size=512 open --type plain /dev/sda cryptlvm<br />
<br />
Unlike encrypting with LUKS, the above command must be executed ''in full'' whenever the mapping needs to be re-established, so it is important to remember the cipher, and key file details.<br />
<br />
We can now check a mapping entry has been made for {{ic|/dev/mapper/cryptlvm}}:<br />
<br />
# fdisk -l<br />
<br />
{{Tip|A simpler alternative to using LVM, advocated in the cryptsetup FAQ for cases where LVM is not necessary, is to just create a filesystem on the entirety of the mapped dm-crypt device.}} <br />
<br />
Next, we setup [[LVM]] logical volumes on the mapped device. See [[Install Arch Linux on LVM]] for further details:<br />
<br />
# pvcreate /dev/mapper/cryptlvm<br />
# vgcreate MyVolGroup /dev/mapper/cryptlvm<br />
# lvcreate -L 32G MyVolGroup -n root<br />
# lvcreate -L 10G MyVolGroup -n swap<br />
# lvcreate -l 100%FREE MyVolGroup -n home<br />
<br />
We format and mount them and activate swap. See [[File systems#Create a file system]] for further details:<br />
<br />
# mkfs.ext4 /dev/MyVolGroup/root<br />
# mkfs.ext4 /dev/MyVolGroup/home<br />
# mount /dev/MyVolGroup/root /mnt<br />
# mkdir /mnt/home<br />
# mount /dev/MyVolGroup/home /mnt/home<br />
# mkswap /dev/MyVolGroup/swap<br />
# swapon /dev/MyVolGroup/swap<br />
<br />
=== Preparing the boot partition ===<br />
<br />
The {{ic|/boot}} partition can be installed on the standard vfat partition of a USB stick, if required. But if manual partitioning is needed, then a small 200 MiB partition is all that is required. Create the partition using a [[Partitioning#Partitioning tools|partitioning tool]] of your choice.<br />
<br />
Create a [[filesystem]] on the partition intended for {{ic|/boot}}:<br />
<br />
# mkfs.ext4 /dev/sdb1<br />
# mkdir /mnt/boot<br />
# mount /dev/sdb1 /mnt/boot<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Make sure the {{Pkg|lvm2}} package is [[install]]ed and add the {{ic|keyboard}}, {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:<br />
<br />
HOOKS=(base udev autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to boot the encrypted root partition, the following [[kernel parameters]] need to be set by the boot loader (note that 64 is the number of bytes in 512 bits):<br />
<br />
cryptdevice=/dev/disk/by-id/''disk-ID-of-sda'':cryptlvm cryptkey=/dev/disk/by-id/''disk-ID-of-sdc'':0:64 crypto=:aes-xts-plain64:512:0:<br />
<br />
The {{ic|''disk-ID-of-'''disk'''''}} refers to the id of the referenced disk. See [[Persistent block device naming]] for details.<br />
<br />
See [[dm-crypt/System configuration#Boot loader]] for details and other parameters that you may need.<br />
<br />
{{Tip|If using GRUB, you can install it on the same USB as the {{ic|/boot}} partition with:<br />
<br />
# grub-install --recheck /dev/sdb<br />
<br />
}}<br />
<br />
=== Post-installation ===<br />
<br />
You may wish to remove the USB sticks after booting. Since the {{ic|/boot}} partition is not usually needed, the {{ic|noauto}} option can be added to the relevant line in {{ic|/etc/fstab}}:<br />
<br />
{{hc|/etc/fstab|<br />
# /dev/sdb1<br />
/dev/sdb1 /boot ext4 '''noauto''',rw,noatime 0 2<br />
}}<br />
<br />
However, when an update to anything used in the initramfs, or a kernel, or the bootloader is required; the {{ic|/boot}} partition must be present and mounted. As the entry in {{ic|fstab}} already exists, it can be mounted simply with:<br />
<br />
# mount /boot<br />
<br />
== Encrypted boot partition (GRUB) ==<br />
<br />
This setup utilizes the same partition layout and configuration as the previous [[#LVM on LUKS]] section, with the difference that the [[GRUB]] boot loader is used since it is capable of booting from an LVM logical volume and a LUKS1-encrypted {{ic|/boot}}. See also [[GRUB#Encrypted /boot]].<br />
<br />
The disk layout in this example is:<br />
<br />
{{Text art|<nowiki><br />
+---------------------+----------------------+----------------------+----------------------+----------------------+<br />
| BIOS boot partition | EFI system partition | Logical volume 1 | Logical volume 2 | Logical volume 3 |<br />
| | | | | |<br />
| | /efi | / | [SWAP] | /home |<br />
| | | | | |<br />
| | | /dev/MyVolGroup/root | /dev/MyVolGroup/swap | /dev/MyVolGroup/home |<br />
| /dev/sda1 | /dev/sda2 |----------------------+----------------------+----------------------+<br />
| unencrypted | unencrypted | /dev/sda3 encrypted using LVM on LUKS1 |<br />
+---------------------+----------------------+--------------------------------------------------------------------+<br />
</nowiki>}}<br />
<br />
{{Tip|<br />
* All scenarios are intended as examples. It is, of course, possible to apply both of the two above distinct installation steps with the other scenarios as well. See also the variants linked in [[#LVM on LUKS]].<br />
* You can use {{ic|cryptboot}} script from {{AUR|cryptboot}} package for simplified encrypted boot management (mounting, unmounting, upgrading packages) and as a defense against [https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html Evil Maid] attacks with [[Secure Boot#Using your own keys|UEFI Secure Boot]]. For more information and limitations see [https://github.com/xmikos/cryptboot cryptboot project] page.<br />
}}<br />
<br />
=== Preparing the disk ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
For [[GRUB#GUID Partition Table (GPT) specific instructions|BIOS/GPT systems]] create a [[BIOS boot partition]] with size of 1 MiB for GRUB to store the second stage of BIOS bootloader. Do not mount the partition. For BIOS/MBR systems this is not necessary.<br />
<br />
For [[GRUB#UEFI systems|UEFI systems]] create an [[EFI system partition]] with an appropriate size, it will later be mounted at {{ic|/efi}}.<br />
<br />
Create a partition of type {{ic|8309}}, which will later contain the encrypted container for the LVM.<br />
<br />
Create the LUKS encrypted container:<br />
<br />
{{Warning|GRUB does not support LUKS2. Use LUKS1 ({{ic|1=--type luks1}}) on partitions that GRUB needs to access. There is experimental support of LUKS2 in {{AUR|grub-git}}, check the comments there for instructions.}}<br />
<br />
# cryptsetup luksFormat --type luks1 /dev/sda3<br />
<br />
For more information about the available cryptsetup options see the [[dm-crypt/Device encryption#Encryption options for LUKS mode|LUKS encryption options]] prior to above command.<br />
<br />
Your partition layout should look similar to this:<br />
<br />
{{hc|# gdisk -l /dev/sda|<br />
...<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 4095 1024.0 KiB EF02 BIOS boot partition<br />
2 4096 1130495 550.0 MiB EF00 EFI System<br />
3 1130496 68239360 32.0 GiB 8309 Linux LUKS<br />
}}<br />
<br />
Open the container:<br />
<br />
# cryptsetup open /dev/sda3 cryptlvm<br />
<br />
The decrypted container is now available at {{ic|/dev/mapper/cryptlvm}}.<br />
<br />
=== Preparing the logical volumes ===<br />
<br />
The LVM logical volumes of this example follow the exact layout as the [[#LVM on LUKS]] scenario. Therefore, please follow [[#Preparing the logical volumes]] above and adjust as required.<br />
<br />
If you plan to boot in UEFI mode, create a mountpoint for the [[EFI system partition]] at {{ic|/efi}} for compatibility with {{ic|grub-install}} and mount it:<br />
<br />
# mkdir /mnt/efi<br />
# mount /dev/sda2 /mnt/efi<br />
<br />
At this point, you should have the following partitions and logical volumes inside of {{ic|/mnt}}:<br />
<br />
{{hc|$ lsblk|<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
sda 8:0 0 200G 0 disk<br />
├─sda1 8:1 0 1M 0 part<br />
├─sda2 8:2 0 550M 0 part /mnt/efi<br />
└─sda3 8:3 0 100G 0 part<br />
└─cryptlvm 254:0 0 100G 0 crypt<br />
├─MyVolGroup-swap 254:1 0 8G 0 lvm [SWAP]<br />
├─MyVolGroup-root 254:2 0 32G 0 lvm /mnt<br />
└─MyVolGroup-home 254:3 0 60G 0 lvm /mnt/home<br />
}}<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Make sure the {{Pkg|lvm2}} package is [[install]]ed and add the {{ic|keyboard}}, {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:<br />
<br />
HOOKS=(base '''udev''' autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
If using the [[sd-encrypt]] hook with the systemd-based initramfs, the following needs to be set instead:<br />
<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' '''sd-lvm2''' filesystems fsck)<br />
<br />
See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring GRUB ===<br />
<br />
Configure GRUB to allow booting from {{ic|/boot}} on a LUKS1 encrypted partition:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_ENABLE_CRYPTODISK=y<br />
}}<br />
<br />
Set the kernel parameters, so that the initramfs can unlock the encrypted root partition. Using the {{ic|encrypt}} hook:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_CMDLINE_LINUX="... cryptdevice=UUID=''device-UUID'':cryptlvm ..."<br />
}}<br />
<br />
If using the [[sd-encrypt]] hook, the following need to be set instead:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_CMDLINE_LINUX="... rd.luks.name=''device-UUID''=cryptlvm ..."<br />
}}<br />
<br />
See [[dm-crypt/System configuration#Boot loader]] and [[GRUB#Encrypted /boot]] for details. The {{ic|''device-UUID''}} refers to the UUID of {{ic|/dev/sda3}} (the partition which holds the lvm containing the root filesystem). See [[Persistent block device naming]].<br />
<br />
[[GRUB#Installation_2|install GRUB]] to the mounted ESP for UEFI booting:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB --recheck<br />
<br />
[[GRUB#Installation|install GRUB]] to the disk for BIOS booting:<br />
<br />
# grub-install --target=i386-pc --recheck /dev/sda<br />
<br />
Generate GRUB's [[GRUB#Generate the main configuration file|configuration]] file:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
If all commands finished without errors, GRUB should prompt for the passphrase to unlock the {{ic|/dev/sda3}} partition after the next reboot.<br />
<br />
=== Avoiding having to enter the passphrase twice ===<br />
<br />
{{Merge|Dm-crypt/Device encryption#With a keyfile embedded in the initramfs|Too much duplicated content, too much detail here for this overview page.|section=Security Issue with Grub Keyfile}}<br />
<br />
While GRUB asks for a passphrase to unlock the LUKS1 encrypted partition after above instructions, the partition unlock is not passed on to the initramfs. Hence, you have to enter the passphrase twice at boot: once for GRUB and once for the initramfs.<br />
<br />
This section deals with extra configuration to let the system boot by only entering the passphrase once, in GRUB. This is accomplished by [[dm-crypt/Device encryption#With a keyfile embedded in the initramfs|with a keyfile embedded in the initramfs]].<br />
<br />
First create a keyfile and add it as LUKS key:<br />
<br />
# dd bs=512 count=4 if=/dev/random of=/root/cryptlvm.keyfile iflag=fullblock<br />
# chmod 000 /root/cryptlvm.keyfile<br />
# cryptsetup -v luksAddKey /dev/sda3 /root/cryptlvm.keyfile<br />
<br />
Add the keyfile to the initramfs image:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
FILES=(/root/cryptlvm.keyfile)<br />
}}<br />
<br />
Recreate the initramfs image and secure the embedded keyfile:<br />
<br />
# chmod 600 /boot/initramfs-linux*<br />
<br />
Set the following kernel parameters to unlock the LUKS partition with the keyfile. Using the {{ic|encrypt}} hook:<br />
<br />
GRUB_CMDLINE_LINUX="... cryptkey=rootfs:/root/cryptlvm.keyfile"<br />
<br />
Or, using the [[sd-encrypt]] hook:<br />
<br />
GRUB_CMDLINE_LINUX="... rd.luks.key=''device-UUID''=/root/cryptlvm.keyfile"<br />
<br />
If for some reason the keyfile fails to unlock the boot partition, systemd will fallback to ask for a passphrase to unlock and, in case that is correct, continue booting.<br />
<br />
{{Tip|If you want to encrypt the {{ic|/boot}} partition to protect against offline tampering threats, the [[dm-crypt/Specialties#mkinitcpio-chkcryptoboot|mkinitcpio-chkcryptoboot]] hook has been contributed to help.}}<br />
<br />
== Btrfs subvolumes with swap ==<br />
<br />
The following example creates a full system encryption with LUKS1 using [[Btrfs]] subvolumes to [[Btrfs#Mounting subvolumes|simulate partitions]].<br />
<br />
If using UEFI, an [[EFI system partition]] (ESP) is required. {{ic|/boot}} itself may reside on {{ic|/}} and be encrypted; however, the ESP itself cannot be encrypted. In this example layout, the ESP is {{ic|/dev/sda1}} and is mounted at {{ic|/efi}}. {{ic|/boot}} itself is located on the system partition, {{ic|/dev/sda2}}.<br />
<br />
Since {{ic|/boot}} resides on the LUKS1 encrypted {{ic|/}}, [[GRUB]] must be used as the bootloader because only GRUB can load modules necessary to decrypt {{ic|/boot}} (e.g., crypto.mod, cryptodisk.mod and luks.mod).<br />
<br />
Additionally an optional plain-encrypted [[swap]] partition is shown.<br />
<br />
{{Warning|Do not use a [[swap file]] instead of a separate partition on Linux kernels before v5.0, because this may result in data loss. See [[Btrfs#Swap file]].}}<br />
<br />
{{Text art|<nowiki><br />
+----------------------+----------------------+----------------------+<br />
| EFI system partition | System partition | Swap partition |<br />
| unencrypted | LUKS1-encrypted | plain-encrypted |<br />
| | | |<br />
| /efi | / | [SWAP] |<br />
| /dev/sda1 | /dev/sda2 | /dev/sda3 |<br />
|----------------------+----------------------+----------------------+<br />
</nowiki>}}<br />
<br />
=== Preparing the disk ===<br />
<br />
{{Note|It is not possible to use btrfs partitioning as described in [[Btrfs#Partitionless Btrfs disk]] when using LUKS. Traditional partitioning must be used, even if it is just to create one partition.}}<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]]. If you are using [[UEFI]] create an [[EFI system partition]] with an appropriate size. It will later be mounted at {{ic|/efi}}. If you are going to create an encrypted swap partition, create the partition for it, but do '''not''' mark it as swap, since plain ''dm-crypt'' will be used with the partition.<br />
<br />
Create the needed partitions, at least one for {{ic|/}} (e.g. {{ic|/dev/sda2}}). See the [[Partitioning]] article.<br />
<br />
=== Preparing the system partition ===<br />
<br />
==== Create LUKS container ====<br />
<br />
{{Warning|GRUB does not support LUKS2. Use LUKS1 ({{ic|1=--type luks1}}) on partitions that GRUB needs to access.}}<br />
<br />
Follow [[dm-crypt/Device encryption#Encrypting devices with LUKS mode]] to setup {{ic|/dev/sda2}} for LUKS. See the [[dm-crypt/Device encryption#Encryption options for LUKS mode]] before doing so for a list of encryption options.<br />
<br />
==== Unlock LUKS container ====<br />
<br />
Now follow [[dm-crypt/Device encryption#Unlocking/Mapping LUKS partitions with the device mapper]] to unlock the LUKS container and map it.<br />
<br />
==== Format mapped device ====<br />
<br />
Proceed to format the mapped device as described in [[Btrfs#File system on a single device]], where {{ic|''/dev/partition''}} is the name of the mapped device (i.e., {{ic|cryptroot}}) and '''not''' {{ic|/dev/sda2}}.<br />
<br />
==== Mount mapped device ====<br />
<br />
Finally, [[mount]] the now-formatted mapped device (i.e., {{ic|/dev/mapper/cryptroot}}) to {{ic|/mnt}}.<br />
<br />
=== Creating btrfs subvolumes ===<br />
<br />
{{Merge|Btrfs|The subvolume layout is not specific to an encrypted system.}}<br />
<br />
==== Layout ====<br />
<br />
[[Btrfs#Subvolumes|Subvolumes]] will be used to simulate partitions, but other (nested) subvolumes will also be created. Here is a partial representation of what the following example will generate:<br />
<br />
{{Text art|<nowiki><br />
subvolid=5 (/dev/sda2)<br />
|<br />
├── @ (mounted as /)<br />
| |<br />
| ├── /bin (directory)<br />
| |<br />
| ├── /home (mounted @home subvolume)<br />
| |<br />
| ├── /usr (directory)<br />
| |<br />
| ├── /.snapshots (mounted @snapshots subvolume)<br />
| |<br />
| ├── /var/cache/pacman/pkg (nested subvolume)<br />
| |<br />
| ├── ... (other directories and nested subvolumes)<br />
|<br />
├── @snapshots (mounted as /.snapshots)<br />
|<br />
├── @home (mounted as /home)<br />
|<br />
└── @... (additional subvolumes you wish to use as mount points)<br />
</nowiki>}}<br />
<br />
This section follows the [[Snapper#Suggested filesystem layout]], which is most useful when used with [[Snapper]]. You should also consult [https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout Btrfs Wiki SysadminGuide#Layout].<br />
<br />
==== Create top-level subvolumes ====<br />
<br />
Here we are using the convention of prefixing {{ic|@}} to subvolume names that will be used as mount points, and {{ic|@}} will be the subvolume that is mounted as {{ic|/}}.<br />
<br />
Following the [[Btrfs#Creating a subvolume]] article, create subvolumes at {{ic|/mnt/@}}, {{ic|/mnt/@snapshots}}, and {{ic|/mnt/@home}}.<br />
<br />
Create any additional subvolumes you wish to use as mount points now.<br />
<br />
==== Mount top-level subvolumes ====<br />
<br />
Unmount the system partition at {{ic|/mnt}}.<br />
<br />
Now mount the newly created {{ic|@}} subvolume which will serve as {{ic|/}} to {{ic|/mnt}} using the {{ic|1=subvol=}} mount option. Assuming the mapped device is named {{ic|cryptroot}}, the command would look like:<br />
<br />
# mount -o compress=zstd,subvol=@ /dev/mapper/cryptroot /mnt<br />
<br />
See [[Btrfs#Mounting subvolumes]] for more details.<br />
<br />
Also mount the other subvolumes to their respective mount points: {{ic|@home}} to {{ic|/mnt/home}} and {{ic|@snapshots}} to {{ic|/mnt/.snapshots}}.<br />
<br />
==== Create nested subvolumes ====<br />
<br />
Create any subvolumes you do '''not''' want to have snapshots of when taking a snapshot of {{ic|/}}. For example, you probably do not want to take snapshots of {{ic|/var/cache/pacman/pkg}}. These subvolumes will be nested under the {{ic|@}} subvolume, but just as easily could have been created earlier at the same level as {{ic|@}} according to your preference.<br />
<br />
Since the {{ic|@}} subvolume is mounted at {{ic|/mnt}} you will need to [[create a subvolume]] at {{ic|/mnt/var/cache/pacman/pkg}} for this example. You may have to create any parent directories first.<br />
<br />
Other directories you may wish to do this with are {{ic|/var/abs}}, {{ic|/var/tmp}}, and {{ic|/srv}}.<br />
<br />
==== Mount ESP ====<br />
<br />
If you prepared an EFI system partition earlier, create its mount point and mount it now.<br />
<br />
{{Note|Btrfs snapshots will exclude {{ic|/efi}}, since it is not a btrfs file system.}}<br />
<br />
At the [[Installation guide#Install essential packages|pacstrap]] installation step, the {{Pkg|btrfs-progs}} must be installed in addition to the {{Pkg|base}} [[meta package]].<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
==== Create keyfile ====<br />
<br />
In order for GRUB to open the LUKS partition without having the user enter his passphrase twice, we will use a keyfile embedded in the initramfs. Follow [[dm-crypt/Device encryption#With a keyfile embedded in the initramfs]] making sure to add the key to {{ic|/dev/sda2}} at the ''luksAddKey'' step.<br />
<br />
==== Edit mkinitcpio.conf ====<br />
<br />
After creating, adding, and embedding the key as described above, add the {{ic|encrypt}} hook to [[mkinitcpio.conf]] as well as any other hooks you require. See [[dm-crypt/System configuration#mkinitcpio]] for detailed information.<br />
<br />
{{Tip|You may want to add {{ic|1=BINARIES=(/usr/bin/btrfs)}} to your {{ic|mkinitcpio.conf}}. See the [[Btrfs#Corruption recovery]] article.}}<br />
<br />
=== Configuring the boot loader ===<br />
<br />
Install [[GRUB]] to {{ic|/dev/sda}}. Then, edit {{ic|/etc/default/grub}} as instructed in the [[GRUB#Additional arguments]], [[GRUB#Encrypted /boot]] and [[dm-crypt/System configuration#Using encrypt hook]], following both the instructions for an encrypted root and boot partition. Finally, generate the GRUB configuration file.<br />
<br />
=== Configuring swap ===<br />
<br />
If you created a partition to be used for encrypted swap, now is the time to configure it. Follow the instructions at [[dm-crypt/Swap encryption]].</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Mullvad&diff=627585Mullvad2020-07-31T21:03:39Z<p>Tobbebobbe: /* Using WireGuard */ formatting</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[es:Mullvad]]<br />
[[ja:Mullvad]]<br />
[https://mullvad.net/en/ Mullvad] is a VPN service based in Sweden which uses [[OpenVPN]] and [[WireGuard]].<br />
<br />
== Installation ==<br />
<br />
The new [https://mullvad.net/download/ official GUI client] is available as {{AUR|mullvad-vpn}}.<br />
<br />
After installation you will need to enable and start the [[systemd]] service {{ic|mullvad-daemon.service}}.<br />
<br />
Alternatively you can use the old client or either [[OpenVPN]] or [[WireGuard]] with a configuration file for Mullvad as explained in [[#Manual configuration]].<br />
<br />
== Manual configuration ==<br />
<br />
If you do not want to use the Mullvad app you can set it up manually with standard Linux software. Mullvad supports the [[OpenVPN]] and [[WireGuard]] protocols. Mullvad themselves [https://mullvad.net/en/help/why-wireguard/ advise] to use WireGuard. However, using OpenVpn may be preferable since for instance the Gnome gui can handle OpenVPN grafically, which makes it easy to see that the VPN is being used, or switching between VPN servers.<br />
<br />
No matter if you opt for OpenVPN or WireGuard, if you use [[NetworkManager]] you may want to set up [[dnsmasq]] to decrease DNS-lookup times and also decreasing risk of DNS leakages. Follow the steps under [[NetworkManager#DNS caching and conditional forwarding|DNS_caching_and_conditional_forwarding]].<br />
<br />
=== Using OpenVPN ===<br />
<br />
First make sure the packages {{Pkg|openvpn}} and {{Pkg|openresolv}} are installed, then proceed to download Mullvad's OpenVPN configuration file package from [https://www.mullvad.net/download/config/ their website] (under the "other platforms" tab) and unzip the downloaded file to {{ic|/etc/openvpn/client/}}. From here you can either use the [[GNOME]] gui for networking which uses [NetworkManager] and provides a neat interface, or you can use [[systemd]] to start it automatically at boot.<br />
<br />
==== Using The Gnome Network Gui ====<br />
<br />
Make sure the package {{Pkg|networkmanager-openvpn}} is installed. Then open the Gnome Settings, and select Network. Click on the "+" by the VPN section, and choose "Import from file". Choose the config file that you have downloaded from Mullvad. Note that you should download the files for Android, not the ones for Linux. Repeat this step for all of the servers you want to add. Now the VPN connections will show up in the roll down menu in the top right corner, below the primary network connections. At this point you manually have to flick the switch to connect to one of the servers. You may want to choose one of the VPN servers to connect to automatically when connected to the internet, using these steps in [[NetworkManager#Automatically connect to VPN]]<br />
<br />
==== Using systemd ====<br />
<br />
Rename {{ic|mullvad_linux.conf}} for a shorter name to be used with the [[systemd]] service later:<br />
<br />
# mv /etc/openvpn/client/mullvad_linux.conf /etc/openvpn/client/mullvad.conf<br />
<br />
In order to use the nameservers supplied by Mullvad, [[OpenVPN#The update-resolv-conf custom script|update-resolv-conf script]] is being called upon starting and stopping the connection with OpenVPN to modify [[resolv.conf]] to include the correct IP addresses. This script is also included in the Mullvad configuration zipfile, but should be moved to {{ic|/etc/openvpn/}} to match the path specified in the Mullvad configuration file:<br />
<br />
# mv /etc/openvpn/client/update-resolv-conf /etc/openvpn/<br />
<br />
The script can be kept updated with the [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script, which also contains a fix for DNS leaks.<br />
<br />
After configuration the VPN connection can be [[enabled|managed]] with {{ic|openvpn-client@mullvad.service}}. If the service fails to start with an error like {{ic|Cannot open TUN/TAP dev /dev/net/tun: No such device <nowiki>(errno=19)</nowiki>}}, you might need to reboot the system to enable OpenVPN creating the correct network device for the task.<br />
<br />
==== Enabling a Kill Switch ====<br />
<br />
To enable a Kill Switch function to prevent data leakage in case the VPN connection goes down, you can use [[iptables]] as explained in the [https://mullvad.net/en/help/linux-openvpn-installation/ Mullvad OpenVPN on Linux] page, under Enabling a Kill Switch.<br />
<br />
=== Using WireGuard ===<br />
<br />
[[Install]] the {{Pkg|wireguard-tools}} package. Log in to Mullvad with your account and then go to the [https://mullvad.net/en/account/#/wireguard-config/ Wireguard-config page]. Choose Linux as platform, then click generate key to generate a public key. In a terminal, issue the following command to generate a private key:<br />
<br />
# wg genkey<br />
<br />
Click on "Manage keys" on the Mullvad WireGuard config page, and insert the private key you just generated into the field that says "Enter private key", and click on "import key". Fill out step 3 on the website and download the file. Unzip the file you downloaded to get one or several config files depending on your selections in step 3. With these config files you can use the terminal interface of NetworkManager, nmcli.<br />
<br />
To add a WireGuard connection from a config-file, issue following command in terminal:<br />
<br />
# nmcli connection import type wireguard file ''configuration_file''<br />
<br />
If the file was called WG1.conf a connection called WG1 should have been added. <br />
<br />
If you at any point want to delete the connection, issue the command:<br />
<br />
# nmcli connection delete ''connection_name''<br />
<br />
To actually start the WireGuard tunnel, issue command:<br />
<br />
# nmcli connection up ''connection_name''<br />
<br />
Make sure the connection is listed when you run nmcli:<br />
<br />
# nmcli<br />
<br />
You might want to verify that the private and public keys are correct and corresponds with what you got from your VPN provider:<br />
<br />
# WG_HIDE_KEYS=never wg<br />
<br />
== DNS leaks ==<br />
<br />
By default, the Mullvad openvpn configurations allow DNS leaks and for usual VPN use cases this is an unfavorable privacy defect. Mullvad's new GUI client automatically stops DNS leaks by removing every DNS server IP from the system configuration and replacing them with an IP pointing out to Mullvad's own non-logging DNS server, valid during the VPN connection. This fix can also be applied with the plain OpenVPN method by configuring [[resolv.conf]] to use '''only''' the Mullvad DNS server IP specified on their [https://www.mullvad.net/guides/dns-leaks/ website].<br />
<br />
The resolv.conf update script version in [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] implements a different fix for the leaks by using the exclusive interface switch {{ic|-x}} when running the {{ic|resolvconf}} command, but this might cause another form of DNS leakage by making even every local network address resolve via the DNS server provided by Mullvad, as noted in the [https://github.com/masterkorp/openvpn-update-resolv-conf/issues/18 script's GitHub issue page].<br />
<br />
== See also ==<br />
* [https://github.com/mullvad/mullvadvpn-app Mullvad client source code]<br />
* [https://mullvad.net/en/faq/ Mullvad FAQ]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Mullvad&diff=627509Mullvad2020-07-31T19:08:38Z<p>Tobbebobbe: /* Using WireGuard */ Added step-by-step guide on setting up Wireguard with nmcli</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[es:Mullvad]]<br />
[[ja:Mullvad]]<br />
[https://mullvad.net/en/ Mullvad] is a VPN service based in Sweden which uses [[OpenVPN]] and [[WireGuard]].<br />
<br />
== Installation ==<br />
<br />
The new [https://mullvad.net/download/ official GUI client] is available as {{AUR|mullvad-vpn}}.<br />
<br />
After installation you will need to enable and start the [[systemd]] service {{ic|mullvad-daemon.service}}.<br />
<br />
Alternatively you can use the old client or either [[OpenVPN]] or [[WireGuard]] with a configuration file for Mullvad as explained in [[#Manual configuration]].<br />
<br />
== Manual configuration ==<br />
<br />
If you do not want to use the Mullvad app you can set it up manually with standard Linux software. Mullvad supports the [[OpenVPN]] and [[WireGuard]] protocols. Mullvad themselves [https://mullvad.net/en/help/why-wireguard/ advise] to use WireGuard. However, using OpenVpn may be preferable since for instance the Gnome gui can handle OpenVPN grafically, which makes it easy to see that the VPN is being used, or switching between VPN servers.<br />
<br />
No matter if you opt for OpenVPN or WireGuard, if you use [[NetworkManager]] you may want to set up [[dnsmasq]] to decrease DNS-lookup times and also decreasing risk of DNS leakages. Follow the steps under [[NetworkManager#DNS caching and conditional forwarding|DNS_caching_and_conditional_forwarding]].<br />
<br />
=== Using OpenVPN ===<br />
<br />
First make sure the packages {{Pkg|openvpn}} and {{Pkg|openresolv}} are installed, then proceed to download Mullvad's OpenVPN configuration file package from [https://www.mullvad.net/download/config/ their website] (under the "other platforms" tab) and unzip the downloaded file to {{ic|/etc/openvpn/client/}}. From here you can either use the [[GNOME]] gui for networking which uses [NetworkManager] and provides a neat interface, or you can use [[systemd]] to start it automatically at boot.<br />
<br />
==== Using The Gnome Network Gui ====<br />
<br />
Make sure the package {{Pkg|networkmanager-openvpn}} is installed. Then open the Gnome Settings, and select Network. Click on the "+" by the VPN section, and choose "Import from file". Choose the config file that you have downloaded from Mullvad. Note that you should download the files for Android, not the ones for Linux. Repeat this step for all of the servers you want to add. Now the VPN connections will show up in the roll down menu in the top right corner, below the primary network connections. At this point you manually have to flick the switch to connect to one of the servers. You may want to choose one of the VPN servers to connect to automatically when connected to the internet, using these steps in [[NetworkManager#Automatically connect to VPN]]<br />
<br />
==== Using systemd ====<br />
<br />
Rename {{ic|mullvad_linux.conf}} for a shorter name to be used with the [[systemd]] service later:<br />
<br />
# mv /etc/openvpn/client/mullvad_linux.conf /etc/openvpn/client/mullvad.conf<br />
<br />
In order to use the nameservers supplied by Mullvad, [[OpenVPN#The update-resolv-conf custom script|update-resolv-conf script]] is being called upon starting and stopping the connection with OpenVPN to modify [[resolv.conf]] to include the correct IP addresses. This script is also included in the Mullvad configuration zipfile, but should be moved to {{ic|/etc/openvpn/}} to match the path specified in the Mullvad configuration file:<br />
<br />
# mv /etc/openvpn/client/update-resolv-conf /etc/openvpn/<br />
<br />
The script can be kept updated with the [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script, which also contains a fix for DNS leaks.<br />
<br />
After configuration the VPN connection can be [[enabled|managed]] with {{ic|openvpn-client@mullvad.service}}. If the service fails to start with an error like {{ic|Cannot open TUN/TAP dev /dev/net/tun: No such device <nowiki>(errno=19)</nowiki>}}, you might need to reboot the system to enable OpenVPN creating the correct network device for the task.<br />
<br />
==== Enabling a Kill Switch ====<br />
<br />
To enable a Kill Switch function to prevent data leakage in case the VPN connection goes down, you can use [[iptables]] as explained in the [https://mullvad.net/en/help/linux-openvpn-installation/ Mullvad OpenVPN on Linux] page, under Enabling a Kill Switch.<br />
<br />
=== Using WireGuard ===<br />
<br />
[Install] the {{Pkg|wireguard-tools}} package. Log in to Mullvad with your account and then go to the [https://mullvad.net/en/account/#/wireguard-config/ Wireguard-config page]. Choose Linux as platform, then click generate key to generate a public key. In a terminal, issue the following command to generate a private key:<br />
<br />
# wg genkey<br />
<br />
Click on "Manage keys" on the Mullvad WireGuard config page, and insert the private key you just generated into the field that says "Enter private key", and click on "import key". Fill out step 3 on the website and download the file. Unzip the file you downloaded to get one or several config files depending on your selections in step 3. With these config files you can use the terminal interface of NetworkManager, nmcli.<br />
<br />
To add a WireGuard connection from a config-file, issue following command in terminal:<br />
<br />
# nmcli connection import type wireguard file ''configuration_file''<br />
<br />
If the file was called WG1.conf a connection called WG1 should have been added. <br />
<br />
If you at any point want to delete the connection, issue the command:<br />
<br />
# nmcli connection delete ''connection_name''<br />
<br />
To actually start the WireGuard tunnel, issue command:<br />
<br />
# nmcli connection up ''connection_name''<br />
<br />
Make sure the connection is listed when you run nmcli:<br />
<br />
# nmcli<br />
<br />
You might want to verify that the private and public keys are correct and corresponds with what you got from your VPN provider:<br />
<br />
# WG_HIDE_KEYS=never wg<br />
<br />
== DNS leaks ==<br />
<br />
By default, the Mullvad openvpn configurations allow DNS leaks and for usual VPN use cases this is an unfavorable privacy defect. Mullvad's new GUI client automatically stops DNS leaks by removing every DNS server IP from the system configuration and replacing them with an IP pointing out to Mullvad's own non-logging DNS server, valid during the VPN connection. This fix can also be applied with the plain OpenVPN method by configuring [[resolv.conf]] to use '''only''' the Mullvad DNS server IP specified on their [https://www.mullvad.net/guides/dns-leaks/ website].<br />
<br />
The resolv.conf update script version in [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] implements a different fix for the leaks by using the exclusive interface switch {{ic|-x}} when running the {{ic|resolvconf}} command, but this might cause another form of DNS leakage by making even every local network address resolve via the DNS server provided by Mullvad, as noted in the [https://github.com/masterkorp/openvpn-update-resolv-conf/issues/18 script's GitHub issue page].<br />
<br />
== See also ==<br />
* [https://github.com/mullvad/mullvadvpn-app Mullvad client source code]<br />
* [https://mullvad.net/en/faq/ Mullvad FAQ]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Mullvad&diff=627298Mullvad2020-07-31T05:50:18Z<p>Tobbebobbe: /* Manual configuration */ formatting</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[es:Mullvad]]<br />
[[ja:Mullvad]]<br />
[https://mullvad.net/en/ Mullvad] is a VPN service based in Sweden which uses [[OpenVPN]] and [[WireGuard]].<br />
<br />
== Installation ==<br />
<br />
The new [https://mullvad.net/download/ official GUI client] is available as {{AUR|mullvad-vpn}}.<br />
<br />
After installation you will need to enable and start the [[systemd]] service {{ic|mullvad-daemon.service}}.<br />
<br />
Alternatively you can use the old client or either [[OpenVPN]] or [[WireGuard]] with a configuration file for Mullvad as explained in [[#Manual configuration]].<br />
<br />
== Manual configuration ==<br />
<br />
If you do not want to use the Mullvad app you can set it up manually with standard Linux software. Mullvad supports the [[OpenVPN]] and [[WireGuard]] protocols. Mullvad themselves [https://mullvad.net/en/help/why-wireguard/ advise] to use WireGuard. However, using OpenVpn may be preferable since for instance the Gnome gui can handle OpenVPN grafically, which makes it easy to see that the VPN is being used, or switching between VPN servers.<br />
<br />
No matter if you opt for OpenVPN or WireGuard, if you use [[NetworkManager]] you may want to set up [[dnsmasq]] to decrease DNS-lookup times and also decreasing risk of DNS leakages. Follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#DNS_caching_and_conditional_forwarding DNS_caching_and_conditional_forwarding].<br />
<br />
=== Using OpenVPN ===<br />
<br />
First make sure the packages {{Pkg|openvpn}} and {{Pkg|openresolv}} are installed, then proceed to download Mullvad's OpenVPN configuration file package from [https://www.mullvad.net/download/config/ their website] (under the "other platforms" tab) and unzip the downloaded file to {{ic|/etc/openvpn/client/}}. From here you can either use the [[Gnome]] gui for networking which uses [NetworkManager] and provides a neat interface, or you can use [[systemd]] to start it automatically at boot.<br />
<br />
==== Using The Gnome Network Gui ====<br />
<br />
Make sure the package {{Pkg|networkmanager-openvpn}} is installed. Then open the Gnome Settings, and select Network. Click on the "+" by the VPN section, and choose "Import from file". Choose the config file that you have downloaded from Mullvad. Note that you should download the files for Android, not the ones for Linux. Repeat this step for all of the servers you want to add. Now the VPN connections will show up in the roll down menu in the top right corner, below the primary network connections. At this point you manually have to flick the switch to connect to one of the servers. You may want to choose one of the VPN servers to connect to automatically when connected to the internet, using these steps in [https://wiki.archlinux.org/index.php/NetworkManager#Automatically_connect_to_VPN NetworkManager#Automatically_connect_to_VPN]<br />
<br />
==== Using systemd ====<br />
<br />
Rename {{ic|mullvad_linux.conf}} for a shorter name to be used with the [[systemd]] service later:<br />
<br />
# mv /etc/openvpn/client/mullvad_linux.conf /etc/openvpn/client/mullvad.conf<br />
<br />
In order to use the nameservers supplied by Mullvad, [[OpenVPN#The update-resolv-conf custom script|update-resolv-conf script]] is being called upon starting and stopping the connection with OpenVPN to modify [[resolv.conf]] to include the correct IP addresses. This script is also included in the Mullvad configuration zipfile, but should be moved to {{ic|/etc/openvpn/}} to match the path specified in the Mullvad configuration file:<br />
<br />
# mv /etc/openvpn/client/update-resolv-conf /etc/openvpn/<br />
<br />
The script can be kept updated with the [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script, which also contains a fix for DNS leaks.<br />
<br />
After configuration the VPN connection can be [[enabled|managed]] with {{ic|openvpn-client@mullvad.service}}. If the service fails to start with an error like {{ic|Cannot open TUN/TAP dev /dev/net/tun: No such device <nowiki>(errno=19)</nowiki>}}, you might need to reboot the system to enable OpenVPN creating the correct network device for the task.<br />
<br />
==== Enabling a Kill Switch ====<br />
<br />
To enable a Kill Switch function to prevent data leakage in case the VPN connection goes down, you can use [[iptables]] as explained in the [https://mullvad.net/en/help/linux-openvpn-installation/ Mullvad OpenVPN on Linux] page, under Enabling a Kill Switch.<br />
<br />
=== Using WireGuard ===<br />
<br />
[Install] the {{Pkg|wireguard-tools}} package. Log in to Mullvad with your account and then go to the [https://mullvad.net/en/account/#/wireguard-config/ Wireguard-config page]. Choose Linux as platform, then click generate key to generate a public key. In a terminal, issue the following command to generate a private key:<br />
<br />
# wg genkey<br />
<br />
Click on "Manage keys" on the Mullvad WireGuard config page, and insert the private key you just generated into the field that says "Enter private key", and click on "import key". Fill out step 3 on the website and download the file. Unzip the file you downloaded to get one or several config files depending on your selections in step 3. With these config files you can follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#Set_up_VPN_with_WireGuard Set_up_VPN_with_WireGuard] in the [[NetworkManager]] wiki.<br />
<br />
== DNS leaks ==<br />
<br />
By default, the Mullvad openvpn configurations allow DNS leaks and for usual VPN use cases this is an unfavorable privacy defect. Mullvad's new GUI client automatically stops DNS leaks by removing every DNS server IP from the system configuration and replacing them with an IP pointing out to Mullvad's own non-logging DNS server, valid during the VPN connection. This fix can also be applied with the plain OpenVPN method by configuring [[resolv.conf]] to use '''only''' the Mullvad DNS server IP specified on their [https://www.mullvad.net/guides/dns-leaks/ website].<br />
<br />
The resolv.conf update script version in [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] implements a different fix for the leaks by using the exclusive interface switch {{ic|-x}} when running the {{ic|resolvconf}} command, but this might cause another form of DNS leakage by making even every local network address resolve via the DNS server provided by Mullvad, as noted in the [https://github.com/masterkorp/openvpn-update-resolv-conf/issues/18 script's GitHub issue page].<br />
<br />
== See also ==<br />
* [https://github.com/mullvad/mullvadvpn-app Mullvad client source code]<br />
* [https://mullvad.net/en/faq/ Mullvad FAQ]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Mullvad&diff=627240Mullvad2020-07-30T17:15:55Z<p>Tobbebobbe: /* Enabling a Kill Switch */ format</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[es:Mullvad]]<br />
[[ja:Mullvad]]<br />
[https://mullvad.net/en/ Mullvad] is a VPN service based in Sweden which uses [[OpenVPN]] and [[WireGuard]].<br />
<br />
== Installation ==<br />
<br />
The new [https://mullvad.net/download/ official GUI client] is available as {{AUR|mullvad-vpn}}.<br />
<br />
After installation you will need to enable and start the [[systemd]] service {{ic|mullvad-daemon.service}}.<br />
<br />
Alternatively you can use the old client or either [[OpenVPN]] or [[WireGuard]] with a configuration file for Mullvad as explained in [[#Manual configuration]].<br />
<br />
== Manual configuration ==<br />
<br />
If you do not want to use the Mullvad app you can set it up manually with standard Linux software. Mullvad supports the [OpenVPN] and [WireGuard] protocols. Mullvad themselves [https://mullvad.net/en/help/why-wireguard/ advise] to use WireGuard. However, using OpenVpn may be preferable since for instance the Gnome gui can handle OpenVPN grafically, which makes it easy to see that the VPN is being used, or switching between VPN servers.<br />
<br />
No matter if you opt for OpenVPN or WireGuard, if you use [[NetworkManager]] you may want to set up [[dnsmasq]] to decrease DNS-lookup times and also decreasing risk of DNS leakages. Follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#DNS_caching_and_conditional_forwarding DNS_caching_and_conditional_forwarding].<br />
<br />
=== Using OpenVPN ===<br />
<br />
First make sure the packages {{Pkg|openvpn}} and {{Pkg|openresolv}} are installed, then proceed to download Mullvad's OpenVPN configuration file package from [https://www.mullvad.net/download/config/ their website] (under the "other platforms" tab) and unzip the downloaded file to {{ic|/etc/openvpn/client/}}. From here you can either use the [[Gnome]] gui for networking which uses [NetworkManager] and provides a neat interface, or you can use [[systemd]] to start it automatically at boot.<br />
<br />
==== Using The Gnome Network Gui ====<br />
<br />
Make sure the package {{Pkg|networkmanager-openvpn}} is installed. Then open the Gnome Settings, and select Network. Click on the "+" by the VPN section, and choose "Import from file". Choose the config file that you have downloaded from Mullvad. Note that you should download the files for Android, not the ones for Linux. Repeat this step for all of the servers you want to add. Now the VPN connections will show up in the roll down menu in the top right corner, below the primary network connections. At this point you manually have to flick the switch to connect to one of the servers. You may want to choose one of the VPN servers to connect to automatically when connected to the internet, using these steps in [https://wiki.archlinux.org/index.php/NetworkManager#Automatically_connect_to_VPN NetworkManager#Automatically_connect_to_VPN]<br />
<br />
==== Using [[systemd]] ====<br />
<br />
Rename mullvad_linux.conf for a shorter name to be used with the [[systemd]] service later:<br />
<br />
# mv /etc/openvpn/client/mullvad_linux.conf /etc/openvpn/client/mullvad.conf<br />
<br />
In order to use the nameservers supplied by Mullvad, [[OpenVPN#Update resolv-conf script|update-resolv-conf script]]{{Broken section link}} is being called upon starting and stopping the connection with OpenVPN to modify [[resolv.conf]] to include the correct IP addresses. This script is also included in the Mullvad configuration zipfile, but should be moved to {{ic|/etc/openvpn/}} to match the path specified in the Mullvad configuration file:<br />
<br />
# mv /etc/openvpn/client/update-resolv-conf /etc/openvpn/<br />
<br />
The script can be kept updated with the [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script, which also contains a fix for DNS leaks.<br />
<br />
After configuration the VPN connection can be [[enabled|managed]] with {{ic|openvpn-client@mullvad.service}}. If the service fails to start with an error like {{ic|Cannot open TUN/TAP dev /dev/net/tun: No such device <nowiki>(errno=19)</nowiki>}}, you might need to reboot the system to enable OpenVPN creating the correct network device for the task.<br />
<br />
==== Enabling a Kill Switch ====<br />
<br />
To enable a Kill Switch function to prevent data leakage in case the VPN connection goes down, you can use [[iptables]] as explained in the [https://mullvad.net/en/help/linux-openvpn-installation/ Mullvad OpenVPN on Linux] page, under Enabling a Kill Switch.<br />
<br />
=== Using WireGuard ===<br />
<br />
[Install] the {{Pkg|wireguard-tools}} package. Log in to Mullvad with your account and then go to the [https://mullvad.net/en/account/#/wireguard-config/ Wireguard-config page]. Choose Linux as platform, then click generate key to generate a public key. In a terminal, issue the following command to generate a private key:<br />
<br />
# wg genkey<br />
<br />
Click on "Manage keys" on the Mullvad WireGuard config page, and insert the private key you just generated into the field that says "Enter private key", and click on "import key". Fill out step 3 on the website and download the file. Unzip the file you downloaded to get one or several config files depending on your selections in step 3. With these config files you can follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#Set_up_VPN_with_WireGuard Set_up_VPN_with_WireGuard] in the [[NetworkManager]] wiki.<br />
<br />
== DNS leaks ==<br />
<br />
By default, the Mullvad openvpn configurations allow DNS leaks and for usual VPN use cases this is an unfavorable privacy defect. Mullvad's new GUI client automatically stops DNS leaks by removing every DNS server IP from the system configuration and replacing them with an IP pointing out to Mullvad's own non-logging DNS server, valid during the VPN connection. This fix can also be applied with the plain OpenVPN method by configuring [[resolv.conf]] to use '''only''' the Mullvad DNS server IP specified on their [https://www.mullvad.net/guides/dns-leaks/ website].<br />
<br />
The resolv.conf update script version in [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] implements a different fix for the leaks by using the exclusive interface switch {{ic|-x}} when running the {{ic|resolvconf}} command, but this might cause another form of DNS leakage by making even every local network address resolve via the DNS server provided by Mullvad, as noted in the [https://github.com/masterkorp/openvpn-update-resolv-conf/issues/18 script's GitHub issue page].<br />
<br />
== See also ==<br />
* [https://github.com/mullvad/mullvadvpn-app Mullvad client source code]<br />
* [https://mullvad.net/en/faq/ Mullvad FAQ]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Mullvad&diff=627239Mullvad2020-07-30T17:15:19Z<p>Tobbebobbe: /* Using OpenVPN */ added information on Kill Switch</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[es:Mullvad]]<br />
[[ja:Mullvad]]<br />
[https://mullvad.net/en/ Mullvad] is a VPN service based in Sweden which uses [[OpenVPN]] and [[WireGuard]].<br />
<br />
== Installation ==<br />
<br />
The new [https://mullvad.net/download/ official GUI client] is available as {{AUR|mullvad-vpn}}.<br />
<br />
After installation you will need to enable and start the [[systemd]] service {{ic|mullvad-daemon.service}}.<br />
<br />
Alternatively you can use the old client or either [[OpenVPN]] or [[WireGuard]] with a configuration file for Mullvad as explained in [[#Manual configuration]].<br />
<br />
== Manual configuration ==<br />
<br />
If you do not want to use the Mullvad app you can set it up manually with standard Linux software. Mullvad supports the [OpenVPN] and [WireGuard] protocols. Mullvad themselves [https://mullvad.net/en/help/why-wireguard/ advise] to use WireGuard. However, using OpenVpn may be preferable since for instance the Gnome gui can handle OpenVPN grafically, which makes it easy to see that the VPN is being used, or switching between VPN servers.<br />
<br />
No matter if you opt for OpenVPN or WireGuard, if you use [[NetworkManager]] you may want to set up [[dnsmasq]] to decrease DNS-lookup times and also decreasing risk of DNS leakages. Follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#DNS_caching_and_conditional_forwarding DNS_caching_and_conditional_forwarding].<br />
<br />
=== Using OpenVPN ===<br />
<br />
First make sure the packages {{Pkg|openvpn}} and {{Pkg|openresolv}} are installed, then proceed to download Mullvad's OpenVPN configuration file package from [https://www.mullvad.net/download/config/ their website] (under the "other platforms" tab) and unzip the downloaded file to {{ic|/etc/openvpn/client/}}. From here you can either use the [[Gnome]] gui for networking which uses [NetworkManager] and provides a neat interface, or you can use [[systemd]] to start it automatically at boot.<br />
<br />
==== Using The Gnome Network Gui ====<br />
<br />
Make sure the package {{Pkg|networkmanager-openvpn}} is installed. Then open the Gnome Settings, and select Network. Click on the "+" by the VPN section, and choose "Import from file". Choose the config file that you have downloaded from Mullvad. Note that you should download the files for Android, not the ones for Linux. Repeat this step for all of the servers you want to add. Now the VPN connections will show up in the roll down menu in the top right corner, below the primary network connections. At this point you manually have to flick the switch to connect to one of the servers. You may want to choose one of the VPN servers to connect to automatically when connected to the internet, using these steps in [https://wiki.archlinux.org/index.php/NetworkManager#Automatically_connect_to_VPN NetworkManager#Automatically_connect_to_VPN]<br />
<br />
==== Using [[systemd]] ====<br />
<br />
Rename mullvad_linux.conf for a shorter name to be used with the [[systemd]] service later:<br />
<br />
# mv /etc/openvpn/client/mullvad_linux.conf /etc/openvpn/client/mullvad.conf<br />
<br />
In order to use the nameservers supplied by Mullvad, [[OpenVPN#Update resolv-conf script|update-resolv-conf script]]{{Broken section link}} is being called upon starting and stopping the connection with OpenVPN to modify [[resolv.conf]] to include the correct IP addresses. This script is also included in the Mullvad configuration zipfile, but should be moved to {{ic|/etc/openvpn/}} to match the path specified in the Mullvad configuration file:<br />
<br />
# mv /etc/openvpn/client/update-resolv-conf /etc/openvpn/<br />
<br />
The script can be kept updated with the [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script, which also contains a fix for DNS leaks.<br />
<br />
After configuration the VPN connection can be [[enabled|managed]] with {{ic|openvpn-client@mullvad.service}}. If the service fails to start with an error like {{ic|Cannot open TUN/TAP dev /dev/net/tun: No such device <nowiki>(errno=19)</nowiki>}}, you might need to reboot the system to enable OpenVPN creating the correct network device for the task.<br />
<br />
==== Enabling a Kill Switch ====<br />
<br />
To enable a Kill Switch function to prevent data leakage in case the VPN connection goes down, you can use [[IPtables]] as explained in the [https://mullvad.net/en/help/linux-openvpn-installation/ Mullvad OpenVPN on Linux] page, under Enabling a Kill Switch.<br />
<br />
=== Using WireGuard ===<br />
<br />
[Install] the {{Pkg|wireguard-tools}} package. Log in to Mullvad with your account and then go to the [https://mullvad.net/en/account/#/wireguard-config/ Wireguard-config page]. Choose Linux as platform, then click generate key to generate a public key. In a terminal, issue the following command to generate a private key:<br />
<br />
# wg genkey<br />
<br />
Click on "Manage keys" on the Mullvad WireGuard config page, and insert the private key you just generated into the field that says "Enter private key", and click on "import key". Fill out step 3 on the website and download the file. Unzip the file you downloaded to get one or several config files depending on your selections in step 3. With these config files you can follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#Set_up_VPN_with_WireGuard Set_up_VPN_with_WireGuard] in the [[NetworkManager]] wiki.<br />
<br />
== DNS leaks ==<br />
<br />
By default, the Mullvad openvpn configurations allow DNS leaks and for usual VPN use cases this is an unfavorable privacy defect. Mullvad's new GUI client automatically stops DNS leaks by removing every DNS server IP from the system configuration and replacing them with an IP pointing out to Mullvad's own non-logging DNS server, valid during the VPN connection. This fix can also be applied with the plain OpenVPN method by configuring [[resolv.conf]] to use '''only''' the Mullvad DNS server IP specified on their [https://www.mullvad.net/guides/dns-leaks/ website].<br />
<br />
The resolv.conf update script version in [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] implements a different fix for the leaks by using the exclusive interface switch {{ic|-x}} when running the {{ic|resolvconf}} command, but this might cause another form of DNS leakage by making even every local network address resolve via the DNS server provided by Mullvad, as noted in the [https://github.com/masterkorp/openvpn-update-resolv-conf/issues/18 script's GitHub issue page].<br />
<br />
== See also ==<br />
* [https://github.com/mullvad/mullvadvpn-app Mullvad client source code]<br />
* [https://mullvad.net/en/faq/ Mullvad FAQ]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Mullvad&diff=627237Mullvad2020-07-30T16:58:23Z<p>Tobbebobbe: /* Manual configuration */ formatting</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[es:Mullvad]]<br />
[[ja:Mullvad]]<br />
[https://mullvad.net/en/ Mullvad] is a VPN service based in Sweden which uses [[OpenVPN]] and [[WireGuard]].<br />
<br />
== Installation ==<br />
<br />
The new [https://mullvad.net/download/ official GUI client] is available as {{AUR|mullvad-vpn}}.<br />
<br />
After installation you will need to enable and start the [[systemd]] service {{ic|mullvad-daemon.service}}.<br />
<br />
Alternatively you can use the old client or either [[OpenVPN]] or [[WireGuard]] with a configuration file for Mullvad as explained in [[#Manual configuration]].<br />
<br />
== Manual configuration ==<br />
<br />
If you do not want to use the Mullvad app you can set it up manually with standard Linux software. Mullvad supports the [OpenVPN] and [WireGuard] protocols. Mullvad themselves [https://mullvad.net/en/help/why-wireguard/ advise] to use WireGuard. However, using OpenVpn may be preferable since for instance the Gnome gui can handle OpenVPN grafically, which makes it easy to see that the VPN is being used, or switching between VPN servers.<br />
<br />
No matter if you opt for OpenVPN or WireGuard, if you use [[NetworkManager]] you may want to set up [[dnsmasq]] to decrease DNS-lookup times and also decreasing risk of DNS leakages. Follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#DNS_caching_and_conditional_forwarding DNS_caching_and_conditional_forwarding].<br />
<br />
=== Using OpenVPN ===<br />
<br />
First make sure the packages {{Pkg|openvpn}} and {{Pkg|openresolv}} are installed, then proceed to download Mullvad's OpenVPN configuration file package from [https://www.mullvad.net/download/config/ their website] (under the "other platforms" tab) and unzip the downloaded file to {{ic|/etc/openvpn/client/}}. From here you can either use the [[Gnome]] gui for networking which uses [NetworkManager] and provides a neat interface, or you can use [[systemd]] to start it automatically at boot.<br />
<br />
==== Using The Gnome Network Gui ====<br />
<br />
Make sure the package {{Pkg|networkmanager-openvpn}} is installed. Then open the Gnome Settings, and select Network. Click on the "+" by the VPN section, and choose "Import from file". Choose the config file that you have downloaded from Mullvad. Note that you should download the files for Android, not the ones for Linux. Repeat this step for all of the servers you want to add. Now the VPN connections will show up in the roll down menu in the top right corner, below the primary network connections. At this point you manually have to flick the switch to connect to one of the servers. You may want to choose one of the VPN servers to connect to automatically when connected to the internet, using these steps in [https://wiki.archlinux.org/index.php/NetworkManager#Automatically_connect_to_VPN NetworkManager#Automatically_connect_to_VPN]<br />
<br />
==== Using [[systemd]] ====<br />
<br />
Rename mullvad_linux.conf for a shorter name to be used with the [[systemd]] service later:<br />
<br />
# mv /etc/openvpn/client/mullvad_linux.conf /etc/openvpn/client/mullvad.conf<br />
<br />
In order to use the nameservers supplied by Mullvad, [[OpenVPN#Update resolv-conf script|update-resolv-conf script]]{{Broken section link}} is being called upon starting and stopping the connection with OpenVPN to modify [[resolv.conf]] to include the correct IP addresses. This script is also included in the Mullvad configuration zipfile, but should be moved to {{ic|/etc/openvpn/}} to match the path specified in the Mullvad configuration file:<br />
<br />
# mv /etc/openvpn/client/update-resolv-conf /etc/openvpn/<br />
<br />
The script can be kept updated with the [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script, which also contains a fix for DNS leaks.<br />
<br />
After configuration the VPN connection can be [[enabled|managed]] with {{ic|openvpn-client@mullvad.service}}. If the service fails to start with an error like {{ic|Cannot open TUN/TAP dev /dev/net/tun: No such device <nowiki>(errno=19)</nowiki>}}, you might need to reboot the system to enable OpenVPN creating the correct network device for the task.<br />
<br />
=== Using WireGuard ===<br />
<br />
[Install] the {{Pkg|wireguard-tools}} package. Log in to Mullvad with your account and then go to the [https://mullvad.net/en/account/#/wireguard-config/ Wireguard-config page]. Choose Linux as platform, then click generate key to generate a public key. In a terminal, issue the following command to generate a private key:<br />
<br />
# wg genkey<br />
<br />
Click on "Manage keys" on the Mullvad WireGuard config page, and insert the private key you just generated into the field that says "Enter private key", and click on "import key". Fill out step 3 on the website and download the file. Unzip the file you downloaded to get one or several config files depending on your selections in step 3. With these config files you can follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#Set_up_VPN_with_WireGuard Set_up_VPN_with_WireGuard] in the [[NetworkManager]] wiki.<br />
<br />
== DNS leaks ==<br />
<br />
By default, the Mullvad openvpn configurations allow DNS leaks and for usual VPN use cases this is an unfavorable privacy defect. Mullvad's new GUI client automatically stops DNS leaks by removing every DNS server IP from the system configuration and replacing them with an IP pointing out to Mullvad's own non-logging DNS server, valid during the VPN connection. This fix can also be applied with the plain OpenVPN method by configuring [[resolv.conf]] to use '''only''' the Mullvad DNS server IP specified on their [https://www.mullvad.net/guides/dns-leaks/ website].<br />
<br />
The resolv.conf update script version in [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] implements a different fix for the leaks by using the exclusive interface switch {{ic|-x}} when running the {{ic|resolvconf}} command, but this might cause another form of DNS leakage by making even every local network address resolve via the DNS server provided by Mullvad, as noted in the [https://github.com/masterkorp/openvpn-update-resolv-conf/issues/18 script's GitHub issue page].<br />
<br />
== See also ==<br />
* [https://github.com/mullvad/mullvadvpn-app Mullvad client source code]<br />
* [https://mullvad.net/en/faq/ Mullvad FAQ]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Mullvad&diff=627236Mullvad2020-07-30T16:57:57Z<p>Tobbebobbe: /* Manual configuration */ formatting</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[es:Mullvad]]<br />
[[ja:Mullvad]]<br />
[https://mullvad.net/en/ Mullvad] is a VPN service based in Sweden which uses [[OpenVPN]] and [[WireGuard]].<br />
<br />
== Installation ==<br />
<br />
The new [https://mullvad.net/download/ official GUI client] is available as {{AUR|mullvad-vpn}}.<br />
<br />
After installation you will need to enable and start the [[systemd]] service {{ic|mullvad-daemon.service}}.<br />
<br />
Alternatively you can use the old client or either [[OpenVPN]] or [[WireGuard]] with a configuration file for Mullvad as explained in [[#Manual configuration]].<br />
<br />
== Manual configuration ==<br />
<br />
If you do not want to use the Mullvad app you can set it up manually with standard Linux software. Mullvad supports the [OpenVPN] and [WireGuard] protocols. Mullvad themselves [https://mullvad.net/en/help/why-wireguard/ advise] to use WireGuard. However, using OpenVpn may be preferable since for instance the Gnome gui can handle OpenVPN grafically, which makes it easy to see that the VPN is being used, or switching between VPN servers.<br />
<br />
No matter if you opt for OpenVPN or WireGuard, if you use [[NetworkManager]] you may want to set up [dnsmasq] to decrease DNS-lookup times and also decreasing risk of DNS leakages. Follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#DNS_caching_and_conditional_forwarding DNS_caching_and_conditional_forwarding].<br />
<br />
=== Using OpenVPN ===<br />
<br />
First make sure the packages {{Pkg|openvpn}} and {{Pkg|openresolv}} are installed, then proceed to download Mullvad's OpenVPN configuration file package from [https://www.mullvad.net/download/config/ their website] (under the "other platforms" tab) and unzip the downloaded file to {{ic|/etc/openvpn/client/}}. From here you can either use the [[Gnome]] gui for networking which uses [NetworkManager] and provides a neat interface, or you can use [[systemd]] to start it automatically at boot.<br />
<br />
==== Using The Gnome Network Gui ====<br />
<br />
Make sure the package {{Pkg|networkmanager-openvpn}} is installed. Then open the Gnome Settings, and select Network. Click on the "+" by the VPN section, and choose "Import from file". Choose the config file that you have downloaded from Mullvad. Note that you should download the files for Android, not the ones for Linux. Repeat this step for all of the servers you want to add. Now the VPN connections will show up in the roll down menu in the top right corner, below the primary network connections. At this point you manually have to flick the switch to connect to one of the servers. You may want to choose one of the VPN servers to connect to automatically when connected to the internet, using these steps in [https://wiki.archlinux.org/index.php/NetworkManager#Automatically_connect_to_VPN NetworkManager#Automatically_connect_to_VPN]<br />
<br />
==== Using [[systemd]] ====<br />
<br />
Rename mullvad_linux.conf for a shorter name to be used with the [[systemd]] service later:<br />
<br />
# mv /etc/openvpn/client/mullvad_linux.conf /etc/openvpn/client/mullvad.conf<br />
<br />
In order to use the nameservers supplied by Mullvad, [[OpenVPN#Update resolv-conf script|update-resolv-conf script]]{{Broken section link}} is being called upon starting and stopping the connection with OpenVPN to modify [[resolv.conf]] to include the correct IP addresses. This script is also included in the Mullvad configuration zipfile, but should be moved to {{ic|/etc/openvpn/}} to match the path specified in the Mullvad configuration file:<br />
<br />
# mv /etc/openvpn/client/update-resolv-conf /etc/openvpn/<br />
<br />
The script can be kept updated with the [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script, which also contains a fix for DNS leaks.<br />
<br />
After configuration the VPN connection can be [[enabled|managed]] with {{ic|openvpn-client@mullvad.service}}. If the service fails to start with an error like {{ic|Cannot open TUN/TAP dev /dev/net/tun: No such device <nowiki>(errno=19)</nowiki>}}, you might need to reboot the system to enable OpenVPN creating the correct network device for the task.<br />
<br />
=== Using WireGuard ===<br />
<br />
[Install] the {{Pkg|wireguard-tools}} package. Log in to Mullvad with your account and then go to the [https://mullvad.net/en/account/#/wireguard-config/ Wireguard-config page]. Choose Linux as platform, then click generate key to generate a public key. In a terminal, issue the following command to generate a private key:<br />
<br />
# wg genkey<br />
<br />
Click on "Manage keys" on the Mullvad WireGuard config page, and insert the private key you just generated into the field that says "Enter private key", and click on "import key". Fill out step 3 on the website and download the file. Unzip the file you downloaded to get one or several config files depending on your selections in step 3. With these config files you can follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#Set_up_VPN_with_WireGuard Set_up_VPN_with_WireGuard] in the [[NetworkManager]] wiki.<br />
<br />
== DNS leaks ==<br />
<br />
By default, the Mullvad openvpn configurations allow DNS leaks and for usual VPN use cases this is an unfavorable privacy defect. Mullvad's new GUI client automatically stops DNS leaks by removing every DNS server IP from the system configuration and replacing them with an IP pointing out to Mullvad's own non-logging DNS server, valid during the VPN connection. This fix can also be applied with the plain OpenVPN method by configuring [[resolv.conf]] to use '''only''' the Mullvad DNS server IP specified on their [https://www.mullvad.net/guides/dns-leaks/ website].<br />
<br />
The resolv.conf update script version in [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] implements a different fix for the leaks by using the exclusive interface switch {{ic|-x}} when running the {{ic|resolvconf}} command, but this might cause another form of DNS leakage by making even every local network address resolve via the DNS server provided by Mullvad, as noted in the [https://github.com/masterkorp/openvpn-update-resolv-conf/issues/18 script's GitHub issue page].<br />
<br />
== See also ==<br />
* [https://github.com/mullvad/mullvadvpn-app Mullvad client source code]<br />
* [https://mullvad.net/en/faq/ Mullvad FAQ]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Mullvad&diff=627235Mullvad2020-07-30T16:56:48Z<p>Tobbebobbe: /* Using The Gnome Network Gui */ specified that it is the android config files that should be used, not linux</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[es:Mullvad]]<br />
[[ja:Mullvad]]<br />
[https://mullvad.net/en/ Mullvad] is a VPN service based in Sweden which uses [[OpenVPN]] and [[WireGuard]].<br />
<br />
== Installation ==<br />
<br />
The new [https://mullvad.net/download/ official GUI client] is available as {{AUR|mullvad-vpn}}.<br />
<br />
After installation you will need to enable and start the [[systemd]] service {{ic|mullvad-daemon.service}}.<br />
<br />
Alternatively you can use the old client or either [[OpenVPN]] or [[WireGuard]] with a configuration file for Mullvad as explained in [[#Manual configuration]].<br />
<br />
== Manual configuration ==<br />
<br />
If you do not want to use the Mullvad app you can set it up manually with standard Linux software. Mullvad supports the [OpenVPN] and [WireGuard] protocols. Mullvad themselves [https://mullvad.net/en/help/why-wireguard/ advise] to use WireGuard. However, using OpenVpn may be preferable since for instance the Gnome gui can handle OpenVPN grafically, which makes it easy to see that the VPN is being used, or switching between VPN servers.<br />
<br />
No matter if you opt for OpenVPN or WireGuard, if you use [NetworkManager] you may want to set up [dnsmasq] to decrease DNS-lookup times and also decreasing risk of DNS leakages. Follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#DNS_caching_and_conditional_forwarding DNS_caching_and_conditional_forwarding].<br />
<br />
=== Using OpenVPN ===<br />
<br />
First make sure the packages {{Pkg|openvpn}} and {{Pkg|openresolv}} are installed, then proceed to download Mullvad's OpenVPN configuration file package from [https://www.mullvad.net/download/config/ their website] (under the "other platforms" tab) and unzip the downloaded file to {{ic|/etc/openvpn/client/}}. From here you can either use the [[Gnome]] gui for networking which uses [NetworkManager] and provides a neat interface, or you can use [[systemd]] to start it automatically at boot.<br />
<br />
==== Using The Gnome Network Gui ====<br />
<br />
Make sure the package {{Pkg|networkmanager-openvpn}} is installed. Then open the Gnome Settings, and select Network. Click on the "+" by the VPN section, and choose "Import from file". Choose the config file that you have downloaded from Mullvad. Note that you should download the files for Android, not the ones for Linux. Repeat this step for all of the servers you want to add. Now the VPN connections will show up in the roll down menu in the top right corner, below the primary network connections. At this point you manually have to flick the switch to connect to one of the servers. You may want to choose one of the VPN servers to connect to automatically when connected to the internet, using these steps in [https://wiki.archlinux.org/index.php/NetworkManager#Automatically_connect_to_VPN NetworkManager#Automatically_connect_to_VPN]<br />
<br />
==== Using [[systemd]] ====<br />
<br />
Rename mullvad_linux.conf for a shorter name to be used with the [[systemd]] service later:<br />
<br />
# mv /etc/openvpn/client/mullvad_linux.conf /etc/openvpn/client/mullvad.conf<br />
<br />
In order to use the nameservers supplied by Mullvad, [[OpenVPN#Update resolv-conf script|update-resolv-conf script]]{{Broken section link}} is being called upon starting and stopping the connection with OpenVPN to modify [[resolv.conf]] to include the correct IP addresses. This script is also included in the Mullvad configuration zipfile, but should be moved to {{ic|/etc/openvpn/}} to match the path specified in the Mullvad configuration file:<br />
<br />
# mv /etc/openvpn/client/update-resolv-conf /etc/openvpn/<br />
<br />
The script can be kept updated with the [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script, which also contains a fix for DNS leaks.<br />
<br />
After configuration the VPN connection can be [[enabled|managed]] with {{ic|openvpn-client@mullvad.service}}. If the service fails to start with an error like {{ic|Cannot open TUN/TAP dev /dev/net/tun: No such device <nowiki>(errno=19)</nowiki>}}, you might need to reboot the system to enable OpenVPN creating the correct network device for the task.<br />
<br />
=== Using WireGuard ===<br />
<br />
[Install] the {{Pkg|wireguard-tools}} package. Log in to Mullvad with your account and then go to the [https://mullvad.net/en/account/#/wireguard-config/ Wireguard-config page]. Choose Linux as platform, then click generate key to generate a public key. In a terminal, issue the following command to generate a private key:<br />
<br />
# wg genkey<br />
<br />
Click on "Manage keys" on the Mullvad WireGuard config page, and insert the private key you just generated into the field that says "Enter private key", and click on "import key". Fill out step 3 on the website and download the file. Unzip the file you downloaded to get one or several config files depending on your selections in step 3. With these config files you can follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#Set_up_VPN_with_WireGuard Set_up_VPN_with_WireGuard] in the [[NetworkManager]] wiki.<br />
<br />
== DNS leaks ==<br />
<br />
By default, the Mullvad openvpn configurations allow DNS leaks and for usual VPN use cases this is an unfavorable privacy defect. Mullvad's new GUI client automatically stops DNS leaks by removing every DNS server IP from the system configuration and replacing them with an IP pointing out to Mullvad's own non-logging DNS server, valid during the VPN connection. This fix can also be applied with the plain OpenVPN method by configuring [[resolv.conf]] to use '''only''' the Mullvad DNS server IP specified on their [https://www.mullvad.net/guides/dns-leaks/ website].<br />
<br />
The resolv.conf update script version in [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] implements a different fix for the leaks by using the exclusive interface switch {{ic|-x}} when running the {{ic|resolvconf}} command, but this might cause another form of DNS leakage by making even every local network address resolve via the DNS server provided by Mullvad, as noted in the [https://github.com/masterkorp/openvpn-update-resolv-conf/issues/18 script's GitHub issue page].<br />
<br />
== See also ==<br />
* [https://github.com/mullvad/mullvadvpn-app Mullvad client source code]<br />
* [https://mullvad.net/en/faq/ Mullvad FAQ]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Mullvad&diff=627234Mullvad2020-07-30T16:54:58Z<p>Tobbebobbe: /* Using OpenVPN */ specified networkmanager-openvpn as a dependecy</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[es:Mullvad]]<br />
[[ja:Mullvad]]<br />
[https://mullvad.net/en/ Mullvad] is a VPN service based in Sweden which uses [[OpenVPN]] and [[WireGuard]].<br />
<br />
== Installation ==<br />
<br />
The new [https://mullvad.net/download/ official GUI client] is available as {{AUR|mullvad-vpn}}.<br />
<br />
After installation you will need to enable and start the [[systemd]] service {{ic|mullvad-daemon.service}}.<br />
<br />
Alternatively you can use the old client or either [[OpenVPN]] or [[WireGuard]] with a configuration file for Mullvad as explained in [[#Manual configuration]].<br />
<br />
== Manual configuration ==<br />
<br />
If you do not want to use the Mullvad app you can set it up manually with standard Linux software. Mullvad supports the [OpenVPN] and [WireGuard] protocols. Mullvad themselves [https://mullvad.net/en/help/why-wireguard/ advise] to use WireGuard. However, using OpenVpn may be preferable since for instance the Gnome gui can handle OpenVPN grafically, which makes it easy to see that the VPN is being used, or switching between VPN servers.<br />
<br />
No matter if you opt for OpenVPN or WireGuard, if you use [NetworkManager] you may want to set up [dnsmasq] to decrease DNS-lookup times and also decreasing risk of DNS leakages. Follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#DNS_caching_and_conditional_forwarding DNS_caching_and_conditional_forwarding].<br />
<br />
=== Using OpenVPN ===<br />
<br />
First make sure the packages {{Pkg|openvpn}} and {{Pkg|openresolv}} are installed, then proceed to download Mullvad's OpenVPN configuration file package from [https://www.mullvad.net/download/config/ their website] (under the "other platforms" tab) and unzip the downloaded file to {{ic|/etc/openvpn/client/}}. From here you can either use the [[Gnome]] gui for networking which uses [NetworkManager] and provides a neat interface, or you can use [[systemd]] to start it automatically at boot.<br />
<br />
==== Using The Gnome Network Gui ====<br />
<br />
Make sure the package {{Pkg|networkmanager-openvpn}} is installed. Then open the Gnome Settings, and select Network. Click on the "+" by the VPN section, and choose "Import from file". Choose the config file that you have downloaded from Mullvad. Repeat this step for all of the servers you want to add. Now the VPN connections will show up in the roll down menu in the top right corner, below the primary network connections. At this point you manually have to flick the switch to connect to one of the servers. You may want to choose one of the VPN servers to connect to automatically when connected to the internet, using these steps in [https://wiki.archlinux.org/index.php/NetworkManager#Automatically_connect_to_VPN NetworkManager#Automatically_connect_to_VPN]<br />
<br />
==== Using [[systemd]] ====<br />
<br />
Rename mullvad_linux.conf for a shorter name to be used with the [[systemd]] service later:<br />
<br />
# mv /etc/openvpn/client/mullvad_linux.conf /etc/openvpn/client/mullvad.conf<br />
<br />
In order to use the nameservers supplied by Mullvad, [[OpenVPN#Update resolv-conf script|update-resolv-conf script]]{{Broken section link}} is being called upon starting and stopping the connection with OpenVPN to modify [[resolv.conf]] to include the correct IP addresses. This script is also included in the Mullvad configuration zipfile, but should be moved to {{ic|/etc/openvpn/}} to match the path specified in the Mullvad configuration file:<br />
<br />
# mv /etc/openvpn/client/update-resolv-conf /etc/openvpn/<br />
<br />
The script can be kept updated with the [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script, which also contains a fix for DNS leaks.<br />
<br />
After configuration the VPN connection can be [[enabled|managed]] with {{ic|openvpn-client@mullvad.service}}. If the service fails to start with an error like {{ic|Cannot open TUN/TAP dev /dev/net/tun: No such device <nowiki>(errno=19)</nowiki>}}, you might need to reboot the system to enable OpenVPN creating the correct network device for the task.<br />
<br />
=== Using WireGuard ===<br />
<br />
[Install] the {{Pkg|wireguard-tools}} package. Log in to Mullvad with your account and then go to the [https://mullvad.net/en/account/#/wireguard-config/ Wireguard-config page]. Choose Linux as platform, then click generate key to generate a public key. In a terminal, issue the following command to generate a private key:<br />
<br />
# wg genkey<br />
<br />
Click on "Manage keys" on the Mullvad WireGuard config page, and insert the private key you just generated into the field that says "Enter private key", and click on "import key". Fill out step 3 on the website and download the file. Unzip the file you downloaded to get one or several config files depending on your selections in step 3. With these config files you can follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#Set_up_VPN_with_WireGuard Set_up_VPN_with_WireGuard] in the [[NetworkManager]] wiki.<br />
<br />
== DNS leaks ==<br />
<br />
By default, the Mullvad openvpn configurations allow DNS leaks and for usual VPN use cases this is an unfavorable privacy defect. Mullvad's new GUI client automatically stops DNS leaks by removing every DNS server IP from the system configuration and replacing them with an IP pointing out to Mullvad's own non-logging DNS server, valid during the VPN connection. This fix can also be applied with the plain OpenVPN method by configuring [[resolv.conf]] to use '''only''' the Mullvad DNS server IP specified on their [https://www.mullvad.net/guides/dns-leaks/ website].<br />
<br />
The resolv.conf update script version in [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] implements a different fix for the leaks by using the exclusive interface switch {{ic|-x}} when running the {{ic|resolvconf}} command, but this might cause another form of DNS leakage by making even every local network address resolve via the DNS server provided by Mullvad, as noted in the [https://github.com/masterkorp/openvpn-update-resolv-conf/issues/18 script's GitHub issue page].<br />
<br />
== See also ==<br />
* [https://github.com/mullvad/mullvadvpn-app Mullvad client source code]<br />
* [https://mullvad.net/en/faq/ Mullvad FAQ]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Mullvad&diff=627233Mullvad2020-07-30T16:52:52Z<p>Tobbebobbe: /* Using The Gnome Network Gui */ formatting</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[es:Mullvad]]<br />
[[ja:Mullvad]]<br />
[https://mullvad.net/en/ Mullvad] is a VPN service based in Sweden which uses [[OpenVPN]] and [[WireGuard]].<br />
<br />
== Installation ==<br />
<br />
The new [https://mullvad.net/download/ official GUI client] is available as {{AUR|mullvad-vpn}}.<br />
<br />
After installation you will need to enable and start the [[systemd]] service {{ic|mullvad-daemon.service}}.<br />
<br />
Alternatively you can use the old client or either [[OpenVPN]] or [[WireGuard]] with a configuration file for Mullvad as explained in [[#Manual configuration]].<br />
<br />
== Manual configuration ==<br />
<br />
If you do not want to use the Mullvad app you can set it up manually with standard Linux software. Mullvad supports the [OpenVPN] and [WireGuard] protocols. Mullvad themselves [https://mullvad.net/en/help/why-wireguard/ advise] to use WireGuard. However, using OpenVpn may be preferable since for instance the Gnome gui can handle OpenVPN grafically, which makes it easy to see that the VPN is being used, or switching between VPN servers.<br />
<br />
No matter if you opt for OpenVPN or WireGuard, if you use [NetworkManager] you may want to set up [dnsmasq] to decrease DNS-lookup times and also decreasing risk of DNS leakages. Follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#DNS_caching_and_conditional_forwarding DNS_caching_and_conditional_forwarding].<br />
<br />
=== Using OpenVPN ===<br />
<br />
First make sure the packages {{Pkg|openvpn}} and {{Pkg|openresolv}} are installed, then proceed to download Mullvad's OpenVPN configuration file package from [https://www.mullvad.net/download/config/ their website] (under the "other platforms" tab) and unzip the downloaded file to {{ic|/etc/openvpn/client/}}. From here you can either use the [[Gnome]] gui for networking which uses [NetworkManager] and provides a neat interface, or you can use [[systemd]] to start it automatically at boot.<br />
<br />
==== Using The Gnome Network Gui ====<br />
<br />
In [[Gnome]], open Settings, and select Network. Click on the "+" by the VPN section, and choose "Import from file". Choose the config file that you have downloaded from Mullvad. Repeat this step for all of the servers you want to add. Now the VPN connections will show up in the roll down menu in the top right corner, below the primary network connections. At this point you manually have to flick the switch to connect to one of the servers. You may want to choose one of the VPN servers to connect to automatically when connected to the internet, using these steps in [https://wiki.archlinux.org/index.php/NetworkManager#Automatically_connect_to_VPN NetworkManager#Automatically_connect_to_VPN]<br />
<br />
==== Using [[systemd]] ====<br />
<br />
Rename mullvad_linux.conf for a shorter name to be used with the [[systemd]] service later:<br />
<br />
# mv /etc/openvpn/client/mullvad_linux.conf /etc/openvpn/client/mullvad.conf<br />
<br />
In order to use the nameservers supplied by Mullvad, [[OpenVPN#Update resolv-conf script|update-resolv-conf script]]{{Broken section link}} is being called upon starting and stopping the connection with OpenVPN to modify [[resolv.conf]] to include the correct IP addresses. This script is also included in the Mullvad configuration zipfile, but should be moved to {{ic|/etc/openvpn/}} to match the path specified in the Mullvad configuration file:<br />
<br />
# mv /etc/openvpn/client/update-resolv-conf /etc/openvpn/<br />
<br />
The script can be kept updated with the [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script, which also contains a fix for DNS leaks.<br />
<br />
After configuration the VPN connection can be [[enabled|managed]] with {{ic|openvpn-client@mullvad.service}}. If the service fails to start with an error like {{ic|Cannot open TUN/TAP dev /dev/net/tun: No such device <nowiki>(errno=19)</nowiki>}}, you might need to reboot the system to enable OpenVPN creating the correct network device for the task.<br />
<br />
=== Using WireGuard ===<br />
<br />
[Install] the {{Pkg|wireguard-tools}} package. Log in to Mullvad with your account and then go to the [https://mullvad.net/en/account/#/wireguard-config/ Wireguard-config page]. Choose Linux as platform, then click generate key to generate a public key. In a terminal, issue the following command to generate a private key:<br />
<br />
# wg genkey<br />
<br />
Click on "Manage keys" on the Mullvad WireGuard config page, and insert the private key you just generated into the field that says "Enter private key", and click on "import key". Fill out step 3 on the website and download the file. Unzip the file you downloaded to get one or several config files depending on your selections in step 3. With these config files you can follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#Set_up_VPN_with_WireGuard Set_up_VPN_with_WireGuard] in the [[NetworkManager]] wiki.<br />
<br />
== DNS leaks ==<br />
<br />
By default, the Mullvad openvpn configurations allow DNS leaks and for usual VPN use cases this is an unfavorable privacy defect. Mullvad's new GUI client automatically stops DNS leaks by removing every DNS server IP from the system configuration and replacing them with an IP pointing out to Mullvad's own non-logging DNS server, valid during the VPN connection. This fix can also be applied with the plain OpenVPN method by configuring [[resolv.conf]] to use '''only''' the Mullvad DNS server IP specified on their [https://www.mullvad.net/guides/dns-leaks/ website].<br />
<br />
The resolv.conf update script version in [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] implements a different fix for the leaks by using the exclusive interface switch {{ic|-x}} when running the {{ic|resolvconf}} command, but this might cause another form of DNS leakage by making even every local network address resolve via the DNS server provided by Mullvad, as noted in the [https://github.com/masterkorp/openvpn-update-resolv-conf/issues/18 script's GitHub issue page].<br />
<br />
== See also ==<br />
* [https://github.com/mullvad/mullvadvpn-app Mullvad client source code]<br />
* [https://mullvad.net/en/faq/ Mullvad FAQ]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Mullvad&diff=627232Mullvad2020-07-30T16:44:22Z<p>Tobbebobbe: /* Using WireGuard */ formatting</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[es:Mullvad]]<br />
[[ja:Mullvad]]<br />
[https://mullvad.net/en/ Mullvad] is a VPN service based in Sweden which uses [[OpenVPN]] and [[WireGuard]].<br />
<br />
== Installation ==<br />
<br />
The new [https://mullvad.net/download/ official GUI client] is available as {{AUR|mullvad-vpn}}.<br />
<br />
After installation you will need to enable and start the [[systemd]] service {{ic|mullvad-daemon.service}}.<br />
<br />
Alternatively you can use the old client or either [[OpenVPN]] or [[WireGuard]] with a configuration file for Mullvad as explained in [[#Manual configuration]].<br />
<br />
== Manual configuration ==<br />
<br />
If you do not want to use the Mullvad app you can set it up manually with standard Linux software. Mullvad supports the [OpenVPN] and [WireGuard] protocols. Mullvad themselves [https://mullvad.net/en/help/why-wireguard/ advise] to use WireGuard. However, using OpenVpn may be preferable since for instance the Gnome gui can handle OpenVPN grafically, which makes it easy to see that the VPN is being used, or switching between VPN servers.<br />
<br />
No matter if you opt for OpenVPN or WireGuard, if you use [NetworkManager] you may want to set up [dnsmasq] to decrease DNS-lookup times and also decreasing risk of DNS leakages. Follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#DNS_caching_and_conditional_forwarding DNS_caching_and_conditional_forwarding].<br />
<br />
=== Using OpenVPN ===<br />
<br />
First make sure the packages {{Pkg|openvpn}} and {{Pkg|openresolv}} are installed, then proceed to download Mullvad's OpenVPN configuration file package from [https://www.mullvad.net/download/config/ their website] (under the "other platforms" tab) and unzip the downloaded file to {{ic|/etc/openvpn/client/}}. From here you can either use the [[Gnome]] gui for networking which uses [NetworkManager] and provides a neat interface, or you can use [[systemd]] to start it automatically at boot.<br />
<br />
==== Using The Gnome Network Gui ====<br />
<br />
In [[Gnome]], open Settings, and select Network. Click on the "+" by the VPN section, and choose "Import from file". Choose the config file that you have downloaded from Mullvad. Repeat this step for all of the servers you want to add. Now the VPN connections will show up in the roll down menu up in the right corner, below the primary network connections. At this point you manually have to flick the switch to connect to one of the servers. You may want to choose one of the VPN servers to connect to automatically when connected to the internet, using these steps in [https://wiki.archlinux.org/index.php/NetworkManager#Automatically_connect_to_VPN NetworkManager#Automatically_connect_to_VPN]<br />
<br />
==== Using [[systemd]] ====<br />
<br />
Rename mullvad_linux.conf for a shorter name to be used with the [[systemd]] service later:<br />
<br />
# mv /etc/openvpn/client/mullvad_linux.conf /etc/openvpn/client/mullvad.conf<br />
<br />
In order to use the nameservers supplied by Mullvad, [[OpenVPN#Update resolv-conf script|update-resolv-conf script]]{{Broken section link}} is being called upon starting and stopping the connection with OpenVPN to modify [[resolv.conf]] to include the correct IP addresses. This script is also included in the Mullvad configuration zipfile, but should be moved to {{ic|/etc/openvpn/}} to match the path specified in the Mullvad configuration file:<br />
<br />
# mv /etc/openvpn/client/update-resolv-conf /etc/openvpn/<br />
<br />
The script can be kept updated with the [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script, which also contains a fix for DNS leaks.<br />
<br />
After configuration the VPN connection can be [[enabled|managed]] with {{ic|openvpn-client@mullvad.service}}. If the service fails to start with an error like {{ic|Cannot open TUN/TAP dev /dev/net/tun: No such device <nowiki>(errno=19)</nowiki>}}, you might need to reboot the system to enable OpenVPN creating the correct network device for the task.<br />
<br />
=== Using WireGuard ===<br />
<br />
[Install] the {{Pkg|wireguard-tools}} package. Log in to Mullvad with your account and then go to the [https://mullvad.net/en/account/#/wireguard-config/ Wireguard-config page]. Choose Linux as platform, then click generate key to generate a public key. In a terminal, issue the following command to generate a private key:<br />
<br />
# wg genkey<br />
<br />
Click on "Manage keys" on the Mullvad WireGuard config page, and insert the private key you just generated into the field that says "Enter private key", and click on "import key". Fill out step 3 on the website and download the file. Unzip the file you downloaded to get one or several config files depending on your selections in step 3. With these config files you can follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#Set_up_VPN_with_WireGuard Set_up_VPN_with_WireGuard] in the [[NetworkManager]] wiki.<br />
<br />
== DNS leaks ==<br />
<br />
By default, the Mullvad openvpn configurations allow DNS leaks and for usual VPN use cases this is an unfavorable privacy defect. Mullvad's new GUI client automatically stops DNS leaks by removing every DNS server IP from the system configuration and replacing them with an IP pointing out to Mullvad's own non-logging DNS server, valid during the VPN connection. This fix can also be applied with the plain OpenVPN method by configuring [[resolv.conf]] to use '''only''' the Mullvad DNS server IP specified on their [https://www.mullvad.net/guides/dns-leaks/ website].<br />
<br />
The resolv.conf update script version in [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] implements a different fix for the leaks by using the exclusive interface switch {{ic|-x}} when running the {{ic|resolvconf}} command, but this might cause another form of DNS leakage by making even every local network address resolve via the DNS server provided by Mullvad, as noted in the [https://github.com/masterkorp/openvpn-update-resolv-conf/issues/18 script's GitHub issue page].<br />
<br />
== See also ==<br />
* [https://github.com/mullvad/mullvadvpn-app Mullvad client source code]<br />
* [https://mullvad.net/en/faq/ Mullvad FAQ]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Mullvad&diff=627231Mullvad2020-07-30T16:43:37Z<p>Tobbebobbe: /* Using WireGuard */ formatting</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[es:Mullvad]]<br />
[[ja:Mullvad]]<br />
[https://mullvad.net/en/ Mullvad] is a VPN service based in Sweden which uses [[OpenVPN]] and [[WireGuard]].<br />
<br />
== Installation ==<br />
<br />
The new [https://mullvad.net/download/ official GUI client] is available as {{AUR|mullvad-vpn}}.<br />
<br />
After installation you will need to enable and start the [[systemd]] service {{ic|mullvad-daemon.service}}.<br />
<br />
Alternatively you can use the old client or either [[OpenVPN]] or [[WireGuard]] with a configuration file for Mullvad as explained in [[#Manual configuration]].<br />
<br />
== Manual configuration ==<br />
<br />
If you do not want to use the Mullvad app you can set it up manually with standard Linux software. Mullvad supports the [OpenVPN] and [WireGuard] protocols. Mullvad themselves [https://mullvad.net/en/help/why-wireguard/ advise] to use WireGuard. However, using OpenVpn may be preferable since for instance the Gnome gui can handle OpenVPN grafically, which makes it easy to see that the VPN is being used, or switching between VPN servers.<br />
<br />
No matter if you opt for OpenVPN or WireGuard, if you use [NetworkManager] you may want to set up [dnsmasq] to decrease DNS-lookup times and also decreasing risk of DNS leakages. Follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#DNS_caching_and_conditional_forwarding DNS_caching_and_conditional_forwarding].<br />
<br />
=== Using OpenVPN ===<br />
<br />
First make sure the packages {{Pkg|openvpn}} and {{Pkg|openresolv}} are installed, then proceed to download Mullvad's OpenVPN configuration file package from [https://www.mullvad.net/download/config/ their website] (under the "other platforms" tab) and unzip the downloaded file to {{ic|/etc/openvpn/client/}}. From here you can either use the [[Gnome]] gui for networking which uses [NetworkManager] and provides a neat interface, or you can use [[systemd]] to start it automatically at boot.<br />
<br />
==== Using The Gnome Network Gui ====<br />
<br />
In [[Gnome]], open Settings, and select Network. Click on the "+" by the VPN section, and choose "Import from file". Choose the config file that you have downloaded from Mullvad. Repeat this step for all of the servers you want to add. Now the VPN connections will show up in the roll down menu up in the right corner, below the primary network connections. At this point you manually have to flick the switch to connect to one of the servers. You may want to choose one of the VPN servers to connect to automatically when connected to the internet, using these steps in [https://wiki.archlinux.org/index.php/NetworkManager#Automatically_connect_to_VPN NetworkManager#Automatically_connect_to_VPN]<br />
<br />
==== Using [[systemd]] ====<br />
<br />
Rename mullvad_linux.conf for a shorter name to be used with the [[systemd]] service later:<br />
<br />
# mv /etc/openvpn/client/mullvad_linux.conf /etc/openvpn/client/mullvad.conf<br />
<br />
In order to use the nameservers supplied by Mullvad, [[OpenVPN#Update resolv-conf script|update-resolv-conf script]]{{Broken section link}} is being called upon starting and stopping the connection with OpenVPN to modify [[resolv.conf]] to include the correct IP addresses. This script is also included in the Mullvad configuration zipfile, but should be moved to {{ic|/etc/openvpn/}} to match the path specified in the Mullvad configuration file:<br />
<br />
# mv /etc/openvpn/client/update-resolv-conf /etc/openvpn/<br />
<br />
The script can be kept updated with the [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script, which also contains a fix for DNS leaks.<br />
<br />
After configuration the VPN connection can be [[enabled|managed]] with {{ic|openvpn-client@mullvad.service}}. If the service fails to start with an error like {{ic|Cannot open TUN/TAP dev /dev/net/tun: No such device <nowiki>(errno=19)</nowiki>}}, you might need to reboot the system to enable OpenVPN creating the correct network device for the task.<br />
<br />
=== Using WireGuard ===<br />
<br />
[Install] the {{Pkg|wireguard-tools}} package. Log in to Mullvad with your account and then go to the [https://mullvad.net/en/account/#/wireguard-config/ Wireguard-config page]. Choose Linux as platform, then click generate key to generate a public key. In a terminal, issue the following command to generate a private key:<br />
<br />
# wg genkey<br />
<br />
Click on "Manage keys" on the Mullvad WireGuard config page, and insert the private key you just generated into the field that says "Enter private key", and click on "import key". Fill out step 3 on the website and download the file. Unzip the file you downloaded to get one or several config files depending on your selections in step 3. With these config files you can follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#Set_up_VPN_with_WireGuard Set_up_VPN_with_WireGuard] in the [NetworkManager] wiki.<br />
<br />
== DNS leaks ==<br />
<br />
By default, the Mullvad openvpn configurations allow DNS leaks and for usual VPN use cases this is an unfavorable privacy defect. Mullvad's new GUI client automatically stops DNS leaks by removing every DNS server IP from the system configuration and replacing them with an IP pointing out to Mullvad's own non-logging DNS server, valid during the VPN connection. This fix can also be applied with the plain OpenVPN method by configuring [[resolv.conf]] to use '''only''' the Mullvad DNS server IP specified on their [https://www.mullvad.net/guides/dns-leaks/ website].<br />
<br />
The resolv.conf update script version in [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] implements a different fix for the leaks by using the exclusive interface switch {{ic|-x}} when running the {{ic|resolvconf}} command, but this might cause another form of DNS leakage by making even every local network address resolve via the DNS server provided by Mullvad, as noted in the [https://github.com/masterkorp/openvpn-update-resolv-conf/issues/18 script's GitHub issue page].<br />
<br />
== See also ==<br />
* [https://github.com/mullvad/mullvadvpn-app Mullvad client source code]<br />
* [https://mullvad.net/en/faq/ Mullvad FAQ]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Mullvad&diff=627230Mullvad2020-07-30T16:43:01Z<p>Tobbebobbe: /* Using OpenVPN */ clearifying text</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[es:Mullvad]]<br />
[[ja:Mullvad]]<br />
[https://mullvad.net/en/ Mullvad] is a VPN service based in Sweden which uses [[OpenVPN]] and [[WireGuard]].<br />
<br />
== Installation ==<br />
<br />
The new [https://mullvad.net/download/ official GUI client] is available as {{AUR|mullvad-vpn}}.<br />
<br />
After installation you will need to enable and start the [[systemd]] service {{ic|mullvad-daemon.service}}.<br />
<br />
Alternatively you can use the old client or either [[OpenVPN]] or [[WireGuard]] with a configuration file for Mullvad as explained in [[#Manual configuration]].<br />
<br />
== Manual configuration ==<br />
<br />
If you do not want to use the Mullvad app you can set it up manually with standard Linux software. Mullvad supports the [OpenVPN] and [WireGuard] protocols. Mullvad themselves [https://mullvad.net/en/help/why-wireguard/ advise] to use WireGuard. However, using OpenVpn may be preferable since for instance the Gnome gui can handle OpenVPN grafically, which makes it easy to see that the VPN is being used, or switching between VPN servers.<br />
<br />
No matter if you opt for OpenVPN or WireGuard, if you use [NetworkManager] you may want to set up [dnsmasq] to decrease DNS-lookup times and also decreasing risk of DNS leakages. Follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#DNS_caching_and_conditional_forwarding DNS_caching_and_conditional_forwarding].<br />
<br />
=== Using OpenVPN ===<br />
<br />
First make sure the packages {{Pkg|openvpn}} and {{Pkg|openresolv}} are installed, then proceed to download Mullvad's OpenVPN configuration file package from [https://www.mullvad.net/download/config/ their website] (under the "other platforms" tab) and unzip the downloaded file to {{ic|/etc/openvpn/client/}}. From here you can either use the [[Gnome]] gui for networking which uses [NetworkManager] and provides a neat interface, or you can use [[systemd]] to start it automatically at boot.<br />
<br />
==== Using The Gnome Network Gui ====<br />
<br />
In [[Gnome]], open Settings, and select Network. Click on the "+" by the VPN section, and choose "Import from file". Choose the config file that you have downloaded from Mullvad. Repeat this step for all of the servers you want to add. Now the VPN connections will show up in the roll down menu up in the right corner, below the primary network connections. At this point you manually have to flick the switch to connect to one of the servers. You may want to choose one of the VPN servers to connect to automatically when connected to the internet, using these steps in [https://wiki.archlinux.org/index.php/NetworkManager#Automatically_connect_to_VPN NetworkManager#Automatically_connect_to_VPN]<br />
<br />
==== Using [[systemd]] ====<br />
<br />
Rename mullvad_linux.conf for a shorter name to be used with the [[systemd]] service later:<br />
<br />
# mv /etc/openvpn/client/mullvad_linux.conf /etc/openvpn/client/mullvad.conf<br />
<br />
In order to use the nameservers supplied by Mullvad, [[OpenVPN#Update resolv-conf script|update-resolv-conf script]]{{Broken section link}} is being called upon starting and stopping the connection with OpenVPN to modify [[resolv.conf]] to include the correct IP addresses. This script is also included in the Mullvad configuration zipfile, but should be moved to {{ic|/etc/openvpn/}} to match the path specified in the Mullvad configuration file:<br />
<br />
# mv /etc/openvpn/client/update-resolv-conf /etc/openvpn/<br />
<br />
The script can be kept updated with the [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script, which also contains a fix for DNS leaks.<br />
<br />
After configuration the VPN connection can be [[enabled|managed]] with {{ic|openvpn-client@mullvad.service}}. If the service fails to start with an error like {{ic|Cannot open TUN/TAP dev /dev/net/tun: No such device <nowiki>(errno=19)</nowiki>}}, you might need to reboot the system to enable OpenVPN creating the correct network device for the task.<br />
<br />
==== Using WireGuard ====<br />
<br />
[Install] the {{Pkg|wireguard-tools}} package. Log in to Mullvad with your account and then go to the [https://mullvad.net/en/account/#/wireguard-config/ Wireguard-config page]. Choose Linux as platform, then click generate key to generate a public key. In a terminal, issue the following command to generate a private key:<br />
<br />
# wg genkey<br />
<br />
Click on "Manage keys" on the Mullvad WireGuard config page, and insert the private key you just generated into the field that says "Enter private key", and click on "import key". Fill out step 3 on the website and download the file. Unzip the file you downloaded to get one or several config files depending on your selections in step 3. With these config files you can follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#Set_up_VPN_with_WireGuard Set_up_VPN_with_WireGuard] in the [NetworkManager] wiki.<br />
<br />
== DNS leaks ==<br />
<br />
By default, the Mullvad openvpn configurations allow DNS leaks and for usual VPN use cases this is an unfavorable privacy defect. Mullvad's new GUI client automatically stops DNS leaks by removing every DNS server IP from the system configuration and replacing them with an IP pointing out to Mullvad's own non-logging DNS server, valid during the VPN connection. This fix can also be applied with the plain OpenVPN method by configuring [[resolv.conf]] to use '''only''' the Mullvad DNS server IP specified on their [https://www.mullvad.net/guides/dns-leaks/ website].<br />
<br />
The resolv.conf update script version in [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] implements a different fix for the leaks by using the exclusive interface switch {{ic|-x}} when running the {{ic|resolvconf}} command, but this might cause another form of DNS leakage by making even every local network address resolve via the DNS server provided by Mullvad, as noted in the [https://github.com/masterkorp/openvpn-update-resolv-conf/issues/18 script's GitHub issue page].<br />
<br />
== See also ==<br />
* [https://github.com/mullvad/mullvadvpn-app Mullvad client source code]<br />
* [https://mullvad.net/en/faq/ Mullvad FAQ]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Mullvad&diff=627228Mullvad2020-07-30T16:40:23Z<p>Tobbebobbe: /* Installation */ added wireguard</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[es:Mullvad]]<br />
[[ja:Mullvad]]<br />
[https://mullvad.net/en/ Mullvad] is a VPN service based in Sweden which uses [[OpenVPN]] and [[WireGuard]].<br />
<br />
== Installation ==<br />
<br />
The new [https://mullvad.net/download/ official GUI client] is available as {{AUR|mullvad-vpn}}.<br />
<br />
After installation you will need to enable and start the [[systemd]] service {{ic|mullvad-daemon.service}}.<br />
<br />
Alternatively you can use the old client or either [[OpenVPN]] or [[WireGuard]] with a configuration file for Mullvad as explained in [[#Manual configuration]].<br />
<br />
== Manual configuration ==<br />
<br />
If you do not want to use the Mullvad app you can set it up manually with standard Linux software. Mullvad supports the [OpenVPN] and [WireGuard] protocols. Mullvad themselves [https://mullvad.net/en/help/why-wireguard/ advise] to use WireGuard. However, using OpenVpn may be preferable since for instance the Gnome gui can handle OpenVPN grafically, which makes it easy to see that the VPN is being used, or switching between VPN servers.<br />
<br />
No matter if you opt for OpenVPN or WireGuard, if you use [NetworkManager] you may want to set up [dnsmasq] to decrease DNS-lookup times and also decreasing risk of DNS leakages. Follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#DNS_caching_and_conditional_forwarding DNS_caching_and_conditional_forwarding].<br />
<br />
=== Using OpenVPN ===<br />
<br />
First make sure the packages {{Pkg|openvpn}} and {{Pkg|openresolv}} are installed, then proceed to download Mullvad's OpenVPN configuration file package from [https://www.mullvad.net/download/config/ their website] (under the "other platforms" tab) and unzip the downloaded file to {{ic|/etc/openvpn/client/}}.<br />
<br />
==== Using The Gnome Network Gui ====<br />
<br />
In [[Gnome]], open Settings, and select Network. Click on the "+" by the VPN section, and choose "Import from file". Choose the config file that you have downloaded from Mullvad. Repeat this step for all of the servers you want to add. Now the VPN connections will show up in the roll down menu up in the right corner, below the primary network connections. At this point you manually have to flick the switch to connect to one of the servers. You may want to choose one of the VPN servers to connect to automatically when connected to the internet, using these steps in [https://wiki.archlinux.org/index.php/NetworkManager#Automatically_connect_to_VPN NetworkManager#Automatically_connect_to_VPN]<br />
<br />
==== Using [[systemd]] ====<br />
<br />
Rename mullvad_linux.conf for a shorter name to be used with the [[systemd]] service later:<br />
<br />
# mv /etc/openvpn/client/mullvad_linux.conf /etc/openvpn/client/mullvad.conf<br />
<br />
In order to use the nameservers supplied by Mullvad, [[OpenVPN#Update resolv-conf script|update-resolv-conf script]]{{Broken section link}} is being called upon starting and stopping the connection with OpenVPN to modify [[resolv.conf]] to include the correct IP addresses. This script is also included in the Mullvad configuration zipfile, but should be moved to {{ic|/etc/openvpn/}} to match the path specified in the Mullvad configuration file:<br />
<br />
# mv /etc/openvpn/client/update-resolv-conf /etc/openvpn/<br />
<br />
The script can be kept updated with the [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script, which also contains a fix for DNS leaks.<br />
<br />
After configuration the VPN connection can be [[enabled|managed]] with {{ic|openvpn-client@mullvad.service}}. If the service fails to start with an error like {{ic|Cannot open TUN/TAP dev /dev/net/tun: No such device <nowiki>(errno=19)</nowiki>}}, you might need to reboot the system to enable OpenVPN creating the correct network device for the task.<br />
<br />
==== Using WireGuard ====<br />
<br />
[Install] the {{Pkg|wireguard-tools}} package. Log in to Mullvad with your account and then go to the [https://mullvad.net/en/account/#/wireguard-config/ Wireguard-config page]. Choose Linux as platform, then click generate key to generate a public key. In a terminal, issue the following command to generate a private key:<br />
<br />
# wg genkey<br />
<br />
Click on "Manage keys" on the Mullvad WireGuard config page, and insert the private key you just generated into the field that says "Enter private key", and click on "import key". Fill out step 3 on the website and download the file. Unzip the file you downloaded to get one or several config files depending on your selections in step 3. With these config files you can follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#Set_up_VPN_with_WireGuard Set_up_VPN_with_WireGuard] in the [NetworkManager] wiki.<br />
<br />
== DNS leaks ==<br />
<br />
By default, the Mullvad openvpn configurations allow DNS leaks and for usual VPN use cases this is an unfavorable privacy defect. Mullvad's new GUI client automatically stops DNS leaks by removing every DNS server IP from the system configuration and replacing them with an IP pointing out to Mullvad's own non-logging DNS server, valid during the VPN connection. This fix can also be applied with the plain OpenVPN method by configuring [[resolv.conf]] to use '''only''' the Mullvad DNS server IP specified on their [https://www.mullvad.net/guides/dns-leaks/ website].<br />
<br />
The resolv.conf update script version in [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] implements a different fix for the leaks by using the exclusive interface switch {{ic|-x}} when running the {{ic|resolvconf}} command, but this might cause another form of DNS leakage by making even every local network address resolve via the DNS server provided by Mullvad, as noted in the [https://github.com/masterkorp/openvpn-update-resolv-conf/issues/18 script's GitHub issue page].<br />
<br />
== See also ==<br />
* [https://github.com/mullvad/mullvadvpn-app Mullvad client source code]<br />
* [https://mullvad.net/en/faq/ Mullvad FAQ]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Mullvad&diff=627227Mullvad2020-07-30T16:39:26Z<p>Tobbebobbe: /* Using WireGuard */ formatting</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[es:Mullvad]]<br />
[[ja:Mullvad]]<br />
[https://mullvad.net/en/ Mullvad] is a VPN service based in Sweden which uses [[OpenVPN]] and [[WireGuard]].<br />
<br />
== Installation ==<br />
<br />
The new [https://mullvad.net/download/ official GUI client] is available as {{AUR|mullvad-vpn}}.<br />
<br />
After installation you will need to enable and start the [[systemd]] service {{ic|mullvad-daemon.service}}.<br />
<br />
Alternatively you can use the old client or [[OpenVPN]] with a configuration file for Mullvad as explained in [[#Manual configuration]].<br />
<br />
== Manual configuration ==<br />
<br />
If you do not want to use the Mullvad app you can set it up manually with standard Linux software. Mullvad supports the [OpenVPN] and [WireGuard] protocols. Mullvad themselves [https://mullvad.net/en/help/why-wireguard/ advise] to use WireGuard. However, using OpenVpn may be preferable since for instance the Gnome gui can handle OpenVPN grafically, which makes it easy to see that the VPN is being used, or switching between VPN servers.<br />
<br />
No matter if you opt for OpenVPN or WireGuard, if you use [NetworkManager] you may want to set up [dnsmasq] to decrease DNS-lookup times and also decreasing risk of DNS leakages. Follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#DNS_caching_and_conditional_forwarding DNS_caching_and_conditional_forwarding].<br />
<br />
=== Using OpenVPN ===<br />
<br />
First make sure the packages {{Pkg|openvpn}} and {{Pkg|openresolv}} are installed, then proceed to download Mullvad's OpenVPN configuration file package from [https://www.mullvad.net/download/config/ their website] (under the "other platforms" tab) and unzip the downloaded file to {{ic|/etc/openvpn/client/}}.<br />
<br />
==== Using The Gnome Network Gui ====<br />
<br />
In [[Gnome]], open Settings, and select Network. Click on the "+" by the VPN section, and choose "Import from file". Choose the config file that you have downloaded from Mullvad. Repeat this step for all of the servers you want to add. Now the VPN connections will show up in the roll down menu up in the right corner, below the primary network connections. At this point you manually have to flick the switch to connect to one of the servers. You may want to choose one of the VPN servers to connect to automatically when connected to the internet, using these steps in [https://wiki.archlinux.org/index.php/NetworkManager#Automatically_connect_to_VPN NetworkManager#Automatically_connect_to_VPN]<br />
<br />
==== Using [[systemd]] ====<br />
<br />
Rename mullvad_linux.conf for a shorter name to be used with the [[systemd]] service later:<br />
<br />
# mv /etc/openvpn/client/mullvad_linux.conf /etc/openvpn/client/mullvad.conf<br />
<br />
In order to use the nameservers supplied by Mullvad, [[OpenVPN#Update resolv-conf script|update-resolv-conf script]]{{Broken section link}} is being called upon starting and stopping the connection with OpenVPN to modify [[resolv.conf]] to include the correct IP addresses. This script is also included in the Mullvad configuration zipfile, but should be moved to {{ic|/etc/openvpn/}} to match the path specified in the Mullvad configuration file:<br />
<br />
# mv /etc/openvpn/client/update-resolv-conf /etc/openvpn/<br />
<br />
The script can be kept updated with the [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script, which also contains a fix for DNS leaks.<br />
<br />
After configuration the VPN connection can be [[enabled|managed]] with {{ic|openvpn-client@mullvad.service}}. If the service fails to start with an error like {{ic|Cannot open TUN/TAP dev /dev/net/tun: No such device <nowiki>(errno=19)</nowiki>}}, you might need to reboot the system to enable OpenVPN creating the correct network device for the task.<br />
<br />
==== Using WireGuard ====<br />
<br />
[Install] the {{Pkg|wireguard-tools}} package. Log in to Mullvad with your account and then go to the [https://mullvad.net/en/account/#/wireguard-config/ Wireguard-config page]. Choose Linux as platform, then click generate key to generate a public key. In a terminal, issue the following command to generate a private key:<br />
<br />
# wg genkey<br />
<br />
Click on "Manage keys" on the Mullvad WireGuard config page, and insert the private key you just generated into the field that says "Enter private key", and click on "import key". Fill out step 3 on the website and download the file. Unzip the file you downloaded to get one or several config files depending on your selections in step 3. With these config files you can follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#Set_up_VPN_with_WireGuard Set_up_VPN_with_WireGuard] in the [NetworkManager] wiki.<br />
<br />
== DNS leaks ==<br />
<br />
By default, the Mullvad openvpn configurations allow DNS leaks and for usual VPN use cases this is an unfavorable privacy defect. Mullvad's new GUI client automatically stops DNS leaks by removing every DNS server IP from the system configuration and replacing them with an IP pointing out to Mullvad's own non-logging DNS server, valid during the VPN connection. This fix can also be applied with the plain OpenVPN method by configuring [[resolv.conf]] to use '''only''' the Mullvad DNS server IP specified on their [https://www.mullvad.net/guides/dns-leaks/ website].<br />
<br />
The resolv.conf update script version in [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] implements a different fix for the leaks by using the exclusive interface switch {{ic|-x}} when running the {{ic|resolvconf}} command, but this might cause another form of DNS leakage by making even every local network address resolve via the DNS server provided by Mullvad, as noted in the [https://github.com/masterkorp/openvpn-update-resolv-conf/issues/18 script's GitHub issue page].<br />
<br />
== See also ==<br />
* [https://github.com/mullvad/mullvadvpn-app Mullvad client source code]<br />
* [https://mullvad.net/en/faq/ Mullvad FAQ]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Mullvad&diff=627226Mullvad2020-07-30T16:39:04Z<p>Tobbebobbe: /* Using The Gnome Network Gui = */ formatting</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[es:Mullvad]]<br />
[[ja:Mullvad]]<br />
[https://mullvad.net/en/ Mullvad] is a VPN service based in Sweden which uses [[OpenVPN]] and [[WireGuard]].<br />
<br />
== Installation ==<br />
<br />
The new [https://mullvad.net/download/ official GUI client] is available as {{AUR|mullvad-vpn}}.<br />
<br />
After installation you will need to enable and start the [[systemd]] service {{ic|mullvad-daemon.service}}.<br />
<br />
Alternatively you can use the old client or [[OpenVPN]] with a configuration file for Mullvad as explained in [[#Manual configuration]].<br />
<br />
== Manual configuration ==<br />
<br />
If you do not want to use the Mullvad app you can set it up manually with standard Linux software. Mullvad supports the [OpenVPN] and [WireGuard] protocols. Mullvad themselves [https://mullvad.net/en/help/why-wireguard/ advise] to use WireGuard. However, using OpenVpn may be preferable since for instance the Gnome gui can handle OpenVPN grafically, which makes it easy to see that the VPN is being used, or switching between VPN servers.<br />
<br />
No matter if you opt for OpenVPN or WireGuard, if you use [NetworkManager] you may want to set up [dnsmasq] to decrease DNS-lookup times and also decreasing risk of DNS leakages. Follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#DNS_caching_and_conditional_forwarding DNS_caching_and_conditional_forwarding].<br />
<br />
=== Using OpenVPN ===<br />
<br />
First make sure the packages {{Pkg|openvpn}} and {{Pkg|openresolv}} are installed, then proceed to download Mullvad's OpenVPN configuration file package from [https://www.mullvad.net/download/config/ their website] (under the "other platforms" tab) and unzip the downloaded file to {{ic|/etc/openvpn/client/}}.<br />
<br />
==== Using The Gnome Network Gui ====<br />
<br />
In [[Gnome]], open Settings, and select Network. Click on the "+" by the VPN section, and choose "Import from file". Choose the config file that you have downloaded from Mullvad. Repeat this step for all of the servers you want to add. Now the VPN connections will show up in the roll down menu up in the right corner, below the primary network connections. At this point you manually have to flick the switch to connect to one of the servers. You may want to choose one of the VPN servers to connect to automatically when connected to the internet, using these steps in [https://wiki.archlinux.org/index.php/NetworkManager#Automatically_connect_to_VPN NetworkManager#Automatically_connect_to_VPN]<br />
<br />
==== Using [[systemd]] ====<br />
<br />
Rename mullvad_linux.conf for a shorter name to be used with the [[systemd]] service later:<br />
<br />
# mv /etc/openvpn/client/mullvad_linux.conf /etc/openvpn/client/mullvad.conf<br />
<br />
In order to use the nameservers supplied by Mullvad, [[OpenVPN#Update resolv-conf script|update-resolv-conf script]]{{Broken section link}} is being called upon starting and stopping the connection with OpenVPN to modify [[resolv.conf]] to include the correct IP addresses. This script is also included in the Mullvad configuration zipfile, but should be moved to {{ic|/etc/openvpn/}} to match the path specified in the Mullvad configuration file:<br />
<br />
# mv /etc/openvpn/client/update-resolv-conf /etc/openvpn/<br />
<br />
The script can be kept updated with the [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script, which also contains a fix for DNS leaks.<br />
<br />
After configuration the VPN connection can be [[enabled|managed]] with {{ic|openvpn-client@mullvad.service}}. If the service fails to start with an error like {{ic|Cannot open TUN/TAP dev /dev/net/tun: No such device <nowiki>(errno=19)</nowiki>}}, you might need to reboot the system to enable OpenVPN creating the correct network device for the task.<br />
<br />
=== Using WireGuard ===<br />
<br />
[Install] the {{Pkg|wireguard-tools}} package. Log in to Mullvad with your account and then go to the [https://mullvad.net/en/account/#/wireguard-config/ Wireguard-config page]. Choose Linux as platform, then click generate key to generate a public key. In a terminal, issue the following command to generate a private key:<br />
<br />
# wg genkey<br />
<br />
Click on "Manage keys" on the Mullvad WireGuard config page, and insert the private key you just generated into the field that says "Enter private key", and click on "import key". Fill out step 3 on the website and download the file. Unzip the file you downloaded to get one or several config files depending on your selections in step 3. With these config files you can follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#Set_up_VPN_with_WireGuard Set_up_VPN_with_WireGuard] in the [NetworkManager] wiki.<br />
<br />
== DNS leaks ==<br />
<br />
By default, the Mullvad openvpn configurations allow DNS leaks and for usual VPN use cases this is an unfavorable privacy defect. Mullvad's new GUI client automatically stops DNS leaks by removing every DNS server IP from the system configuration and replacing them with an IP pointing out to Mullvad's own non-logging DNS server, valid during the VPN connection. This fix can also be applied with the plain OpenVPN method by configuring [[resolv.conf]] to use '''only''' the Mullvad DNS server IP specified on their [https://www.mullvad.net/guides/dns-leaks/ website].<br />
<br />
The resolv.conf update script version in [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] implements a different fix for the leaks by using the exclusive interface switch {{ic|-x}} when running the {{ic|resolvconf}} command, but this might cause another form of DNS leakage by making even every local network address resolve via the DNS server provided by Mullvad, as noted in the [https://github.com/masterkorp/openvpn-update-resolv-conf/issues/18 script's GitHub issue page].<br />
<br />
== See also ==<br />
* [https://github.com/mullvad/mullvadvpn-app Mullvad client source code]<br />
* [https://mullvad.net/en/faq/ Mullvad FAQ]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Mullvad&diff=627225Mullvad2020-07-30T16:38:09Z<p>Tobbebobbe: /* Using {{WireGuard}} */ formatting</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[es:Mullvad]]<br />
[[ja:Mullvad]]<br />
[https://mullvad.net/en/ Mullvad] is a VPN service based in Sweden which uses [[OpenVPN]] and [[WireGuard]].<br />
<br />
== Installation ==<br />
<br />
The new [https://mullvad.net/download/ official GUI client] is available as {{AUR|mullvad-vpn}}.<br />
<br />
After installation you will need to enable and start the [[systemd]] service {{ic|mullvad-daemon.service}}.<br />
<br />
Alternatively you can use the old client or [[OpenVPN]] with a configuration file for Mullvad as explained in [[#Manual configuration]].<br />
<br />
== Manual configuration ==<br />
<br />
If you do not want to use the Mullvad app you can set it up manually with standard Linux software. Mullvad supports the [OpenVPN] and [WireGuard] protocols. Mullvad themselves [https://mullvad.net/en/help/why-wireguard/ advise] to use WireGuard. However, using OpenVpn may be preferable since for instance the Gnome gui can handle OpenVPN grafically, which makes it easy to see that the VPN is being used, or switching between VPN servers.<br />
<br />
No matter if you opt for OpenVPN or WireGuard, if you use [NetworkManager] you may want to set up [dnsmasq] to decrease DNS-lookup times and also decreasing risk of DNS leakages. Follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#DNS_caching_and_conditional_forwarding DNS_caching_and_conditional_forwarding].<br />
<br />
=== Using OpenVPN ===<br />
<br />
First make sure the packages {{Pkg|openvpn}} and {{Pkg|openresolv}} are installed, then proceed to download Mullvad's OpenVPN configuration file package from [https://www.mullvad.net/download/config/ their website] (under the "other platforms" tab) and unzip the downloaded file to {{ic|/etc/openvpn/client/}}.<br />
<br />
==== Using The Gnome Network Gui =====<br />
<br />
In [[Gnome]], open Settings, and select Network. Click on the "+" by the VPN section, and choose "Import from file". Choose the config file that you have downloaded from Mullvad. Repeat this step for all of the servers you want to add. Now the VPN connections will show up in the roll down menu up in the right corner, below the primary network connections. At this point you manually have to flick the switch to connect to one of the servers. You may want to choose one of the VPN servers to connect to automatically when connected to the internet, using these steps in [https://wiki.archlinux.org/index.php/NetworkManager#Automatically_connect_to_VPN NetworkManager#Automatically_connect_to_VPN]<br />
<br />
<br />
==== Using [[systemd]] ====<br />
<br />
Rename mullvad_linux.conf for a shorter name to be used with the [[systemd]] service later:<br />
<br />
# mv /etc/openvpn/client/mullvad_linux.conf /etc/openvpn/client/mullvad.conf<br />
<br />
In order to use the nameservers supplied by Mullvad, [[OpenVPN#Update resolv-conf script|update-resolv-conf script]]{{Broken section link}} is being called upon starting and stopping the connection with OpenVPN to modify [[resolv.conf]] to include the correct IP addresses. This script is also included in the Mullvad configuration zipfile, but should be moved to {{ic|/etc/openvpn/}} to match the path specified in the Mullvad configuration file:<br />
<br />
# mv /etc/openvpn/client/update-resolv-conf /etc/openvpn/<br />
<br />
The script can be kept updated with the [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script, which also contains a fix for DNS leaks.<br />
<br />
After configuration the VPN connection can be [[enabled|managed]] with {{ic|openvpn-client@mullvad.service}}. If the service fails to start with an error like {{ic|Cannot open TUN/TAP dev /dev/net/tun: No such device <nowiki>(errno=19)</nowiki>}}, you might need to reboot the system to enable OpenVPN creating the correct network device for the task.<br />
<br />
=== Using WireGuard ===<br />
<br />
[Install] the {{Pkg|wireguard-tools}} package. Log in to Mullvad with your account and then go to the [https://mullvad.net/en/account/#/wireguard-config/ Wireguard-config page]. Choose Linux as platform, then click generate key to generate a public key. In a terminal, issue the following command to generate a private key:<br />
<br />
# wg genkey<br />
<br />
Click on "Manage keys" on the Mullvad WireGuard config page, and insert the private key you just generated into the field that says "Enter private key", and click on "import key". Fill out step 3 on the website and download the file. Unzip the file you downloaded to get one or several config files depending on your selections in step 3. With these config files you can follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#Set_up_VPN_with_WireGuard Set_up_VPN_with_WireGuard] in the [NetworkManager] wiki.<br />
<br />
== DNS leaks ==<br />
<br />
By default, the Mullvad openvpn configurations allow DNS leaks and for usual VPN use cases this is an unfavorable privacy defect. Mullvad's new GUI client automatically stops DNS leaks by removing every DNS server IP from the system configuration and replacing them with an IP pointing out to Mullvad's own non-logging DNS server, valid during the VPN connection. This fix can also be applied with the plain OpenVPN method by configuring [[resolv.conf]] to use '''only''' the Mullvad DNS server IP specified on their [https://www.mullvad.net/guides/dns-leaks/ website].<br />
<br />
The resolv.conf update script version in [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] implements a different fix for the leaks by using the exclusive interface switch {{ic|-x}} when running the {{ic|resolvconf}} command, but this might cause another form of DNS leakage by making even every local network address resolve via the DNS server provided by Mullvad, as noted in the [https://github.com/masterkorp/openvpn-update-resolv-conf/issues/18 script's GitHub issue page].<br />
<br />
== See also ==<br />
* [https://github.com/mullvad/mullvadvpn-app Mullvad client source code]<br />
* [https://mullvad.net/en/faq/ Mullvad FAQ]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Mullvad&diff=627224Mullvad2020-07-30T16:37:54Z<p>Tobbebobbe: /* Using {{OpenVPN}} */ formatting</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[es:Mullvad]]<br />
[[ja:Mullvad]]<br />
[https://mullvad.net/en/ Mullvad] is a VPN service based in Sweden which uses [[OpenVPN]] and [[WireGuard]].<br />
<br />
== Installation ==<br />
<br />
The new [https://mullvad.net/download/ official GUI client] is available as {{AUR|mullvad-vpn}}.<br />
<br />
After installation you will need to enable and start the [[systemd]] service {{ic|mullvad-daemon.service}}.<br />
<br />
Alternatively you can use the old client or [[OpenVPN]] with a configuration file for Mullvad as explained in [[#Manual configuration]].<br />
<br />
== Manual configuration ==<br />
<br />
If you do not want to use the Mullvad app you can set it up manually with standard Linux software. Mullvad supports the [OpenVPN] and [WireGuard] protocols. Mullvad themselves [https://mullvad.net/en/help/why-wireguard/ advise] to use WireGuard. However, using OpenVpn may be preferable since for instance the Gnome gui can handle OpenVPN grafically, which makes it easy to see that the VPN is being used, or switching between VPN servers.<br />
<br />
No matter if you opt for OpenVPN or WireGuard, if you use [NetworkManager] you may want to set up [dnsmasq] to decrease DNS-lookup times and also decreasing risk of DNS leakages. Follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#DNS_caching_and_conditional_forwarding DNS_caching_and_conditional_forwarding].<br />
<br />
=== Using OpenVPN ===<br />
<br />
First make sure the packages {{Pkg|openvpn}} and {{Pkg|openresolv}} are installed, then proceed to download Mullvad's OpenVPN configuration file package from [https://www.mullvad.net/download/config/ their website] (under the "other platforms" tab) and unzip the downloaded file to {{ic|/etc/openvpn/client/}}.<br />
<br />
==== Using The Gnome Network Gui =====<br />
<br />
In [[Gnome]], open Settings, and select Network. Click on the "+" by the VPN section, and choose "Import from file". Choose the config file that you have downloaded from Mullvad. Repeat this step for all of the servers you want to add. Now the VPN connections will show up in the roll down menu up in the right corner, below the primary network connections. At this point you manually have to flick the switch to connect to one of the servers. You may want to choose one of the VPN servers to connect to automatically when connected to the internet, using these steps in [https://wiki.archlinux.org/index.php/NetworkManager#Automatically_connect_to_VPN NetworkManager#Automatically_connect_to_VPN]<br />
<br />
<br />
==== Using [[systemd]] ====<br />
<br />
Rename mullvad_linux.conf for a shorter name to be used with the [[systemd]] service later:<br />
<br />
# mv /etc/openvpn/client/mullvad_linux.conf /etc/openvpn/client/mullvad.conf<br />
<br />
In order to use the nameservers supplied by Mullvad, [[OpenVPN#Update resolv-conf script|update-resolv-conf script]]{{Broken section link}} is being called upon starting and stopping the connection with OpenVPN to modify [[resolv.conf]] to include the correct IP addresses. This script is also included in the Mullvad configuration zipfile, but should be moved to {{ic|/etc/openvpn/}} to match the path specified in the Mullvad configuration file:<br />
<br />
# mv /etc/openvpn/client/update-resolv-conf /etc/openvpn/<br />
<br />
The script can be kept updated with the [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script, which also contains a fix for DNS leaks.<br />
<br />
After configuration the VPN connection can be [[enabled|managed]] with {{ic|openvpn-client@mullvad.service}}. If the service fails to start with an error like {{ic|Cannot open TUN/TAP dev /dev/net/tun: No such device <nowiki>(errno=19)</nowiki>}}, you might need to reboot the system to enable OpenVPN creating the correct network device for the task.<br />
<br />
=== Using {{WireGuard}} ===<br />
<br />
[Install] the {{Pkg|wireguard-tools}} package. Log in to Mullvad with your account and then go to the [https://mullvad.net/en/account/#/wireguard-config/ Wireguard-config page]. Choose Linux as platform, then click generate key to generate a public key. In a terminal, issue the following command to generate a private key:<br />
<br />
# wg genkey<br />
<br />
Click on "Manage keys" on the Mullvad WireGuard config page, and insert the private key you just generated into the field that says "Enter private key", and click on "import key". Fill out step 3 on the website and download the file. Unzip the file you downloaded to get one or several config files depending on your selections in step 3. With these config files you can follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#Set_up_VPN_with_WireGuard Set_up_VPN_with_WireGuard] in the [NetworkManager] wiki.<br />
<br />
== DNS leaks ==<br />
<br />
By default, the Mullvad openvpn configurations allow DNS leaks and for usual VPN use cases this is an unfavorable privacy defect. Mullvad's new GUI client automatically stops DNS leaks by removing every DNS server IP from the system configuration and replacing them with an IP pointing out to Mullvad's own non-logging DNS server, valid during the VPN connection. This fix can also be applied with the plain OpenVPN method by configuring [[resolv.conf]] to use '''only''' the Mullvad DNS server IP specified on their [https://www.mullvad.net/guides/dns-leaks/ website].<br />
<br />
The resolv.conf update script version in [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] implements a different fix for the leaks by using the exclusive interface switch {{ic|-x}} when running the {{ic|resolvconf}} command, but this might cause another form of DNS leakage by making even every local network address resolve via the DNS server provided by Mullvad, as noted in the [https://github.com/masterkorp/openvpn-update-resolv-conf/issues/18 script's GitHub issue page].<br />
<br />
== See also ==<br />
* [https://github.com/mullvad/mullvadvpn-app Mullvad client source code]<br />
* [https://mullvad.net/en/faq/ Mullvad FAQ]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Mullvad&diff=627223Mullvad2020-07-30T16:37:22Z<p>Tobbebobbe: /* Manual configuration */ Added instructions on how to set up manual config using WireGuard, Also manual config for OpenVPN using Gnome gui, and suggestion to use dnsmasq+link</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[es:Mullvad]]<br />
[[ja:Mullvad]]<br />
[https://mullvad.net/en/ Mullvad] is a VPN service based in Sweden which uses [[OpenVPN]] and [[WireGuard]].<br />
<br />
== Installation ==<br />
<br />
The new [https://mullvad.net/download/ official GUI client] is available as {{AUR|mullvad-vpn}}.<br />
<br />
After installation you will need to enable and start the [[systemd]] service {{ic|mullvad-daemon.service}}.<br />
<br />
Alternatively you can use the old client or [[OpenVPN]] with a configuration file for Mullvad as explained in [[#Manual configuration]].<br />
<br />
== Manual configuration ==<br />
<br />
If you do not want to use the Mullvad app you can set it up manually with standard Linux software. Mullvad supports the [OpenVPN] and [WireGuard] protocols. Mullvad themselves [https://mullvad.net/en/help/why-wireguard/ advise] to use WireGuard. However, using OpenVpn may be preferable since for instance the Gnome gui can handle OpenVPN grafically, which makes it easy to see that the VPN is being used, or switching between VPN servers.<br />
<br />
No matter if you opt for OpenVPN or WireGuard, if you use [NetworkManager] you may want to set up [dnsmasq] to decrease DNS-lookup times and also decreasing risk of DNS leakages. Follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#DNS_caching_and_conditional_forwarding DNS_caching_and_conditional_forwarding].<br />
<br />
=== Using {{OpenVPN}} ===<br />
<br />
First make sure the packages {{Pkg|openvpn}} and {{Pkg|openresolv}} are installed, then proceed to download Mullvad's OpenVPN configuration file package from [https://www.mullvad.net/download/config/ their website] (under the "other platforms" tab) and unzip the downloaded file to {{ic|/etc/openvpn/client/}}.<br />
<br />
==== Using The Gnome Network Gui =====<br />
<br />
In [[Gnome]], open Settings, and select Network. Click on the "+" by the VPN section, and choose "Import from file". Choose the config file that you have downloaded from Mullvad. Repeat this step for all of the servers you want to add. Now the VPN connections will show up in the roll down menu up in the right corner, below the primary network connections. At this point you manually have to flick the switch to connect to one of the servers. You may want to choose one of the VPN servers to connect to automatically when connected to the internet, using these steps in [https://wiki.archlinux.org/index.php/NetworkManager#Automatically_connect_to_VPN NetworkManager#Automatically_connect_to_VPN]<br />
<br />
<br />
==== Using [[systemd]] ====<br />
<br />
Rename mullvad_linux.conf for a shorter name to be used with the [[systemd]] service later:<br />
<br />
# mv /etc/openvpn/client/mullvad_linux.conf /etc/openvpn/client/mullvad.conf<br />
<br />
In order to use the nameservers supplied by Mullvad, [[OpenVPN#Update resolv-conf script|update-resolv-conf script]]{{Broken section link}} is being called upon starting and stopping the connection with OpenVPN to modify [[resolv.conf]] to include the correct IP addresses. This script is also included in the Mullvad configuration zipfile, but should be moved to {{ic|/etc/openvpn/}} to match the path specified in the Mullvad configuration file:<br />
<br />
# mv /etc/openvpn/client/update-resolv-conf /etc/openvpn/<br />
<br />
The script can be kept updated with the [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script, which also contains a fix for DNS leaks.<br />
<br />
After configuration the VPN connection can be [[enabled|managed]] with {{ic|openvpn-client@mullvad.service}}. If the service fails to start with an error like {{ic|Cannot open TUN/TAP dev /dev/net/tun: No such device <nowiki>(errno=19)</nowiki>}}, you might need to reboot the system to enable OpenVPN creating the correct network device for the task.<br />
<br />
=== Using {{WireGuard}} ===<br />
<br />
[Install] the {{Pkg|wireguard-tools}} package. Log in to Mullvad with your account and then go to the [https://mullvad.net/en/account/#/wireguard-config/ Wireguard-config page]. Choose Linux as platform, then click generate key to generate a public key. In a terminal, issue the following command to generate a private key:<br />
<br />
# wg genkey<br />
<br />
Click on "Manage keys" on the Mullvad WireGuard config page, and insert the private key you just generated into the field that says "Enter private key", and click on "import key". Fill out step 3 on the website and download the file. Unzip the file you downloaded to get one or several config files depending on your selections in step 3. With these config files you can follow the steps under [https://wiki.archlinux.org/index.php/NetworkManager#Set_up_VPN_with_WireGuard Set_up_VPN_with_WireGuard] in the [NetworkManager] wiki.<br />
<br />
== DNS leaks ==<br />
<br />
By default, the Mullvad openvpn configurations allow DNS leaks and for usual VPN use cases this is an unfavorable privacy defect. Mullvad's new GUI client automatically stops DNS leaks by removing every DNS server IP from the system configuration and replacing them with an IP pointing out to Mullvad's own non-logging DNS server, valid during the VPN connection. This fix can also be applied with the plain OpenVPN method by configuring [[resolv.conf]] to use '''only''' the Mullvad DNS server IP specified on their [https://www.mullvad.net/guides/dns-leaks/ website].<br />
<br />
The resolv.conf update script version in [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] implements a different fix for the leaks by using the exclusive interface switch {{ic|-x}} when running the {{ic|resolvconf}} command, but this might cause another form of DNS leakage by making even every local network address resolve via the DNS server provided by Mullvad, as noted in the [https://github.com/masterkorp/openvpn-update-resolv-conf/issues/18 script's GitHub issue page].<br />
<br />
== See also ==<br />
* [https://github.com/mullvad/mullvadvpn-app Mullvad client source code]<br />
* [https://mullvad.net/en/faq/ Mullvad FAQ]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=NetworkManager&diff=627221NetworkManager2020-07-30T15:37:24Z<p>Tobbebobbe: /* Automatically connect to VPN */ formatting</p>
<hr />
<div>[[Category:Network managers]]<br />
[[Category:Red Hat]]<br />
[[cs:NetworkManager]]<br />
[[de:Networkmanager]]<br />
[[es:NetworkManager]]<br />
[[fr:NetworkManager]]<br />
[[it:NetworkManager]]<br />
[[ja:NetworkManager]]<br />
[[pt:NetworkManager]]<br />
[[zh-hans:NetworkManager]]<br />
{{Related articles start}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related articles end}}<br />
[https://wiki.gnome.org/Projects/NetworkManager/ NetworkManager] is a program for providing detection and configuration for systems to automatically connect to networks. NetworkManager's functionality can be useful for both wireless and wired networks. For wireless networks, NetworkManager prefers known wireless networks and has the ability to switch to the most reliable network. NetworkManager-aware applications can switch from online and offline mode. NetworkManager also prefers wired connections over wireless ones, has support for modem connections and certain types of VPN. NetworkManager was originally developed by Red Hat and now is hosted by the [[GNOME]] project.<br />
<br />
{{Expansion|Clear text storage of secrets is not limited to just Wi-Fi passwords. The secrets are stored in files (and folder) only accesible to root.}}<br />
<br />
{{Warning|By default, Wi-Fi passwords are stored in clear text, see [[#Encrypted Wi-Fi passwords]].}}<br />
<br />
== Installation ==<br />
<br />
NetworkManager can be [[install]]ed with the package {{Pkg|networkmanager}}, which contains a daemon, a command line interface ({{ic|nmcli}}) and a curses‐based interface ({{ic|nmtui}}). <br />
<br />
=== Enable NetworkManager ===<br />
<br />
After installation, you should [[start/enable]] {{ic|NetworkManager.service}}. Once the NetworkManager daemon is started, it will automatically connect to any available "system connections" that have already been configured. Any "user connections" or unconfigured connections will need ''nmcli'' or an applet to configure and connect.<br />
<br />
=== Additional interfaces ===<br />
<br />
* {{Pkg|nm-connection-editor}} for a graphical user interface,<br />
* {{Pkg|network-manager-applet}} for a system tray applet ({{ic|nm-applet}}).<br />
<br />
{{Note|You must ensure that no other service that wants to configure the network is running; in fact, multiple networking services will conflict. You can find a list of the currently running services with {{ic|1=systemctl --type=service}} and then [[stop]] them. See [[#Configuration]] to enable the NetworkManager service.}}<br />
<br />
=== Mobile broadband support ===<br />
<br />
[[Install]] {{Pkg|modemmanager}}, {{Pkg|mobile-broadband-provider-info}} and {{Pkg|usb_modeswitch}} packages for mobile broadband connection support. See [[USB 3G Modem#NetworkManager]] for details.<br />
<br />
=== PPPoE / DSL support ===<br />
<br />
[[Install]] {{Pkg|rp-pppoe}} package for PPPoE / DSL connection support. To actually add PPPoE connection, use {{ic|1=nm-connection-editor}} and add new DSL/PPPoE connection.<br />
<br />
=== VPN support ===<br />
<br />
NetworkManager since version 1.16 has native support for [[WireGuard]], all it needs is the {{ic|wireguard}} kernel module. Read the [https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-networkmanager/ WireGuard in NetworkManager blog post] for details.<br />
<br />
Support for other VPN types is based on a plug-in system. They are provided in the following packages:<br />
<br />
* {{Pkg|networkmanager-openconnect}} for [[OpenConnect]]<br />
* [[networkmanager-openvpn]] for [[OpenVPN]]<br />
* {{Pkg|networkmanager-pptp}} for [[PPTP Client]]<br />
* {{Pkg|networkmanager-vpnc}} for [[Vpnc]]<br />
* {{Pkg|networkmanager-strongswan}} for [[strongSwan]]<br />
* {{AUR|networkmanager-fortisslvpn-git}}<br />
* {{AUR|networkmanager-iodine-git}}<br />
* {{AUR|networkmanager-libreswan}}<br />
* {{AUR|networkmanager-l2tp}}<br />
* {{AUR|networkmanager-ssh-git}}<br />
* {{Pkg|network-manager-sstp}}<br />
<br />
{{Warning|1=There are a lot of [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues?search=VPN&state=opened bugs] (and [https://bugzilla.gnome.org/buglist.cgi?bug_status=__open__&content=VPN&product=NetworkManager old bugs]) related to VPN support. Check the daemon processes options set via the GUI correctly and double-check with each package release.}}<br />
<br />
{{Note|To have fully functioning DNS resolution when using VPN, you should set up [[#DNS caching and conditional forwarding|conditional forwarding]].}}<br />
<br />
==== Set up VPN with WireGuard ====<br />
<br />
The Gnome gui for NetworkManager does not handle WireGuard connections. To add a WireGuard connection from a config-file, issue following command in terminal:<br />
<br />
# nmcli connection import type wireguard file <CONFIG-FILE><br />
<br />
If the file was called WG1.conf a connection called WG1 should have been added. <br />
<br />
If you at any point want to delete the connection, issue the command:<br />
<br />
# nmcli connection delete <CONNECTION NAME><br />
<br />
To actually start the WireGuard tunnel, issue command:<br />
<br />
# nmcli connection up <CONNECTION NAME><br />
<br />
Make sure the connection is listed when you run nmcli:<br />
<br />
# nmcli<br />
<br />
You might want to verify that the private and public keys are correct and corresponds with what you got from your VPN provider:<br />
<br />
# sudo WG_HIDE_KEYS=never wg<br />
<br />
Since WireGuard lacks support in the Gnome gui you may want to proceed to configure NetworkManager to automatically use the WireGuard connection, as described [https://wiki.archlinux.org/index.php/NetworkManager#Automatically_connect_to_VPN elsewhere] on this Wiki page.<br />
<br />
== Usage ==<br />
<br />
NetworkManager comes with {{man|1|nmcli}} and {{man|1|nmtui}}.<br />
<br />
=== nmcli examples ===<br />
<br />
List nearby wifi networks:<br />
<br />
$ nmcli device wifi list<br />
<br />
Connect to a wifi network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
Connect to a hidden network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' hidden yes<br />
<br />
Connect to a wifi on the {{ic|wlan1}} wifi interface:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' ifname wlan1 ''profile_name''<br />
<br />
Disconnect an interface:<br />
<br />
$ nmcli device disconnect ifname eth0<br />
<br />
Reconnect an interface marked as disconnected:<br />
<br />
$ nmcli connection up uuid ''UUID''<br />
<br />
Get a list of UUIDs:<br />
<br />
$ nmcli connection show<br />
<br />
See a list of network devices and their state:<br />
<br />
$ nmcli device<br />
<br />
Turn off wifi:<br />
<br />
$ nmcli radio wifi off<br />
<br />
=== Edit a connection ===<br />
<br />
For a comprehensive list of settings, see {{man|5|nm-settings}}.<br />
<br />
Firstly you need to get list of connections:<br />
<br />
{{hc|$ nmcli connection|<nowiki><br />
NAME UUID TYPE DEVICE<br />
Wired connection 2 e7054040-a421-3bef-965d-bb7d60b7cecf ethernet enp5s0<br />
Wired connection 1 997f2782-f0fc-301d-bfba-15421a2735d8 ethernet enp0s25<br />
MY-HOME-WIFI-5G 92a0f7b3-2eba-49ab-a899-24d83978f308 wifi --<br />
</nowiki>}}<br />
<br />
Here you can use the first column as connection-id used later. In this example we pick {{ic|Wired connection 2}} as a connection-id.<br />
<br />
You have three methods to configure a connection {{ic|Wired connection 2}} after it has been created:<br />
<br />
; nmcli interactive editor<br />
: {{ic|nmcli connection edit 'Wired connection 2'}}.<br> Usage is well documented from the editor.<br />
<br />
; nmcli command line interface<br />
: {{ic|nmcli connection modify 'Wired connection 2' ''setting''.''property'' ''value''}}. See {{man|1|nmcli}} for usage. For example you can change its IPv4 route metric to 200 using {{ic|nmcli connection modify 'Wired connection 2' ipv4.route-metric 200}} command.<br />
<br />
; Connection file<br />
: In {{ic|/etc/NetworkManager/system-connections/}}, modify the corresponding {{ic|Wired connection 2.nmconnection}} file .<br> Do not forget to reload the configuration file with {{ic|nmcli connection reload}}.<br />
<br />
== Front-ends ==<br />
<br />
To configure and have easy access to NetworkManager, most users will want to install an applet. This GUI front-end usually resides in the system tray (or notification area) and allows network selection and configuration of NetworkManager. Various desktop environments have their own applet. Otherwise you can use [[#nm-applet]].<br />
<br />
=== GNOME ===<br />
<br />
[[GNOME]] has a built-in tool, accessible from the Network settings.<br />
<br />
=== KDE Plasma ===<br />
<br />
[[Install]] the {{Pkg|plasma-nm}} package. After that, add it to the KDE taskbar via the ''Panel options > Add widgets > Networks'' menu.<br />
<br />
=== nm-applet ===<br />
<br />
{{Pkg|network-manager-applet}} is a GTK 3 front-end which works under Xorg environments with a systray.<br />
<br />
To store connection secrets install and configure [[GNOME/Keyring]].<br />
<br />
Be aware that after enabling the tick-box option {{ic|Make available to other users}} for a connection, NetworkManager stores the password in plain-text, though the respective file is accessible only to root (or other users via {{ic|nm-applet}}). See [[#Encrypted Wi-Fi passwords]].<br />
<br />
In order to run {{ic|nm-applet}} without a systray, you can use {{Pkg|trayer}} or {{Pkg|stalonetray}}. For example, you can add a script like this one in your path:<br />
<br />
{{hc|nmgui|<nowiki><br />
#!/bin/sh<br />
nm-applet 2>&1 > /dev/null &<br />
stalonetray 2>&1 > /dev/null<br />
killall nm-applet<br />
</nowiki>}}<br />
<br />
When you close the ''stalonetray'' window, it closes {{ic|nm-applet}} too, so no extra memory is used once you are done with network settings.<br />
<br />
The applet can show notifications for events such as connecting to or disconnecting from a WiFi network. For these notifications to display, ensure that you have a notification server installed - see [[Desktop notifications]]. If you use the applet without a notification server, you might see some messages in stdout/stderr, and the app might hang. See [https://bugzilla.gnome.org/show_bug.cgi?id=788313].<br />
<br />
In order to run {{ic|nm-applet}} with such notifications disabled, start the applet with the following command:<br />
<br />
$ nm-applet --no-agent<br />
<br />
{{Tip|{{ic|nm-applet}} might be started automatically with a [[XDG Autostart|autostart desktop file]], to add the --no-agent option modify the Exec line there, i.e.<br />
<br />
{{bc|1=Exec=nm-applet --no-agent}}<br />
<br />
}}<br />
<br />
{{Warning|On [[i3]], if nm-applet is started with the {{ic|--no-agent}} option, it is not possible to connect to a new encrypted WiFi network by clicking on the item list because no password input dialogue window will pop out. [[journal]] will show {{ic|no secrets: No agents were available for this request}}.}}<br />
<br />
==== Appindicator ====<br />
<br />
As of version 1.18.0 Appindicator support is [https://github.com/archlinux/svntogit-packages/commit/7640a2bd557fe84813207ef4d5e35bb5aece6c54 available] in the official {{Pkg|network-manager-applet}} package. To use nm-applet in an Appindicator environment start the applet with the following command:<br />
<br />
$ nm-applet --indicator<br />
<br />
=== networkmanager-dmenu ===<br />
<br />
Alternatively there is {{AUR|networkmanager-dmenu-git}} which is a small script to manage NetworkManager connections with [[dmenu]] or [[rofi]] instead of {{ic|nm-applet}}. It provides all essential features such as connection to existing NetworkManager wifi or wired connections, connect to new wifi connections, requests passphrase if required, connect to existing VPN connections, enable/disable networking, launch ''nm-connection-editor'' GUI, connect to Bluetooth networks.<br />
<br />
== Configuration ==<br />
<br />
NetworkManager will require some additional steps to be able run properly. Make sure you have configured {{ic|/etc/hosts}} as described in [[Network configuration#Set the hostname]] section.<br />
<br />
NetworkManager has a global configuration file at {{ic|/etc/NetworkManager/NetworkManager.conf}}. Addition configuration files can be placed in {{ic|/etc/NetworkManager/conf.d/}}. Usually no configuration needs to be done to the global defaults.<br />
<br />
After editing a configuration file, the changes can be applied by running:<br />
<br />
# nmcli general reload<br />
<br />
=== Enable NetworkManager Wait Online ===<br />
<br />
{{Out of date|{{ic|NetworkManager.service}} has {{ic|1=Also=NetworkManager-wait-online.service}} in the {{ic|[Install]}} section.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/167e42a87e97ed7fb26a4263c22f1774716ac51b] If {{ic|NetworkManager.service}} was [[enable]]d before the change, it needs to be [[enable|reenabled]].}}<br />
<br />
If you have services which fail if they are started before the network is up, you may use {{ic|NetworkManager-wait-online.service}} in addition to {{ic|NetworkManager.service}}. This is, however, rarely necessary because most networked daemons start up okay, even if the network has not been configured yet.<br />
<br />
In some cases, the service will still fail to start successfully on boot due to the timeout setting in {{ic|/usr/lib/systemd/system/NetworkManager-wait-online.service}} being too short. Change the default timeout from 30 to a higher value.<br />
<br />
=== Set up PolicyKit permissions ===<br />
<br />
See [[General troubleshooting#Session permissions]] for setting up a working session.<br />
<br />
With a working session, you have several options for granting the necessary privileges to NetworkManager:<br />
<br />
* ''Option 1.'' Run a [[Polkit]] authentication agent when you log in, such as {{ic|/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1}} (part of {{Pkg|polkit-gnome}}). You will be prompted for your password whenever you add or remove a network connection.<br />
* ''Option 2.'' [[Users and groups#Group management|Add]] yourself to the {{ic|wheel}} group. You will not have to enter your password, but your user account may be granted other permissions as well, such as the ability to use [[sudo]] without entering the root password.<br />
* ''Option 3.'' [[Users and groups#Group management|Add]] yourself to the {{ic|network}} group and create the following file:<br />
<br />
{{hc|/etc/polkit-1/rules.d/50-org.freedesktop.NetworkManager.rules|<nowiki><br />
polkit.addRule(function(action, subject) {<br />
if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0 && subject.isInGroup("network")) {<br />
return polkit.Result.YES;<br />
}<br />
});<br />
</nowiki>}}<br />
<br />
: All users in the {{ic|network}} group will be able to add and remove networks without a password. This will not work under [[systemd]] if you do not have an active session with ''systemd-logind''.<br />
<br />
=== Proxy settings ===<br />
<br />
NetworkManager does not directly handle proxy settings, but if you are using [[GNOME]] or [[KDE]], you could use [http://marin.jb.free.fr/proxydriver/ proxydriver] which handles proxy settings using NetworkManager's information. proxydriver is found in the package {{AUR|proxydriver}}.<br />
<br />
In order for ''proxydriver'' to be able to change the proxy settings, you would need to execute this command, as part of the GNOME startup process (see [[GNOME#Autostart]]).<br />
<br />
xhost +si:localuser:''username''<br />
<br />
See also [[Proxy settings]].<br />
<br />
=== Checking connectivity ===<br />
<br />
NetworkManager can try to reach a page on Internet when connecting to a network. {{Pkg|networkmanager}} is configured by default in {{ic|/usr/lib/NetworkManager/conf.d/20-connectivity.conf}} to check connectivity to archlinux.org. To use a different webserver or disable connectivity checking create {{ic|/etc/NetworkManager/conf.d/20-connectivity.conf}}, see {{man|5|NetworkManager.conf|CONNECTIVITY SECTION}}. Below is an example of using GNOME servers (it does not require the use of [[GNOME]]):<br />
<br />
{{hc|/etc/NetworkManager/conf.d/20-connectivity.conf|<nowiki><br />
[connectivity]<br />
uri=http://nmcheck.gnome.org/check_network_status.txt<br />
</nowiki>}}<br />
<br />
{{Note|Although automatic connectivity checks are a potential privacy leak, the official archlinux.org default connectivity URL is committed to not logging any access. See [https://gitlab.archlinux.org/archlinux/infrastructure/-/commit/68fbaca2ef9f31f624f117899848f4288d6b39d1].}}<br />
<br />
=== Captive portals ===<br />
<br />
{{Style|Complex scripts should not be maintained on the wiki.}}<br />
<br />
For those behind a [[Wikipedia:Captive portal|captive portal]], the desktop manager may automatically open a window asking for credentials. If your desktop does not, you can use {{Pkg|capnet-assist}} package (however, it currently it has a broken NetworkManager dispatcher script). Alternatively, you can create a NetworkManager dispatcher script with the following content:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/90-open_captive_portal|<nowiki><br />
#!/bin/sh -e<br />
# Script to dispatch NetworkManager events<br />
#<br />
# Runs shows a login webpage on walled garden networks.<br />
# See NetworkManager(8) for further documentation of the dispatcher events.<br />
<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin<br />
<br />
if [ -x "/usr/bin/logger" ]; then<br />
logger="/usr/bin/logger -s -t captive-portal"<br />
else<br />
logger=":"<br />
fi<br />
<br />
wait_for_process() {<br />
PNAME=$1<br />
while [ -z "$(/usr/bin/pgrep $PNAME)" ]; do<br />
sleep 3;<br />
done<br />
}<br />
<br />
#launch the browser, but on boot we need to wait that nm-applet starts<br />
start_browser() {<br />
local user="$1"<br />
local display="$2"<br />
<br />
export DISPLAY="$display"<br />
wait_for_process nm-applet<br />
<br />
export XAUTHORITY="/home/$user/.Xauthority"<br />
<br />
$logger "Running browser as '$user' with display '$display' to login in captive portal"<br />
sudo -u "$user" --preserve-env=DISPLAY,XAUTHORITY -H xdg-open http://capnet.elementary.io 2>&1 > /dev/null<br />
}<br />
<br />
# Run the right scripts<br />
case "$2" in<br />
connectivity-change)<br />
$logger -p user.debug "dispatcher script triggered on connectivity change: $CONNECTIVITY_STATE"<br />
if [ "$CONNECTIVITY_STATE" = "PORTAL" ]; then<br />
# Match last column of who's output with ' :[at least one digit] '<br />
who | awk '$NF ~ /\(:[0-9]+\)/ { print $1 " " substr($NF, 2, length($NF)-2) };' | \<br />
while read user display; do<br />
start_browser $user $display || $logger -p user.err "Failed for user: '$user' display: '$display'"<br />
done<br />
fi<br />
;;<br />
*)<br />
# In a down phase<br />
exit 0<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
You will need to [[restart]] {{ic|NetworkManager.service}} or reboot for this to start working. Once you do, the dispatcher script should open a login window once it detects you are behind a captive portal.<br />
<br />
Another solution is {{AUR|captive-browser-git}} based on Google Chrome.<br />
<br />
=== DHCP client ===<br />
<br />
By default NetworkManager uses its internal DHCP client. The internal DHCPv4 plugin is based on the [https://nettools.github.io/n-dhcp4/ nettools' n-dhcp4] library, while the internal DHCPv6 plugin is made from code based on systemd-networkd.<br />
<br />
To use ISC’s DHCP client, [[install]] {{Pkg|dhclient}}. To change the DHCP client backend, set the option {{ic|1=main.dhcp=''dhcp_client_name''}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}. E.g.:<br />
<br />
{{hc|1=/etc/NetworkManager/conf.d/dhcp-client.conf|2=<br />
[main]<br />
dhcp=dhclient<br />
}}<br />
<br />
{{Note|<br />
* Do not enable the systemd units shipped with the {{Pkg|dhclient}} and {{Pkg|dhcpcd}} packages. They will conflict with NetworkManager, see the note in [[#Installation]] for details.<br />
* NetworkManger does not support dhcpcd ≥ 9.0.0. See {{Bug|66231}}.<br />
}}<br />
<br />
=== DNS management ===<br />
<br />
NetworkManager's DNS management is described in the GNOME project's wiki page—[https://wiki.gnome.org/Projects/NetworkManager/DNS Projects/NetworkManager/DNS].<br />
<br />
==== DNS caching and conditional forwarding ====<br />
<br />
NetworkManager has a plugin to enable DNS caching and conditional forwarding ([https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/143 previously] called "split DNS" in NetworkManager's documentation) using [[dnsmasq]] or [[systemd-resolved]]. The advantages of this setup is that DNS lookups will be cached, shortening resolve times, and DNS lookups of VPN hosts will be routed to the relevant VPN's DNS servers. This is especially useful if you are connected to more than one VPN.<br />
<br />
===== dnsmasq =====<br />
<br />
Make sure {{Pkg|dnsmasq}} has been installed. Then set {{ic|1=main.dns=dnsmasq}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=dnsmasq<br />
}}<br />
<br />
Now run {{ic|nmcli general reload}} as root. NetworkManager will automatically start dnsmasq and add {{ic|127.0.0.1}} to {{ic|/etc/resolv.conf}}. The original DNS servers can be found in {{ic|/run/NetworkManager/no-stub-resolv.conf}}. You can verify dnsmasq is being used by doing the same DNS lookup twice with {{ic|drill example.com}} and verifying the server and query times.<br />
<br />
{{Note|<br />
* You do not need to start {{ic|dnsmasq.service}} or edit {{ic|/etc/dnsmasq.conf}}. NetworkManager will start dnsmasq without using the systemd service and without reading the dnsmasq's default configuration file(s).<br />
* The dnsmasq instance started by NetworkManager will bind to {{ic|127.0.0.1:53}}, you cannot run any other software (including {{ic|dnsmasq.service}}) on the same address and port.<br />
}}<br />
<br />
====== Custom dnsmasq configuration ======<br />
<br />
Custom configurations can be created for ''dnsmasq'' by creating configuration files in {{ic|/etc/NetworkManager/dnsmasq.d/}}. For example, to change the size of the DNS cache (which is stored in RAM):<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/cache.conf|2=<br />
cache-size=1000<br />
}}<br />
<br />
{{Tip|Check the configuration file syntax with {{ic|1=dnsmasq --test --conf-file=/dev/null --conf-dir=/etc/NetworkManager/dnsmasq.d}}.}}<br />
<br />
See {{man|8|dnsmasq}} for all available options.<br />
<br />
====== IPv6 ======<br />
<br />
{{Accuracy|This does not solve the issue because NetworkManager does not add {{ic|::1}} to {{ic|/etc/resolv.conf}}. Unless {{ic|@::1}} is manually passed to drill, it will still fail with {{ic|Error: error sending query: No (valid) nameservers defined in the resolver}}.}}<br />
<br />
Enabling {{ic|dnsmasq}} in NetworkManager may break IPv6-only DNS lookups (i.e. {{ic|drill -6 [hostname]}}) which would otherwise work. In order to resolve this, creating the following file will configure ''dnsmasq'' to also listen to the IPv6 loopback:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/ipv6-listen.conf|2=<br />
listen-address=::1<br />
}}<br />
<br />
In addition, {{ic|dnsmasq}} also does not prioritize upstream IPv6 DNS. Unfortunately NetworkManager does not do this ([https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/936712 Ubuntu Bug]). A workaround would be to disable IPv4 DNS in the NetworkManager config, assuming one exists<br />
<br />
====== DNSSEC ======<br />
<br />
The dnsmasq instance started by NetworkManager by default will not validate [[DNSSEC]] since it is started with the {{ic|--proxy-dnssec}} option. It will trust whatever DNSSEC information it gets from the upstream DNS server.<br />
<br />
For dnsmasq to properly validate DNSSEC, thus breaking DNS resolution with name servers that do not support it, create the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/dnssec.conf|2=<br />
conf-file=/usr/share/dnsmasq/trust-anchors.conf<br />
dnssec<br />
}}<br />
<br />
===== systemd-resolved =====<br />
<br />
{{Expansion|NetworkManager 1.16 adds a new setting {{ic|main.systemd-resolved}}[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383] (enabled by default). It unconditionally sends DNS configuration to systemd-resolved. Related to "Preserving resolv.conf" from [[systemd-resolved#DNS]]?}}<br />
<br />
NetworkManager can use [[systemd-resolved]] as a DNS resolver and cache. Make sure that ''systemd-resolved'' is properly configured and that {{ic|systemd-resolved.service}} is [[started]] before using it.<br />
<br />
systemd-resolved will be used automatically if {{ic|/etc/resolv.conf}} is a [[Systemd-resolved#DNS|symlink]] to {{ic|/run/systemd/resolve/stub-resolv.conf}}, {{ic|/run/systemd/resolve/resolv.conf}} or {{ic|/usr/lib/systemd/resolv.conf}}.<br />
<br />
You can enable it explicitly by setting {{ic|1=main.dns=systemd-resolved}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=systemd-resolved<br />
}}<br />
<br />
===== DNS resolver with an openresolv subscriber =====<br />
<br />
If [[openresolv]] has a subscriber for your local [[DNS resolver]], set up the subscriber and [[#Use openresolv|configure NetworkManager to use openresolv]].<br />
<br />
Because NetworkManager advertises a single "interface" to ''resolvconf'', it is not possible to implement conditional forwarding between two NetworkManager connections. See [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 NetworkManager issue 153].<br />
<br />
This can be partially mitigated if you set {{ic|1=private="*"}} in {{ic|/etc/resolvconf.conf}}[https://roy.marples.name/projects/openresolv/configuration.html]. Any queries for domains that are not in search domain list will not get forwarded. They will be handled according to the local resolver's configuration, for example, forwarded to another DNS server or resolved recursively from the DNS root.<br />
<br />
==== Custom DNS servers ====<br />
<br />
===== Setting custom global DNS servers =====<br />
<br />
To set DNS servers for all connections, specify them in {{man|5|NetworkManager.conf}} using the syntax {{ic|1=servers=''serveripaddress1'',''serveripaddress2'',''serveripaddress3''}} in a section named {{ic|[global-dns-domain-*]}}. For example:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns-servers.conf|2=<br />
[global-dns-domain-*]<br />
servers=::1,127.0.0.1<br />
}}<br />
<br />
{{Note|<br />
* If you use [[#DNS caching and conditional forwarding|NetworkManager's dnsmasq or systemd-resolved plugin]] or [[#DNS resolver with an openresolv subscriber|openresolv subscribers]], then do not specify loopback addresses with the {{ic|1=servers=}} option, it can break DNS resolution.<br />
* The specified servers do not get sent to [[systemd-resolved]], the connection's DNS servers are used instead.<br />
}}<br />
<br />
===== Setting custom DNS servers in a connection =====<br />
<br />
====== Setting custom DNS servers in a connection (GUI) ======<br />
<br />
Setup will depend on the type of front-end used; the process usually involves right-clicking on the applet, editing (or creating) a profile, and then choosing DHCP type as ''Automatic (specify addresses)''. The DNS addresses will need to be entered and are usually in this form: {{ic|127.0.0.1, ''DNS-server-one'', ...}}.<br />
<br />
====== Setting custom DNS servers in a connection (nmcli / connection file) ======<br />
<br />
To setup DNS Servers per connection, you can use the {{ic|dns}} field (and the associated {{ic|dns-search}} and {{ic|dns-options}}) in the [[#Edit a connection|connection settings]]. <br />
<br />
If {{ic|method}} is set to {{ic|auto}} (when you use DHCP), you need to set {{ic|ignore-auto-dns}} to {{ic|yes}}.<br />
<br />
==== /etc/resolv.conf ====<br />
<br />
By default {{ic|/etc/resolv.conf}} is managed by ''NetworkManager'' unless it is a symlink.<br />
<br />
It can be configured to write it through [[#Use openresolv|openresolv]] or to [[#Unmanaged /etc/resolv.conf|not touch it at all]].<br />
<br />
Using openresolv allows NetworkManager to coexists with other ''resolvconf'' supporting software or, for example, to run a local DNS caching and split-DNS resolver for which openresolv has a [[openresolv#Subscribers|subscriber]].<br />
<br />
{{Note|Conditional forwarding is [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 not yet fully supported] when using NetworkManager with openresolv.}}<br />
<br />
''NetworkManager'' also offers hooks via so called dispatcher scripts that can be used to alter the {{ic|/etc/resolv.conf}} after network changes. See [[#Network services with NetworkManager dispatcher]] and {{man|8|NetworkManager}} for more information.<br />
<br />
{{Note|<br />
* If NetworkManager is configured to use either [[#dnsmasq|dnsmasq]] or [[#systemd-resolved|systemd-resolved]], then the appropriate loopback addresses will be written to {{ic|/etc/resolv.conf}}.<br />
* The {{ic|resolv.conf}} file NetworkManager writes or would write to {{ic|/etc/resolv.conf}} can be found at {{ic|/run/NetworkManager/resolv.conf}}.<br />
* A {{ic|resolv.conf}} file with the acquired name servers and search domains can be found at {{ic|/run/NetworkManager/no-stub-resolv.conf}}.<br />
}}<br />
<br />
===== Unmanaged /etc/resolv.conf =====<br />
<br />
To stop NetworkManager from touching {{ic|/etc/resolv.conf}}, set {{ic|1=main.dns=none}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=none<br />
}}<br />
<br />
{{Tip|You might also want to set {{ic|1=main.systemd-resolved=false}}, so that NetworkManager does not send the DNS configuration to [[systemd-resolved]].}}<br />
<br />
{{Note|See [[#DNS caching and conditional forwarding]], to configure NetworkManager using other DNS backends like [[dnsmasq]] and [[systemd-resolved]], instead of using {{ic|1=main.dns=none}}.}}<br />
<br />
After that {{ic|/etc/resolv.conf}} might be a broken symlink that you will need to remove. Then, just create a new {{ic|/etc/resolv.conf}} file.<br />
<br />
===== Use openresolv =====<br />
<br />
{{Note|Do not set {{ic|1=rc-manager=resolvconf}} when {{Pkg|systemd-resolvconf}} is installed. ''systemd-resolved'' provides limited support for the ''resolvconf'' interface and NetworkManager supports communicating with systemd-resolved through D-Bus without using ''resolvconf''.}}<br />
<br />
To configure NetworkManager to use [[openresolv]], set {{ic|1=main.rc-manager=resolvconf}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/rc-manager.conf|2=<br />
[main]<br />
rc-manager=resolvconf<br />
}}<br />
<br />
=== Firewall ===<br />
<br />
You can assign a [[firewalld]] zone based on your current connection. For example a restrictive firewall when at work, and a less restrictive one when at home.<br />
<br />
This can also be done with [[#Network services with NetworkManager dispatcher|NetworkManager dispatcher]].<br />
<br />
=== 802.1x / PEAP configuration ===<br />
<br />
A PEAP and 802.1x network can be added by adding a config file to {{ic|/etc/NetworkManager/system-connections/''name''}}.<br />
<br />
Here is an example configuration file for IPv4 with IPv6 disabled:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''name''|2=<br />
[ipv6]<br />
method=ignore<br />
<br />
[ipv4]<br />
method=auto<br />
<br />
[connection]<br />
#id=XXXXXXXXX<br />
#uuid=XXXXXXXXX<br />
type=802-11-wireless<br />
#timestamp=XXXX<br />
<br />
[802-11-wireless-security]<br />
key-mgmt=wpa-eap<br />
<br />
[802-11-wireless]<br />
ssid=ssid<br />
mode=infrastructure<br />
#seen-bssids=XXXXXXXXX<br />
security=802-11-wireless-security<br />
<br />
[802-1x]<br />
eap=peap;<br />
identity=user<br />
password=password<br />
phase2-auth=mschapv2<br />
}}<br />
<br />
The number sign (#) defines comments.<br />
<br />
=== Automatically connect to VPN ===<br />
<br />
NetworkManager can be set to automatically connect to a VPN when connecting to the internet, on a per network basis. The VPN connection itself can be added in the Gnome gui, but to make it automatically use the VPN {{ic|nmcli}} must be used.<br />
<br />
First, make sure to make the VPN connection available to all users. In the Gnome gui this is a matter of checking a box under the {{ic|details}} tab. Then under the {{ic|Identity}} tab, in the password field, click the icon on the right side in the field, and set it to {{ic|Store the password for all users}}.<br />
<br />
Then use the {{ic|nmcli}} tool via command line to list your connections:<br />
<br />
# nmcli connection<br />
<br />
Then enter configuration mode for the internet connection you want to automatically connect to a VPN:<br />
<br />
# nmcli connection edit <NAME of Internet Connection><br />
<br />
Please note that it is the Internet connection and not the VPN you should edit. Here you do not need to use the UUID of the Internet connection, the NAME is fine. Then make the setting with the command:<br />
<br />
# set connection.secondaries <UUID of VPN><br />
<br />
Here the UUID of the VPN must be used, but {{ic|tab}} works for autocompletion.<br />
<br />
Finally save and quit:<br />
<br />
# save<br />
# quit<br />
<br />
Now when NetworkManager is restarted and you connect to the Internet connection you have configured, you should automatically get connected to the VPN.<br />
<br />
== Network services with NetworkManager dispatcher ==<br />
<br />
There are quite a few network services that you will not want running until NetworkManager brings up an interface. NetworkManager has the ability to start services when you connect to a network and stop them when you disconnect (e.g. when using [[NFS]], [[SMB]] and [[NTPd]]).<br />
<br />
To activate the feature you need to [[enable]] and [[start]] the {{ic|NetworkManager-dispatcher.service}}.<br />
<br />
Once the service is active, scripts can be added to the {{ic|/etc/NetworkManager/dispatcher.d}} directory.<br />
<br />
Scripts must be owned by '''root''', otherwise the dispatcher will not execute them. For added security, set group [[ownership]] to root as well:<br />
<br />
# chown root:root /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
Make sure the file has correct permissions:<br />
<br />
# chmod 755 /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
The scripts will be run in alphabetical order at connection time, and in reverse alphabetical order at disconnect time. To ensure what order they come up in, it is common to use numerical characters prior to the name of the script (e.g. {{ic|10-portmap}} or {{ic|30-netfs}} (which ensures that the ''portmapper'' is up before NFS mounts are attempted).<br />
<br />
Scripts will receive the following arguments:<br />
<br />
* '''Interface name:''' e.g. {{ic|eth0}}<br />
* '''Interface status:''' ''up'' or ''down''<br />
* '''VPN status:''' ''vpn-up'' or ''vpn-down''<br />
<br />
{{Warning|If you connect to foreign or public networks, be aware of what services you are starting and what servers you expect to be available for them to connect to. You could make a security hole by starting the wrong services while connected to a public network.}}<br />
<br />
=== Avoiding the dispatcher timeout ===<br />
<br />
If the above is working, then this section is not relevant. However, there is a general problem related to running dispatcher scripts which take longer to be executed. Initially an internal timeout of three seconds only was used. If the called script did not complete in time, it was killed. Later the timeout was extended to about 20 seconds (see the [https://bugzilla.redhat.com/show_bug.cgi?id=982734 Bugtracker] for more information). If the timeout still creates the problem, a work around may be to modify the dispatcher service file {{ic|/usr/lib/systemd/system/NetworkManager-dispatcher.service}} to remain active after exit: <br />
<br />
{{hc|/etc/systemd/system/NetworkManager-dispatcher.service.d/remain_after_exit.conf|2=<br />
[Service]<br />
RemainAfterExit=yes<br />
}}<br />
<br />
Now start and enable the modified {{ic|NetworkManager-dispatcher}} service.<br />
<br />
{{Warning|Adding the {{ic|RemainAfterExit}} line to it will prevent the dispatcher from closing. Unfortunately, the dispatcher '''has''' to close before it can run your scripts again. With it the dispatcher will not time out but it also will not close, which means that the scripts will only run once per boot. Therefore, do not add the line unless the timeout is definitely causing a problem.}}<br />
<br />
=== Dispatcher examples ===<br />
<br />
==== Mount remote folder with sshfs ====<br />
<br />
As the script is run in a very restrictive environment, you have to export {{ic|SSH_AUTH_SOCK}} in order to connect to your SSH agent. There are different ways to accomplish this, see [https://bbs.archlinux.org/viewtopic.php?pid=1042030#p1042030 this message] for more information. The example below works with [[GNOME Keyring]], and will ask you for the password if not unlocked already. In case NetworkManager connects automatically on login, it is likely ''gnome-keyring'' has not yet started and the export will fail (hence the sleep). The {{ic|UUID}} to match can be found with the command {{ic|nmcli connection status}} or {{ic|nmcli connection list}}. <br />
<br />
{{bc|<nowiki><br />
#!/bin/sh<br />
USER='username'<br />
REMOTE='user@host:/remote/path'<br />
LOCAL='/local/path'<br />
<br />
interface=$1 status=$2<br />
if [ "$CONNECTION_UUID" = "</nowiki>''uuid''<nowiki>" ]; then<br />
case $status in<br />
up)<br />
SSH_AUTH_SOCK=$(find /tmp -maxdepth 1 -type s -user "$USER" -name 'ssh')<br />
export SSH_AUTH_SOCK<br />
su "$USER" -c "sshfs $REMOTE $LOCAL"<br />
;;<br />
down)<br />
fusermount -u "$LOCAL"<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
==== Mounting of SMB shares ====<br />
<br />
Some [[SMB]] shares are only available on certain networks or locations (e.g. at home). You can use the dispatcher to only mount SMB shares that are present at your current location.<br />
<br />
The following script will check if we connected to a specific network and mount shares accordingly:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-mount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
# Find the connection UUID with "nmcli connection show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
if [ "$2" = "up" ]; then<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
mount /your/mount/point & <br />
# add more shares as needed<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The following script will unmount all SMB shares before a software initiated disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/pre-down.d/30-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|Make sure this script is located in the {{ic|pre-down.d}} sub-directory as shown above, otherwise it will unmount all shares on any connection state change.}}<br />
<br />
The following script will attempt to unmount all SMB shares following an unexpected disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/40-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
if [ "$2" = "down" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|<br />
* Since NetworkManager 0.9.8, the ''pre-down'' and ''down'' events are not executed on shutdown or restart, see [https://bugzilla.gnome.org/show_bug.cgi?id&#61;701242 this bug report] for more info.<br />
* The previous ''umount'' scripts are still prone to leaving applications actually accessing the mount to 'hang'.<br />
}}<br />
<br />
An alternative is to use the script as seen in [[NFS#Using a NetworkManager dispatcher]]:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-smb.sh|<nowiki><br />
#!/bin/bash<br />
<br />
# Find the connection UUID with "nmcli con show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
WANTED_CON_UUID="CHANGE-ME-NOW-9c7eff15-010a-4b1c-a786-9b4efa218ba9"<br />
<br />
if [[ "$CONNECTION_UUID" == "$WANTED_CON_UUID" ]]; then<br />
<br />
# Script parameter $1: NetworkManager connection name, not used<br />
# Script parameter $2: dispatched event<br />
<br />
case "$2" in<br />
"up")<br />
mount -a -t cifs<br />
;;<br />
"pre-down");&<br />
"vpn-pre-down")<br />
umount -l -a -t cifs >/dev/null<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|This script ignores mounts with the {{ic|noauto}} option, remove this mount option or use {{ic|auto}} to allow the dispatcher to manage these mounts.}}<br />
<br />
Create a symlink inside {{ic|/etc/NetworkManager/dispatcher.d/pre-down/}} to catch the {{ic|pre-down}} events:<br />
<br />
# ln -s ../30-smb.sh /etc/NetworkManager/dispatcher.d/pre-down.d/30-smb.sh<br />
<br />
==== Mounting of NFS shares ====<br />
<br />
See [[NFS#Using a NetworkManager dispatcher]].<br />
<br />
==== Use dispatcher to automatically toggle wireless depending on LAN cable being plugged in ====<br />
<br />
The idea is to only turn Wi-Fi on when the LAN cable is unplugged (for example when detaching from a laptop dock), and for Wi-Fi to be automatically disabled, once a LAN cable is plugged in again. <br />
<br />
Create the following dispatcher script[https://superuser.com/questions/233448/disable-wlan-if-wired-cable-network-is-available], replacing {{ic|1=LAN_interface}} with yours.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/wlan_auto_toggle.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$1" = "LAN_interface" ]; then<br />
case "$2" in<br />
up)<br />
nmcli radio wifi off<br />
;;<br />
down)<br />
nmcli radio wifi on<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|You can get a list of interfaces using [[#nmcli examples|nmcli]]. The ethernet (LAN) interfaces start with {{ic|en}}, e.g. {{ic|1=enp0s5}}}}<br />
<br />
==== Use dispatcher to connect to a VPN after a network connection is established ====<br />
<br />
In this example we want to connect automatically to a previously defined VPN connection after connecting to a specific Wi-Fi network. First thing to do is to create the dispatcher script that defines what to do after we are connected to the network.<br />
<br />
{{Note|This script will require {{Pkg|wireless_tools}} in order to use {{ic|iwgetid}}.}}<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME"<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you would like to attempt to automatically connect to VPN for all Wi-Fi networks, you can use the following definition of the ESSID: {{ic|1=ESSID=$(iwgetid -r)}}. Remember to set the script's permissions [[#Network services with NetworkManager dispatcher|accordingly]]. <br />
<br />
Trying to connect with the above script may still fail with {{ic|NetworkManager-dispatcher.service}} complaining about 'no valid VPN secrets', because of [https://developer.gnome.org/NetworkManager/0.9/secrets-flags.html the way VPN secrets are stored]. Fortunately, there are different options to give the above script access to your VPN password.<br />
<br />
1: One of them requires editing the VPN connection configuration file to make NetworkManager store the secrets by itself rather than inside a keyring [https://bugzilla.redhat.com/show_bug.cgi?id=710552 that will be inaccessible for root]: open up {{ic|/etc/NetworkManager/system-connections/''name of your VPN connection''}} and change the {{ic|password-flags}} and {{ic|secret-flags}} from {{ic|1}} to {{ic|0}}.<br />
<br />
If that alone does not work, you may have to create a {{ic|passwd-file}} in a safe location with the same permissions and ownership as the dispatcher script, containing the following:<br />
<br />
{{hc|/path/to/passwd-file|<br />
vpn.secrets.password:YOUR_PASSWORD<br />
}}<br />
<br />
The script must be changed accordingly, so that it gets the password from the file:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME" passwd-file /path/to/passwd-file<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
2: Alternatively, change the {{ic|password-flags}} and put the password directly in the configuration file adding the section {{ic|vpn-secrets}}:<br />
<br />
[vpn]<br />
....<br />
password-flags=0<br />
<br />
[vpn-secrets]<br />
password=''your_password''<br />
<br />
{{Note|It may now be necessary to re-open the NetworkManager connection editor and save the VPN passwords/secrets again.}}<br />
<br />
==== Use dispatcher to disable IPv6 on VPN provider connections ====<br />
<br />
Many [[:Category:VPN providers|commercial VPN providers]] support only IPv4. That means all IPv6 traffic bypasses the VPN and renders it virtually useless. To avoid this, dispatcher can be used to disable all IPv6 traffic for the time a VPN connection is up.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/10-vpn-ipv6|<nowiki><br />
#!/bin/sh<br />
<br />
case "$2" in<br />
vpn-up)<br />
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
vpn-down)<br />
echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
==== OpenNTPD ====<br />
<br />
See [[OpenNTPD#Using NetworkManager dispatcher]].<br />
<br />
== Testing ==<br />
<br />
NetworkManager applets are designed to load upon login so no further configuration should be necessary for most users. If you have already disabled your previous network settings and disconnected from your network, you can now test if NetworkManager will work. The first step is to [[start]] {{ic|NetworkManager.service}}.<br />
<br />
Some applets will provide you with a {{ic|.desktop}} file so that the NetworkManager applet can be loaded through the application menu. If it does not, you are going to either have to discover the command to use or logout and login again to start the applet. Once the applet is started, it will likely begin polling network connections with for auto-configuration with a DHCP server.<br />
<br />
To start the GNOME applet in non-xdg-compliant window managers like [[awesome]]:<br />
<br />
nm-applet --sm-disable &<br />
<br />
For static IP addresses, you will have to configure NetworkManager to understand them. The process usually involves right-clicking the applet and selecting something like 'Edit Connections'.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Encrypted Wi-Fi passwords ===<br />
<br />
By default, NetworkManager stores passwords in clear text in the connection files at {{ic|/etc/NetworkManager/system-connections/}}. To print the stored passwords, use the following command:<br />
<br />
# grep -r '^psk=' /etc/NetworkManager/system-connections/<br />
<br />
The passwords are accessible to the root user in the filesystem and to users with access to settings via the GUI (e.g. {{ic|nm-applet}}). <br />
<br />
It is preferable to save the passwords in encrypted form in a keyring instead of clear text. The downside of using a keyring is that the connections have to be set up for each user.<br />
<br />
==== Using GNOME Keyring ====<br />
<br />
The keyring daemon has to be started and the keyring needs to be unlocked for the following to work.<br />
<br />
Furthermore, NetworkManager needs to be configured not to store the password for all users. Using GNOME {{ic|nm-applet}}, run {{ic|nm-connection-editor}} from a terminal, select a network connection, click {{ic|Edit}}, select the {{ic|Wifi-Security}} tab and click on the right icon of password and check {{ic|Store the password only for this user}}.<br />
<br />
==== Using KDE Wallet ====<br />
<br />
Using KDE's {{Pkg|plasma-nm}}, click the applet, click on the top right {{ic|Settings}} icon, click on a network connection, in the {{ic|General settings}} tab, untick {{ic|all users may connect to this network}}. If the option is ticked, the passwords will still be stored in clear text, even if a keyring daemon is running.<br />
<br />
If the option was selected previously and you un-tick it, you may have to use the {{ic|reset}} option first to make the password disappear from the file. Alternatively, delete the connection first and set it up again.<br />
<br />
=== Sharing internet connection over Wi-Fi ===<br />
<br />
You can share your internet connection (e.g. 3G or wired) with a few clicks. Please note that a [[firewall]] may interfere with internet sharing.<br />
<br />
You will need a Wi-Fi card which supports AP mode, see [[Software access point#Wi-Fi device must support AP mode]] for details.<br />
<br />
[[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
<br />
Create the shared connection:<br />
<br />
* Click on applet and choose ''Create new wireless network''.<br />
* Follow wizard (choose WPA2 or higher, be sure to use at least 8 character long password, lower lengths will fail).<br />
** Choose either [[Fedora:Features/RealHotspot|Hotspot]] or Ad-hoc as Wi-Fi mode.<br />
<br />
The connection will be saved and remain stored for the next time you need it.<br />
<br />
{{Note|Android does not support connecting to Ad-hoc networks. To share a connection with Android use infrastructure mode (i.e. set Wi-Fi mode to "Hotspot").}}<br />
<br />
=== Sharing internet connection over Ethernet ===<br />
<br />
Scenario: your device has internet connection over wi-fi and you want to share the internet connection to other devices over ethernet.<br />
<br />
Requirements:<br />
<br />
* [[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
* Your internet connected device and the other devices are connected over a suitable ethernet cable (this usually means a cross over cable or a switch in between).<br />
* Internet sharing is not blocked by a [[firewall]].<br />
<br />
Steps:<br />
<br />
{{Style|{{Pkg|nm-connection-editor}} is not a dependency of {{Pkg|networkmanager}} and needs to be installed separately.}}<br />
<br />
* Run {{ic|nm-connection-editor}} from terminal.<br />
* Add a new ethernet connection.<br />
* Give it some sensible name. For example "Shared Internet"<br />
* Go to "IPv4 Settings".<br />
* For "Method:" select "Shared to other computers".<br />
* Save<br />
<br />
Now you should have a new option "Shared Internet" under the Wired connections in NetworkManager.<br />
<br />
=== Checking if networking is up inside a cron job or script ===<br />
<br />
{{Out of date|''nm-tool'' was remove from NetworkManager for long time now[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/bb8c75bd536d4f8fb80a4366025a279078f0ec81]. ''nmcli'' should be used instead.}}<br />
<br />
Some ''cron'' jobs require networking to be up to succeed. You may wish to avoid running these jobs when the network is down. To accomplish this, add an '''if''' test for networking that queries NetworkManager's ''nm-tool'' and checks the state of networking. The test shown here succeeds if any interface is up, and fails if they are all down. This is convenient for laptops that might be hardwired, might be on wireless, or might be off the network.<br />
<br />
{{bc|<nowiki><br />
if [ $(nm-tool|grep State|cut -f2 -d' ') == "connected" ]; then<br />
#Whatever you want to do if the network is online<br />
else<br />
#Whatever you want to do if the network is offline - note, this and the else above are optional<br />
fi<br />
</nowiki>}}<br />
<br />
This useful for a {{ic|cron.hourly}} script that runs ''fpupdate'' for the F-Prot virus scanner signature update, as an example. Another way it might be useful, with a little modification, is to differentiate between networks using various parts of the output from ''nm-tool''; for example, since the active wireless network is denoted with an asterisk, you could grep for the network name and then grep for a literal asterisk.<br />
<br />
=== Connect to network with secret on boot ===<br />
<br />
By default, NetworkManager will not connect to networks requiring a secret automatically on boot. This is because it locks such connections to the user who makes it by default, only connecting after they have logged in. To change this, do the following:<br />
<br />
# Right click on the {{ic|nm-applet}} icon in your panel and select Edit Connections and open the Wireless tab<br />
# Select the connection you want to work with and click the Edit button<br />
# Check the boxes “Connect Automatically” and “Available to all users”<br />
# Additionally, ensure that under "Wi-Fi Security", "Store password for all users (not encrypted)" is selected<br />
<br />
Log out and log back in to complete.<br />
<br />
=== OpenConnect with password in KWallet ===<br />
<br />
While you may type both values at connection time, {{Pkg|plasma-nm}} 0.9.3.2-1 and above are capable of retrieving OpenConnect username and password directly from [[KWallet]].<br />
<br />
Open "KDE Wallet Manager" and look up your OpenConnect VPN connection under "Network Management|Maps". Click "Show values" and <br />
enter your credentials in key "VpnSecrets" in this form (replace ''username'' and ''password'' accordingly):<br />
<br />
form:main:username%SEP%''username''%SEP%form:main:password%SEP%''password''<br />
<br />
Next time you connect, username and password should appear in the "VPN secrets" dialog box.<br />
<br />
=== Ignore specific devices ===<br />
<br />
Sometimes it may be desired that NetworkManager ignores specific devices and does not try to configure addresses and routes for them. You can quickly and easily ignore devices by MAC or interface-name by using the following in {{ic|/etc/NetworkManager/conf.d/unmanaged.conf}}:<br />
<br />
[keyfile]<br />
unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth0<br />
<br />
After editing the file, run {{ic|nmcli general reload}} as root. Afterwards you should be able to configure interfaces without NetworkManager altering what you have set.<br />
<br />
=== Configuring MAC address randomization ===<br />
<br />
{{Note|1=Disabling MAC address randomization may be needed to get (stable) link connection [https://bbs.archlinux.org/viewtopic.php?id=220101] and/or networks that restrict devices based on their MAC Address or have a limit network capacity.}}<br />
<br />
MAC randomization can be used for increased privacy by not disclosing your real MAC address to the network.<br />
<br />
NetworkManager supports two types MAC Address Randomization: randomization during scanning, and for network connections. Both modes can be configured by modifying {{ic|/etc/NetworkManager/NetworkManager.conf}} or by creating a separate configuration file in {{ic|/etc/NetworkManager/conf.d/}} which is recommended since the aforementioned config file may be overwritten by NetworkManager.<br />
<br />
Randomization during Wi-Fi scanning is enabled by default, but it may be disabled by adding the following lines to {{ic|/etc/NetworkManager/NetworkManager.conf}} or a dedicated configuration file under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device]<br />
wifi.scan-rand-mac-address=no<br />
}}<br />
<br />
MAC randomization for network connections can be set to different modes for both wireless and ethernet interfaces. See the [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details on the different modes. <br />
<br />
In terms of MAC randomization the most important modes are {{ic|stable}} and {{ic|random}}. {{ic|stable}} generates a random MAC address when you connect to a new network and associates the two permanently. This means that you will use the same MAC address every time you connect to that network. In contrast, {{ic|random}} will generate a new MAC address every time you connect to a network, new or previously known. You can configure the MAC randomization by adding the desired configuration under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device-mac-randomization]<br />
# "yes" is already the default for scanning<br />
wifi.scan-rand-mac-address=yes<br />
<br />
[connection-mac-randomization]<br />
# Randomize MAC for every ethernet connection<br />
ethernet.cloned-mac-address=random<br />
# Generate a random MAC for each WiFi and associate the two permanently.<br />
wifi.cloned-mac-address=stable<br />
}}<br />
<br />
See the following [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details.<br />
<br />
=== Enable IPv6 Privacy Extensions ===<br />
<br />
See [[IPv6#NetworkManager]].<br />
<br />
=== Working with wired connections ===<br />
<br />
By default, NetworkManager generates a connection profile for each wired ethernet connection it finds. At the point when generating the connection, it does not know whether there will be more ethernet adapters available. Hence, it calls the first wired connection "Wired connection 1". You can avoid generating this connection, by configuring {{ic|no-auto-default}} (see {{man|5|NetworkManager.conf}}), or by simply deleting it. Then NetworkManager will remember not to generate a connection for this interface again.<br />
<br />
You can also edit the connection (and persist it to disk) or delete it. NetworkManager will not re-generate a new connection. Then you can change the name to whatever you want. You can use something like nm-connection-editor for this task.<br />
<br />
=== Using iwd as the Wi-Fi backend ===<br />
<br />
Install {{AUR|networkmanager-iwd}} or enable the experimental [[iwd]] backend creating the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_backend.conf|2=<br />
[device]<br />
wifi.backend=iwd<br />
}}<br />
<br />
=== Running in a network namespace ===<br />
<br />
If you would like to run NetworkManager inside a network namespace (e.g., to manage a specific device which should be use by selected applications), bring the device down before moving it to the namespace:<br />
<br />
$ ip link set dev ''MY_DEVICE'' down<br />
$ ip link set dev ''MY_DEVICE'' netns ''MY_NAMESPACE''<br />
$ ip netns exec ''MY_NAMESPACE'' NetworkManager<br />
...<br />
$ ip netns exec ''MY_NAMESPACE'' killall NetworkManager<br />
<br />
otherwise NetworkManager will later fail to establish the connection with a {{ic|device is strictly unmanaged}} error.<br />
<br />
== Troubleshooting ==<br />
<br />
=== No prompt for password of secured Wi-Fi networks ===<br />
<br />
When trying to connect to a secured Wi-Fi network, no prompt for a password is shown and no connection is established. This happens when no keyring package is installed. An easy solution is to install {{Pkg|gnome-keyring}}. If you want the passwords to be stored in encrypted form, follow [[GNOME Keyring]] to set up the ''gnome-keyring-daemon''.<br />
<br />
=== Network management disabled ===<br />
<br />
When NetworkManager shuts down but the pid (state) file is not removed, you will see a {{ic|Network management disabled}} message. If this happens, remove the file manually:<br />
<br />
# rm /var/lib/NetworkManager/NetworkManager.state<br />
<br />
=== Problems with internal DHCP client ===<br />
<br />
If you have problems with getting an IP address using the internal DHCP client, consider using another DHCP client, see [[#DHCP client]] for instructions. This workaround might solve problems in big wireless networks like eduroam.<br />
<br />
=== DHCP problems with dhclient ===<br />
<br />
If you have problems with getting an IP address via DHCP, try to add the following to your {{ic|/etc/dhclient.conf}}:<br />
<br />
interface "eth0" {<br />
send dhcp-client-identifier 01:''aa:bb:cc:dd:ee:ff'';<br />
}<br />
<br />
Where {{ic|''aa:bb:cc:dd:ee:ff''}} is the MAC address of this NIC. The MAC address can be found using the {{ic|ip link show ''interface''}} command from the {{Pkg|iproute2}} package.<br />
<br />
=== 3G modem not detected ===<br />
<br />
See [[USB 3G Modem#NetworkManager]].<br />
<br />
=== Switching off WLAN on laptops ===<br />
<br />
Sometimes NetworkManager will not work when you disable your Wi-Fi adapter with a switch on your laptop and try to enable it again afterwards. This is often a problem with ''rfkill''. To check if the driver notifies ''rfkill'' about the wireless adapter's status, use:<br />
<br />
$ watch -n1 rfkill list all<br />
<br />
If one identifier stays blocked after you switch on the adapter you could try to manually unblock it with (where X is the number of the identifier provided by the above output):<br />
<br />
# rfkill event unblock X<br />
<br />
=== Static IP address settings revert to DHCP ===<br />
<br />
Due to an unresolved bug, when changing default connections to a static IP address, {{ic|nm-applet}} may not properly store the configuration change, and will revert to automatic DHCP.<br />
<br />
To work around this issue you have to edit the default connection (e.g. "Auto eth0") in {{ic|nm-applet}}, change the connection name (e.g. "my eth0"), uncheck the "Available to all users" checkbox, change your static IP address settings as desired, and click '''Apply'''. This will save a new connection with the given name.<br />
<br />
Next, you will want to make the default connection not connect automatically. To do so, run {{ic|nm-connection-editor}} ('''not''' as root). In the connection editor, edit the default connection (e.g. "Auto eth0") and uncheck "Connect automatically". Click '''Apply''' and close the connection editor.<br />
<br />
=== Cannot edit connections as normal user ===<br />
<br />
See [[#Set up PolicyKit permissions]].<br />
<br />
=== Forget hidden wireless network ===<br />
<br />
Since hidden networks are not displayed in the selection list of the Wireless view, they cannot be forgotten (removed) with the GUI. You can delete one with the following command:<br />
<br />
# rm /etc/NetworkManager/system-connections/''SSID''<br />
<br />
This works for any other connection.<br />
<br />
=== VPN not working in GNOME ===<br />
<br />
When setting up OpenConnect or vpnc connections in NetworkManager while using GNOME, you will sometimes never see the dialog box pop up and the following error appears in {{ic|/var/log/errors.log}}:<br />
<br />
localhost NetworkManager[399]: <error> [1361719690.10506] [nm-vpn-connection.c:1405] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.<br />
<br />
This is caused by the GNOME NM Applet expecting dialog scripts to be at {{ic|/usr/lib/gnome-shell}}, when NetworkManager's packages put them in {{ic|/usr/lib/networkmanager}}.<br />
As a "temporary" fix (this bug has been around for a while now), make the following symlink(s):<br />
<br />
* For OpenConnect: {{ic|ln -s /usr/lib/networkmanager/nm-openconnect-auth-dialog /usr/lib/gnome-shell/}}<br />
* For VPNC (i.e. Cisco VPN): {{ic|ln -s /usr/lib/networkmanager/nm-vpnc-auth-dialog /usr/lib/gnome-shell/}}<br />
<br />
This may need to be done for any other NM VPN plugins as well, but these are the two most common.<br />
<br />
=== Unable to connect to visible European wireless networks ===<br />
<br />
WLAN chips are shipped with a default [[Wireless network configuration#Respecting the regulatory domain|regulatory domain]]. If your access point does not operate within these limitations, you will not be able to connect to the network. Fixing this is easy:<br />
<br />
# [[Install]] {{Pkg|crda}}<br />
# Uncomment the correct Country Code in {{ic|/etc/conf.d/wireless-regdom}}<br />
# Reboot the system, because the setting is only read on boot<br />
<br />
=== Automatic connect to VPN on boot is not working ===<br />
<br />
The problem occurs when the system (i.e. NetworkManager running as the root user) tries to establish a VPN connection, but the password is not accessible because it is stored in the GNOME keyring of a particular user. <br />
<br />
A solution is to keep the password to your VPN in plaintext, as described in step (2.) of [[#Use dispatcher to connect to a VPN after a network connection is established]]. <br />
<br />
You do not need to use the dispatcher described in step (1.) to auto-connect anymore, if you use the new "auto-connect VPN" option from the {{ic|nm-applet}} GUI.<br />
<br />
=== Systemd Bottleneck ===<br />
<br />
Over time the log files ({{ic|/var/log/journal}}) can become very large. This can have a big impact on boot performance when using NetworkManager, see: [[Systemd#Boot time increasing over time]].<br />
<br />
=== Regular network disconnects, latency and lost packets (WiFi) ===<br />
<br />
NetworkManager does a scan every 2 minutes.<br />
<br />
Some WiFi drivers have issues when scanning for base stations whilst connected/associated. Symptoms include VPN disconnects/reconnects and lost packets, web pages failing to load and then refresh fine.<br />
<br />
Running {{ic|journalctl -f}} will indicate that this is taking place, messages like the following will be contained in the logs at regular intervals.<br />
<br />
NetworkManager[410]: <info> (wlp3s0): roamed from BSSID 00:14:48:11:20:CF (my-wifi-name) to (none) ((none))<br />
<br />
There is a patched version of NetworkManager which should prevent this type of scanning: {{AUR|networkmanager-noscan}}.<br />
<br />
Alternatively, if roaming is not important, the periodic scanning behavior can be disabled by locking the BSSID of the access point in the WiFi connection profile.<br />
<br />
=== Unable to turn on wi-fi with Lenovo laptop (IdeaPad, Legion, etc.) ===<br />
<br />
There is an issue with the {{ic|ideapad_laptop}} module on some Lenovo models due to the wi-fi driver incorrectly reporting a soft block. The card can still be manipulated with {{ic|netctl}}, but managers like NetworkManager break. You can verify that this is the problem by checking the output of {{ic|rfkill list}} after toggling your hardware switch and seeing that the soft block persists.<br />
<br />
{{Accuracy|Try to use {{ic|rfkill.default_state}} and {{ic|rfkill.master_switch_mode}} (see [https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt kernel-parameters.txt]) to fix the rfkill problem.}}<br />
<br />
[[modprobe|Unloading]] the {{ic|ideapad_laptop}} module should fix this. ('''warning''': this may disable the laptop keyboard and touchpad also!).<br />
<br />
=== Turn off hostname sending ===<br />
<br />
NetworkManager by default sends the hostname to the DHCP server. Hostname sending can only be disabled per connection not globally ([https://bugzilla.gnome.org/show_bug.cgi?id=768076 GNOME Bug 768076]).<br />
<br />
To disable sending your hostname to the DHCP server for a specific connection, add the following to your network connection file:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''your_connection_file''|2=<br />
...<br />
[ipv4]<br />
dhcp-send-hostname=false<br />
...<br />
[ipv6]<br />
dhcp-send-hostname=false<br />
...<br />
}}<br />
<br />
=== nm-applet disappears in i3wm ===<br />
<br />
If you use the {{ic|xfce4-notifyd.service}} for notifications you must [[edit]] the unit and add the following:<br />
<br />
{{hc|/etc/systemd/user/xfce4-notifyd.service.d/display_env.conf|2=<br />
[Service]<br />
Environment="DISPLAY=:0.0"<br />
}}<br />
<br />
After reloading the daemons [[restart]] {{ic|xfce4-notifyd.service}}. Exit i3 and start it back up again and the applet should show on the tray.<br />
<br />
=== nm-applet tray icons display wrongly ===<br />
<br />
Currently the tray icons of nm-applet are drawn on top of one another, i.e. the icon displaying wireless strength might show on top of the icon indicating no wired connection.<br />
This is apparently a GTK3 bug/problem: https://gitlab.gnome.org/GNOME/gtk/issues/1280 .<br />
<br />
A patched version of GTK3 exists in AUR, which apparently fixes the tray icon bug: {{AUR|gtk3-mushrooms}} .<br />
<br />
=== Unit dbus-org.freedesktop.resolve1.service not found ===<br />
<br />
If {{ic|systemd-resolved.service}} is not started, NetworkManager will try to start it using D-Bus and fail:<br />
<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
dbus-daemon[991]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
<br />
This is because NetworkManager will try to send DNS information to [[systemd-resolved]] regardless of the {{ic|1=main.dns=}} setting in {{man|5|NetworkManager.conf}}.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383]<br />
<br />
This can be disabled with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/no-systemd-resolved.conf|2=<br />
[main]<br />
systemd-resolved=false<br />
}}<br />
<br />
See {{Bug|62138}}.<br />
<br />
=== Secrets were required, but not provided ===<br />
<br />
If you attempt to connect to a network using {{ic|nmcli device wifi connect ''SSID'' password ''password''}} and received the following error:<br />
<br />
Error: Connection activation failed: (7) Secrets were required, but not provided<br />
<br />
The error can be resolved by deleting the connection profile and creating a new one:<br />
<br />
$ nmcli connection delete ''SSID''<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
=== WPA Enterprise connection with NetworkManager ===<br />
<br />
If you try to connect to an WPA Enterprise network like 'eduroam' with NetworkManager with the [[iwd]] backend then you will get the following error from NetworkManager:<br />
<br />
Connection 'eduroam' is not avialable on device wlan0 because profile is not compatible with device (802.1x connections must have IWD provisioning files)<br />
<br />
This is because NetworkManager can not configure a WPA Enterprise network. Therefore you have to configure it using an iwd config file {{ic|/var/lib/iwd/''essid''.8021x}} like described in [[iwd#WPA Enterprise]].<br />
<br />
== See also ==<br />
<br />
* [https://blogs.gnome.org/dcbw/2015/02/16/networkmanager-for-administrators-part-1/ NetworkManager for Administrators Part 1]<br />
* [[Wikipedia:NetworkManager]]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=NetworkManager&diff=627219NetworkManager2020-07-30T15:22:44Z<p>Tobbebobbe: /* Set up VPN with WireGuard */ inserted link</p>
<hr />
<div>[[Category:Network managers]]<br />
[[Category:Red Hat]]<br />
[[cs:NetworkManager]]<br />
[[de:Networkmanager]]<br />
[[es:NetworkManager]]<br />
[[fr:NetworkManager]]<br />
[[it:NetworkManager]]<br />
[[ja:NetworkManager]]<br />
[[pt:NetworkManager]]<br />
[[zh-hans:NetworkManager]]<br />
{{Related articles start}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related articles end}}<br />
[https://wiki.gnome.org/Projects/NetworkManager/ NetworkManager] is a program for providing detection and configuration for systems to automatically connect to networks. NetworkManager's functionality can be useful for both wireless and wired networks. For wireless networks, NetworkManager prefers known wireless networks and has the ability to switch to the most reliable network. NetworkManager-aware applications can switch from online and offline mode. NetworkManager also prefers wired connections over wireless ones, has support for modem connections and certain types of VPN. NetworkManager was originally developed by Red Hat and now is hosted by the [[GNOME]] project.<br />
<br />
{{Expansion|Clear text storage of secrets is not limited to just Wi-Fi passwords. The secrets are stored in files (and folder) only accesible to root.}}<br />
<br />
{{Warning|By default, Wi-Fi passwords are stored in clear text, see [[#Encrypted Wi-Fi passwords]].}}<br />
<br />
== Installation ==<br />
<br />
NetworkManager can be [[install]]ed with the package {{Pkg|networkmanager}}, which contains a daemon, a command line interface ({{ic|nmcli}}) and a curses‐based interface ({{ic|nmtui}}). <br />
<br />
=== Enable NetworkManager ===<br />
<br />
After installation, you should [[start/enable]] {{ic|NetworkManager.service}}. Once the NetworkManager daemon is started, it will automatically connect to any available "system connections" that have already been configured. Any "user connections" or unconfigured connections will need ''nmcli'' or an applet to configure and connect.<br />
<br />
=== Additional interfaces ===<br />
<br />
* {{Pkg|nm-connection-editor}} for a graphical user interface,<br />
* {{Pkg|network-manager-applet}} for a system tray applet ({{ic|nm-applet}}).<br />
<br />
{{Note|You must ensure that no other service that wants to configure the network is running; in fact, multiple networking services will conflict. You can find a list of the currently running services with {{ic|1=systemctl --type=service}} and then [[stop]] them. See [[#Configuration]] to enable the NetworkManager service.}}<br />
<br />
=== Mobile broadband support ===<br />
<br />
[[Install]] {{Pkg|modemmanager}}, {{Pkg|mobile-broadband-provider-info}} and {{Pkg|usb_modeswitch}} packages for mobile broadband connection support. See [[USB 3G Modem#NetworkManager]] for details.<br />
<br />
=== PPPoE / DSL support ===<br />
<br />
[[Install]] {{Pkg|rp-pppoe}} package for PPPoE / DSL connection support. To actually add PPPoE connection, use {{ic|1=nm-connection-editor}} and add new DSL/PPPoE connection.<br />
<br />
=== VPN support ===<br />
<br />
NetworkManager since version 1.16 has native support for [[WireGuard]], all it needs is the {{ic|wireguard}} kernel module. Read the [https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-networkmanager/ WireGuard in NetworkManager blog post] for details.<br />
<br />
Support for other VPN types is based on a plug-in system. They are provided in the following packages:<br />
<br />
* {{Pkg|networkmanager-openconnect}} for [[OpenConnect]]<br />
* [[networkmanager-openvpn]] for [[OpenVPN]]<br />
* {{Pkg|networkmanager-pptp}} for [[PPTP Client]]<br />
* {{Pkg|networkmanager-vpnc}} for [[Vpnc]]<br />
* {{Pkg|networkmanager-strongswan}} for [[strongSwan]]<br />
* {{AUR|networkmanager-fortisslvpn-git}}<br />
* {{AUR|networkmanager-iodine-git}}<br />
* {{AUR|networkmanager-libreswan}}<br />
* {{AUR|networkmanager-l2tp}}<br />
* {{AUR|networkmanager-ssh-git}}<br />
* {{Pkg|network-manager-sstp}}<br />
<br />
{{Warning|1=There are a lot of [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues?search=VPN&state=opened bugs] (and [https://bugzilla.gnome.org/buglist.cgi?bug_status=__open__&content=VPN&product=NetworkManager old bugs]) related to VPN support. Check the daemon processes options set via the GUI correctly and double-check with each package release.}}<br />
<br />
{{Note|To have fully functioning DNS resolution when using VPN, you should set up [[#DNS caching and conditional forwarding|conditional forwarding]].}}<br />
<br />
==== Set up VPN with WireGuard ====<br />
<br />
The Gnome gui for NetworkManager does not handle WireGuard connections. To add a WireGuard connection from a config-file, issue following command in terminal:<br />
<br />
# nmcli connection import type wireguard file <CONFIG-FILE><br />
<br />
If the file was called WG1.conf a connection called WG1 should have been added. <br />
<br />
If you at any point want to delete the connection, issue the command:<br />
<br />
# nmcli connection delete <CONNECTION NAME><br />
<br />
To actually start the WireGuard tunnel, issue command:<br />
<br />
# nmcli connection up <CONNECTION NAME><br />
<br />
Make sure the connection is listed when you run nmcli:<br />
<br />
# nmcli<br />
<br />
You might want to verify that the private and public keys are correct and corresponds with what you got from your VPN provider:<br />
<br />
# sudo WG_HIDE_KEYS=never wg<br />
<br />
Since WireGuard lacks support in the Gnome gui you may want to proceed to configure NetworkManager to automatically use the WireGuard connection, as described [https://wiki.archlinux.org/index.php/NetworkManager#Automatically_connect_to_VPN elsewhere] on this Wiki page.<br />
<br />
== Usage ==<br />
<br />
NetworkManager comes with {{man|1|nmcli}} and {{man|1|nmtui}}.<br />
<br />
=== nmcli examples ===<br />
<br />
List nearby wifi networks:<br />
<br />
$ nmcli device wifi list<br />
<br />
Connect to a wifi network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
Connect to a hidden network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' hidden yes<br />
<br />
Connect to a wifi on the {{ic|wlan1}} wifi interface:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' ifname wlan1 ''profile_name''<br />
<br />
Disconnect an interface:<br />
<br />
$ nmcli device disconnect ifname eth0<br />
<br />
Reconnect an interface marked as disconnected:<br />
<br />
$ nmcli connection up uuid ''UUID''<br />
<br />
Get a list of UUIDs:<br />
<br />
$ nmcli connection show<br />
<br />
See a list of network devices and their state:<br />
<br />
$ nmcli device<br />
<br />
Turn off wifi:<br />
<br />
$ nmcli radio wifi off<br />
<br />
=== Edit a connection ===<br />
<br />
For a comprehensive list of settings, see {{man|5|nm-settings}}.<br />
<br />
Firstly you need to get list of connections:<br />
<br />
{{hc|$ nmcli connection|<nowiki><br />
NAME UUID TYPE DEVICE<br />
Wired connection 2 e7054040-a421-3bef-965d-bb7d60b7cecf ethernet enp5s0<br />
Wired connection 1 997f2782-f0fc-301d-bfba-15421a2735d8 ethernet enp0s25<br />
MY-HOME-WIFI-5G 92a0f7b3-2eba-49ab-a899-24d83978f308 wifi --<br />
</nowiki>}}<br />
<br />
Here you can use the first column as connection-id used later. In this example we pick {{ic|Wired connection 2}} as a connection-id.<br />
<br />
You have three methods to configure a connection {{ic|Wired connection 2}} after it has been created:<br />
<br />
; nmcli interactive editor<br />
: {{ic|nmcli connection edit 'Wired connection 2'}}.<br> Usage is well documented from the editor.<br />
<br />
; nmcli command line interface<br />
: {{ic|nmcli connection modify 'Wired connection 2' ''setting''.''property'' ''value''}}. See {{man|1|nmcli}} for usage. For example you can change its IPv4 route metric to 200 using {{ic|nmcli connection modify 'Wired connection 2' ipv4.route-metric 200}} command.<br />
<br />
; Connection file<br />
: In {{ic|/etc/NetworkManager/system-connections/}}, modify the corresponding {{ic|Wired connection 2.nmconnection}} file .<br> Do not forget to reload the configuration file with {{ic|nmcli connection reload}}.<br />
<br />
== Front-ends ==<br />
<br />
To configure and have easy access to NetworkManager, most users will want to install an applet. This GUI front-end usually resides in the system tray (or notification area) and allows network selection and configuration of NetworkManager. Various desktop environments have their own applet. Otherwise you can use [[#nm-applet]].<br />
<br />
=== GNOME ===<br />
<br />
[[GNOME]] has a built-in tool, accessible from the Network settings.<br />
<br />
=== KDE Plasma ===<br />
<br />
[[Install]] the {{Pkg|plasma-nm}} package. After that, add it to the KDE taskbar via the ''Panel options > Add widgets > Networks'' menu.<br />
<br />
=== nm-applet ===<br />
<br />
{{Pkg|network-manager-applet}} is a GTK 3 front-end which works under Xorg environments with a systray.<br />
<br />
To store connection secrets install and configure [[GNOME/Keyring]].<br />
<br />
Be aware that after enabling the tick-box option {{ic|Make available to other users}} for a connection, NetworkManager stores the password in plain-text, though the respective file is accessible only to root (or other users via {{ic|nm-applet}}). See [[#Encrypted Wi-Fi passwords]].<br />
<br />
In order to run {{ic|nm-applet}} without a systray, you can use {{Pkg|trayer}} or {{Pkg|stalonetray}}. For example, you can add a script like this one in your path:<br />
<br />
{{hc|nmgui|<nowiki><br />
#!/bin/sh<br />
nm-applet 2>&1 > /dev/null &<br />
stalonetray 2>&1 > /dev/null<br />
killall nm-applet<br />
</nowiki>}}<br />
<br />
When you close the ''stalonetray'' window, it closes {{ic|nm-applet}} too, so no extra memory is used once you are done with network settings.<br />
<br />
The applet can show notifications for events such as connecting to or disconnecting from a WiFi network. For these notifications to display, ensure that you have a notification server installed - see [[Desktop notifications]]. If you use the applet without a notification server, you might see some messages in stdout/stderr, and the app might hang. See [https://bugzilla.gnome.org/show_bug.cgi?id=788313].<br />
<br />
In order to run {{ic|nm-applet}} with such notifications disabled, start the applet with the following command:<br />
<br />
$ nm-applet --no-agent<br />
<br />
{{Tip|{{ic|nm-applet}} might be started automatically with a [[XDG Autostart|autostart desktop file]], to add the --no-agent option modify the Exec line there, i.e.<br />
<br />
{{bc|1=Exec=nm-applet --no-agent}}<br />
<br />
}}<br />
<br />
{{Warning|On [[i3]], if nm-applet is started with the {{ic|--no-agent}} option, it is not possible to connect to a new encrypted WiFi network by clicking on the item list because no password input dialogue window will pop out. [[journal]] will show {{ic|no secrets: No agents were available for this request}}.}}<br />
<br />
==== Appindicator ====<br />
<br />
As of version 1.18.0 Appindicator support is [https://github.com/archlinux/svntogit-packages/commit/7640a2bd557fe84813207ef4d5e35bb5aece6c54 available] in the official {{Pkg|network-manager-applet}} package. To use nm-applet in an Appindicator environment start the applet with the following command:<br />
<br />
$ nm-applet --indicator<br />
<br />
=== networkmanager-dmenu ===<br />
<br />
Alternatively there is {{AUR|networkmanager-dmenu-git}} which is a small script to manage NetworkManager connections with [[dmenu]] or [[rofi]] instead of {{ic|nm-applet}}. It provides all essential features such as connection to existing NetworkManager wifi or wired connections, connect to new wifi connections, requests passphrase if required, connect to existing VPN connections, enable/disable networking, launch ''nm-connection-editor'' GUI, connect to Bluetooth networks.<br />
<br />
== Configuration ==<br />
<br />
NetworkManager will require some additional steps to be able run properly. Make sure you have configured {{ic|/etc/hosts}} as described in [[Network configuration#Set the hostname]] section.<br />
<br />
NetworkManager has a global configuration file at {{ic|/etc/NetworkManager/NetworkManager.conf}}. Addition configuration files can be placed in {{ic|/etc/NetworkManager/conf.d/}}. Usually no configuration needs to be done to the global defaults.<br />
<br />
After editing a configuration file, the changes can be applied by running:<br />
<br />
# nmcli general reload<br />
<br />
=== Enable NetworkManager Wait Online ===<br />
<br />
{{Out of date|{{ic|NetworkManager.service}} has {{ic|1=Also=NetworkManager-wait-online.service}} in the {{ic|[Install]}} section.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/167e42a87e97ed7fb26a4263c22f1774716ac51b] If {{ic|NetworkManager.service}} was [[enable]]d before the change, it needs to be [[enable|reenabled]].}}<br />
<br />
If you have services which fail if they are started before the network is up, you may use {{ic|NetworkManager-wait-online.service}} in addition to {{ic|NetworkManager.service}}. This is, however, rarely necessary because most networked daemons start up okay, even if the network has not been configured yet.<br />
<br />
In some cases, the service will still fail to start successfully on boot due to the timeout setting in {{ic|/usr/lib/systemd/system/NetworkManager-wait-online.service}} being too short. Change the default timeout from 30 to a higher value.<br />
<br />
=== Set up PolicyKit permissions ===<br />
<br />
See [[General troubleshooting#Session permissions]] for setting up a working session.<br />
<br />
With a working session, you have several options for granting the necessary privileges to NetworkManager:<br />
<br />
* ''Option 1.'' Run a [[Polkit]] authentication agent when you log in, such as {{ic|/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1}} (part of {{Pkg|polkit-gnome}}). You will be prompted for your password whenever you add or remove a network connection.<br />
* ''Option 2.'' [[Users and groups#Group management|Add]] yourself to the {{ic|wheel}} group. You will not have to enter your password, but your user account may be granted other permissions as well, such as the ability to use [[sudo]] without entering the root password.<br />
* ''Option 3.'' [[Users and groups#Group management|Add]] yourself to the {{ic|network}} group and create the following file:<br />
<br />
{{hc|/etc/polkit-1/rules.d/50-org.freedesktop.NetworkManager.rules|<nowiki><br />
polkit.addRule(function(action, subject) {<br />
if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0 && subject.isInGroup("network")) {<br />
return polkit.Result.YES;<br />
}<br />
});<br />
</nowiki>}}<br />
<br />
: All users in the {{ic|network}} group will be able to add and remove networks without a password. This will not work under [[systemd]] if you do not have an active session with ''systemd-logind''.<br />
<br />
=== Proxy settings ===<br />
<br />
NetworkManager does not directly handle proxy settings, but if you are using [[GNOME]] or [[KDE]], you could use [http://marin.jb.free.fr/proxydriver/ proxydriver] which handles proxy settings using NetworkManager's information. proxydriver is found in the package {{AUR|proxydriver}}.<br />
<br />
In order for ''proxydriver'' to be able to change the proxy settings, you would need to execute this command, as part of the GNOME startup process (see [[GNOME#Autostart]]).<br />
<br />
xhost +si:localuser:''username''<br />
<br />
See also [[Proxy settings]].<br />
<br />
=== Checking connectivity ===<br />
<br />
NetworkManager can try to reach a page on Internet when connecting to a network. {{Pkg|networkmanager}} is configured by default in {{ic|/usr/lib/NetworkManager/conf.d/20-connectivity.conf}} to check connectivity to archlinux.org. To use a different webserver or disable connectivity checking create {{ic|/etc/NetworkManager/conf.d/20-connectivity.conf}}, see {{man|5|NetworkManager.conf|CONNECTIVITY SECTION}}. Below is an example of using GNOME servers (it does not require the use of [[GNOME]]):<br />
<br />
{{hc|/etc/NetworkManager/conf.d/20-connectivity.conf|<nowiki><br />
[connectivity]<br />
uri=http://nmcheck.gnome.org/check_network_status.txt<br />
</nowiki>}}<br />
<br />
{{Note|Although automatic connectivity checks are a potential privacy leak, the official archlinux.org default connectivity URL is committed to not logging any access. See [https://gitlab.archlinux.org/archlinux/infrastructure/-/commit/68fbaca2ef9f31f624f117899848f4288d6b39d1].}}<br />
<br />
=== Captive portals ===<br />
<br />
{{Style|Complex scripts should not be maintained on the wiki.}}<br />
<br />
For those behind a [[Wikipedia:Captive portal|captive portal]], the desktop manager may automatically open a window asking for credentials. If your desktop does not, you can use {{Pkg|capnet-assist}} package (however, it currently it has a broken NetworkManager dispatcher script). Alternatively, you can create a NetworkManager dispatcher script with the following content:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/90-open_captive_portal|<nowiki><br />
#!/bin/sh -e<br />
# Script to dispatch NetworkManager events<br />
#<br />
# Runs shows a login webpage on walled garden networks.<br />
# See NetworkManager(8) for further documentation of the dispatcher events.<br />
<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin<br />
<br />
if [ -x "/usr/bin/logger" ]; then<br />
logger="/usr/bin/logger -s -t captive-portal"<br />
else<br />
logger=":"<br />
fi<br />
<br />
wait_for_process() {<br />
PNAME=$1<br />
while [ -z "$(/usr/bin/pgrep $PNAME)" ]; do<br />
sleep 3;<br />
done<br />
}<br />
<br />
#launch the browser, but on boot we need to wait that nm-applet starts<br />
start_browser() {<br />
local user="$1"<br />
local display="$2"<br />
<br />
export DISPLAY="$display"<br />
wait_for_process nm-applet<br />
<br />
export XAUTHORITY="/home/$user/.Xauthority"<br />
<br />
$logger "Running browser as '$user' with display '$display' to login in captive portal"<br />
sudo -u "$user" --preserve-env=DISPLAY,XAUTHORITY -H xdg-open http://capnet.elementary.io 2>&1 > /dev/null<br />
}<br />
<br />
# Run the right scripts<br />
case "$2" in<br />
connectivity-change)<br />
$logger -p user.debug "dispatcher script triggered on connectivity change: $CONNECTIVITY_STATE"<br />
if [ "$CONNECTIVITY_STATE" = "PORTAL" ]; then<br />
# Match last column of who's output with ' :[at least one digit] '<br />
who | awk '$NF ~ /\(:[0-9]+\)/ { print $1 " " substr($NF, 2, length($NF)-2) };' | \<br />
while read user display; do<br />
start_browser $user $display || $logger -p user.err "Failed for user: '$user' display: '$display'"<br />
done<br />
fi<br />
;;<br />
*)<br />
# In a down phase<br />
exit 0<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
You will need to [[restart]] {{ic|NetworkManager.service}} or reboot for this to start working. Once you do, the dispatcher script should open a login window once it detects you are behind a captive portal.<br />
<br />
Another solution is {{AUR|captive-browser-git}} based on Google Chrome.<br />
<br />
=== DHCP client ===<br />
<br />
By default NetworkManager uses its internal DHCP client. The internal DHCPv4 plugin is based on the [https://nettools.github.io/n-dhcp4/ nettools' n-dhcp4] library, while the internal DHCPv6 plugin is made from code based on systemd-networkd.<br />
<br />
To use ISC’s DHCP client, [[install]] {{Pkg|dhclient}}. To change the DHCP client backend, set the option {{ic|1=main.dhcp=''dhcp_client_name''}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}. E.g.:<br />
<br />
{{hc|1=/etc/NetworkManager/conf.d/dhcp-client.conf|2=<br />
[main]<br />
dhcp=dhclient<br />
}}<br />
<br />
{{Note|<br />
* Do not enable the systemd units shipped with the {{Pkg|dhclient}} and {{Pkg|dhcpcd}} packages. They will conflict with NetworkManager, see the note in [[#Installation]] for details.<br />
* NetworkManger does not support dhcpcd ≥ 9.0.0. See {{Bug|66231}}.<br />
}}<br />
<br />
=== DNS management ===<br />
<br />
NetworkManager's DNS management is described in the GNOME project's wiki page—[https://wiki.gnome.org/Projects/NetworkManager/DNS Projects/NetworkManager/DNS].<br />
<br />
==== DNS caching and conditional forwarding ====<br />
<br />
NetworkManager has a plugin to enable DNS caching and conditional forwarding ([https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/143 previously] called "split DNS" in NetworkManager's documentation) using [[dnsmasq]] or [[systemd-resolved]]. The advantages of this setup is that DNS lookups will be cached, shortening resolve times, and DNS lookups of VPN hosts will be routed to the relevant VPN's DNS servers. This is especially useful if you are connected to more than one VPN.<br />
<br />
===== dnsmasq =====<br />
<br />
Make sure {{Pkg|dnsmasq}} has been installed. Then set {{ic|1=main.dns=dnsmasq}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=dnsmasq<br />
}}<br />
<br />
Now run {{ic|nmcli general reload}} as root. NetworkManager will automatically start dnsmasq and add {{ic|127.0.0.1}} to {{ic|/etc/resolv.conf}}. The original DNS servers can be found in {{ic|/run/NetworkManager/no-stub-resolv.conf}}. You can verify dnsmasq is being used by doing the same DNS lookup twice with {{ic|drill example.com}} and verifying the server and query times.<br />
<br />
{{Note|<br />
* You do not need to start {{ic|dnsmasq.service}} or edit {{ic|/etc/dnsmasq.conf}}. NetworkManager will start dnsmasq without using the systemd service and without reading the dnsmasq's default configuration file(s).<br />
* The dnsmasq instance started by NetworkManager will bind to {{ic|127.0.0.1:53}}, you cannot run any other software (including {{ic|dnsmasq.service}}) on the same address and port.<br />
}}<br />
<br />
====== Custom dnsmasq configuration ======<br />
<br />
Custom configurations can be created for ''dnsmasq'' by creating configuration files in {{ic|/etc/NetworkManager/dnsmasq.d/}}. For example, to change the size of the DNS cache (which is stored in RAM):<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/cache.conf|2=<br />
cache-size=1000<br />
}}<br />
<br />
{{Tip|Check the configuration file syntax with {{ic|1=dnsmasq --test --conf-file=/dev/null --conf-dir=/etc/NetworkManager/dnsmasq.d}}.}}<br />
<br />
See {{man|8|dnsmasq}} for all available options.<br />
<br />
====== IPv6 ======<br />
<br />
{{Accuracy|This does not solve the issue because NetworkManager does not add {{ic|::1}} to {{ic|/etc/resolv.conf}}. Unless {{ic|@::1}} is manually passed to drill, it will still fail with {{ic|Error: error sending query: No (valid) nameservers defined in the resolver}}.}}<br />
<br />
Enabling {{ic|dnsmasq}} in NetworkManager may break IPv6-only DNS lookups (i.e. {{ic|drill -6 [hostname]}}) which would otherwise work. In order to resolve this, creating the following file will configure ''dnsmasq'' to also listen to the IPv6 loopback:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/ipv6-listen.conf|2=<br />
listen-address=::1<br />
}}<br />
<br />
In addition, {{ic|dnsmasq}} also does not prioritize upstream IPv6 DNS. Unfortunately NetworkManager does not do this ([https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/936712 Ubuntu Bug]). A workaround would be to disable IPv4 DNS in the NetworkManager config, assuming one exists<br />
<br />
====== DNSSEC ======<br />
<br />
The dnsmasq instance started by NetworkManager by default will not validate [[DNSSEC]] since it is started with the {{ic|--proxy-dnssec}} option. It will trust whatever DNSSEC information it gets from the upstream DNS server.<br />
<br />
For dnsmasq to properly validate DNSSEC, thus breaking DNS resolution with name servers that do not support it, create the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/dnssec.conf|2=<br />
conf-file=/usr/share/dnsmasq/trust-anchors.conf<br />
dnssec<br />
}}<br />
<br />
===== systemd-resolved =====<br />
<br />
{{Expansion|NetworkManager 1.16 adds a new setting {{ic|main.systemd-resolved}}[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383] (enabled by default). It unconditionally sends DNS configuration to systemd-resolved. Related to "Preserving resolv.conf" from [[systemd-resolved#DNS]]?}}<br />
<br />
NetworkManager can use [[systemd-resolved]] as a DNS resolver and cache. Make sure that ''systemd-resolved'' is properly configured and that {{ic|systemd-resolved.service}} is [[started]] before using it.<br />
<br />
systemd-resolved will be used automatically if {{ic|/etc/resolv.conf}} is a [[Systemd-resolved#DNS|symlink]] to {{ic|/run/systemd/resolve/stub-resolv.conf}}, {{ic|/run/systemd/resolve/resolv.conf}} or {{ic|/usr/lib/systemd/resolv.conf}}.<br />
<br />
You can enable it explicitly by setting {{ic|1=main.dns=systemd-resolved}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=systemd-resolved<br />
}}<br />
<br />
===== DNS resolver with an openresolv subscriber =====<br />
<br />
If [[openresolv]] has a subscriber for your local [[DNS resolver]], set up the subscriber and [[#Use openresolv|configure NetworkManager to use openresolv]].<br />
<br />
Because NetworkManager advertises a single "interface" to ''resolvconf'', it is not possible to implement conditional forwarding between two NetworkManager connections. See [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 NetworkManager issue 153].<br />
<br />
This can be partially mitigated if you set {{ic|1=private="*"}} in {{ic|/etc/resolvconf.conf}}[https://roy.marples.name/projects/openresolv/configuration.html]. Any queries for domains that are not in search domain list will not get forwarded. They will be handled according to the local resolver's configuration, for example, forwarded to another DNS server or resolved recursively from the DNS root.<br />
<br />
==== Custom DNS servers ====<br />
<br />
===== Setting custom global DNS servers =====<br />
<br />
To set DNS servers for all connections, specify them in {{man|5|NetworkManager.conf}} using the syntax {{ic|1=servers=''serveripaddress1'',''serveripaddress2'',''serveripaddress3''}} in a section named {{ic|[global-dns-domain-*]}}. For example:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns-servers.conf|2=<br />
[global-dns-domain-*]<br />
servers=::1,127.0.0.1<br />
}}<br />
<br />
{{Note|<br />
* If you use [[#DNS caching and conditional forwarding|NetworkManager's dnsmasq or systemd-resolved plugin]] or [[#DNS resolver with an openresolv subscriber|openresolv subscribers]], then do not specify loopback addresses with the {{ic|1=servers=}} option, it can break DNS resolution.<br />
* The specified servers do not get sent to [[systemd-resolved]], the connection's DNS servers are used instead.<br />
}}<br />
<br />
===== Setting custom DNS servers in a connection =====<br />
<br />
====== Setting custom DNS servers in a connection (GUI) ======<br />
<br />
Setup will depend on the type of front-end used; the process usually involves right-clicking on the applet, editing (or creating) a profile, and then choosing DHCP type as ''Automatic (specify addresses)''. The DNS addresses will need to be entered and are usually in this form: {{ic|127.0.0.1, ''DNS-server-one'', ...}}.<br />
<br />
====== Setting custom DNS servers in a connection (nmcli / connection file) ======<br />
<br />
To setup DNS Servers per connection, you can use the {{ic|dns}} field (and the associated {{ic|dns-search}} and {{ic|dns-options}}) in the [[#Edit a connection|connection settings]]. <br />
<br />
If {{ic|method}} is set to {{ic|auto}} (when you use DHCP), you need to set {{ic|ignore-auto-dns}} to {{ic|yes}}.<br />
<br />
==== /etc/resolv.conf ====<br />
<br />
By default {{ic|/etc/resolv.conf}} is managed by ''NetworkManager'' unless it is a symlink.<br />
<br />
It can be configured to write it through [[#Use openresolv|openresolv]] or to [[#Unmanaged /etc/resolv.conf|not touch it at all]].<br />
<br />
Using openresolv allows NetworkManager to coexists with other ''resolvconf'' supporting software or, for example, to run a local DNS caching and split-DNS resolver for which openresolv has a [[openresolv#Subscribers|subscriber]].<br />
<br />
{{Note|Conditional forwarding is [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 not yet fully supported] when using NetworkManager with openresolv.}}<br />
<br />
''NetworkManager'' also offers hooks via so called dispatcher scripts that can be used to alter the {{ic|/etc/resolv.conf}} after network changes. See [[#Network services with NetworkManager dispatcher]] and {{man|8|NetworkManager}} for more information.<br />
<br />
{{Note|<br />
* If NetworkManager is configured to use either [[#dnsmasq|dnsmasq]] or [[#systemd-resolved|systemd-resolved]], then the appropriate loopback addresses will be written to {{ic|/etc/resolv.conf}}.<br />
* The {{ic|resolv.conf}} file NetworkManager writes or would write to {{ic|/etc/resolv.conf}} can be found at {{ic|/run/NetworkManager/resolv.conf}}.<br />
* A {{ic|resolv.conf}} file with the acquired name servers and search domains can be found at {{ic|/run/NetworkManager/no-stub-resolv.conf}}.<br />
}}<br />
<br />
===== Unmanaged /etc/resolv.conf =====<br />
<br />
To stop NetworkManager from touching {{ic|/etc/resolv.conf}}, set {{ic|1=main.dns=none}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=none<br />
}}<br />
<br />
{{Tip|You might also want to set {{ic|1=main.systemd-resolved=false}}, so that NetworkManager does not send the DNS configuration to [[systemd-resolved]].}}<br />
<br />
{{Note|See [[#DNS caching and conditional forwarding]], to configure NetworkManager using other DNS backends like [[dnsmasq]] and [[systemd-resolved]], instead of using {{ic|1=main.dns=none}}.}}<br />
<br />
After that {{ic|/etc/resolv.conf}} might be a broken symlink that you will need to remove. Then, just create a new {{ic|/etc/resolv.conf}} file.<br />
<br />
===== Use openresolv =====<br />
<br />
{{Note|Do not set {{ic|1=rc-manager=resolvconf}} when {{Pkg|systemd-resolvconf}} is installed. ''systemd-resolved'' provides limited support for the ''resolvconf'' interface and NetworkManager supports communicating with systemd-resolved through D-Bus without using ''resolvconf''.}}<br />
<br />
To configure NetworkManager to use [[openresolv]], set {{ic|1=main.rc-manager=resolvconf}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/rc-manager.conf|2=<br />
[main]<br />
rc-manager=resolvconf<br />
}}<br />
<br />
=== Firewall ===<br />
<br />
You can assign a [[firewalld]] zone based on your current connection. For example a restrictive firewall when at work, and a less restrictive one when at home.<br />
<br />
This can also be done with [[#Network services with NetworkManager dispatcher|NetworkManager dispatcher]].<br />
<br />
=== 802.1x / PEAP configuration ===<br />
<br />
A PEAP and 802.1x network can be added by adding a config file to {{ic|/etc/NetworkManager/system-connections/''name''}}.<br />
<br />
Here is an example configuration file for IPv4 with IPv6 disabled:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''name''|2=<br />
[ipv6]<br />
method=ignore<br />
<br />
[ipv4]<br />
method=auto<br />
<br />
[connection]<br />
#id=XXXXXXXXX<br />
#uuid=XXXXXXXXX<br />
type=802-11-wireless<br />
#timestamp=XXXX<br />
<br />
[802-11-wireless-security]<br />
key-mgmt=wpa-eap<br />
<br />
[802-11-wireless]<br />
ssid=ssid<br />
mode=infrastructure<br />
#seen-bssids=XXXXXXXXX<br />
security=802-11-wireless-security<br />
<br />
[802-1x]<br />
eap=peap;<br />
identity=user<br />
password=password<br />
phase2-auth=mschapv2<br />
}}<br />
<br />
The number sign (#) defines comments.<br />
<br />
=== Automatically connect to VPN ===<br />
<br />
NetworkManager can be set to automatically connect to a VPN when connecting to the internet, on a per network basis. The VPN connection itself can be added in the Gnome gui, but to make it automatically use the VPN {{ic|nmcli}} must be used.<br />
<br />
First, make sure to make the VPN connection available to all users. In the Gnome gui this is a matter of checking a box under the {{ic|details}} tab. Then under the {{ic|Identity}} tab, in the password field, click the icon on the right side in the field, and set it to {{ic|Store the password for all users}}.<br />
<br />
Then use the {{ic|nmcli}} tool via command line:<br />
<br />
# nmcli connection<br />
<br />
To list your connections. Then enter configuration mode for the internet connection you want to automatically connect to a VPN<br />
<br />
# nmcli connection edit <NAME of Internet Connection><br />
<br />
Please note that it is the Internet connection and not the VPN you should edit. Here you do not need to use the UUID of the Internet connection, the NAME is fine. Then make the setting with the command:<br />
<br />
# set connection.secondaries <UUID of VPN><br />
<br />
Here the UUID of the VPN must be used, but {{ic|tab}} works for autocompletion.<br />
<br />
Finally save and quit:<br />
<br />
# save<br />
# quit<br />
<br />
Now when NetworkManager is restarted and you connect to the Internet connection you have configured, you should automatically get connected to the VPN.<br />
<br />
== Network services with NetworkManager dispatcher ==<br />
<br />
There are quite a few network services that you will not want running until NetworkManager brings up an interface. NetworkManager has the ability to start services when you connect to a network and stop them when you disconnect (e.g. when using [[NFS]], [[SMB]] and [[NTPd]]).<br />
<br />
To activate the feature you need to [[enable]] and [[start]] the {{ic|NetworkManager-dispatcher.service}}.<br />
<br />
Once the service is active, scripts can be added to the {{ic|/etc/NetworkManager/dispatcher.d}} directory.<br />
<br />
Scripts must be owned by '''root''', otherwise the dispatcher will not execute them. For added security, set group [[ownership]] to root as well:<br />
<br />
# chown root:root /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
Make sure the file has correct permissions:<br />
<br />
# chmod 755 /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
The scripts will be run in alphabetical order at connection time, and in reverse alphabetical order at disconnect time. To ensure what order they come up in, it is common to use numerical characters prior to the name of the script (e.g. {{ic|10-portmap}} or {{ic|30-netfs}} (which ensures that the ''portmapper'' is up before NFS mounts are attempted).<br />
<br />
Scripts will receive the following arguments:<br />
<br />
* '''Interface name:''' e.g. {{ic|eth0}}<br />
* '''Interface status:''' ''up'' or ''down''<br />
* '''VPN status:''' ''vpn-up'' or ''vpn-down''<br />
<br />
{{Warning|If you connect to foreign or public networks, be aware of what services you are starting and what servers you expect to be available for them to connect to. You could make a security hole by starting the wrong services while connected to a public network.}}<br />
<br />
=== Avoiding the dispatcher timeout ===<br />
<br />
If the above is working, then this section is not relevant. However, there is a general problem related to running dispatcher scripts which take longer to be executed. Initially an internal timeout of three seconds only was used. If the called script did not complete in time, it was killed. Later the timeout was extended to about 20 seconds (see the [https://bugzilla.redhat.com/show_bug.cgi?id=982734 Bugtracker] for more information). If the timeout still creates the problem, a work around may be to modify the dispatcher service file {{ic|/usr/lib/systemd/system/NetworkManager-dispatcher.service}} to remain active after exit: <br />
<br />
{{hc|/etc/systemd/system/NetworkManager-dispatcher.service.d/remain_after_exit.conf|2=<br />
[Service]<br />
RemainAfterExit=yes<br />
}}<br />
<br />
Now start and enable the modified {{ic|NetworkManager-dispatcher}} service.<br />
<br />
{{Warning|Adding the {{ic|RemainAfterExit}} line to it will prevent the dispatcher from closing. Unfortunately, the dispatcher '''has''' to close before it can run your scripts again. With it the dispatcher will not time out but it also will not close, which means that the scripts will only run once per boot. Therefore, do not add the line unless the timeout is definitely causing a problem.}}<br />
<br />
=== Dispatcher examples ===<br />
<br />
==== Mount remote folder with sshfs ====<br />
<br />
As the script is run in a very restrictive environment, you have to export {{ic|SSH_AUTH_SOCK}} in order to connect to your SSH agent. There are different ways to accomplish this, see [https://bbs.archlinux.org/viewtopic.php?pid=1042030#p1042030 this message] for more information. The example below works with [[GNOME Keyring]], and will ask you for the password if not unlocked already. In case NetworkManager connects automatically on login, it is likely ''gnome-keyring'' has not yet started and the export will fail (hence the sleep). The {{ic|UUID}} to match can be found with the command {{ic|nmcli connection status}} or {{ic|nmcli connection list}}. <br />
<br />
{{bc|<nowiki><br />
#!/bin/sh<br />
USER='username'<br />
REMOTE='user@host:/remote/path'<br />
LOCAL='/local/path'<br />
<br />
interface=$1 status=$2<br />
if [ "$CONNECTION_UUID" = "</nowiki>''uuid''<nowiki>" ]; then<br />
case $status in<br />
up)<br />
SSH_AUTH_SOCK=$(find /tmp -maxdepth 1 -type s -user "$USER" -name 'ssh')<br />
export SSH_AUTH_SOCK<br />
su "$USER" -c "sshfs $REMOTE $LOCAL"<br />
;;<br />
down)<br />
fusermount -u "$LOCAL"<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
==== Mounting of SMB shares ====<br />
<br />
Some [[SMB]] shares are only available on certain networks or locations (e.g. at home). You can use the dispatcher to only mount SMB shares that are present at your current location.<br />
<br />
The following script will check if we connected to a specific network and mount shares accordingly:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-mount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
# Find the connection UUID with "nmcli connection show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
if [ "$2" = "up" ]; then<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
mount /your/mount/point & <br />
# add more shares as needed<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The following script will unmount all SMB shares before a software initiated disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/pre-down.d/30-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|Make sure this script is located in the {{ic|pre-down.d}} sub-directory as shown above, otherwise it will unmount all shares on any connection state change.}}<br />
<br />
The following script will attempt to unmount all SMB shares following an unexpected disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/40-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
if [ "$2" = "down" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|<br />
* Since NetworkManager 0.9.8, the ''pre-down'' and ''down'' events are not executed on shutdown or restart, see [https://bugzilla.gnome.org/show_bug.cgi?id&#61;701242 this bug report] for more info.<br />
* The previous ''umount'' scripts are still prone to leaving applications actually accessing the mount to 'hang'.<br />
}}<br />
<br />
An alternative is to use the script as seen in [[NFS#Using a NetworkManager dispatcher]]:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-smb.sh|<nowiki><br />
#!/bin/bash<br />
<br />
# Find the connection UUID with "nmcli con show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
WANTED_CON_UUID="CHANGE-ME-NOW-9c7eff15-010a-4b1c-a786-9b4efa218ba9"<br />
<br />
if [[ "$CONNECTION_UUID" == "$WANTED_CON_UUID" ]]; then<br />
<br />
# Script parameter $1: NetworkManager connection name, not used<br />
# Script parameter $2: dispatched event<br />
<br />
case "$2" in<br />
"up")<br />
mount -a -t cifs<br />
;;<br />
"pre-down");&<br />
"vpn-pre-down")<br />
umount -l -a -t cifs >/dev/null<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|This script ignores mounts with the {{ic|noauto}} option, remove this mount option or use {{ic|auto}} to allow the dispatcher to manage these mounts.}}<br />
<br />
Create a symlink inside {{ic|/etc/NetworkManager/dispatcher.d/pre-down/}} to catch the {{ic|pre-down}} events:<br />
<br />
# ln -s ../30-smb.sh /etc/NetworkManager/dispatcher.d/pre-down.d/30-smb.sh<br />
<br />
==== Mounting of NFS shares ====<br />
<br />
See [[NFS#Using a NetworkManager dispatcher]].<br />
<br />
==== Use dispatcher to automatically toggle wireless depending on LAN cable being plugged in ====<br />
<br />
The idea is to only turn Wi-Fi on when the LAN cable is unplugged (for example when detaching from a laptop dock), and for Wi-Fi to be automatically disabled, once a LAN cable is plugged in again. <br />
<br />
Create the following dispatcher script[https://superuser.com/questions/233448/disable-wlan-if-wired-cable-network-is-available], replacing {{ic|1=LAN_interface}} with yours.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/wlan_auto_toggle.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$1" = "LAN_interface" ]; then<br />
case "$2" in<br />
up)<br />
nmcli radio wifi off<br />
;;<br />
down)<br />
nmcli radio wifi on<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|You can get a list of interfaces using [[#nmcli examples|nmcli]]. The ethernet (LAN) interfaces start with {{ic|en}}, e.g. {{ic|1=enp0s5}}}}<br />
<br />
==== Use dispatcher to connect to a VPN after a network connection is established ====<br />
<br />
In this example we want to connect automatically to a previously defined VPN connection after connecting to a specific Wi-Fi network. First thing to do is to create the dispatcher script that defines what to do after we are connected to the network.<br />
<br />
{{Note|This script will require {{Pkg|wireless_tools}} in order to use {{ic|iwgetid}}.}}<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME"<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you would like to attempt to automatically connect to VPN for all Wi-Fi networks, you can use the following definition of the ESSID: {{ic|1=ESSID=$(iwgetid -r)}}. Remember to set the script's permissions [[#Network services with NetworkManager dispatcher|accordingly]]. <br />
<br />
Trying to connect with the above script may still fail with {{ic|NetworkManager-dispatcher.service}} complaining about 'no valid VPN secrets', because of [https://developer.gnome.org/NetworkManager/0.9/secrets-flags.html the way VPN secrets are stored]. Fortunately, there are different options to give the above script access to your VPN password.<br />
<br />
1: One of them requires editing the VPN connection configuration file to make NetworkManager store the secrets by itself rather than inside a keyring [https://bugzilla.redhat.com/show_bug.cgi?id=710552 that will be inaccessible for root]: open up {{ic|/etc/NetworkManager/system-connections/''name of your VPN connection''}} and change the {{ic|password-flags}} and {{ic|secret-flags}} from {{ic|1}} to {{ic|0}}.<br />
<br />
If that alone does not work, you may have to create a {{ic|passwd-file}} in a safe location with the same permissions and ownership as the dispatcher script, containing the following:<br />
<br />
{{hc|/path/to/passwd-file|<br />
vpn.secrets.password:YOUR_PASSWORD<br />
}}<br />
<br />
The script must be changed accordingly, so that it gets the password from the file:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME" passwd-file /path/to/passwd-file<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
2: Alternatively, change the {{ic|password-flags}} and put the password directly in the configuration file adding the section {{ic|vpn-secrets}}:<br />
<br />
[vpn]<br />
....<br />
password-flags=0<br />
<br />
[vpn-secrets]<br />
password=''your_password''<br />
<br />
{{Note|It may now be necessary to re-open the NetworkManager connection editor and save the VPN passwords/secrets again.}}<br />
<br />
==== Use dispatcher to disable IPv6 on VPN provider connections ====<br />
<br />
Many [[:Category:VPN providers|commercial VPN providers]] support only IPv4. That means all IPv6 traffic bypasses the VPN and renders it virtually useless. To avoid this, dispatcher can be used to disable all IPv6 traffic for the time a VPN connection is up.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/10-vpn-ipv6|<nowiki><br />
#!/bin/sh<br />
<br />
case "$2" in<br />
vpn-up)<br />
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
vpn-down)<br />
echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
==== OpenNTPD ====<br />
<br />
See [[OpenNTPD#Using NetworkManager dispatcher]].<br />
<br />
== Testing ==<br />
<br />
NetworkManager applets are designed to load upon login so no further configuration should be necessary for most users. If you have already disabled your previous network settings and disconnected from your network, you can now test if NetworkManager will work. The first step is to [[start]] {{ic|NetworkManager.service}}.<br />
<br />
Some applets will provide you with a {{ic|.desktop}} file so that the NetworkManager applet can be loaded through the application menu. If it does not, you are going to either have to discover the command to use or logout and login again to start the applet. Once the applet is started, it will likely begin polling network connections with for auto-configuration with a DHCP server.<br />
<br />
To start the GNOME applet in non-xdg-compliant window managers like [[awesome]]:<br />
<br />
nm-applet --sm-disable &<br />
<br />
For static IP addresses, you will have to configure NetworkManager to understand them. The process usually involves right-clicking the applet and selecting something like 'Edit Connections'.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Encrypted Wi-Fi passwords ===<br />
<br />
By default, NetworkManager stores passwords in clear text in the connection files at {{ic|/etc/NetworkManager/system-connections/}}. To print the stored passwords, use the following command:<br />
<br />
# grep -r '^psk=' /etc/NetworkManager/system-connections/<br />
<br />
The passwords are accessible to the root user in the filesystem and to users with access to settings via the GUI (e.g. {{ic|nm-applet}}). <br />
<br />
It is preferable to save the passwords in encrypted form in a keyring instead of clear text. The downside of using a keyring is that the connections have to be set up for each user.<br />
<br />
==== Using GNOME Keyring ====<br />
<br />
The keyring daemon has to be started and the keyring needs to be unlocked for the following to work.<br />
<br />
Furthermore, NetworkManager needs to be configured not to store the password for all users. Using GNOME {{ic|nm-applet}}, run {{ic|nm-connection-editor}} from a terminal, select a network connection, click {{ic|Edit}}, select the {{ic|Wifi-Security}} tab and click on the right icon of password and check {{ic|Store the password only for this user}}.<br />
<br />
==== Using KDE Wallet ====<br />
<br />
Using KDE's {{Pkg|plasma-nm}}, click the applet, click on the top right {{ic|Settings}} icon, click on a network connection, in the {{ic|General settings}} tab, untick {{ic|all users may connect to this network}}. If the option is ticked, the passwords will still be stored in clear text, even if a keyring daemon is running.<br />
<br />
If the option was selected previously and you un-tick it, you may have to use the {{ic|reset}} option first to make the password disappear from the file. Alternatively, delete the connection first and set it up again.<br />
<br />
=== Sharing internet connection over Wi-Fi ===<br />
<br />
You can share your internet connection (e.g. 3G or wired) with a few clicks. Please note that a [[firewall]] may interfere with internet sharing.<br />
<br />
You will need a Wi-Fi card which supports AP mode, see [[Software access point#Wi-Fi device must support AP mode]] for details.<br />
<br />
[[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
<br />
Create the shared connection:<br />
<br />
* Click on applet and choose ''Create new wireless network''.<br />
* Follow wizard (choose WPA2 or higher, be sure to use at least 8 character long password, lower lengths will fail).<br />
** Choose either [[Fedora:Features/RealHotspot|Hotspot]] or Ad-hoc as Wi-Fi mode.<br />
<br />
The connection will be saved and remain stored for the next time you need it.<br />
<br />
{{Note|Android does not support connecting to Ad-hoc networks. To share a connection with Android use infrastructure mode (i.e. set Wi-Fi mode to "Hotspot").}}<br />
<br />
=== Sharing internet connection over Ethernet ===<br />
<br />
Scenario: your device has internet connection over wi-fi and you want to share the internet connection to other devices over ethernet.<br />
<br />
Requirements:<br />
<br />
* [[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
* Your internet connected device and the other devices are connected over a suitable ethernet cable (this usually means a cross over cable or a switch in between).<br />
* Internet sharing is not blocked by a [[firewall]].<br />
<br />
Steps:<br />
<br />
{{Style|{{Pkg|nm-connection-editor}} is not a dependency of {{Pkg|networkmanager}} and needs to be installed separately.}}<br />
<br />
* Run {{ic|nm-connection-editor}} from terminal.<br />
* Add a new ethernet connection.<br />
* Give it some sensible name. For example "Shared Internet"<br />
* Go to "IPv4 Settings".<br />
* For "Method:" select "Shared to other computers".<br />
* Save<br />
<br />
Now you should have a new option "Shared Internet" under the Wired connections in NetworkManager.<br />
<br />
=== Checking if networking is up inside a cron job or script ===<br />
<br />
{{Out of date|''nm-tool'' was remove from NetworkManager for long time now[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/bb8c75bd536d4f8fb80a4366025a279078f0ec81]. ''nmcli'' should be used instead.}}<br />
<br />
Some ''cron'' jobs require networking to be up to succeed. You may wish to avoid running these jobs when the network is down. To accomplish this, add an '''if''' test for networking that queries NetworkManager's ''nm-tool'' and checks the state of networking. The test shown here succeeds if any interface is up, and fails if they are all down. This is convenient for laptops that might be hardwired, might be on wireless, or might be off the network.<br />
<br />
{{bc|<nowiki><br />
if [ $(nm-tool|grep State|cut -f2 -d' ') == "connected" ]; then<br />
#Whatever you want to do if the network is online<br />
else<br />
#Whatever you want to do if the network is offline - note, this and the else above are optional<br />
fi<br />
</nowiki>}}<br />
<br />
This useful for a {{ic|cron.hourly}} script that runs ''fpupdate'' for the F-Prot virus scanner signature update, as an example. Another way it might be useful, with a little modification, is to differentiate between networks using various parts of the output from ''nm-tool''; for example, since the active wireless network is denoted with an asterisk, you could grep for the network name and then grep for a literal asterisk.<br />
<br />
=== Connect to network with secret on boot ===<br />
<br />
By default, NetworkManager will not connect to networks requiring a secret automatically on boot. This is because it locks such connections to the user who makes it by default, only connecting after they have logged in. To change this, do the following:<br />
<br />
# Right click on the {{ic|nm-applet}} icon in your panel and select Edit Connections and open the Wireless tab<br />
# Select the connection you want to work with and click the Edit button<br />
# Check the boxes “Connect Automatically” and “Available to all users”<br />
# Additionally, ensure that under "Wi-Fi Security", "Store password for all users (not encrypted)" is selected<br />
<br />
Log out and log back in to complete.<br />
<br />
=== OpenConnect with password in KWallet ===<br />
<br />
While you may type both values at connection time, {{Pkg|plasma-nm}} 0.9.3.2-1 and above are capable of retrieving OpenConnect username and password directly from [[KWallet]].<br />
<br />
Open "KDE Wallet Manager" and look up your OpenConnect VPN connection under "Network Management|Maps". Click "Show values" and <br />
enter your credentials in key "VpnSecrets" in this form (replace ''username'' and ''password'' accordingly):<br />
<br />
form:main:username%SEP%''username''%SEP%form:main:password%SEP%''password''<br />
<br />
Next time you connect, username and password should appear in the "VPN secrets" dialog box.<br />
<br />
=== Ignore specific devices ===<br />
<br />
Sometimes it may be desired that NetworkManager ignores specific devices and does not try to configure addresses and routes for them. You can quickly and easily ignore devices by MAC or interface-name by using the following in {{ic|/etc/NetworkManager/conf.d/unmanaged.conf}}:<br />
<br />
[keyfile]<br />
unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth0<br />
<br />
After editing the file, run {{ic|nmcli general reload}} as root. Afterwards you should be able to configure interfaces without NetworkManager altering what you have set.<br />
<br />
=== Configuring MAC address randomization ===<br />
<br />
{{Note|1=Disabling MAC address randomization may be needed to get (stable) link connection [https://bbs.archlinux.org/viewtopic.php?id=220101] and/or networks that restrict devices based on their MAC Address or have a limit network capacity.}}<br />
<br />
MAC randomization can be used for increased privacy by not disclosing your real MAC address to the network.<br />
<br />
NetworkManager supports two types MAC Address Randomization: randomization during scanning, and for network connections. Both modes can be configured by modifying {{ic|/etc/NetworkManager/NetworkManager.conf}} or by creating a separate configuration file in {{ic|/etc/NetworkManager/conf.d/}} which is recommended since the aforementioned config file may be overwritten by NetworkManager.<br />
<br />
Randomization during Wi-Fi scanning is enabled by default, but it may be disabled by adding the following lines to {{ic|/etc/NetworkManager/NetworkManager.conf}} or a dedicated configuration file under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device]<br />
wifi.scan-rand-mac-address=no<br />
}}<br />
<br />
MAC randomization for network connections can be set to different modes for both wireless and ethernet interfaces. See the [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details on the different modes. <br />
<br />
In terms of MAC randomization the most important modes are {{ic|stable}} and {{ic|random}}. {{ic|stable}} generates a random MAC address when you connect to a new network and associates the two permanently. This means that you will use the same MAC address every time you connect to that network. In contrast, {{ic|random}} will generate a new MAC address every time you connect to a network, new or previously known. You can configure the MAC randomization by adding the desired configuration under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device-mac-randomization]<br />
# "yes" is already the default for scanning<br />
wifi.scan-rand-mac-address=yes<br />
<br />
[connection-mac-randomization]<br />
# Randomize MAC for every ethernet connection<br />
ethernet.cloned-mac-address=random<br />
# Generate a random MAC for each WiFi and associate the two permanently.<br />
wifi.cloned-mac-address=stable<br />
}}<br />
<br />
See the following [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details.<br />
<br />
=== Enable IPv6 Privacy Extensions ===<br />
<br />
See [[IPv6#NetworkManager]].<br />
<br />
=== Working with wired connections ===<br />
<br />
By default, NetworkManager generates a connection profile for each wired ethernet connection it finds. At the point when generating the connection, it does not know whether there will be more ethernet adapters available. Hence, it calls the first wired connection "Wired connection 1". You can avoid generating this connection, by configuring {{ic|no-auto-default}} (see {{man|5|NetworkManager.conf}}), or by simply deleting it. Then NetworkManager will remember not to generate a connection for this interface again.<br />
<br />
You can also edit the connection (and persist it to disk) or delete it. NetworkManager will not re-generate a new connection. Then you can change the name to whatever you want. You can use something like nm-connection-editor for this task.<br />
<br />
=== Using iwd as the Wi-Fi backend ===<br />
<br />
Install {{AUR|networkmanager-iwd}} or enable the experimental [[iwd]] backend creating the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_backend.conf|2=<br />
[device]<br />
wifi.backend=iwd<br />
}}<br />
<br />
=== Running in a network namespace ===<br />
<br />
If you would like to run NetworkManager inside a network namespace (e.g., to manage a specific device which should be use by selected applications), bring the device down before moving it to the namespace:<br />
<br />
$ ip link set dev ''MY_DEVICE'' down<br />
$ ip link set dev ''MY_DEVICE'' netns ''MY_NAMESPACE''<br />
$ ip netns exec ''MY_NAMESPACE'' NetworkManager<br />
...<br />
$ ip netns exec ''MY_NAMESPACE'' killall NetworkManager<br />
<br />
otherwise NetworkManager will later fail to establish the connection with a {{ic|device is strictly unmanaged}} error.<br />
<br />
== Troubleshooting ==<br />
<br />
=== No prompt for password of secured Wi-Fi networks ===<br />
<br />
When trying to connect to a secured Wi-Fi network, no prompt for a password is shown and no connection is established. This happens when no keyring package is installed. An easy solution is to install {{Pkg|gnome-keyring}}. If you want the passwords to be stored in encrypted form, follow [[GNOME Keyring]] to set up the ''gnome-keyring-daemon''.<br />
<br />
=== Network management disabled ===<br />
<br />
When NetworkManager shuts down but the pid (state) file is not removed, you will see a {{ic|Network management disabled}} message. If this happens, remove the file manually:<br />
<br />
# rm /var/lib/NetworkManager/NetworkManager.state<br />
<br />
=== Problems with internal DHCP client ===<br />
<br />
If you have problems with getting an IP address using the internal DHCP client, consider using another DHCP client, see [[#DHCP client]] for instructions. This workaround might solve problems in big wireless networks like eduroam.<br />
<br />
=== DHCP problems with dhclient ===<br />
<br />
If you have problems with getting an IP address via DHCP, try to add the following to your {{ic|/etc/dhclient.conf}}:<br />
<br />
interface "eth0" {<br />
send dhcp-client-identifier 01:''aa:bb:cc:dd:ee:ff'';<br />
}<br />
<br />
Where {{ic|''aa:bb:cc:dd:ee:ff''}} is the MAC address of this NIC. The MAC address can be found using the {{ic|ip link show ''interface''}} command from the {{Pkg|iproute2}} package.<br />
<br />
=== 3G modem not detected ===<br />
<br />
See [[USB 3G Modem#NetworkManager]].<br />
<br />
=== Switching off WLAN on laptops ===<br />
<br />
Sometimes NetworkManager will not work when you disable your Wi-Fi adapter with a switch on your laptop and try to enable it again afterwards. This is often a problem with ''rfkill''. To check if the driver notifies ''rfkill'' about the wireless adapter's status, use:<br />
<br />
$ watch -n1 rfkill list all<br />
<br />
If one identifier stays blocked after you switch on the adapter you could try to manually unblock it with (where X is the number of the identifier provided by the above output):<br />
<br />
# rfkill event unblock X<br />
<br />
=== Static IP address settings revert to DHCP ===<br />
<br />
Due to an unresolved bug, when changing default connections to a static IP address, {{ic|nm-applet}} may not properly store the configuration change, and will revert to automatic DHCP.<br />
<br />
To work around this issue you have to edit the default connection (e.g. "Auto eth0") in {{ic|nm-applet}}, change the connection name (e.g. "my eth0"), uncheck the "Available to all users" checkbox, change your static IP address settings as desired, and click '''Apply'''. This will save a new connection with the given name.<br />
<br />
Next, you will want to make the default connection not connect automatically. To do so, run {{ic|nm-connection-editor}} ('''not''' as root). In the connection editor, edit the default connection (e.g. "Auto eth0") and uncheck "Connect automatically". Click '''Apply''' and close the connection editor.<br />
<br />
=== Cannot edit connections as normal user ===<br />
<br />
See [[#Set up PolicyKit permissions]].<br />
<br />
=== Forget hidden wireless network ===<br />
<br />
Since hidden networks are not displayed in the selection list of the Wireless view, they cannot be forgotten (removed) with the GUI. You can delete one with the following command:<br />
<br />
# rm /etc/NetworkManager/system-connections/''SSID''<br />
<br />
This works for any other connection.<br />
<br />
=== VPN not working in GNOME ===<br />
<br />
When setting up OpenConnect or vpnc connections in NetworkManager while using GNOME, you will sometimes never see the dialog box pop up and the following error appears in {{ic|/var/log/errors.log}}:<br />
<br />
localhost NetworkManager[399]: <error> [1361719690.10506] [nm-vpn-connection.c:1405] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.<br />
<br />
This is caused by the GNOME NM Applet expecting dialog scripts to be at {{ic|/usr/lib/gnome-shell}}, when NetworkManager's packages put them in {{ic|/usr/lib/networkmanager}}.<br />
As a "temporary" fix (this bug has been around for a while now), make the following symlink(s):<br />
<br />
* For OpenConnect: {{ic|ln -s /usr/lib/networkmanager/nm-openconnect-auth-dialog /usr/lib/gnome-shell/}}<br />
* For VPNC (i.e. Cisco VPN): {{ic|ln -s /usr/lib/networkmanager/nm-vpnc-auth-dialog /usr/lib/gnome-shell/}}<br />
<br />
This may need to be done for any other NM VPN plugins as well, but these are the two most common.<br />
<br />
=== Unable to connect to visible European wireless networks ===<br />
<br />
WLAN chips are shipped with a default [[Wireless network configuration#Respecting the regulatory domain|regulatory domain]]. If your access point does not operate within these limitations, you will not be able to connect to the network. Fixing this is easy:<br />
<br />
# [[Install]] {{Pkg|crda}}<br />
# Uncomment the correct Country Code in {{ic|/etc/conf.d/wireless-regdom}}<br />
# Reboot the system, because the setting is only read on boot<br />
<br />
=== Automatic connect to VPN on boot is not working ===<br />
<br />
The problem occurs when the system (i.e. NetworkManager running as the root user) tries to establish a VPN connection, but the password is not accessible because it is stored in the GNOME keyring of a particular user. <br />
<br />
A solution is to keep the password to your VPN in plaintext, as described in step (2.) of [[#Use dispatcher to connect to a VPN after a network connection is established]]. <br />
<br />
You do not need to use the dispatcher described in step (1.) to auto-connect anymore, if you use the new "auto-connect VPN" option from the {{ic|nm-applet}} GUI.<br />
<br />
=== Systemd Bottleneck ===<br />
<br />
Over time the log files ({{ic|/var/log/journal}}) can become very large. This can have a big impact on boot performance when using NetworkManager, see: [[Systemd#Boot time increasing over time]].<br />
<br />
=== Regular network disconnects, latency and lost packets (WiFi) ===<br />
<br />
NetworkManager does a scan every 2 minutes.<br />
<br />
Some WiFi drivers have issues when scanning for base stations whilst connected/associated. Symptoms include VPN disconnects/reconnects and lost packets, web pages failing to load and then refresh fine.<br />
<br />
Running {{ic|journalctl -f}} will indicate that this is taking place, messages like the following will be contained in the logs at regular intervals.<br />
<br />
NetworkManager[410]: <info> (wlp3s0): roamed from BSSID 00:14:48:11:20:CF (my-wifi-name) to (none) ((none))<br />
<br />
There is a patched version of NetworkManager which should prevent this type of scanning: {{AUR|networkmanager-noscan}}.<br />
<br />
Alternatively, if roaming is not important, the periodic scanning behavior can be disabled by locking the BSSID of the access point in the WiFi connection profile.<br />
<br />
=== Unable to turn on wi-fi with Lenovo laptop (IdeaPad, Legion, etc.) ===<br />
<br />
There is an issue with the {{ic|ideapad_laptop}} module on some Lenovo models due to the wi-fi driver incorrectly reporting a soft block. The card can still be manipulated with {{ic|netctl}}, but managers like NetworkManager break. You can verify that this is the problem by checking the output of {{ic|rfkill list}} after toggling your hardware switch and seeing that the soft block persists.<br />
<br />
{{Accuracy|Try to use {{ic|rfkill.default_state}} and {{ic|rfkill.master_switch_mode}} (see [https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt kernel-parameters.txt]) to fix the rfkill problem.}}<br />
<br />
[[modprobe|Unloading]] the {{ic|ideapad_laptop}} module should fix this. ('''warning''': this may disable the laptop keyboard and touchpad also!).<br />
<br />
=== Turn off hostname sending ===<br />
<br />
NetworkManager by default sends the hostname to the DHCP server. Hostname sending can only be disabled per connection not globally ([https://bugzilla.gnome.org/show_bug.cgi?id=768076 GNOME Bug 768076]).<br />
<br />
To disable sending your hostname to the DHCP server for a specific connection, add the following to your network connection file:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''your_connection_file''|2=<br />
...<br />
[ipv4]<br />
dhcp-send-hostname=false<br />
...<br />
[ipv6]<br />
dhcp-send-hostname=false<br />
...<br />
}}<br />
<br />
=== nm-applet disappears in i3wm ===<br />
<br />
If you use the {{ic|xfce4-notifyd.service}} for notifications you must [[edit]] the unit and add the following:<br />
<br />
{{hc|/etc/systemd/user/xfce4-notifyd.service.d/display_env.conf|2=<br />
[Service]<br />
Environment="DISPLAY=:0.0"<br />
}}<br />
<br />
After reloading the daemons [[restart]] {{ic|xfce4-notifyd.service}}. Exit i3 and start it back up again and the applet should show on the tray.<br />
<br />
=== nm-applet tray icons display wrongly ===<br />
<br />
Currently the tray icons of nm-applet are drawn on top of one another, i.e. the icon displaying wireless strength might show on top of the icon indicating no wired connection.<br />
This is apparently a GTK3 bug/problem: https://gitlab.gnome.org/GNOME/gtk/issues/1280 .<br />
<br />
A patched version of GTK3 exists in AUR, which apparently fixes the tray icon bug: {{AUR|gtk3-mushrooms}} .<br />
<br />
=== Unit dbus-org.freedesktop.resolve1.service not found ===<br />
<br />
If {{ic|systemd-resolved.service}} is not started, NetworkManager will try to start it using D-Bus and fail:<br />
<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
dbus-daemon[991]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
<br />
This is because NetworkManager will try to send DNS information to [[systemd-resolved]] regardless of the {{ic|1=main.dns=}} setting in {{man|5|NetworkManager.conf}}.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383]<br />
<br />
This can be disabled with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/no-systemd-resolved.conf|2=<br />
[main]<br />
systemd-resolved=false<br />
}}<br />
<br />
See {{Bug|62138}}.<br />
<br />
=== Secrets were required, but not provided ===<br />
<br />
If you attempt to connect to a network using {{ic|nmcli device wifi connect ''SSID'' password ''password''}} and received the following error:<br />
<br />
Error: Connection activation failed: (7) Secrets were required, but not provided<br />
<br />
The error can be resolved by deleting the connection profile and creating a new one:<br />
<br />
$ nmcli connection delete ''SSID''<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
=== WPA Enterprise connection with NetworkManager ===<br />
<br />
If you try to connect to an WPA Enterprise network like 'eduroam' with NetworkManager with the [[iwd]] backend then you will get the following error from NetworkManager:<br />
<br />
Connection 'eduroam' is not avialable on device wlan0 because profile is not compatible with device (802.1x connections must have IWD provisioning files)<br />
<br />
This is because NetworkManager can not configure a WPA Enterprise network. Therefore you have to configure it using an iwd config file {{ic|/var/lib/iwd/''essid''.8021x}} like described in [[iwd#WPA Enterprise]].<br />
<br />
== See also ==<br />
<br />
* [https://blogs.gnome.org/dcbw/2015/02/16/networkmanager-for-administrators-part-1/ NetworkManager for Administrators Part 1]<br />
* [[Wikipedia:NetworkManager]]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=NetworkManager&diff=627218NetworkManager2020-07-30T15:16:43Z<p>Tobbebobbe: /* Set up VPN with WireGuard */ spelling</p>
<hr />
<div>[[Category:Network managers]]<br />
[[Category:Red Hat]]<br />
[[cs:NetworkManager]]<br />
[[de:Networkmanager]]<br />
[[es:NetworkManager]]<br />
[[fr:NetworkManager]]<br />
[[it:NetworkManager]]<br />
[[ja:NetworkManager]]<br />
[[pt:NetworkManager]]<br />
[[zh-hans:NetworkManager]]<br />
{{Related articles start}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related articles end}}<br />
[https://wiki.gnome.org/Projects/NetworkManager/ NetworkManager] is a program for providing detection and configuration for systems to automatically connect to networks. NetworkManager's functionality can be useful for both wireless and wired networks. For wireless networks, NetworkManager prefers known wireless networks and has the ability to switch to the most reliable network. NetworkManager-aware applications can switch from online and offline mode. NetworkManager also prefers wired connections over wireless ones, has support for modem connections and certain types of VPN. NetworkManager was originally developed by Red Hat and now is hosted by the [[GNOME]] project.<br />
<br />
{{Expansion|Clear text storage of secrets is not limited to just Wi-Fi passwords. The secrets are stored in files (and folder) only accesible to root.}}<br />
<br />
{{Warning|By default, Wi-Fi passwords are stored in clear text, see [[#Encrypted Wi-Fi passwords]].}}<br />
<br />
== Installation ==<br />
<br />
NetworkManager can be [[install]]ed with the package {{Pkg|networkmanager}}, which contains a daemon, a command line interface ({{ic|nmcli}}) and a curses‐based interface ({{ic|nmtui}}). <br />
<br />
=== Enable NetworkManager ===<br />
<br />
After installation, you should [[start/enable]] {{ic|NetworkManager.service}}. Once the NetworkManager daemon is started, it will automatically connect to any available "system connections" that have already been configured. Any "user connections" or unconfigured connections will need ''nmcli'' or an applet to configure and connect.<br />
<br />
=== Additional interfaces ===<br />
<br />
* {{Pkg|nm-connection-editor}} for a graphical user interface,<br />
* {{Pkg|network-manager-applet}} for a system tray applet ({{ic|nm-applet}}).<br />
<br />
{{Note|You must ensure that no other service that wants to configure the network is running; in fact, multiple networking services will conflict. You can find a list of the currently running services with {{ic|1=systemctl --type=service}} and then [[stop]] them. See [[#Configuration]] to enable the NetworkManager service.}}<br />
<br />
=== Mobile broadband support ===<br />
<br />
[[Install]] {{Pkg|modemmanager}}, {{Pkg|mobile-broadband-provider-info}} and {{Pkg|usb_modeswitch}} packages for mobile broadband connection support. See [[USB 3G Modem#NetworkManager]] for details.<br />
<br />
=== PPPoE / DSL support ===<br />
<br />
[[Install]] {{Pkg|rp-pppoe}} package for PPPoE / DSL connection support. To actually add PPPoE connection, use {{ic|1=nm-connection-editor}} and add new DSL/PPPoE connection.<br />
<br />
=== VPN support ===<br />
<br />
NetworkManager since version 1.16 has native support for [[WireGuard]], all it needs is the {{ic|wireguard}} kernel module. Read the [https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-networkmanager/ WireGuard in NetworkManager blog post] for details.<br />
<br />
Support for other VPN types is based on a plug-in system. They are provided in the following packages:<br />
<br />
* {{Pkg|networkmanager-openconnect}} for [[OpenConnect]]<br />
* [[networkmanager-openvpn]] for [[OpenVPN]]<br />
* {{Pkg|networkmanager-pptp}} for [[PPTP Client]]<br />
* {{Pkg|networkmanager-vpnc}} for [[Vpnc]]<br />
* {{Pkg|networkmanager-strongswan}} for [[strongSwan]]<br />
* {{AUR|networkmanager-fortisslvpn-git}}<br />
* {{AUR|networkmanager-iodine-git}}<br />
* {{AUR|networkmanager-libreswan}}<br />
* {{AUR|networkmanager-l2tp}}<br />
* {{AUR|networkmanager-ssh-git}}<br />
* {{Pkg|network-manager-sstp}}<br />
<br />
{{Warning|1=There are a lot of [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues?search=VPN&state=opened bugs] (and [https://bugzilla.gnome.org/buglist.cgi?bug_status=__open__&content=VPN&product=NetworkManager old bugs]) related to VPN support. Check the daemon processes options set via the GUI correctly and double-check with each package release.}}<br />
<br />
{{Note|To have fully functioning DNS resolution when using VPN, you should set up [[#DNS caching and conditional forwarding|conditional forwarding]].}}<br />
<br />
==== Set up VPN with WireGuard ====<br />
<br />
The Gnome gui for NetworkManager does not handle WireGuard connections. To add a WireGuard connection from a config-file, issue following command in terminal:<br />
<br />
# nmcli connection import type wireguard file <CONFIG-FILE><br />
<br />
If the file was called WG1.conf a connection called WG1 should have been added. <br />
<br />
If you at any point want to delete the connection, issue the command:<br />
<br />
# nmcli connection delete <CONNECTION NAME><br />
<br />
To actually start the WireGuard tunnel, issue command:<br />
<br />
# nmcli connection up <CONNECTION NAME><br />
<br />
Make sure the connection is listed when you run nmcli:<br />
<br />
# nmcli<br />
<br />
You might want to verify that the private and public keys are correct and corresponds with what you got from your VPN provider:<br />
<br />
# sudo WG_HIDE_KEYS=never wg<br />
<br />
Since WireGuard lacks support in the Gnome gui you may want to proceed to configure NetworkManager to automatically use the WireGuard connection, as described elsewhere on this Wiki page.<br />
<br />
== Usage ==<br />
<br />
NetworkManager comes with {{man|1|nmcli}} and {{man|1|nmtui}}.<br />
<br />
=== nmcli examples ===<br />
<br />
List nearby wifi networks:<br />
<br />
$ nmcli device wifi list<br />
<br />
Connect to a wifi network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
Connect to a hidden network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' hidden yes<br />
<br />
Connect to a wifi on the {{ic|wlan1}} wifi interface:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' ifname wlan1 ''profile_name''<br />
<br />
Disconnect an interface:<br />
<br />
$ nmcli device disconnect ifname eth0<br />
<br />
Reconnect an interface marked as disconnected:<br />
<br />
$ nmcli connection up uuid ''UUID''<br />
<br />
Get a list of UUIDs:<br />
<br />
$ nmcli connection show<br />
<br />
See a list of network devices and their state:<br />
<br />
$ nmcli device<br />
<br />
Turn off wifi:<br />
<br />
$ nmcli radio wifi off<br />
<br />
=== Edit a connection ===<br />
<br />
For a comprehensive list of settings, see {{man|5|nm-settings}}.<br />
<br />
Firstly you need to get list of connections:<br />
<br />
{{hc|$ nmcli connection|<nowiki><br />
NAME UUID TYPE DEVICE<br />
Wired connection 2 e7054040-a421-3bef-965d-bb7d60b7cecf ethernet enp5s0<br />
Wired connection 1 997f2782-f0fc-301d-bfba-15421a2735d8 ethernet enp0s25<br />
MY-HOME-WIFI-5G 92a0f7b3-2eba-49ab-a899-24d83978f308 wifi --<br />
</nowiki>}}<br />
<br />
Here you can use the first column as connection-id used later. In this example we pick {{ic|Wired connection 2}} as a connection-id.<br />
<br />
You have three methods to configure a connection {{ic|Wired connection 2}} after it has been created:<br />
<br />
; nmcli interactive editor<br />
: {{ic|nmcli connection edit 'Wired connection 2'}}.<br> Usage is well documented from the editor.<br />
<br />
; nmcli command line interface<br />
: {{ic|nmcli connection modify 'Wired connection 2' ''setting''.''property'' ''value''}}. See {{man|1|nmcli}} for usage. For example you can change its IPv4 route metric to 200 using {{ic|nmcli connection modify 'Wired connection 2' ipv4.route-metric 200}} command.<br />
<br />
; Connection file<br />
: In {{ic|/etc/NetworkManager/system-connections/}}, modify the corresponding {{ic|Wired connection 2.nmconnection}} file .<br> Do not forget to reload the configuration file with {{ic|nmcli connection reload}}.<br />
<br />
== Front-ends ==<br />
<br />
To configure and have easy access to NetworkManager, most users will want to install an applet. This GUI front-end usually resides in the system tray (or notification area) and allows network selection and configuration of NetworkManager. Various desktop environments have their own applet. Otherwise you can use [[#nm-applet]].<br />
<br />
=== GNOME ===<br />
<br />
[[GNOME]] has a built-in tool, accessible from the Network settings.<br />
<br />
=== KDE Plasma ===<br />
<br />
[[Install]] the {{Pkg|plasma-nm}} package. After that, add it to the KDE taskbar via the ''Panel options > Add widgets > Networks'' menu.<br />
<br />
=== nm-applet ===<br />
<br />
{{Pkg|network-manager-applet}} is a GTK 3 front-end which works under Xorg environments with a systray.<br />
<br />
To store connection secrets install and configure [[GNOME/Keyring]].<br />
<br />
Be aware that after enabling the tick-box option {{ic|Make available to other users}} for a connection, NetworkManager stores the password in plain-text, though the respective file is accessible only to root (or other users via {{ic|nm-applet}}). See [[#Encrypted Wi-Fi passwords]].<br />
<br />
In order to run {{ic|nm-applet}} without a systray, you can use {{Pkg|trayer}} or {{Pkg|stalonetray}}. For example, you can add a script like this one in your path:<br />
<br />
{{hc|nmgui|<nowiki><br />
#!/bin/sh<br />
nm-applet 2>&1 > /dev/null &<br />
stalonetray 2>&1 > /dev/null<br />
killall nm-applet<br />
</nowiki>}}<br />
<br />
When you close the ''stalonetray'' window, it closes {{ic|nm-applet}} too, so no extra memory is used once you are done with network settings.<br />
<br />
The applet can show notifications for events such as connecting to or disconnecting from a WiFi network. For these notifications to display, ensure that you have a notification server installed - see [[Desktop notifications]]. If you use the applet without a notification server, you might see some messages in stdout/stderr, and the app might hang. See [https://bugzilla.gnome.org/show_bug.cgi?id=788313].<br />
<br />
In order to run {{ic|nm-applet}} with such notifications disabled, start the applet with the following command:<br />
<br />
$ nm-applet --no-agent<br />
<br />
{{Tip|{{ic|nm-applet}} might be started automatically with a [[XDG Autostart|autostart desktop file]], to add the --no-agent option modify the Exec line there, i.e.<br />
<br />
{{bc|1=Exec=nm-applet --no-agent}}<br />
<br />
}}<br />
<br />
{{Warning|On [[i3]], if nm-applet is started with the {{ic|--no-agent}} option, it is not possible to connect to a new encrypted WiFi network by clicking on the item list because no password input dialogue window will pop out. [[journal]] will show {{ic|no secrets: No agents were available for this request}}.}}<br />
<br />
==== Appindicator ====<br />
<br />
As of version 1.18.0 Appindicator support is [https://github.com/archlinux/svntogit-packages/commit/7640a2bd557fe84813207ef4d5e35bb5aece6c54 available] in the official {{Pkg|network-manager-applet}} package. To use nm-applet in an Appindicator environment start the applet with the following command:<br />
<br />
$ nm-applet --indicator<br />
<br />
=== networkmanager-dmenu ===<br />
<br />
Alternatively there is {{AUR|networkmanager-dmenu-git}} which is a small script to manage NetworkManager connections with [[dmenu]] or [[rofi]] instead of {{ic|nm-applet}}. It provides all essential features such as connection to existing NetworkManager wifi or wired connections, connect to new wifi connections, requests passphrase if required, connect to existing VPN connections, enable/disable networking, launch ''nm-connection-editor'' GUI, connect to Bluetooth networks.<br />
<br />
== Configuration ==<br />
<br />
NetworkManager will require some additional steps to be able run properly. Make sure you have configured {{ic|/etc/hosts}} as described in [[Network configuration#Set the hostname]] section.<br />
<br />
NetworkManager has a global configuration file at {{ic|/etc/NetworkManager/NetworkManager.conf}}. Addition configuration files can be placed in {{ic|/etc/NetworkManager/conf.d/}}. Usually no configuration needs to be done to the global defaults.<br />
<br />
After editing a configuration file, the changes can be applied by running:<br />
<br />
# nmcli general reload<br />
<br />
=== Enable NetworkManager Wait Online ===<br />
<br />
{{Out of date|{{ic|NetworkManager.service}} has {{ic|1=Also=NetworkManager-wait-online.service}} in the {{ic|[Install]}} section.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/167e42a87e97ed7fb26a4263c22f1774716ac51b] If {{ic|NetworkManager.service}} was [[enable]]d before the change, it needs to be [[enable|reenabled]].}}<br />
<br />
If you have services which fail if they are started before the network is up, you may use {{ic|NetworkManager-wait-online.service}} in addition to {{ic|NetworkManager.service}}. This is, however, rarely necessary because most networked daemons start up okay, even if the network has not been configured yet.<br />
<br />
In some cases, the service will still fail to start successfully on boot due to the timeout setting in {{ic|/usr/lib/systemd/system/NetworkManager-wait-online.service}} being too short. Change the default timeout from 30 to a higher value.<br />
<br />
=== Set up PolicyKit permissions ===<br />
<br />
See [[General troubleshooting#Session permissions]] for setting up a working session.<br />
<br />
With a working session, you have several options for granting the necessary privileges to NetworkManager:<br />
<br />
* ''Option 1.'' Run a [[Polkit]] authentication agent when you log in, such as {{ic|/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1}} (part of {{Pkg|polkit-gnome}}). You will be prompted for your password whenever you add or remove a network connection.<br />
* ''Option 2.'' [[Users and groups#Group management|Add]] yourself to the {{ic|wheel}} group. You will not have to enter your password, but your user account may be granted other permissions as well, such as the ability to use [[sudo]] without entering the root password.<br />
* ''Option 3.'' [[Users and groups#Group management|Add]] yourself to the {{ic|network}} group and create the following file:<br />
<br />
{{hc|/etc/polkit-1/rules.d/50-org.freedesktop.NetworkManager.rules|<nowiki><br />
polkit.addRule(function(action, subject) {<br />
if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0 && subject.isInGroup("network")) {<br />
return polkit.Result.YES;<br />
}<br />
});<br />
</nowiki>}}<br />
<br />
: All users in the {{ic|network}} group will be able to add and remove networks without a password. This will not work under [[systemd]] if you do not have an active session with ''systemd-logind''.<br />
<br />
=== Proxy settings ===<br />
<br />
NetworkManager does not directly handle proxy settings, but if you are using [[GNOME]] or [[KDE]], you could use [http://marin.jb.free.fr/proxydriver/ proxydriver] which handles proxy settings using NetworkManager's information. proxydriver is found in the package {{AUR|proxydriver}}.<br />
<br />
In order for ''proxydriver'' to be able to change the proxy settings, you would need to execute this command, as part of the GNOME startup process (see [[GNOME#Autostart]]).<br />
<br />
xhost +si:localuser:''username''<br />
<br />
See also [[Proxy settings]].<br />
<br />
=== Checking connectivity ===<br />
<br />
NetworkManager can try to reach a page on Internet when connecting to a network. {{Pkg|networkmanager}} is configured by default in {{ic|/usr/lib/NetworkManager/conf.d/20-connectivity.conf}} to check connectivity to archlinux.org. To use a different webserver or disable connectivity checking create {{ic|/etc/NetworkManager/conf.d/20-connectivity.conf}}, see {{man|5|NetworkManager.conf|CONNECTIVITY SECTION}}. Below is an example of using GNOME servers (it does not require the use of [[GNOME]]):<br />
<br />
{{hc|/etc/NetworkManager/conf.d/20-connectivity.conf|<nowiki><br />
[connectivity]<br />
uri=http://nmcheck.gnome.org/check_network_status.txt<br />
</nowiki>}}<br />
<br />
{{Note|Although automatic connectivity checks are a potential privacy leak, the official archlinux.org default connectivity URL is committed to not logging any access. See [https://gitlab.archlinux.org/archlinux/infrastructure/-/commit/68fbaca2ef9f31f624f117899848f4288d6b39d1].}}<br />
<br />
=== Captive portals ===<br />
<br />
{{Style|Complex scripts should not be maintained on the wiki.}}<br />
<br />
For those behind a [[Wikipedia:Captive portal|captive portal]], the desktop manager may automatically open a window asking for credentials. If your desktop does not, you can use {{Pkg|capnet-assist}} package (however, it currently it has a broken NetworkManager dispatcher script). Alternatively, you can create a NetworkManager dispatcher script with the following content:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/90-open_captive_portal|<nowiki><br />
#!/bin/sh -e<br />
# Script to dispatch NetworkManager events<br />
#<br />
# Runs shows a login webpage on walled garden networks.<br />
# See NetworkManager(8) for further documentation of the dispatcher events.<br />
<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin<br />
<br />
if [ -x "/usr/bin/logger" ]; then<br />
logger="/usr/bin/logger -s -t captive-portal"<br />
else<br />
logger=":"<br />
fi<br />
<br />
wait_for_process() {<br />
PNAME=$1<br />
while [ -z "$(/usr/bin/pgrep $PNAME)" ]; do<br />
sleep 3;<br />
done<br />
}<br />
<br />
#launch the browser, but on boot we need to wait that nm-applet starts<br />
start_browser() {<br />
local user="$1"<br />
local display="$2"<br />
<br />
export DISPLAY="$display"<br />
wait_for_process nm-applet<br />
<br />
export XAUTHORITY="/home/$user/.Xauthority"<br />
<br />
$logger "Running browser as '$user' with display '$display' to login in captive portal"<br />
sudo -u "$user" --preserve-env=DISPLAY,XAUTHORITY -H xdg-open http://capnet.elementary.io 2>&1 > /dev/null<br />
}<br />
<br />
# Run the right scripts<br />
case "$2" in<br />
connectivity-change)<br />
$logger -p user.debug "dispatcher script triggered on connectivity change: $CONNECTIVITY_STATE"<br />
if [ "$CONNECTIVITY_STATE" = "PORTAL" ]; then<br />
# Match last column of who's output with ' :[at least one digit] '<br />
who | awk '$NF ~ /\(:[0-9]+\)/ { print $1 " " substr($NF, 2, length($NF)-2) };' | \<br />
while read user display; do<br />
start_browser $user $display || $logger -p user.err "Failed for user: '$user' display: '$display'"<br />
done<br />
fi<br />
;;<br />
*)<br />
# In a down phase<br />
exit 0<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
You will need to [[restart]] {{ic|NetworkManager.service}} or reboot for this to start working. Once you do, the dispatcher script should open a login window once it detects you are behind a captive portal.<br />
<br />
Another solution is {{AUR|captive-browser-git}} based on Google Chrome.<br />
<br />
=== DHCP client ===<br />
<br />
By default NetworkManager uses its internal DHCP client. The internal DHCPv4 plugin is based on the [https://nettools.github.io/n-dhcp4/ nettools' n-dhcp4] library, while the internal DHCPv6 plugin is made from code based on systemd-networkd.<br />
<br />
To use ISC’s DHCP client, [[install]] {{Pkg|dhclient}}. To change the DHCP client backend, set the option {{ic|1=main.dhcp=''dhcp_client_name''}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}. E.g.:<br />
<br />
{{hc|1=/etc/NetworkManager/conf.d/dhcp-client.conf|2=<br />
[main]<br />
dhcp=dhclient<br />
}}<br />
<br />
{{Note|<br />
* Do not enable the systemd units shipped with the {{Pkg|dhclient}} and {{Pkg|dhcpcd}} packages. They will conflict with NetworkManager, see the note in [[#Installation]] for details.<br />
* NetworkManger does not support dhcpcd ≥ 9.0.0. See {{Bug|66231}}.<br />
}}<br />
<br />
=== DNS management ===<br />
<br />
NetworkManager's DNS management is described in the GNOME project's wiki page—[https://wiki.gnome.org/Projects/NetworkManager/DNS Projects/NetworkManager/DNS].<br />
<br />
==== DNS caching and conditional forwarding ====<br />
<br />
NetworkManager has a plugin to enable DNS caching and conditional forwarding ([https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/143 previously] called "split DNS" in NetworkManager's documentation) using [[dnsmasq]] or [[systemd-resolved]]. The advantages of this setup is that DNS lookups will be cached, shortening resolve times, and DNS lookups of VPN hosts will be routed to the relevant VPN's DNS servers. This is especially useful if you are connected to more than one VPN.<br />
<br />
===== dnsmasq =====<br />
<br />
Make sure {{Pkg|dnsmasq}} has been installed. Then set {{ic|1=main.dns=dnsmasq}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=dnsmasq<br />
}}<br />
<br />
Now run {{ic|nmcli general reload}} as root. NetworkManager will automatically start dnsmasq and add {{ic|127.0.0.1}} to {{ic|/etc/resolv.conf}}. The original DNS servers can be found in {{ic|/run/NetworkManager/no-stub-resolv.conf}}. You can verify dnsmasq is being used by doing the same DNS lookup twice with {{ic|drill example.com}} and verifying the server and query times.<br />
<br />
{{Note|<br />
* You do not need to start {{ic|dnsmasq.service}} or edit {{ic|/etc/dnsmasq.conf}}. NetworkManager will start dnsmasq without using the systemd service and without reading the dnsmasq's default configuration file(s).<br />
* The dnsmasq instance started by NetworkManager will bind to {{ic|127.0.0.1:53}}, you cannot run any other software (including {{ic|dnsmasq.service}}) on the same address and port.<br />
}}<br />
<br />
====== Custom dnsmasq configuration ======<br />
<br />
Custom configurations can be created for ''dnsmasq'' by creating configuration files in {{ic|/etc/NetworkManager/dnsmasq.d/}}. For example, to change the size of the DNS cache (which is stored in RAM):<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/cache.conf|2=<br />
cache-size=1000<br />
}}<br />
<br />
{{Tip|Check the configuration file syntax with {{ic|1=dnsmasq --test --conf-file=/dev/null --conf-dir=/etc/NetworkManager/dnsmasq.d}}.}}<br />
<br />
See {{man|8|dnsmasq}} for all available options.<br />
<br />
====== IPv6 ======<br />
<br />
{{Accuracy|This does not solve the issue because NetworkManager does not add {{ic|::1}} to {{ic|/etc/resolv.conf}}. Unless {{ic|@::1}} is manually passed to drill, it will still fail with {{ic|Error: error sending query: No (valid) nameservers defined in the resolver}}.}}<br />
<br />
Enabling {{ic|dnsmasq}} in NetworkManager may break IPv6-only DNS lookups (i.e. {{ic|drill -6 [hostname]}}) which would otherwise work. In order to resolve this, creating the following file will configure ''dnsmasq'' to also listen to the IPv6 loopback:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/ipv6-listen.conf|2=<br />
listen-address=::1<br />
}}<br />
<br />
In addition, {{ic|dnsmasq}} also does not prioritize upstream IPv6 DNS. Unfortunately NetworkManager does not do this ([https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/936712 Ubuntu Bug]). A workaround would be to disable IPv4 DNS in the NetworkManager config, assuming one exists<br />
<br />
====== DNSSEC ======<br />
<br />
The dnsmasq instance started by NetworkManager by default will not validate [[DNSSEC]] since it is started with the {{ic|--proxy-dnssec}} option. It will trust whatever DNSSEC information it gets from the upstream DNS server.<br />
<br />
For dnsmasq to properly validate DNSSEC, thus breaking DNS resolution with name servers that do not support it, create the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/dnssec.conf|2=<br />
conf-file=/usr/share/dnsmasq/trust-anchors.conf<br />
dnssec<br />
}}<br />
<br />
===== systemd-resolved =====<br />
<br />
{{Expansion|NetworkManager 1.16 adds a new setting {{ic|main.systemd-resolved}}[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383] (enabled by default). It unconditionally sends DNS configuration to systemd-resolved. Related to "Preserving resolv.conf" from [[systemd-resolved#DNS]]?}}<br />
<br />
NetworkManager can use [[systemd-resolved]] as a DNS resolver and cache. Make sure that ''systemd-resolved'' is properly configured and that {{ic|systemd-resolved.service}} is [[started]] before using it.<br />
<br />
systemd-resolved will be used automatically if {{ic|/etc/resolv.conf}} is a [[Systemd-resolved#DNS|symlink]] to {{ic|/run/systemd/resolve/stub-resolv.conf}}, {{ic|/run/systemd/resolve/resolv.conf}} or {{ic|/usr/lib/systemd/resolv.conf}}.<br />
<br />
You can enable it explicitly by setting {{ic|1=main.dns=systemd-resolved}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=systemd-resolved<br />
}}<br />
<br />
===== DNS resolver with an openresolv subscriber =====<br />
<br />
If [[openresolv]] has a subscriber for your local [[DNS resolver]], set up the subscriber and [[#Use openresolv|configure NetworkManager to use openresolv]].<br />
<br />
Because NetworkManager advertises a single "interface" to ''resolvconf'', it is not possible to implement conditional forwarding between two NetworkManager connections. See [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 NetworkManager issue 153].<br />
<br />
This can be partially mitigated if you set {{ic|1=private="*"}} in {{ic|/etc/resolvconf.conf}}[https://roy.marples.name/projects/openresolv/configuration.html]. Any queries for domains that are not in search domain list will not get forwarded. They will be handled according to the local resolver's configuration, for example, forwarded to another DNS server or resolved recursively from the DNS root.<br />
<br />
==== Custom DNS servers ====<br />
<br />
===== Setting custom global DNS servers =====<br />
<br />
To set DNS servers for all connections, specify them in {{man|5|NetworkManager.conf}} using the syntax {{ic|1=servers=''serveripaddress1'',''serveripaddress2'',''serveripaddress3''}} in a section named {{ic|[global-dns-domain-*]}}. For example:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns-servers.conf|2=<br />
[global-dns-domain-*]<br />
servers=::1,127.0.0.1<br />
}}<br />
<br />
{{Note|<br />
* If you use [[#DNS caching and conditional forwarding|NetworkManager's dnsmasq or systemd-resolved plugin]] or [[#DNS resolver with an openresolv subscriber|openresolv subscribers]], then do not specify loopback addresses with the {{ic|1=servers=}} option, it can break DNS resolution.<br />
* The specified servers do not get sent to [[systemd-resolved]], the connection's DNS servers are used instead.<br />
}}<br />
<br />
===== Setting custom DNS servers in a connection =====<br />
<br />
====== Setting custom DNS servers in a connection (GUI) ======<br />
<br />
Setup will depend on the type of front-end used; the process usually involves right-clicking on the applet, editing (or creating) a profile, and then choosing DHCP type as ''Automatic (specify addresses)''. The DNS addresses will need to be entered and are usually in this form: {{ic|127.0.0.1, ''DNS-server-one'', ...}}.<br />
<br />
====== Setting custom DNS servers in a connection (nmcli / connection file) ======<br />
<br />
To setup DNS Servers per connection, you can use the {{ic|dns}} field (and the associated {{ic|dns-search}} and {{ic|dns-options}}) in the [[#Edit a connection|connection settings]]. <br />
<br />
If {{ic|method}} is set to {{ic|auto}} (when you use DHCP), you need to set {{ic|ignore-auto-dns}} to {{ic|yes}}.<br />
<br />
==== /etc/resolv.conf ====<br />
<br />
By default {{ic|/etc/resolv.conf}} is managed by ''NetworkManager'' unless it is a symlink.<br />
<br />
It can be configured to write it through [[#Use openresolv|openresolv]] or to [[#Unmanaged /etc/resolv.conf|not touch it at all]].<br />
<br />
Using openresolv allows NetworkManager to coexists with other ''resolvconf'' supporting software or, for example, to run a local DNS caching and split-DNS resolver for which openresolv has a [[openresolv#Subscribers|subscriber]].<br />
<br />
{{Note|Conditional forwarding is [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 not yet fully supported] when using NetworkManager with openresolv.}}<br />
<br />
''NetworkManager'' also offers hooks via so called dispatcher scripts that can be used to alter the {{ic|/etc/resolv.conf}} after network changes. See [[#Network services with NetworkManager dispatcher]] and {{man|8|NetworkManager}} for more information.<br />
<br />
{{Note|<br />
* If NetworkManager is configured to use either [[#dnsmasq|dnsmasq]] or [[#systemd-resolved|systemd-resolved]], then the appropriate loopback addresses will be written to {{ic|/etc/resolv.conf}}.<br />
* The {{ic|resolv.conf}} file NetworkManager writes or would write to {{ic|/etc/resolv.conf}} can be found at {{ic|/run/NetworkManager/resolv.conf}}.<br />
* A {{ic|resolv.conf}} file with the acquired name servers and search domains can be found at {{ic|/run/NetworkManager/no-stub-resolv.conf}}.<br />
}}<br />
<br />
===== Unmanaged /etc/resolv.conf =====<br />
<br />
To stop NetworkManager from touching {{ic|/etc/resolv.conf}}, set {{ic|1=main.dns=none}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=none<br />
}}<br />
<br />
{{Tip|You might also want to set {{ic|1=main.systemd-resolved=false}}, so that NetworkManager does not send the DNS configuration to [[systemd-resolved]].}}<br />
<br />
{{Note|See [[#DNS caching and conditional forwarding]], to configure NetworkManager using other DNS backends like [[dnsmasq]] and [[systemd-resolved]], instead of using {{ic|1=main.dns=none}}.}}<br />
<br />
After that {{ic|/etc/resolv.conf}} might be a broken symlink that you will need to remove. Then, just create a new {{ic|/etc/resolv.conf}} file.<br />
<br />
===== Use openresolv =====<br />
<br />
{{Note|Do not set {{ic|1=rc-manager=resolvconf}} when {{Pkg|systemd-resolvconf}} is installed. ''systemd-resolved'' provides limited support for the ''resolvconf'' interface and NetworkManager supports communicating with systemd-resolved through D-Bus without using ''resolvconf''.}}<br />
<br />
To configure NetworkManager to use [[openresolv]], set {{ic|1=main.rc-manager=resolvconf}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/rc-manager.conf|2=<br />
[main]<br />
rc-manager=resolvconf<br />
}}<br />
<br />
=== Firewall ===<br />
<br />
You can assign a [[firewalld]] zone based on your current connection. For example a restrictive firewall when at work, and a less restrictive one when at home.<br />
<br />
This can also be done with [[#Network services with NetworkManager dispatcher|NetworkManager dispatcher]].<br />
<br />
=== 802.1x / PEAP configuration ===<br />
<br />
A PEAP and 802.1x network can be added by adding a config file to {{ic|/etc/NetworkManager/system-connections/''name''}}.<br />
<br />
Here is an example configuration file for IPv4 with IPv6 disabled:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''name''|2=<br />
[ipv6]<br />
method=ignore<br />
<br />
[ipv4]<br />
method=auto<br />
<br />
[connection]<br />
#id=XXXXXXXXX<br />
#uuid=XXXXXXXXX<br />
type=802-11-wireless<br />
#timestamp=XXXX<br />
<br />
[802-11-wireless-security]<br />
key-mgmt=wpa-eap<br />
<br />
[802-11-wireless]<br />
ssid=ssid<br />
mode=infrastructure<br />
#seen-bssids=XXXXXXXXX<br />
security=802-11-wireless-security<br />
<br />
[802-1x]<br />
eap=peap;<br />
identity=user<br />
password=password<br />
phase2-auth=mschapv2<br />
}}<br />
<br />
The number sign (#) defines comments.<br />
<br />
=== Automatically connect to VPN ===<br />
<br />
NetworkManager can be set to automatically connect to a VPN when connecting to the internet, on a per network basis. The VPN connection itself can be added in the Gnome gui, but to make it automatically use the VPN {{ic|nmcli}} must be used.<br />
<br />
First, make sure to make the VPN connection available to all users. In the Gnome gui this is a matter of checking a box under the {{ic|details}} tab. Then under the {{ic|Identity}} tab, in the password field, click the icon on the right side in the field, and set it to {{ic|Store the password for all users}}.<br />
<br />
Then use the {{ic|nmcli}} tool via command line:<br />
<br />
# nmcli connection<br />
<br />
To list your connections. Then enter configuration mode for the internet connection you want to automatically connect to a VPN<br />
<br />
# nmcli connection edit <NAME of Internet Connection><br />
<br />
Please note that it is the Internet connection and not the VPN you should edit. Here you do not need to use the UUID of the Internet connection, the NAME is fine. Then make the setting with the command:<br />
<br />
# set connection.secondaries <UUID of VPN><br />
<br />
Here the UUID of the VPN must be used, but {{ic|tab}} works for autocompletion.<br />
<br />
Finally save and quit:<br />
<br />
# save<br />
# quit<br />
<br />
Now when NetworkManager is restarted and you connect to the Internet connection you have configured, you should automatically get connected to the VPN.<br />
<br />
== Network services with NetworkManager dispatcher ==<br />
<br />
There are quite a few network services that you will not want running until NetworkManager brings up an interface. NetworkManager has the ability to start services when you connect to a network and stop them when you disconnect (e.g. when using [[NFS]], [[SMB]] and [[NTPd]]).<br />
<br />
To activate the feature you need to [[enable]] and [[start]] the {{ic|NetworkManager-dispatcher.service}}.<br />
<br />
Once the service is active, scripts can be added to the {{ic|/etc/NetworkManager/dispatcher.d}} directory.<br />
<br />
Scripts must be owned by '''root''', otherwise the dispatcher will not execute them. For added security, set group [[ownership]] to root as well:<br />
<br />
# chown root:root /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
Make sure the file has correct permissions:<br />
<br />
# chmod 755 /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
The scripts will be run in alphabetical order at connection time, and in reverse alphabetical order at disconnect time. To ensure what order they come up in, it is common to use numerical characters prior to the name of the script (e.g. {{ic|10-portmap}} or {{ic|30-netfs}} (which ensures that the ''portmapper'' is up before NFS mounts are attempted).<br />
<br />
Scripts will receive the following arguments:<br />
<br />
* '''Interface name:''' e.g. {{ic|eth0}}<br />
* '''Interface status:''' ''up'' or ''down''<br />
* '''VPN status:''' ''vpn-up'' or ''vpn-down''<br />
<br />
{{Warning|If you connect to foreign or public networks, be aware of what services you are starting and what servers you expect to be available for them to connect to. You could make a security hole by starting the wrong services while connected to a public network.}}<br />
<br />
=== Avoiding the dispatcher timeout ===<br />
<br />
If the above is working, then this section is not relevant. However, there is a general problem related to running dispatcher scripts which take longer to be executed. Initially an internal timeout of three seconds only was used. If the called script did not complete in time, it was killed. Later the timeout was extended to about 20 seconds (see the [https://bugzilla.redhat.com/show_bug.cgi?id=982734 Bugtracker] for more information). If the timeout still creates the problem, a work around may be to modify the dispatcher service file {{ic|/usr/lib/systemd/system/NetworkManager-dispatcher.service}} to remain active after exit: <br />
<br />
{{hc|/etc/systemd/system/NetworkManager-dispatcher.service.d/remain_after_exit.conf|2=<br />
[Service]<br />
RemainAfterExit=yes<br />
}}<br />
<br />
Now start and enable the modified {{ic|NetworkManager-dispatcher}} service.<br />
<br />
{{Warning|Adding the {{ic|RemainAfterExit}} line to it will prevent the dispatcher from closing. Unfortunately, the dispatcher '''has''' to close before it can run your scripts again. With it the dispatcher will not time out but it also will not close, which means that the scripts will only run once per boot. Therefore, do not add the line unless the timeout is definitely causing a problem.}}<br />
<br />
=== Dispatcher examples ===<br />
<br />
==== Mount remote folder with sshfs ====<br />
<br />
As the script is run in a very restrictive environment, you have to export {{ic|SSH_AUTH_SOCK}} in order to connect to your SSH agent. There are different ways to accomplish this, see [https://bbs.archlinux.org/viewtopic.php?pid=1042030#p1042030 this message] for more information. The example below works with [[GNOME Keyring]], and will ask you for the password if not unlocked already. In case NetworkManager connects automatically on login, it is likely ''gnome-keyring'' has not yet started and the export will fail (hence the sleep). The {{ic|UUID}} to match can be found with the command {{ic|nmcli connection status}} or {{ic|nmcli connection list}}. <br />
<br />
{{bc|<nowiki><br />
#!/bin/sh<br />
USER='username'<br />
REMOTE='user@host:/remote/path'<br />
LOCAL='/local/path'<br />
<br />
interface=$1 status=$2<br />
if [ "$CONNECTION_UUID" = "</nowiki>''uuid''<nowiki>" ]; then<br />
case $status in<br />
up)<br />
SSH_AUTH_SOCK=$(find /tmp -maxdepth 1 -type s -user "$USER" -name 'ssh')<br />
export SSH_AUTH_SOCK<br />
su "$USER" -c "sshfs $REMOTE $LOCAL"<br />
;;<br />
down)<br />
fusermount -u "$LOCAL"<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
==== Mounting of SMB shares ====<br />
<br />
Some [[SMB]] shares are only available on certain networks or locations (e.g. at home). You can use the dispatcher to only mount SMB shares that are present at your current location.<br />
<br />
The following script will check if we connected to a specific network and mount shares accordingly:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-mount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
# Find the connection UUID with "nmcli connection show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
if [ "$2" = "up" ]; then<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
mount /your/mount/point & <br />
# add more shares as needed<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The following script will unmount all SMB shares before a software initiated disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/pre-down.d/30-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|Make sure this script is located in the {{ic|pre-down.d}} sub-directory as shown above, otherwise it will unmount all shares on any connection state change.}}<br />
<br />
The following script will attempt to unmount all SMB shares following an unexpected disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/40-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
if [ "$2" = "down" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|<br />
* Since NetworkManager 0.9.8, the ''pre-down'' and ''down'' events are not executed on shutdown or restart, see [https://bugzilla.gnome.org/show_bug.cgi?id&#61;701242 this bug report] for more info.<br />
* The previous ''umount'' scripts are still prone to leaving applications actually accessing the mount to 'hang'.<br />
}}<br />
<br />
An alternative is to use the script as seen in [[NFS#Using a NetworkManager dispatcher]]:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-smb.sh|<nowiki><br />
#!/bin/bash<br />
<br />
# Find the connection UUID with "nmcli con show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
WANTED_CON_UUID="CHANGE-ME-NOW-9c7eff15-010a-4b1c-a786-9b4efa218ba9"<br />
<br />
if [[ "$CONNECTION_UUID" == "$WANTED_CON_UUID" ]]; then<br />
<br />
# Script parameter $1: NetworkManager connection name, not used<br />
# Script parameter $2: dispatched event<br />
<br />
case "$2" in<br />
"up")<br />
mount -a -t cifs<br />
;;<br />
"pre-down");&<br />
"vpn-pre-down")<br />
umount -l -a -t cifs >/dev/null<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|This script ignores mounts with the {{ic|noauto}} option, remove this mount option or use {{ic|auto}} to allow the dispatcher to manage these mounts.}}<br />
<br />
Create a symlink inside {{ic|/etc/NetworkManager/dispatcher.d/pre-down/}} to catch the {{ic|pre-down}} events:<br />
<br />
# ln -s ../30-smb.sh /etc/NetworkManager/dispatcher.d/pre-down.d/30-smb.sh<br />
<br />
==== Mounting of NFS shares ====<br />
<br />
See [[NFS#Using a NetworkManager dispatcher]].<br />
<br />
==== Use dispatcher to automatically toggle wireless depending on LAN cable being plugged in ====<br />
<br />
The idea is to only turn Wi-Fi on when the LAN cable is unplugged (for example when detaching from a laptop dock), and for Wi-Fi to be automatically disabled, once a LAN cable is plugged in again. <br />
<br />
Create the following dispatcher script[https://superuser.com/questions/233448/disable-wlan-if-wired-cable-network-is-available], replacing {{ic|1=LAN_interface}} with yours.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/wlan_auto_toggle.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$1" = "LAN_interface" ]; then<br />
case "$2" in<br />
up)<br />
nmcli radio wifi off<br />
;;<br />
down)<br />
nmcli radio wifi on<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|You can get a list of interfaces using [[#nmcli examples|nmcli]]. The ethernet (LAN) interfaces start with {{ic|en}}, e.g. {{ic|1=enp0s5}}}}<br />
<br />
==== Use dispatcher to connect to a VPN after a network connection is established ====<br />
<br />
In this example we want to connect automatically to a previously defined VPN connection after connecting to a specific Wi-Fi network. First thing to do is to create the dispatcher script that defines what to do after we are connected to the network.<br />
<br />
{{Note|This script will require {{Pkg|wireless_tools}} in order to use {{ic|iwgetid}}.}}<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME"<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you would like to attempt to automatically connect to VPN for all Wi-Fi networks, you can use the following definition of the ESSID: {{ic|1=ESSID=$(iwgetid -r)}}. Remember to set the script's permissions [[#Network services with NetworkManager dispatcher|accordingly]]. <br />
<br />
Trying to connect with the above script may still fail with {{ic|NetworkManager-dispatcher.service}} complaining about 'no valid VPN secrets', because of [https://developer.gnome.org/NetworkManager/0.9/secrets-flags.html the way VPN secrets are stored]. Fortunately, there are different options to give the above script access to your VPN password.<br />
<br />
1: One of them requires editing the VPN connection configuration file to make NetworkManager store the secrets by itself rather than inside a keyring [https://bugzilla.redhat.com/show_bug.cgi?id=710552 that will be inaccessible for root]: open up {{ic|/etc/NetworkManager/system-connections/''name of your VPN connection''}} and change the {{ic|password-flags}} and {{ic|secret-flags}} from {{ic|1}} to {{ic|0}}.<br />
<br />
If that alone does not work, you may have to create a {{ic|passwd-file}} in a safe location with the same permissions and ownership as the dispatcher script, containing the following:<br />
<br />
{{hc|/path/to/passwd-file|<br />
vpn.secrets.password:YOUR_PASSWORD<br />
}}<br />
<br />
The script must be changed accordingly, so that it gets the password from the file:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME" passwd-file /path/to/passwd-file<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
2: Alternatively, change the {{ic|password-flags}} and put the password directly in the configuration file adding the section {{ic|vpn-secrets}}:<br />
<br />
[vpn]<br />
....<br />
password-flags=0<br />
<br />
[vpn-secrets]<br />
password=''your_password''<br />
<br />
{{Note|It may now be necessary to re-open the NetworkManager connection editor and save the VPN passwords/secrets again.}}<br />
<br />
==== Use dispatcher to disable IPv6 on VPN provider connections ====<br />
<br />
Many [[:Category:VPN providers|commercial VPN providers]] support only IPv4. That means all IPv6 traffic bypasses the VPN and renders it virtually useless. To avoid this, dispatcher can be used to disable all IPv6 traffic for the time a VPN connection is up.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/10-vpn-ipv6|<nowiki><br />
#!/bin/sh<br />
<br />
case "$2" in<br />
vpn-up)<br />
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
vpn-down)<br />
echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
==== OpenNTPD ====<br />
<br />
See [[OpenNTPD#Using NetworkManager dispatcher]].<br />
<br />
== Testing ==<br />
<br />
NetworkManager applets are designed to load upon login so no further configuration should be necessary for most users. If you have already disabled your previous network settings and disconnected from your network, you can now test if NetworkManager will work. The first step is to [[start]] {{ic|NetworkManager.service}}.<br />
<br />
Some applets will provide you with a {{ic|.desktop}} file so that the NetworkManager applet can be loaded through the application menu. If it does not, you are going to either have to discover the command to use or logout and login again to start the applet. Once the applet is started, it will likely begin polling network connections with for auto-configuration with a DHCP server.<br />
<br />
To start the GNOME applet in non-xdg-compliant window managers like [[awesome]]:<br />
<br />
nm-applet --sm-disable &<br />
<br />
For static IP addresses, you will have to configure NetworkManager to understand them. The process usually involves right-clicking the applet and selecting something like 'Edit Connections'.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Encrypted Wi-Fi passwords ===<br />
<br />
By default, NetworkManager stores passwords in clear text in the connection files at {{ic|/etc/NetworkManager/system-connections/}}. To print the stored passwords, use the following command:<br />
<br />
# grep -r '^psk=' /etc/NetworkManager/system-connections/<br />
<br />
The passwords are accessible to the root user in the filesystem and to users with access to settings via the GUI (e.g. {{ic|nm-applet}}). <br />
<br />
It is preferable to save the passwords in encrypted form in a keyring instead of clear text. The downside of using a keyring is that the connections have to be set up for each user.<br />
<br />
==== Using GNOME Keyring ====<br />
<br />
The keyring daemon has to be started and the keyring needs to be unlocked for the following to work.<br />
<br />
Furthermore, NetworkManager needs to be configured not to store the password for all users. Using GNOME {{ic|nm-applet}}, run {{ic|nm-connection-editor}} from a terminal, select a network connection, click {{ic|Edit}}, select the {{ic|Wifi-Security}} tab and click on the right icon of password and check {{ic|Store the password only for this user}}.<br />
<br />
==== Using KDE Wallet ====<br />
<br />
Using KDE's {{Pkg|plasma-nm}}, click the applet, click on the top right {{ic|Settings}} icon, click on a network connection, in the {{ic|General settings}} tab, untick {{ic|all users may connect to this network}}. If the option is ticked, the passwords will still be stored in clear text, even if a keyring daemon is running.<br />
<br />
If the option was selected previously and you un-tick it, you may have to use the {{ic|reset}} option first to make the password disappear from the file. Alternatively, delete the connection first and set it up again.<br />
<br />
=== Sharing internet connection over Wi-Fi ===<br />
<br />
You can share your internet connection (e.g. 3G or wired) with a few clicks. Please note that a [[firewall]] may interfere with internet sharing.<br />
<br />
You will need a Wi-Fi card which supports AP mode, see [[Software access point#Wi-Fi device must support AP mode]] for details.<br />
<br />
[[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
<br />
Create the shared connection:<br />
<br />
* Click on applet and choose ''Create new wireless network''.<br />
* Follow wizard (choose WPA2 or higher, be sure to use at least 8 character long password, lower lengths will fail).<br />
** Choose either [[Fedora:Features/RealHotspot|Hotspot]] or Ad-hoc as Wi-Fi mode.<br />
<br />
The connection will be saved and remain stored for the next time you need it.<br />
<br />
{{Note|Android does not support connecting to Ad-hoc networks. To share a connection with Android use infrastructure mode (i.e. set Wi-Fi mode to "Hotspot").}}<br />
<br />
=== Sharing internet connection over Ethernet ===<br />
<br />
Scenario: your device has internet connection over wi-fi and you want to share the internet connection to other devices over ethernet.<br />
<br />
Requirements:<br />
<br />
* [[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
* Your internet connected device and the other devices are connected over a suitable ethernet cable (this usually means a cross over cable or a switch in between).<br />
* Internet sharing is not blocked by a [[firewall]].<br />
<br />
Steps:<br />
<br />
{{Style|{{Pkg|nm-connection-editor}} is not a dependency of {{Pkg|networkmanager}} and needs to be installed separately.}}<br />
<br />
* Run {{ic|nm-connection-editor}} from terminal.<br />
* Add a new ethernet connection.<br />
* Give it some sensible name. For example "Shared Internet"<br />
* Go to "IPv4 Settings".<br />
* For "Method:" select "Shared to other computers".<br />
* Save<br />
<br />
Now you should have a new option "Shared Internet" under the Wired connections in NetworkManager.<br />
<br />
=== Checking if networking is up inside a cron job or script ===<br />
<br />
{{Out of date|''nm-tool'' was remove from NetworkManager for long time now[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/bb8c75bd536d4f8fb80a4366025a279078f0ec81]. ''nmcli'' should be used instead.}}<br />
<br />
Some ''cron'' jobs require networking to be up to succeed. You may wish to avoid running these jobs when the network is down. To accomplish this, add an '''if''' test for networking that queries NetworkManager's ''nm-tool'' and checks the state of networking. The test shown here succeeds if any interface is up, and fails if they are all down. This is convenient for laptops that might be hardwired, might be on wireless, or might be off the network.<br />
<br />
{{bc|<nowiki><br />
if [ $(nm-tool|grep State|cut -f2 -d' ') == "connected" ]; then<br />
#Whatever you want to do if the network is online<br />
else<br />
#Whatever you want to do if the network is offline - note, this and the else above are optional<br />
fi<br />
</nowiki>}}<br />
<br />
This useful for a {{ic|cron.hourly}} script that runs ''fpupdate'' for the F-Prot virus scanner signature update, as an example. Another way it might be useful, with a little modification, is to differentiate between networks using various parts of the output from ''nm-tool''; for example, since the active wireless network is denoted with an asterisk, you could grep for the network name and then grep for a literal asterisk.<br />
<br />
=== Connect to network with secret on boot ===<br />
<br />
By default, NetworkManager will not connect to networks requiring a secret automatically on boot. This is because it locks such connections to the user who makes it by default, only connecting after they have logged in. To change this, do the following:<br />
<br />
# Right click on the {{ic|nm-applet}} icon in your panel and select Edit Connections and open the Wireless tab<br />
# Select the connection you want to work with and click the Edit button<br />
# Check the boxes “Connect Automatically” and “Available to all users”<br />
# Additionally, ensure that under "Wi-Fi Security", "Store password for all users (not encrypted)" is selected<br />
<br />
Log out and log back in to complete.<br />
<br />
=== OpenConnect with password in KWallet ===<br />
<br />
While you may type both values at connection time, {{Pkg|plasma-nm}} 0.9.3.2-1 and above are capable of retrieving OpenConnect username and password directly from [[KWallet]].<br />
<br />
Open "KDE Wallet Manager" and look up your OpenConnect VPN connection under "Network Management|Maps". Click "Show values" and <br />
enter your credentials in key "VpnSecrets" in this form (replace ''username'' and ''password'' accordingly):<br />
<br />
form:main:username%SEP%''username''%SEP%form:main:password%SEP%''password''<br />
<br />
Next time you connect, username and password should appear in the "VPN secrets" dialog box.<br />
<br />
=== Ignore specific devices ===<br />
<br />
Sometimes it may be desired that NetworkManager ignores specific devices and does not try to configure addresses and routes for them. You can quickly and easily ignore devices by MAC or interface-name by using the following in {{ic|/etc/NetworkManager/conf.d/unmanaged.conf}}:<br />
<br />
[keyfile]<br />
unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth0<br />
<br />
After editing the file, run {{ic|nmcli general reload}} as root. Afterwards you should be able to configure interfaces without NetworkManager altering what you have set.<br />
<br />
=== Configuring MAC address randomization ===<br />
<br />
{{Note|1=Disabling MAC address randomization may be needed to get (stable) link connection [https://bbs.archlinux.org/viewtopic.php?id=220101] and/or networks that restrict devices based on their MAC Address or have a limit network capacity.}}<br />
<br />
MAC randomization can be used for increased privacy by not disclosing your real MAC address to the network.<br />
<br />
NetworkManager supports two types MAC Address Randomization: randomization during scanning, and for network connections. Both modes can be configured by modifying {{ic|/etc/NetworkManager/NetworkManager.conf}} or by creating a separate configuration file in {{ic|/etc/NetworkManager/conf.d/}} which is recommended since the aforementioned config file may be overwritten by NetworkManager.<br />
<br />
Randomization during Wi-Fi scanning is enabled by default, but it may be disabled by adding the following lines to {{ic|/etc/NetworkManager/NetworkManager.conf}} or a dedicated configuration file under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device]<br />
wifi.scan-rand-mac-address=no<br />
}}<br />
<br />
MAC randomization for network connections can be set to different modes for both wireless and ethernet interfaces. See the [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details on the different modes. <br />
<br />
In terms of MAC randomization the most important modes are {{ic|stable}} and {{ic|random}}. {{ic|stable}} generates a random MAC address when you connect to a new network and associates the two permanently. This means that you will use the same MAC address every time you connect to that network. In contrast, {{ic|random}} will generate a new MAC address every time you connect to a network, new or previously known. You can configure the MAC randomization by adding the desired configuration under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device-mac-randomization]<br />
# "yes" is already the default for scanning<br />
wifi.scan-rand-mac-address=yes<br />
<br />
[connection-mac-randomization]<br />
# Randomize MAC for every ethernet connection<br />
ethernet.cloned-mac-address=random<br />
# Generate a random MAC for each WiFi and associate the two permanently.<br />
wifi.cloned-mac-address=stable<br />
}}<br />
<br />
See the following [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details.<br />
<br />
=== Enable IPv6 Privacy Extensions ===<br />
<br />
See [[IPv6#NetworkManager]].<br />
<br />
=== Working with wired connections ===<br />
<br />
By default, NetworkManager generates a connection profile for each wired ethernet connection it finds. At the point when generating the connection, it does not know whether there will be more ethernet adapters available. Hence, it calls the first wired connection "Wired connection 1". You can avoid generating this connection, by configuring {{ic|no-auto-default}} (see {{man|5|NetworkManager.conf}}), or by simply deleting it. Then NetworkManager will remember not to generate a connection for this interface again.<br />
<br />
You can also edit the connection (and persist it to disk) or delete it. NetworkManager will not re-generate a new connection. Then you can change the name to whatever you want. You can use something like nm-connection-editor for this task.<br />
<br />
=== Using iwd as the Wi-Fi backend ===<br />
<br />
Install {{AUR|networkmanager-iwd}} or enable the experimental [[iwd]] backend creating the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_backend.conf|2=<br />
[device]<br />
wifi.backend=iwd<br />
}}<br />
<br />
=== Running in a network namespace ===<br />
<br />
If you would like to run NetworkManager inside a network namespace (e.g., to manage a specific device which should be use by selected applications), bring the device down before moving it to the namespace:<br />
<br />
$ ip link set dev ''MY_DEVICE'' down<br />
$ ip link set dev ''MY_DEVICE'' netns ''MY_NAMESPACE''<br />
$ ip netns exec ''MY_NAMESPACE'' NetworkManager<br />
...<br />
$ ip netns exec ''MY_NAMESPACE'' killall NetworkManager<br />
<br />
otherwise NetworkManager will later fail to establish the connection with a {{ic|device is strictly unmanaged}} error.<br />
<br />
== Troubleshooting ==<br />
<br />
=== No prompt for password of secured Wi-Fi networks ===<br />
<br />
When trying to connect to a secured Wi-Fi network, no prompt for a password is shown and no connection is established. This happens when no keyring package is installed. An easy solution is to install {{Pkg|gnome-keyring}}. If you want the passwords to be stored in encrypted form, follow [[GNOME Keyring]] to set up the ''gnome-keyring-daemon''.<br />
<br />
=== Network management disabled ===<br />
<br />
When NetworkManager shuts down but the pid (state) file is not removed, you will see a {{ic|Network management disabled}} message. If this happens, remove the file manually:<br />
<br />
# rm /var/lib/NetworkManager/NetworkManager.state<br />
<br />
=== Problems with internal DHCP client ===<br />
<br />
If you have problems with getting an IP address using the internal DHCP client, consider using another DHCP client, see [[#DHCP client]] for instructions. This workaround might solve problems in big wireless networks like eduroam.<br />
<br />
=== DHCP problems with dhclient ===<br />
<br />
If you have problems with getting an IP address via DHCP, try to add the following to your {{ic|/etc/dhclient.conf}}:<br />
<br />
interface "eth0" {<br />
send dhcp-client-identifier 01:''aa:bb:cc:dd:ee:ff'';<br />
}<br />
<br />
Where {{ic|''aa:bb:cc:dd:ee:ff''}} is the MAC address of this NIC. The MAC address can be found using the {{ic|ip link show ''interface''}} command from the {{Pkg|iproute2}} package.<br />
<br />
=== 3G modem not detected ===<br />
<br />
See [[USB 3G Modem#NetworkManager]].<br />
<br />
=== Switching off WLAN on laptops ===<br />
<br />
Sometimes NetworkManager will not work when you disable your Wi-Fi adapter with a switch on your laptop and try to enable it again afterwards. This is often a problem with ''rfkill''. To check if the driver notifies ''rfkill'' about the wireless adapter's status, use:<br />
<br />
$ watch -n1 rfkill list all<br />
<br />
If one identifier stays blocked after you switch on the adapter you could try to manually unblock it with (where X is the number of the identifier provided by the above output):<br />
<br />
# rfkill event unblock X<br />
<br />
=== Static IP address settings revert to DHCP ===<br />
<br />
Due to an unresolved bug, when changing default connections to a static IP address, {{ic|nm-applet}} may not properly store the configuration change, and will revert to automatic DHCP.<br />
<br />
To work around this issue you have to edit the default connection (e.g. "Auto eth0") in {{ic|nm-applet}}, change the connection name (e.g. "my eth0"), uncheck the "Available to all users" checkbox, change your static IP address settings as desired, and click '''Apply'''. This will save a new connection with the given name.<br />
<br />
Next, you will want to make the default connection not connect automatically. To do so, run {{ic|nm-connection-editor}} ('''not''' as root). In the connection editor, edit the default connection (e.g. "Auto eth0") and uncheck "Connect automatically". Click '''Apply''' and close the connection editor.<br />
<br />
=== Cannot edit connections as normal user ===<br />
<br />
See [[#Set up PolicyKit permissions]].<br />
<br />
=== Forget hidden wireless network ===<br />
<br />
Since hidden networks are not displayed in the selection list of the Wireless view, they cannot be forgotten (removed) with the GUI. You can delete one with the following command:<br />
<br />
# rm /etc/NetworkManager/system-connections/''SSID''<br />
<br />
This works for any other connection.<br />
<br />
=== VPN not working in GNOME ===<br />
<br />
When setting up OpenConnect or vpnc connections in NetworkManager while using GNOME, you will sometimes never see the dialog box pop up and the following error appears in {{ic|/var/log/errors.log}}:<br />
<br />
localhost NetworkManager[399]: <error> [1361719690.10506] [nm-vpn-connection.c:1405] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.<br />
<br />
This is caused by the GNOME NM Applet expecting dialog scripts to be at {{ic|/usr/lib/gnome-shell}}, when NetworkManager's packages put them in {{ic|/usr/lib/networkmanager}}.<br />
As a "temporary" fix (this bug has been around for a while now), make the following symlink(s):<br />
<br />
* For OpenConnect: {{ic|ln -s /usr/lib/networkmanager/nm-openconnect-auth-dialog /usr/lib/gnome-shell/}}<br />
* For VPNC (i.e. Cisco VPN): {{ic|ln -s /usr/lib/networkmanager/nm-vpnc-auth-dialog /usr/lib/gnome-shell/}}<br />
<br />
This may need to be done for any other NM VPN plugins as well, but these are the two most common.<br />
<br />
=== Unable to connect to visible European wireless networks ===<br />
<br />
WLAN chips are shipped with a default [[Wireless network configuration#Respecting the regulatory domain|regulatory domain]]. If your access point does not operate within these limitations, you will not be able to connect to the network. Fixing this is easy:<br />
<br />
# [[Install]] {{Pkg|crda}}<br />
# Uncomment the correct Country Code in {{ic|/etc/conf.d/wireless-regdom}}<br />
# Reboot the system, because the setting is only read on boot<br />
<br />
=== Automatic connect to VPN on boot is not working ===<br />
<br />
The problem occurs when the system (i.e. NetworkManager running as the root user) tries to establish a VPN connection, but the password is not accessible because it is stored in the GNOME keyring of a particular user. <br />
<br />
A solution is to keep the password to your VPN in plaintext, as described in step (2.) of [[#Use dispatcher to connect to a VPN after a network connection is established]]. <br />
<br />
You do not need to use the dispatcher described in step (1.) to auto-connect anymore, if you use the new "auto-connect VPN" option from the {{ic|nm-applet}} GUI.<br />
<br />
=== Systemd Bottleneck ===<br />
<br />
Over time the log files ({{ic|/var/log/journal}}) can become very large. This can have a big impact on boot performance when using NetworkManager, see: [[Systemd#Boot time increasing over time]].<br />
<br />
=== Regular network disconnects, latency and lost packets (WiFi) ===<br />
<br />
NetworkManager does a scan every 2 minutes.<br />
<br />
Some WiFi drivers have issues when scanning for base stations whilst connected/associated. Symptoms include VPN disconnects/reconnects and lost packets, web pages failing to load and then refresh fine.<br />
<br />
Running {{ic|journalctl -f}} will indicate that this is taking place, messages like the following will be contained in the logs at regular intervals.<br />
<br />
NetworkManager[410]: <info> (wlp3s0): roamed from BSSID 00:14:48:11:20:CF (my-wifi-name) to (none) ((none))<br />
<br />
There is a patched version of NetworkManager which should prevent this type of scanning: {{AUR|networkmanager-noscan}}.<br />
<br />
Alternatively, if roaming is not important, the periodic scanning behavior can be disabled by locking the BSSID of the access point in the WiFi connection profile.<br />
<br />
=== Unable to turn on wi-fi with Lenovo laptop (IdeaPad, Legion, etc.) ===<br />
<br />
There is an issue with the {{ic|ideapad_laptop}} module on some Lenovo models due to the wi-fi driver incorrectly reporting a soft block. The card can still be manipulated with {{ic|netctl}}, but managers like NetworkManager break. You can verify that this is the problem by checking the output of {{ic|rfkill list}} after toggling your hardware switch and seeing that the soft block persists.<br />
<br />
{{Accuracy|Try to use {{ic|rfkill.default_state}} and {{ic|rfkill.master_switch_mode}} (see [https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt kernel-parameters.txt]) to fix the rfkill problem.}}<br />
<br />
[[modprobe|Unloading]] the {{ic|ideapad_laptop}} module should fix this. ('''warning''': this may disable the laptop keyboard and touchpad also!).<br />
<br />
=== Turn off hostname sending ===<br />
<br />
NetworkManager by default sends the hostname to the DHCP server. Hostname sending can only be disabled per connection not globally ([https://bugzilla.gnome.org/show_bug.cgi?id=768076 GNOME Bug 768076]).<br />
<br />
To disable sending your hostname to the DHCP server for a specific connection, add the following to your network connection file:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''your_connection_file''|2=<br />
...<br />
[ipv4]<br />
dhcp-send-hostname=false<br />
...<br />
[ipv6]<br />
dhcp-send-hostname=false<br />
...<br />
}}<br />
<br />
=== nm-applet disappears in i3wm ===<br />
<br />
If you use the {{ic|xfce4-notifyd.service}} for notifications you must [[edit]] the unit and add the following:<br />
<br />
{{hc|/etc/systemd/user/xfce4-notifyd.service.d/display_env.conf|2=<br />
[Service]<br />
Environment="DISPLAY=:0.0"<br />
}}<br />
<br />
After reloading the daemons [[restart]] {{ic|xfce4-notifyd.service}}. Exit i3 and start it back up again and the applet should show on the tray.<br />
<br />
=== nm-applet tray icons display wrongly ===<br />
<br />
Currently the tray icons of nm-applet are drawn on top of one another, i.e. the icon displaying wireless strength might show on top of the icon indicating no wired connection.<br />
This is apparently a GTK3 bug/problem: https://gitlab.gnome.org/GNOME/gtk/issues/1280 .<br />
<br />
A patched version of GTK3 exists in AUR, which apparently fixes the tray icon bug: {{AUR|gtk3-mushrooms}} .<br />
<br />
=== Unit dbus-org.freedesktop.resolve1.service not found ===<br />
<br />
If {{ic|systemd-resolved.service}} is not started, NetworkManager will try to start it using D-Bus and fail:<br />
<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
dbus-daemon[991]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
<br />
This is because NetworkManager will try to send DNS information to [[systemd-resolved]] regardless of the {{ic|1=main.dns=}} setting in {{man|5|NetworkManager.conf}}.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383]<br />
<br />
This can be disabled with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/no-systemd-resolved.conf|2=<br />
[main]<br />
systemd-resolved=false<br />
}}<br />
<br />
See {{Bug|62138}}.<br />
<br />
=== Secrets were required, but not provided ===<br />
<br />
If you attempt to connect to a network using {{ic|nmcli device wifi connect ''SSID'' password ''password''}} and received the following error:<br />
<br />
Error: Connection activation failed: (7) Secrets were required, but not provided<br />
<br />
The error can be resolved by deleting the connection profile and creating a new one:<br />
<br />
$ nmcli connection delete ''SSID''<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
=== WPA Enterprise connection with NetworkManager ===<br />
<br />
If you try to connect to an WPA Enterprise network like 'eduroam' with NetworkManager with the [[iwd]] backend then you will get the following error from NetworkManager:<br />
<br />
Connection 'eduroam' is not avialable on device wlan0 because profile is not compatible with device (802.1x connections must have IWD provisioning files)<br />
<br />
This is because NetworkManager can not configure a WPA Enterprise network. Therefore you have to configure it using an iwd config file {{ic|/var/lib/iwd/''essid''.8021x}} like described in [[iwd#WPA Enterprise]].<br />
<br />
== See also ==<br />
<br />
* [https://blogs.gnome.org/dcbw/2015/02/16/networkmanager-for-administrators-part-1/ NetworkManager for Administrators Part 1]<br />
* [[Wikipedia:NetworkManager]]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=NetworkManager&diff=627217NetworkManager2020-07-30T15:16:02Z<p>Tobbebobbe: /* VPN support */ Added step-by-step on how to set up a WireGuard connection, since that was lacking and is now promoted over OpenVPN by some VPN providers.</p>
<hr />
<div>[[Category:Network managers]]<br />
[[Category:Red Hat]]<br />
[[cs:NetworkManager]]<br />
[[de:Networkmanager]]<br />
[[es:NetworkManager]]<br />
[[fr:NetworkManager]]<br />
[[it:NetworkManager]]<br />
[[ja:NetworkManager]]<br />
[[pt:NetworkManager]]<br />
[[zh-hans:NetworkManager]]<br />
{{Related articles start}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related articles end}}<br />
[https://wiki.gnome.org/Projects/NetworkManager/ NetworkManager] is a program for providing detection and configuration for systems to automatically connect to networks. NetworkManager's functionality can be useful for both wireless and wired networks. For wireless networks, NetworkManager prefers known wireless networks and has the ability to switch to the most reliable network. NetworkManager-aware applications can switch from online and offline mode. NetworkManager also prefers wired connections over wireless ones, has support for modem connections and certain types of VPN. NetworkManager was originally developed by Red Hat and now is hosted by the [[GNOME]] project.<br />
<br />
{{Expansion|Clear text storage of secrets is not limited to just Wi-Fi passwords. The secrets are stored in files (and folder) only accesible to root.}}<br />
<br />
{{Warning|By default, Wi-Fi passwords are stored in clear text, see [[#Encrypted Wi-Fi passwords]].}}<br />
<br />
== Installation ==<br />
<br />
NetworkManager can be [[install]]ed with the package {{Pkg|networkmanager}}, which contains a daemon, a command line interface ({{ic|nmcli}}) and a curses‐based interface ({{ic|nmtui}}). <br />
<br />
=== Enable NetworkManager ===<br />
<br />
After installation, you should [[start/enable]] {{ic|NetworkManager.service}}. Once the NetworkManager daemon is started, it will automatically connect to any available "system connections" that have already been configured. Any "user connections" or unconfigured connections will need ''nmcli'' or an applet to configure and connect.<br />
<br />
=== Additional interfaces ===<br />
<br />
* {{Pkg|nm-connection-editor}} for a graphical user interface,<br />
* {{Pkg|network-manager-applet}} for a system tray applet ({{ic|nm-applet}}).<br />
<br />
{{Note|You must ensure that no other service that wants to configure the network is running; in fact, multiple networking services will conflict. You can find a list of the currently running services with {{ic|1=systemctl --type=service}} and then [[stop]] them. See [[#Configuration]] to enable the NetworkManager service.}}<br />
<br />
=== Mobile broadband support ===<br />
<br />
[[Install]] {{Pkg|modemmanager}}, {{Pkg|mobile-broadband-provider-info}} and {{Pkg|usb_modeswitch}} packages for mobile broadband connection support. See [[USB 3G Modem#NetworkManager]] for details.<br />
<br />
=== PPPoE / DSL support ===<br />
<br />
[[Install]] {{Pkg|rp-pppoe}} package for PPPoE / DSL connection support. To actually add PPPoE connection, use {{ic|1=nm-connection-editor}} and add new DSL/PPPoE connection.<br />
<br />
=== VPN support ===<br />
<br />
NetworkManager since version 1.16 has native support for [[WireGuard]], all it needs is the {{ic|wireguard}} kernel module. Read the [https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-networkmanager/ WireGuard in NetworkManager blog post] for details.<br />
<br />
Support for other VPN types is based on a plug-in system. They are provided in the following packages:<br />
<br />
* {{Pkg|networkmanager-openconnect}} for [[OpenConnect]]<br />
* [[networkmanager-openvpn]] for [[OpenVPN]]<br />
* {{Pkg|networkmanager-pptp}} for [[PPTP Client]]<br />
* {{Pkg|networkmanager-vpnc}} for [[Vpnc]]<br />
* {{Pkg|networkmanager-strongswan}} for [[strongSwan]]<br />
* {{AUR|networkmanager-fortisslvpn-git}}<br />
* {{AUR|networkmanager-iodine-git}}<br />
* {{AUR|networkmanager-libreswan}}<br />
* {{AUR|networkmanager-l2tp}}<br />
* {{AUR|networkmanager-ssh-git}}<br />
* {{Pkg|network-manager-sstp}}<br />
<br />
{{Warning|1=There are a lot of [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues?search=VPN&state=opened bugs] (and [https://bugzilla.gnome.org/buglist.cgi?bug_status=__open__&content=VPN&product=NetworkManager old bugs]) related to VPN support. Check the daemon processes options set via the GUI correctly and double-check with each package release.}}<br />
<br />
{{Note|To have fully functioning DNS resolution when using VPN, you should set up [[#DNS caching and conditional forwarding|conditional forwarding]].}}<br />
<br />
==== Set up VPN with WireGuard ====<br />
<br />
The Gnome gui for NetworkManager does not handle WireGuard connections. To add a WireGuard connection from a config-file, issue following command in terminal:<br />
<br />
# nmcli connection import type wireguard file <FILE><br />
<br />
If the file was called WG1.conf a connection called WG1 should have been added. <br />
<br />
If you at any point want to delete the connection, issue the command:<br />
<br />
# nmcli connection delete <CONNECTION NAME><br />
<br />
To actually start the WireGuard tunnel, issue command:<br />
<br />
# nmcli connection up <CONNECTION NAME><br />
<br />
Make sure the connection is listed when you run nmcli:<br />
<br />
# nmcli<br />
<br />
You might want to verify that the private and public keys are correct and corresponds with what you got from your VPN provider:<br />
<br />
# sudo WG_HIDE_KEYS=never wg<br />
<br />
Since WireGuard lacks support in the Gnome gui you may want to proceed to configure NetworkManager to automatically use the WireGuard connection, as described elsewhere on this Wiki page.<br />
<br />
== Usage ==<br />
<br />
NetworkManager comes with {{man|1|nmcli}} and {{man|1|nmtui}}.<br />
<br />
=== nmcli examples ===<br />
<br />
List nearby wifi networks:<br />
<br />
$ nmcli device wifi list<br />
<br />
Connect to a wifi network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
Connect to a hidden network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' hidden yes<br />
<br />
Connect to a wifi on the {{ic|wlan1}} wifi interface:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' ifname wlan1 ''profile_name''<br />
<br />
Disconnect an interface:<br />
<br />
$ nmcli device disconnect ifname eth0<br />
<br />
Reconnect an interface marked as disconnected:<br />
<br />
$ nmcli connection up uuid ''UUID''<br />
<br />
Get a list of UUIDs:<br />
<br />
$ nmcli connection show<br />
<br />
See a list of network devices and their state:<br />
<br />
$ nmcli device<br />
<br />
Turn off wifi:<br />
<br />
$ nmcli radio wifi off<br />
<br />
=== Edit a connection ===<br />
<br />
For a comprehensive list of settings, see {{man|5|nm-settings}}.<br />
<br />
Firstly you need to get list of connections:<br />
<br />
{{hc|$ nmcli connection|<nowiki><br />
NAME UUID TYPE DEVICE<br />
Wired connection 2 e7054040-a421-3bef-965d-bb7d60b7cecf ethernet enp5s0<br />
Wired connection 1 997f2782-f0fc-301d-bfba-15421a2735d8 ethernet enp0s25<br />
MY-HOME-WIFI-5G 92a0f7b3-2eba-49ab-a899-24d83978f308 wifi --<br />
</nowiki>}}<br />
<br />
Here you can use the first column as connection-id used later. In this example we pick {{ic|Wired connection 2}} as a connection-id.<br />
<br />
You have three methods to configure a connection {{ic|Wired connection 2}} after it has been created:<br />
<br />
; nmcli interactive editor<br />
: {{ic|nmcli connection edit 'Wired connection 2'}}.<br> Usage is well documented from the editor.<br />
<br />
; nmcli command line interface<br />
: {{ic|nmcli connection modify 'Wired connection 2' ''setting''.''property'' ''value''}}. See {{man|1|nmcli}} for usage. For example you can change its IPv4 route metric to 200 using {{ic|nmcli connection modify 'Wired connection 2' ipv4.route-metric 200}} command.<br />
<br />
; Connection file<br />
: In {{ic|/etc/NetworkManager/system-connections/}}, modify the corresponding {{ic|Wired connection 2.nmconnection}} file .<br> Do not forget to reload the configuration file with {{ic|nmcli connection reload}}.<br />
<br />
== Front-ends ==<br />
<br />
To configure and have easy access to NetworkManager, most users will want to install an applet. This GUI front-end usually resides in the system tray (or notification area) and allows network selection and configuration of NetworkManager. Various desktop environments have their own applet. Otherwise you can use [[#nm-applet]].<br />
<br />
=== GNOME ===<br />
<br />
[[GNOME]] has a built-in tool, accessible from the Network settings.<br />
<br />
=== KDE Plasma ===<br />
<br />
[[Install]] the {{Pkg|plasma-nm}} package. After that, add it to the KDE taskbar via the ''Panel options > Add widgets > Networks'' menu.<br />
<br />
=== nm-applet ===<br />
<br />
{{Pkg|network-manager-applet}} is a GTK 3 front-end which works under Xorg environments with a systray.<br />
<br />
To store connection secrets install and configure [[GNOME/Keyring]].<br />
<br />
Be aware that after enabling the tick-box option {{ic|Make available to other users}} for a connection, NetworkManager stores the password in plain-text, though the respective file is accessible only to root (or other users via {{ic|nm-applet}}). See [[#Encrypted Wi-Fi passwords]].<br />
<br />
In order to run {{ic|nm-applet}} without a systray, you can use {{Pkg|trayer}} or {{Pkg|stalonetray}}. For example, you can add a script like this one in your path:<br />
<br />
{{hc|nmgui|<nowiki><br />
#!/bin/sh<br />
nm-applet 2>&1 > /dev/null &<br />
stalonetray 2>&1 > /dev/null<br />
killall nm-applet<br />
</nowiki>}}<br />
<br />
When you close the ''stalonetray'' window, it closes {{ic|nm-applet}} too, so no extra memory is used once you are done with network settings.<br />
<br />
The applet can show notifications for events such as connecting to or disconnecting from a WiFi network. For these notifications to display, ensure that you have a notification server installed - see [[Desktop notifications]]. If you use the applet without a notification server, you might see some messages in stdout/stderr, and the app might hang. See [https://bugzilla.gnome.org/show_bug.cgi?id=788313].<br />
<br />
In order to run {{ic|nm-applet}} with such notifications disabled, start the applet with the following command:<br />
<br />
$ nm-applet --no-agent<br />
<br />
{{Tip|{{ic|nm-applet}} might be started automatically with a [[XDG Autostart|autostart desktop file]], to add the --no-agent option modify the Exec line there, i.e.<br />
<br />
{{bc|1=Exec=nm-applet --no-agent}}<br />
<br />
}}<br />
<br />
{{Warning|On [[i3]], if nm-applet is started with the {{ic|--no-agent}} option, it is not possible to connect to a new encrypted WiFi network by clicking on the item list because no password input dialogue window will pop out. [[journal]] will show {{ic|no secrets: No agents were available for this request}}.}}<br />
<br />
==== Appindicator ====<br />
<br />
As of version 1.18.0 Appindicator support is [https://github.com/archlinux/svntogit-packages/commit/7640a2bd557fe84813207ef4d5e35bb5aece6c54 available] in the official {{Pkg|network-manager-applet}} package. To use nm-applet in an Appindicator environment start the applet with the following command:<br />
<br />
$ nm-applet --indicator<br />
<br />
=== networkmanager-dmenu ===<br />
<br />
Alternatively there is {{AUR|networkmanager-dmenu-git}} which is a small script to manage NetworkManager connections with [[dmenu]] or [[rofi]] instead of {{ic|nm-applet}}. It provides all essential features such as connection to existing NetworkManager wifi or wired connections, connect to new wifi connections, requests passphrase if required, connect to existing VPN connections, enable/disable networking, launch ''nm-connection-editor'' GUI, connect to Bluetooth networks.<br />
<br />
== Configuration ==<br />
<br />
NetworkManager will require some additional steps to be able run properly. Make sure you have configured {{ic|/etc/hosts}} as described in [[Network configuration#Set the hostname]] section.<br />
<br />
NetworkManager has a global configuration file at {{ic|/etc/NetworkManager/NetworkManager.conf}}. Addition configuration files can be placed in {{ic|/etc/NetworkManager/conf.d/}}. Usually no configuration needs to be done to the global defaults.<br />
<br />
After editing a configuration file, the changes can be applied by running:<br />
<br />
# nmcli general reload<br />
<br />
=== Enable NetworkManager Wait Online ===<br />
<br />
{{Out of date|{{ic|NetworkManager.service}} has {{ic|1=Also=NetworkManager-wait-online.service}} in the {{ic|[Install]}} section.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/167e42a87e97ed7fb26a4263c22f1774716ac51b] If {{ic|NetworkManager.service}} was [[enable]]d before the change, it needs to be [[enable|reenabled]].}}<br />
<br />
If you have services which fail if they are started before the network is up, you may use {{ic|NetworkManager-wait-online.service}} in addition to {{ic|NetworkManager.service}}. This is, however, rarely necessary because most networked daemons start up okay, even if the network has not been configured yet.<br />
<br />
In some cases, the service will still fail to start successfully on boot due to the timeout setting in {{ic|/usr/lib/systemd/system/NetworkManager-wait-online.service}} being too short. Change the default timeout from 30 to a higher value.<br />
<br />
=== Set up PolicyKit permissions ===<br />
<br />
See [[General troubleshooting#Session permissions]] for setting up a working session.<br />
<br />
With a working session, you have several options for granting the necessary privileges to NetworkManager:<br />
<br />
* ''Option 1.'' Run a [[Polkit]] authentication agent when you log in, such as {{ic|/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1}} (part of {{Pkg|polkit-gnome}}). You will be prompted for your password whenever you add or remove a network connection.<br />
* ''Option 2.'' [[Users and groups#Group management|Add]] yourself to the {{ic|wheel}} group. You will not have to enter your password, but your user account may be granted other permissions as well, such as the ability to use [[sudo]] without entering the root password.<br />
* ''Option 3.'' [[Users and groups#Group management|Add]] yourself to the {{ic|network}} group and create the following file:<br />
<br />
{{hc|/etc/polkit-1/rules.d/50-org.freedesktop.NetworkManager.rules|<nowiki><br />
polkit.addRule(function(action, subject) {<br />
if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0 && subject.isInGroup("network")) {<br />
return polkit.Result.YES;<br />
}<br />
});<br />
</nowiki>}}<br />
<br />
: All users in the {{ic|network}} group will be able to add and remove networks without a password. This will not work under [[systemd]] if you do not have an active session with ''systemd-logind''.<br />
<br />
=== Proxy settings ===<br />
<br />
NetworkManager does not directly handle proxy settings, but if you are using [[GNOME]] or [[KDE]], you could use [http://marin.jb.free.fr/proxydriver/ proxydriver] which handles proxy settings using NetworkManager's information. proxydriver is found in the package {{AUR|proxydriver}}.<br />
<br />
In order for ''proxydriver'' to be able to change the proxy settings, you would need to execute this command, as part of the GNOME startup process (see [[GNOME#Autostart]]).<br />
<br />
xhost +si:localuser:''username''<br />
<br />
See also [[Proxy settings]].<br />
<br />
=== Checking connectivity ===<br />
<br />
NetworkManager can try to reach a page on Internet when connecting to a network. {{Pkg|networkmanager}} is configured by default in {{ic|/usr/lib/NetworkManager/conf.d/20-connectivity.conf}} to check connectivity to archlinux.org. To use a different webserver or disable connectivity checking create {{ic|/etc/NetworkManager/conf.d/20-connectivity.conf}}, see {{man|5|NetworkManager.conf|CONNECTIVITY SECTION}}. Below is an example of using GNOME servers (it does not require the use of [[GNOME]]):<br />
<br />
{{hc|/etc/NetworkManager/conf.d/20-connectivity.conf|<nowiki><br />
[connectivity]<br />
uri=http://nmcheck.gnome.org/check_network_status.txt<br />
</nowiki>}}<br />
<br />
{{Note|Although automatic connectivity checks are a potential privacy leak, the official archlinux.org default connectivity URL is committed to not logging any access. See [https://gitlab.archlinux.org/archlinux/infrastructure/-/commit/68fbaca2ef9f31f624f117899848f4288d6b39d1].}}<br />
<br />
=== Captive portals ===<br />
<br />
{{Style|Complex scripts should not be maintained on the wiki.}}<br />
<br />
For those behind a [[Wikipedia:Captive portal|captive portal]], the desktop manager may automatically open a window asking for credentials. If your desktop does not, you can use {{Pkg|capnet-assist}} package (however, it currently it has a broken NetworkManager dispatcher script). Alternatively, you can create a NetworkManager dispatcher script with the following content:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/90-open_captive_portal|<nowiki><br />
#!/bin/sh -e<br />
# Script to dispatch NetworkManager events<br />
#<br />
# Runs shows a login webpage on walled garden networks.<br />
# See NetworkManager(8) for further documentation of the dispatcher events.<br />
<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin<br />
<br />
if [ -x "/usr/bin/logger" ]; then<br />
logger="/usr/bin/logger -s -t captive-portal"<br />
else<br />
logger=":"<br />
fi<br />
<br />
wait_for_process() {<br />
PNAME=$1<br />
while [ -z "$(/usr/bin/pgrep $PNAME)" ]; do<br />
sleep 3;<br />
done<br />
}<br />
<br />
#launch the browser, but on boot we need to wait that nm-applet starts<br />
start_browser() {<br />
local user="$1"<br />
local display="$2"<br />
<br />
export DISPLAY="$display"<br />
wait_for_process nm-applet<br />
<br />
export XAUTHORITY="/home/$user/.Xauthority"<br />
<br />
$logger "Running browser as '$user' with display '$display' to login in captive portal"<br />
sudo -u "$user" --preserve-env=DISPLAY,XAUTHORITY -H xdg-open http://capnet.elementary.io 2>&1 > /dev/null<br />
}<br />
<br />
# Run the right scripts<br />
case "$2" in<br />
connectivity-change)<br />
$logger -p user.debug "dispatcher script triggered on connectivity change: $CONNECTIVITY_STATE"<br />
if [ "$CONNECTIVITY_STATE" = "PORTAL" ]; then<br />
# Match last column of who's output with ' :[at least one digit] '<br />
who | awk '$NF ~ /\(:[0-9]+\)/ { print $1 " " substr($NF, 2, length($NF)-2) };' | \<br />
while read user display; do<br />
start_browser $user $display || $logger -p user.err "Failed for user: '$user' display: '$display'"<br />
done<br />
fi<br />
;;<br />
*)<br />
# In a down phase<br />
exit 0<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
You will need to [[restart]] {{ic|NetworkManager.service}} or reboot for this to start working. Once you do, the dispatcher script should open a login window once it detects you are behind a captive portal.<br />
<br />
Another solution is {{AUR|captive-browser-git}} based on Google Chrome.<br />
<br />
=== DHCP client ===<br />
<br />
By default NetworkManager uses its internal DHCP client. The internal DHCPv4 plugin is based on the [https://nettools.github.io/n-dhcp4/ nettools' n-dhcp4] library, while the internal DHCPv6 plugin is made from code based on systemd-networkd.<br />
<br />
To use ISC’s DHCP client, [[install]] {{Pkg|dhclient}}. To change the DHCP client backend, set the option {{ic|1=main.dhcp=''dhcp_client_name''}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}. E.g.:<br />
<br />
{{hc|1=/etc/NetworkManager/conf.d/dhcp-client.conf|2=<br />
[main]<br />
dhcp=dhclient<br />
}}<br />
<br />
{{Note|<br />
* Do not enable the systemd units shipped with the {{Pkg|dhclient}} and {{Pkg|dhcpcd}} packages. They will conflict with NetworkManager, see the note in [[#Installation]] for details.<br />
* NetworkManger does not support dhcpcd ≥ 9.0.0. See {{Bug|66231}}.<br />
}}<br />
<br />
=== DNS management ===<br />
<br />
NetworkManager's DNS management is described in the GNOME project's wiki page—[https://wiki.gnome.org/Projects/NetworkManager/DNS Projects/NetworkManager/DNS].<br />
<br />
==== DNS caching and conditional forwarding ====<br />
<br />
NetworkManager has a plugin to enable DNS caching and conditional forwarding ([https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/143 previously] called "split DNS" in NetworkManager's documentation) using [[dnsmasq]] or [[systemd-resolved]]. The advantages of this setup is that DNS lookups will be cached, shortening resolve times, and DNS lookups of VPN hosts will be routed to the relevant VPN's DNS servers. This is especially useful if you are connected to more than one VPN.<br />
<br />
===== dnsmasq =====<br />
<br />
Make sure {{Pkg|dnsmasq}} has been installed. Then set {{ic|1=main.dns=dnsmasq}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=dnsmasq<br />
}}<br />
<br />
Now run {{ic|nmcli general reload}} as root. NetworkManager will automatically start dnsmasq and add {{ic|127.0.0.1}} to {{ic|/etc/resolv.conf}}. The original DNS servers can be found in {{ic|/run/NetworkManager/no-stub-resolv.conf}}. You can verify dnsmasq is being used by doing the same DNS lookup twice with {{ic|drill example.com}} and verifying the server and query times.<br />
<br />
{{Note|<br />
* You do not need to start {{ic|dnsmasq.service}} or edit {{ic|/etc/dnsmasq.conf}}. NetworkManager will start dnsmasq without using the systemd service and without reading the dnsmasq's default configuration file(s).<br />
* The dnsmasq instance started by NetworkManager will bind to {{ic|127.0.0.1:53}}, you cannot run any other software (including {{ic|dnsmasq.service}}) on the same address and port.<br />
}}<br />
<br />
====== Custom dnsmasq configuration ======<br />
<br />
Custom configurations can be created for ''dnsmasq'' by creating configuration files in {{ic|/etc/NetworkManager/dnsmasq.d/}}. For example, to change the size of the DNS cache (which is stored in RAM):<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/cache.conf|2=<br />
cache-size=1000<br />
}}<br />
<br />
{{Tip|Check the configuration file syntax with {{ic|1=dnsmasq --test --conf-file=/dev/null --conf-dir=/etc/NetworkManager/dnsmasq.d}}.}}<br />
<br />
See {{man|8|dnsmasq}} for all available options.<br />
<br />
====== IPv6 ======<br />
<br />
{{Accuracy|This does not solve the issue because NetworkManager does not add {{ic|::1}} to {{ic|/etc/resolv.conf}}. Unless {{ic|@::1}} is manually passed to drill, it will still fail with {{ic|Error: error sending query: No (valid) nameservers defined in the resolver}}.}}<br />
<br />
Enabling {{ic|dnsmasq}} in NetworkManager may break IPv6-only DNS lookups (i.e. {{ic|drill -6 [hostname]}}) which would otherwise work. In order to resolve this, creating the following file will configure ''dnsmasq'' to also listen to the IPv6 loopback:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/ipv6-listen.conf|2=<br />
listen-address=::1<br />
}}<br />
<br />
In addition, {{ic|dnsmasq}} also does not prioritize upstream IPv6 DNS. Unfortunately NetworkManager does not do this ([https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/936712 Ubuntu Bug]). A workaround would be to disable IPv4 DNS in the NetworkManager config, assuming one exists<br />
<br />
====== DNSSEC ======<br />
<br />
The dnsmasq instance started by NetworkManager by default will not validate [[DNSSEC]] since it is started with the {{ic|--proxy-dnssec}} option. It will trust whatever DNSSEC information it gets from the upstream DNS server.<br />
<br />
For dnsmasq to properly validate DNSSEC, thus breaking DNS resolution with name servers that do not support it, create the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/dnssec.conf|2=<br />
conf-file=/usr/share/dnsmasq/trust-anchors.conf<br />
dnssec<br />
}}<br />
<br />
===== systemd-resolved =====<br />
<br />
{{Expansion|NetworkManager 1.16 adds a new setting {{ic|main.systemd-resolved}}[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383] (enabled by default). It unconditionally sends DNS configuration to systemd-resolved. Related to "Preserving resolv.conf" from [[systemd-resolved#DNS]]?}}<br />
<br />
NetworkManager can use [[systemd-resolved]] as a DNS resolver and cache. Make sure that ''systemd-resolved'' is properly configured and that {{ic|systemd-resolved.service}} is [[started]] before using it.<br />
<br />
systemd-resolved will be used automatically if {{ic|/etc/resolv.conf}} is a [[Systemd-resolved#DNS|symlink]] to {{ic|/run/systemd/resolve/stub-resolv.conf}}, {{ic|/run/systemd/resolve/resolv.conf}} or {{ic|/usr/lib/systemd/resolv.conf}}.<br />
<br />
You can enable it explicitly by setting {{ic|1=main.dns=systemd-resolved}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=systemd-resolved<br />
}}<br />
<br />
===== DNS resolver with an openresolv subscriber =====<br />
<br />
If [[openresolv]] has a subscriber for your local [[DNS resolver]], set up the subscriber and [[#Use openresolv|configure NetworkManager to use openresolv]].<br />
<br />
Because NetworkManager advertises a single "interface" to ''resolvconf'', it is not possible to implement conditional forwarding between two NetworkManager connections. See [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 NetworkManager issue 153].<br />
<br />
This can be partially mitigated if you set {{ic|1=private="*"}} in {{ic|/etc/resolvconf.conf}}[https://roy.marples.name/projects/openresolv/configuration.html]. Any queries for domains that are not in search domain list will not get forwarded. They will be handled according to the local resolver's configuration, for example, forwarded to another DNS server or resolved recursively from the DNS root.<br />
<br />
==== Custom DNS servers ====<br />
<br />
===== Setting custom global DNS servers =====<br />
<br />
To set DNS servers for all connections, specify them in {{man|5|NetworkManager.conf}} using the syntax {{ic|1=servers=''serveripaddress1'',''serveripaddress2'',''serveripaddress3''}} in a section named {{ic|[global-dns-domain-*]}}. For example:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns-servers.conf|2=<br />
[global-dns-domain-*]<br />
servers=::1,127.0.0.1<br />
}}<br />
<br />
{{Note|<br />
* If you use [[#DNS caching and conditional forwarding|NetworkManager's dnsmasq or systemd-resolved plugin]] or [[#DNS resolver with an openresolv subscriber|openresolv subscribers]], then do not specify loopback addresses with the {{ic|1=servers=}} option, it can break DNS resolution.<br />
* The specified servers do not get sent to [[systemd-resolved]], the connection's DNS servers are used instead.<br />
}}<br />
<br />
===== Setting custom DNS servers in a connection =====<br />
<br />
====== Setting custom DNS servers in a connection (GUI) ======<br />
<br />
Setup will depend on the type of front-end used; the process usually involves right-clicking on the applet, editing (or creating) a profile, and then choosing DHCP type as ''Automatic (specify addresses)''. The DNS addresses will need to be entered and are usually in this form: {{ic|127.0.0.1, ''DNS-server-one'', ...}}.<br />
<br />
====== Setting custom DNS servers in a connection (nmcli / connection file) ======<br />
<br />
To setup DNS Servers per connection, you can use the {{ic|dns}} field (and the associated {{ic|dns-search}} and {{ic|dns-options}}) in the [[#Edit a connection|connection settings]]. <br />
<br />
If {{ic|method}} is set to {{ic|auto}} (when you use DHCP), you need to set {{ic|ignore-auto-dns}} to {{ic|yes}}.<br />
<br />
==== /etc/resolv.conf ====<br />
<br />
By default {{ic|/etc/resolv.conf}} is managed by ''NetworkManager'' unless it is a symlink.<br />
<br />
It can be configured to write it through [[#Use openresolv|openresolv]] or to [[#Unmanaged /etc/resolv.conf|not touch it at all]].<br />
<br />
Using openresolv allows NetworkManager to coexists with other ''resolvconf'' supporting software or, for example, to run a local DNS caching and split-DNS resolver for which openresolv has a [[openresolv#Subscribers|subscriber]].<br />
<br />
{{Note|Conditional forwarding is [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 not yet fully supported] when using NetworkManager with openresolv.}}<br />
<br />
''NetworkManager'' also offers hooks via so called dispatcher scripts that can be used to alter the {{ic|/etc/resolv.conf}} after network changes. See [[#Network services with NetworkManager dispatcher]] and {{man|8|NetworkManager}} for more information.<br />
<br />
{{Note|<br />
* If NetworkManager is configured to use either [[#dnsmasq|dnsmasq]] or [[#systemd-resolved|systemd-resolved]], then the appropriate loopback addresses will be written to {{ic|/etc/resolv.conf}}.<br />
* The {{ic|resolv.conf}} file NetworkManager writes or would write to {{ic|/etc/resolv.conf}} can be found at {{ic|/run/NetworkManager/resolv.conf}}.<br />
* A {{ic|resolv.conf}} file with the acquired name servers and search domains can be found at {{ic|/run/NetworkManager/no-stub-resolv.conf}}.<br />
}}<br />
<br />
===== Unmanaged /etc/resolv.conf =====<br />
<br />
To stop NetworkManager from touching {{ic|/etc/resolv.conf}}, set {{ic|1=main.dns=none}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=none<br />
}}<br />
<br />
{{Tip|You might also want to set {{ic|1=main.systemd-resolved=false}}, so that NetworkManager does not send the DNS configuration to [[systemd-resolved]].}}<br />
<br />
{{Note|See [[#DNS caching and conditional forwarding]], to configure NetworkManager using other DNS backends like [[dnsmasq]] and [[systemd-resolved]], instead of using {{ic|1=main.dns=none}}.}}<br />
<br />
After that {{ic|/etc/resolv.conf}} might be a broken symlink that you will need to remove. Then, just create a new {{ic|/etc/resolv.conf}} file.<br />
<br />
===== Use openresolv =====<br />
<br />
{{Note|Do not set {{ic|1=rc-manager=resolvconf}} when {{Pkg|systemd-resolvconf}} is installed. ''systemd-resolved'' provides limited support for the ''resolvconf'' interface and NetworkManager supports communicating with systemd-resolved through D-Bus without using ''resolvconf''.}}<br />
<br />
To configure NetworkManager to use [[openresolv]], set {{ic|1=main.rc-manager=resolvconf}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/rc-manager.conf|2=<br />
[main]<br />
rc-manager=resolvconf<br />
}}<br />
<br />
=== Firewall ===<br />
<br />
You can assign a [[firewalld]] zone based on your current connection. For example a restrictive firewall when at work, and a less restrictive one when at home.<br />
<br />
This can also be done with [[#Network services with NetworkManager dispatcher|NetworkManager dispatcher]].<br />
<br />
=== 802.1x / PEAP configuration ===<br />
<br />
A PEAP and 802.1x network can be added by adding a config file to {{ic|/etc/NetworkManager/system-connections/''name''}}.<br />
<br />
Here is an example configuration file for IPv4 with IPv6 disabled:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''name''|2=<br />
[ipv6]<br />
method=ignore<br />
<br />
[ipv4]<br />
method=auto<br />
<br />
[connection]<br />
#id=XXXXXXXXX<br />
#uuid=XXXXXXXXX<br />
type=802-11-wireless<br />
#timestamp=XXXX<br />
<br />
[802-11-wireless-security]<br />
key-mgmt=wpa-eap<br />
<br />
[802-11-wireless]<br />
ssid=ssid<br />
mode=infrastructure<br />
#seen-bssids=XXXXXXXXX<br />
security=802-11-wireless-security<br />
<br />
[802-1x]<br />
eap=peap;<br />
identity=user<br />
password=password<br />
phase2-auth=mschapv2<br />
}}<br />
<br />
The number sign (#) defines comments.<br />
<br />
=== Automatically connect to VPN ===<br />
<br />
NetworkManager can be set to automatically connect to a VPN when connecting to the internet, on a per network basis. The VPN connection itself can be added in the Gnome gui, but to make it automatically use the VPN {{ic|nmcli}} must be used.<br />
<br />
First, make sure to make the VPN connection available to all users. In the Gnome gui this is a matter of checking a box under the {{ic|details}} tab. Then under the {{ic|Identity}} tab, in the password field, click the icon on the right side in the field, and set it to {{ic|Store the password for all users}}.<br />
<br />
Then use the {{ic|nmcli}} tool via command line:<br />
<br />
# nmcli connection<br />
<br />
To list your connections. Then enter configuration mode for the internet connection you want to automatically connect to a VPN<br />
<br />
# nmcli connection edit <NAME of Internet Connection><br />
<br />
Please note that it is the Internet connection and not the VPN you should edit. Here you do not need to use the UUID of the Internet connection, the NAME is fine. Then make the setting with the command:<br />
<br />
# set connection.secondaries <UUID of VPN><br />
<br />
Here the UUID of the VPN must be used, but {{ic|tab}} works for autocompletion.<br />
<br />
Finally save and quit:<br />
<br />
# save<br />
# quit<br />
<br />
Now when NetworkManager is restarted and you connect to the Internet connection you have configured, you should automatically get connected to the VPN.<br />
<br />
== Network services with NetworkManager dispatcher ==<br />
<br />
There are quite a few network services that you will not want running until NetworkManager brings up an interface. NetworkManager has the ability to start services when you connect to a network and stop them when you disconnect (e.g. when using [[NFS]], [[SMB]] and [[NTPd]]).<br />
<br />
To activate the feature you need to [[enable]] and [[start]] the {{ic|NetworkManager-dispatcher.service}}.<br />
<br />
Once the service is active, scripts can be added to the {{ic|/etc/NetworkManager/dispatcher.d}} directory.<br />
<br />
Scripts must be owned by '''root''', otherwise the dispatcher will not execute them. For added security, set group [[ownership]] to root as well:<br />
<br />
# chown root:root /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
Make sure the file has correct permissions:<br />
<br />
# chmod 755 /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
The scripts will be run in alphabetical order at connection time, and in reverse alphabetical order at disconnect time. To ensure what order they come up in, it is common to use numerical characters prior to the name of the script (e.g. {{ic|10-portmap}} or {{ic|30-netfs}} (which ensures that the ''portmapper'' is up before NFS mounts are attempted).<br />
<br />
Scripts will receive the following arguments:<br />
<br />
* '''Interface name:''' e.g. {{ic|eth0}}<br />
* '''Interface status:''' ''up'' or ''down''<br />
* '''VPN status:''' ''vpn-up'' or ''vpn-down''<br />
<br />
{{Warning|If you connect to foreign or public networks, be aware of what services you are starting and what servers you expect to be available for them to connect to. You could make a security hole by starting the wrong services while connected to a public network.}}<br />
<br />
=== Avoiding the dispatcher timeout ===<br />
<br />
If the above is working, then this section is not relevant. However, there is a general problem related to running dispatcher scripts which take longer to be executed. Initially an internal timeout of three seconds only was used. If the called script did not complete in time, it was killed. Later the timeout was extended to about 20 seconds (see the [https://bugzilla.redhat.com/show_bug.cgi?id=982734 Bugtracker] for more information). If the timeout still creates the problem, a work around may be to modify the dispatcher service file {{ic|/usr/lib/systemd/system/NetworkManager-dispatcher.service}} to remain active after exit: <br />
<br />
{{hc|/etc/systemd/system/NetworkManager-dispatcher.service.d/remain_after_exit.conf|2=<br />
[Service]<br />
RemainAfterExit=yes<br />
}}<br />
<br />
Now start and enable the modified {{ic|NetworkManager-dispatcher}} service.<br />
<br />
{{Warning|Adding the {{ic|RemainAfterExit}} line to it will prevent the dispatcher from closing. Unfortunately, the dispatcher '''has''' to close before it can run your scripts again. With it the dispatcher will not time out but it also will not close, which means that the scripts will only run once per boot. Therefore, do not add the line unless the timeout is definitely causing a problem.}}<br />
<br />
=== Dispatcher examples ===<br />
<br />
==== Mount remote folder with sshfs ====<br />
<br />
As the script is run in a very restrictive environment, you have to export {{ic|SSH_AUTH_SOCK}} in order to connect to your SSH agent. There are different ways to accomplish this, see [https://bbs.archlinux.org/viewtopic.php?pid=1042030#p1042030 this message] for more information. The example below works with [[GNOME Keyring]], and will ask you for the password if not unlocked already. In case NetworkManager connects automatically on login, it is likely ''gnome-keyring'' has not yet started and the export will fail (hence the sleep). The {{ic|UUID}} to match can be found with the command {{ic|nmcli connection status}} or {{ic|nmcli connection list}}. <br />
<br />
{{bc|<nowiki><br />
#!/bin/sh<br />
USER='username'<br />
REMOTE='user@host:/remote/path'<br />
LOCAL='/local/path'<br />
<br />
interface=$1 status=$2<br />
if [ "$CONNECTION_UUID" = "</nowiki>''uuid''<nowiki>" ]; then<br />
case $status in<br />
up)<br />
SSH_AUTH_SOCK=$(find /tmp -maxdepth 1 -type s -user "$USER" -name 'ssh')<br />
export SSH_AUTH_SOCK<br />
su "$USER" -c "sshfs $REMOTE $LOCAL"<br />
;;<br />
down)<br />
fusermount -u "$LOCAL"<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
==== Mounting of SMB shares ====<br />
<br />
Some [[SMB]] shares are only available on certain networks or locations (e.g. at home). You can use the dispatcher to only mount SMB shares that are present at your current location.<br />
<br />
The following script will check if we connected to a specific network and mount shares accordingly:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-mount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
# Find the connection UUID with "nmcli connection show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
if [ "$2" = "up" ]; then<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
mount /your/mount/point & <br />
# add more shares as needed<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The following script will unmount all SMB shares before a software initiated disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/pre-down.d/30-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|Make sure this script is located in the {{ic|pre-down.d}} sub-directory as shown above, otherwise it will unmount all shares on any connection state change.}}<br />
<br />
The following script will attempt to unmount all SMB shares following an unexpected disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/40-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
if [ "$2" = "down" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|<br />
* Since NetworkManager 0.9.8, the ''pre-down'' and ''down'' events are not executed on shutdown or restart, see [https://bugzilla.gnome.org/show_bug.cgi?id&#61;701242 this bug report] for more info.<br />
* The previous ''umount'' scripts are still prone to leaving applications actually accessing the mount to 'hang'.<br />
}}<br />
<br />
An alternative is to use the script as seen in [[NFS#Using a NetworkManager dispatcher]]:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-smb.sh|<nowiki><br />
#!/bin/bash<br />
<br />
# Find the connection UUID with "nmcli con show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
WANTED_CON_UUID="CHANGE-ME-NOW-9c7eff15-010a-4b1c-a786-9b4efa218ba9"<br />
<br />
if [[ "$CONNECTION_UUID" == "$WANTED_CON_UUID" ]]; then<br />
<br />
# Script parameter $1: NetworkManager connection name, not used<br />
# Script parameter $2: dispatched event<br />
<br />
case "$2" in<br />
"up")<br />
mount -a -t cifs<br />
;;<br />
"pre-down");&<br />
"vpn-pre-down")<br />
umount -l -a -t cifs >/dev/null<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|This script ignores mounts with the {{ic|noauto}} option, remove this mount option or use {{ic|auto}} to allow the dispatcher to manage these mounts.}}<br />
<br />
Create a symlink inside {{ic|/etc/NetworkManager/dispatcher.d/pre-down/}} to catch the {{ic|pre-down}} events:<br />
<br />
# ln -s ../30-smb.sh /etc/NetworkManager/dispatcher.d/pre-down.d/30-smb.sh<br />
<br />
==== Mounting of NFS shares ====<br />
<br />
See [[NFS#Using a NetworkManager dispatcher]].<br />
<br />
==== Use dispatcher to automatically toggle wireless depending on LAN cable being plugged in ====<br />
<br />
The idea is to only turn Wi-Fi on when the LAN cable is unplugged (for example when detaching from a laptop dock), and for Wi-Fi to be automatically disabled, once a LAN cable is plugged in again. <br />
<br />
Create the following dispatcher script[https://superuser.com/questions/233448/disable-wlan-if-wired-cable-network-is-available], replacing {{ic|1=LAN_interface}} with yours.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/wlan_auto_toggle.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$1" = "LAN_interface" ]; then<br />
case "$2" in<br />
up)<br />
nmcli radio wifi off<br />
;;<br />
down)<br />
nmcli radio wifi on<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|You can get a list of interfaces using [[#nmcli examples|nmcli]]. The ethernet (LAN) interfaces start with {{ic|en}}, e.g. {{ic|1=enp0s5}}}}<br />
<br />
==== Use dispatcher to connect to a VPN after a network connection is established ====<br />
<br />
In this example we want to connect automatically to a previously defined VPN connection after connecting to a specific Wi-Fi network. First thing to do is to create the dispatcher script that defines what to do after we are connected to the network.<br />
<br />
{{Note|This script will require {{Pkg|wireless_tools}} in order to use {{ic|iwgetid}}.}}<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME"<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you would like to attempt to automatically connect to VPN for all Wi-Fi networks, you can use the following definition of the ESSID: {{ic|1=ESSID=$(iwgetid -r)}}. Remember to set the script's permissions [[#Network services with NetworkManager dispatcher|accordingly]]. <br />
<br />
Trying to connect with the above script may still fail with {{ic|NetworkManager-dispatcher.service}} complaining about 'no valid VPN secrets', because of [https://developer.gnome.org/NetworkManager/0.9/secrets-flags.html the way VPN secrets are stored]. Fortunately, there are different options to give the above script access to your VPN password.<br />
<br />
1: One of them requires editing the VPN connection configuration file to make NetworkManager store the secrets by itself rather than inside a keyring [https://bugzilla.redhat.com/show_bug.cgi?id=710552 that will be inaccessible for root]: open up {{ic|/etc/NetworkManager/system-connections/''name of your VPN connection''}} and change the {{ic|password-flags}} and {{ic|secret-flags}} from {{ic|1}} to {{ic|0}}.<br />
<br />
If that alone does not work, you may have to create a {{ic|passwd-file}} in a safe location with the same permissions and ownership as the dispatcher script, containing the following:<br />
<br />
{{hc|/path/to/passwd-file|<br />
vpn.secrets.password:YOUR_PASSWORD<br />
}}<br />
<br />
The script must be changed accordingly, so that it gets the password from the file:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME" passwd-file /path/to/passwd-file<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
2: Alternatively, change the {{ic|password-flags}} and put the password directly in the configuration file adding the section {{ic|vpn-secrets}}:<br />
<br />
[vpn]<br />
....<br />
password-flags=0<br />
<br />
[vpn-secrets]<br />
password=''your_password''<br />
<br />
{{Note|It may now be necessary to re-open the NetworkManager connection editor and save the VPN passwords/secrets again.}}<br />
<br />
==== Use dispatcher to disable IPv6 on VPN provider connections ====<br />
<br />
Many [[:Category:VPN providers|commercial VPN providers]] support only IPv4. That means all IPv6 traffic bypasses the VPN and renders it virtually useless. To avoid this, dispatcher can be used to disable all IPv6 traffic for the time a VPN connection is up.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/10-vpn-ipv6|<nowiki><br />
#!/bin/sh<br />
<br />
case "$2" in<br />
vpn-up)<br />
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
vpn-down)<br />
echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
==== OpenNTPD ====<br />
<br />
See [[OpenNTPD#Using NetworkManager dispatcher]].<br />
<br />
== Testing ==<br />
<br />
NetworkManager applets are designed to load upon login so no further configuration should be necessary for most users. If you have already disabled your previous network settings and disconnected from your network, you can now test if NetworkManager will work. The first step is to [[start]] {{ic|NetworkManager.service}}.<br />
<br />
Some applets will provide you with a {{ic|.desktop}} file so that the NetworkManager applet can be loaded through the application menu. If it does not, you are going to either have to discover the command to use or logout and login again to start the applet. Once the applet is started, it will likely begin polling network connections with for auto-configuration with a DHCP server.<br />
<br />
To start the GNOME applet in non-xdg-compliant window managers like [[awesome]]:<br />
<br />
nm-applet --sm-disable &<br />
<br />
For static IP addresses, you will have to configure NetworkManager to understand them. The process usually involves right-clicking the applet and selecting something like 'Edit Connections'.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Encrypted Wi-Fi passwords ===<br />
<br />
By default, NetworkManager stores passwords in clear text in the connection files at {{ic|/etc/NetworkManager/system-connections/}}. To print the stored passwords, use the following command:<br />
<br />
# grep -r '^psk=' /etc/NetworkManager/system-connections/<br />
<br />
The passwords are accessible to the root user in the filesystem and to users with access to settings via the GUI (e.g. {{ic|nm-applet}}). <br />
<br />
It is preferable to save the passwords in encrypted form in a keyring instead of clear text. The downside of using a keyring is that the connections have to be set up for each user.<br />
<br />
==== Using GNOME Keyring ====<br />
<br />
The keyring daemon has to be started and the keyring needs to be unlocked for the following to work.<br />
<br />
Furthermore, NetworkManager needs to be configured not to store the password for all users. Using GNOME {{ic|nm-applet}}, run {{ic|nm-connection-editor}} from a terminal, select a network connection, click {{ic|Edit}}, select the {{ic|Wifi-Security}} tab and click on the right icon of password and check {{ic|Store the password only for this user}}.<br />
<br />
==== Using KDE Wallet ====<br />
<br />
Using KDE's {{Pkg|plasma-nm}}, click the applet, click on the top right {{ic|Settings}} icon, click on a network connection, in the {{ic|General settings}} tab, untick {{ic|all users may connect to this network}}. If the option is ticked, the passwords will still be stored in clear text, even if a keyring daemon is running.<br />
<br />
If the option was selected previously and you un-tick it, you may have to use the {{ic|reset}} option first to make the password disappear from the file. Alternatively, delete the connection first and set it up again.<br />
<br />
=== Sharing internet connection over Wi-Fi ===<br />
<br />
You can share your internet connection (e.g. 3G or wired) with a few clicks. Please note that a [[firewall]] may interfere with internet sharing.<br />
<br />
You will need a Wi-Fi card which supports AP mode, see [[Software access point#Wi-Fi device must support AP mode]] for details.<br />
<br />
[[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
<br />
Create the shared connection:<br />
<br />
* Click on applet and choose ''Create new wireless network''.<br />
* Follow wizard (choose WPA2 or higher, be sure to use at least 8 character long password, lower lengths will fail).<br />
** Choose either [[Fedora:Features/RealHotspot|Hotspot]] or Ad-hoc as Wi-Fi mode.<br />
<br />
The connection will be saved and remain stored for the next time you need it.<br />
<br />
{{Note|Android does not support connecting to Ad-hoc networks. To share a connection with Android use infrastructure mode (i.e. set Wi-Fi mode to "Hotspot").}}<br />
<br />
=== Sharing internet connection over Ethernet ===<br />
<br />
Scenario: your device has internet connection over wi-fi and you want to share the internet connection to other devices over ethernet.<br />
<br />
Requirements:<br />
<br />
* [[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
* Your internet connected device and the other devices are connected over a suitable ethernet cable (this usually means a cross over cable or a switch in between).<br />
* Internet sharing is not blocked by a [[firewall]].<br />
<br />
Steps:<br />
<br />
{{Style|{{Pkg|nm-connection-editor}} is not a dependency of {{Pkg|networkmanager}} and needs to be installed separately.}}<br />
<br />
* Run {{ic|nm-connection-editor}} from terminal.<br />
* Add a new ethernet connection.<br />
* Give it some sensible name. For example "Shared Internet"<br />
* Go to "IPv4 Settings".<br />
* For "Method:" select "Shared to other computers".<br />
* Save<br />
<br />
Now you should have a new option "Shared Internet" under the Wired connections in NetworkManager.<br />
<br />
=== Checking if networking is up inside a cron job or script ===<br />
<br />
{{Out of date|''nm-tool'' was remove from NetworkManager for long time now[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/bb8c75bd536d4f8fb80a4366025a279078f0ec81]. ''nmcli'' should be used instead.}}<br />
<br />
Some ''cron'' jobs require networking to be up to succeed. You may wish to avoid running these jobs when the network is down. To accomplish this, add an '''if''' test for networking that queries NetworkManager's ''nm-tool'' and checks the state of networking. The test shown here succeeds if any interface is up, and fails if they are all down. This is convenient for laptops that might be hardwired, might be on wireless, or might be off the network.<br />
<br />
{{bc|<nowiki><br />
if [ $(nm-tool|grep State|cut -f2 -d' ') == "connected" ]; then<br />
#Whatever you want to do if the network is online<br />
else<br />
#Whatever you want to do if the network is offline - note, this and the else above are optional<br />
fi<br />
</nowiki>}}<br />
<br />
This useful for a {{ic|cron.hourly}} script that runs ''fpupdate'' for the F-Prot virus scanner signature update, as an example. Another way it might be useful, with a little modification, is to differentiate between networks using various parts of the output from ''nm-tool''; for example, since the active wireless network is denoted with an asterisk, you could grep for the network name and then grep for a literal asterisk.<br />
<br />
=== Connect to network with secret on boot ===<br />
<br />
By default, NetworkManager will not connect to networks requiring a secret automatically on boot. This is because it locks such connections to the user who makes it by default, only connecting after they have logged in. To change this, do the following:<br />
<br />
# Right click on the {{ic|nm-applet}} icon in your panel and select Edit Connections and open the Wireless tab<br />
# Select the connection you want to work with and click the Edit button<br />
# Check the boxes “Connect Automatically” and “Available to all users”<br />
# Additionally, ensure that under "Wi-Fi Security", "Store password for all users (not encrypted)" is selected<br />
<br />
Log out and log back in to complete.<br />
<br />
=== OpenConnect with password in KWallet ===<br />
<br />
While you may type both values at connection time, {{Pkg|plasma-nm}} 0.9.3.2-1 and above are capable of retrieving OpenConnect username and password directly from [[KWallet]].<br />
<br />
Open "KDE Wallet Manager" and look up your OpenConnect VPN connection under "Network Management|Maps". Click "Show values" and <br />
enter your credentials in key "VpnSecrets" in this form (replace ''username'' and ''password'' accordingly):<br />
<br />
form:main:username%SEP%''username''%SEP%form:main:password%SEP%''password''<br />
<br />
Next time you connect, username and password should appear in the "VPN secrets" dialog box.<br />
<br />
=== Ignore specific devices ===<br />
<br />
Sometimes it may be desired that NetworkManager ignores specific devices and does not try to configure addresses and routes for them. You can quickly and easily ignore devices by MAC or interface-name by using the following in {{ic|/etc/NetworkManager/conf.d/unmanaged.conf}}:<br />
<br />
[keyfile]<br />
unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth0<br />
<br />
After editing the file, run {{ic|nmcli general reload}} as root. Afterwards you should be able to configure interfaces without NetworkManager altering what you have set.<br />
<br />
=== Configuring MAC address randomization ===<br />
<br />
{{Note|1=Disabling MAC address randomization may be needed to get (stable) link connection [https://bbs.archlinux.org/viewtopic.php?id=220101] and/or networks that restrict devices based on their MAC Address or have a limit network capacity.}}<br />
<br />
MAC randomization can be used for increased privacy by not disclosing your real MAC address to the network.<br />
<br />
NetworkManager supports two types MAC Address Randomization: randomization during scanning, and for network connections. Both modes can be configured by modifying {{ic|/etc/NetworkManager/NetworkManager.conf}} or by creating a separate configuration file in {{ic|/etc/NetworkManager/conf.d/}} which is recommended since the aforementioned config file may be overwritten by NetworkManager.<br />
<br />
Randomization during Wi-Fi scanning is enabled by default, but it may be disabled by adding the following lines to {{ic|/etc/NetworkManager/NetworkManager.conf}} or a dedicated configuration file under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device]<br />
wifi.scan-rand-mac-address=no<br />
}}<br />
<br />
MAC randomization for network connections can be set to different modes for both wireless and ethernet interfaces. See the [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details on the different modes. <br />
<br />
In terms of MAC randomization the most important modes are {{ic|stable}} and {{ic|random}}. {{ic|stable}} generates a random MAC address when you connect to a new network and associates the two permanently. This means that you will use the same MAC address every time you connect to that network. In contrast, {{ic|random}} will generate a new MAC address every time you connect to a network, new or previously known. You can configure the MAC randomization by adding the desired configuration under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device-mac-randomization]<br />
# "yes" is already the default for scanning<br />
wifi.scan-rand-mac-address=yes<br />
<br />
[connection-mac-randomization]<br />
# Randomize MAC for every ethernet connection<br />
ethernet.cloned-mac-address=random<br />
# Generate a random MAC for each WiFi and associate the two permanently.<br />
wifi.cloned-mac-address=stable<br />
}}<br />
<br />
See the following [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details.<br />
<br />
=== Enable IPv6 Privacy Extensions ===<br />
<br />
See [[IPv6#NetworkManager]].<br />
<br />
=== Working with wired connections ===<br />
<br />
By default, NetworkManager generates a connection profile for each wired ethernet connection it finds. At the point when generating the connection, it does not know whether there will be more ethernet adapters available. Hence, it calls the first wired connection "Wired connection 1". You can avoid generating this connection, by configuring {{ic|no-auto-default}} (see {{man|5|NetworkManager.conf}}), or by simply deleting it. Then NetworkManager will remember not to generate a connection for this interface again.<br />
<br />
You can also edit the connection (and persist it to disk) or delete it. NetworkManager will not re-generate a new connection. Then you can change the name to whatever you want. You can use something like nm-connection-editor for this task.<br />
<br />
=== Using iwd as the Wi-Fi backend ===<br />
<br />
Install {{AUR|networkmanager-iwd}} or enable the experimental [[iwd]] backend creating the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_backend.conf|2=<br />
[device]<br />
wifi.backend=iwd<br />
}}<br />
<br />
=== Running in a network namespace ===<br />
<br />
If you would like to run NetworkManager inside a network namespace (e.g., to manage a specific device which should be use by selected applications), bring the device down before moving it to the namespace:<br />
<br />
$ ip link set dev ''MY_DEVICE'' down<br />
$ ip link set dev ''MY_DEVICE'' netns ''MY_NAMESPACE''<br />
$ ip netns exec ''MY_NAMESPACE'' NetworkManager<br />
...<br />
$ ip netns exec ''MY_NAMESPACE'' killall NetworkManager<br />
<br />
otherwise NetworkManager will later fail to establish the connection with a {{ic|device is strictly unmanaged}} error.<br />
<br />
== Troubleshooting ==<br />
<br />
=== No prompt for password of secured Wi-Fi networks ===<br />
<br />
When trying to connect to a secured Wi-Fi network, no prompt for a password is shown and no connection is established. This happens when no keyring package is installed. An easy solution is to install {{Pkg|gnome-keyring}}. If you want the passwords to be stored in encrypted form, follow [[GNOME Keyring]] to set up the ''gnome-keyring-daemon''.<br />
<br />
=== Network management disabled ===<br />
<br />
When NetworkManager shuts down but the pid (state) file is not removed, you will see a {{ic|Network management disabled}} message. If this happens, remove the file manually:<br />
<br />
# rm /var/lib/NetworkManager/NetworkManager.state<br />
<br />
=== Problems with internal DHCP client ===<br />
<br />
If you have problems with getting an IP address using the internal DHCP client, consider using another DHCP client, see [[#DHCP client]] for instructions. This workaround might solve problems in big wireless networks like eduroam.<br />
<br />
=== DHCP problems with dhclient ===<br />
<br />
If you have problems with getting an IP address via DHCP, try to add the following to your {{ic|/etc/dhclient.conf}}:<br />
<br />
interface "eth0" {<br />
send dhcp-client-identifier 01:''aa:bb:cc:dd:ee:ff'';<br />
}<br />
<br />
Where {{ic|''aa:bb:cc:dd:ee:ff''}} is the MAC address of this NIC. The MAC address can be found using the {{ic|ip link show ''interface''}} command from the {{Pkg|iproute2}} package.<br />
<br />
=== 3G modem not detected ===<br />
<br />
See [[USB 3G Modem#NetworkManager]].<br />
<br />
=== Switching off WLAN on laptops ===<br />
<br />
Sometimes NetworkManager will not work when you disable your Wi-Fi adapter with a switch on your laptop and try to enable it again afterwards. This is often a problem with ''rfkill''. To check if the driver notifies ''rfkill'' about the wireless adapter's status, use:<br />
<br />
$ watch -n1 rfkill list all<br />
<br />
If one identifier stays blocked after you switch on the adapter you could try to manually unblock it with (where X is the number of the identifier provided by the above output):<br />
<br />
# rfkill event unblock X<br />
<br />
=== Static IP address settings revert to DHCP ===<br />
<br />
Due to an unresolved bug, when changing default connections to a static IP address, {{ic|nm-applet}} may not properly store the configuration change, and will revert to automatic DHCP.<br />
<br />
To work around this issue you have to edit the default connection (e.g. "Auto eth0") in {{ic|nm-applet}}, change the connection name (e.g. "my eth0"), uncheck the "Available to all users" checkbox, change your static IP address settings as desired, and click '''Apply'''. This will save a new connection with the given name.<br />
<br />
Next, you will want to make the default connection not connect automatically. To do so, run {{ic|nm-connection-editor}} ('''not''' as root). In the connection editor, edit the default connection (e.g. "Auto eth0") and uncheck "Connect automatically". Click '''Apply''' and close the connection editor.<br />
<br />
=== Cannot edit connections as normal user ===<br />
<br />
See [[#Set up PolicyKit permissions]].<br />
<br />
=== Forget hidden wireless network ===<br />
<br />
Since hidden networks are not displayed in the selection list of the Wireless view, they cannot be forgotten (removed) with the GUI. You can delete one with the following command:<br />
<br />
# rm /etc/NetworkManager/system-connections/''SSID''<br />
<br />
This works for any other connection.<br />
<br />
=== VPN not working in GNOME ===<br />
<br />
When setting up OpenConnect or vpnc connections in NetworkManager while using GNOME, you will sometimes never see the dialog box pop up and the following error appears in {{ic|/var/log/errors.log}}:<br />
<br />
localhost NetworkManager[399]: <error> [1361719690.10506] [nm-vpn-connection.c:1405] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.<br />
<br />
This is caused by the GNOME NM Applet expecting dialog scripts to be at {{ic|/usr/lib/gnome-shell}}, when NetworkManager's packages put them in {{ic|/usr/lib/networkmanager}}.<br />
As a "temporary" fix (this bug has been around for a while now), make the following symlink(s):<br />
<br />
* For OpenConnect: {{ic|ln -s /usr/lib/networkmanager/nm-openconnect-auth-dialog /usr/lib/gnome-shell/}}<br />
* For VPNC (i.e. Cisco VPN): {{ic|ln -s /usr/lib/networkmanager/nm-vpnc-auth-dialog /usr/lib/gnome-shell/}}<br />
<br />
This may need to be done for any other NM VPN plugins as well, but these are the two most common.<br />
<br />
=== Unable to connect to visible European wireless networks ===<br />
<br />
WLAN chips are shipped with a default [[Wireless network configuration#Respecting the regulatory domain|regulatory domain]]. If your access point does not operate within these limitations, you will not be able to connect to the network. Fixing this is easy:<br />
<br />
# [[Install]] {{Pkg|crda}}<br />
# Uncomment the correct Country Code in {{ic|/etc/conf.d/wireless-regdom}}<br />
# Reboot the system, because the setting is only read on boot<br />
<br />
=== Automatic connect to VPN on boot is not working ===<br />
<br />
The problem occurs when the system (i.e. NetworkManager running as the root user) tries to establish a VPN connection, but the password is not accessible because it is stored in the GNOME keyring of a particular user. <br />
<br />
A solution is to keep the password to your VPN in plaintext, as described in step (2.) of [[#Use dispatcher to connect to a VPN after a network connection is established]]. <br />
<br />
You do not need to use the dispatcher described in step (1.) to auto-connect anymore, if you use the new "auto-connect VPN" option from the {{ic|nm-applet}} GUI.<br />
<br />
=== Systemd Bottleneck ===<br />
<br />
Over time the log files ({{ic|/var/log/journal}}) can become very large. This can have a big impact on boot performance when using NetworkManager, see: [[Systemd#Boot time increasing over time]].<br />
<br />
=== Regular network disconnects, latency and lost packets (WiFi) ===<br />
<br />
NetworkManager does a scan every 2 minutes.<br />
<br />
Some WiFi drivers have issues when scanning for base stations whilst connected/associated. Symptoms include VPN disconnects/reconnects and lost packets, web pages failing to load and then refresh fine.<br />
<br />
Running {{ic|journalctl -f}} will indicate that this is taking place, messages like the following will be contained in the logs at regular intervals.<br />
<br />
NetworkManager[410]: <info> (wlp3s0): roamed from BSSID 00:14:48:11:20:CF (my-wifi-name) to (none) ((none))<br />
<br />
There is a patched version of NetworkManager which should prevent this type of scanning: {{AUR|networkmanager-noscan}}.<br />
<br />
Alternatively, if roaming is not important, the periodic scanning behavior can be disabled by locking the BSSID of the access point in the WiFi connection profile.<br />
<br />
=== Unable to turn on wi-fi with Lenovo laptop (IdeaPad, Legion, etc.) ===<br />
<br />
There is an issue with the {{ic|ideapad_laptop}} module on some Lenovo models due to the wi-fi driver incorrectly reporting a soft block. The card can still be manipulated with {{ic|netctl}}, but managers like NetworkManager break. You can verify that this is the problem by checking the output of {{ic|rfkill list}} after toggling your hardware switch and seeing that the soft block persists.<br />
<br />
{{Accuracy|Try to use {{ic|rfkill.default_state}} and {{ic|rfkill.master_switch_mode}} (see [https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt kernel-parameters.txt]) to fix the rfkill problem.}}<br />
<br />
[[modprobe|Unloading]] the {{ic|ideapad_laptop}} module should fix this. ('''warning''': this may disable the laptop keyboard and touchpad also!).<br />
<br />
=== Turn off hostname sending ===<br />
<br />
NetworkManager by default sends the hostname to the DHCP server. Hostname sending can only be disabled per connection not globally ([https://bugzilla.gnome.org/show_bug.cgi?id=768076 GNOME Bug 768076]).<br />
<br />
To disable sending your hostname to the DHCP server for a specific connection, add the following to your network connection file:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''your_connection_file''|2=<br />
...<br />
[ipv4]<br />
dhcp-send-hostname=false<br />
...<br />
[ipv6]<br />
dhcp-send-hostname=false<br />
...<br />
}}<br />
<br />
=== nm-applet disappears in i3wm ===<br />
<br />
If you use the {{ic|xfce4-notifyd.service}} for notifications you must [[edit]] the unit and add the following:<br />
<br />
{{hc|/etc/systemd/user/xfce4-notifyd.service.d/display_env.conf|2=<br />
[Service]<br />
Environment="DISPLAY=:0.0"<br />
}}<br />
<br />
After reloading the daemons [[restart]] {{ic|xfce4-notifyd.service}}. Exit i3 and start it back up again and the applet should show on the tray.<br />
<br />
=== nm-applet tray icons display wrongly ===<br />
<br />
Currently the tray icons of nm-applet are drawn on top of one another, i.e. the icon displaying wireless strength might show on top of the icon indicating no wired connection.<br />
This is apparently a GTK3 bug/problem: https://gitlab.gnome.org/GNOME/gtk/issues/1280 .<br />
<br />
A patched version of GTK3 exists in AUR, which apparently fixes the tray icon bug: {{AUR|gtk3-mushrooms}} .<br />
<br />
=== Unit dbus-org.freedesktop.resolve1.service not found ===<br />
<br />
If {{ic|systemd-resolved.service}} is not started, NetworkManager will try to start it using D-Bus and fail:<br />
<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
dbus-daemon[991]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
<br />
This is because NetworkManager will try to send DNS information to [[systemd-resolved]] regardless of the {{ic|1=main.dns=}} setting in {{man|5|NetworkManager.conf}}.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383]<br />
<br />
This can be disabled with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/no-systemd-resolved.conf|2=<br />
[main]<br />
systemd-resolved=false<br />
}}<br />
<br />
See {{Bug|62138}}.<br />
<br />
=== Secrets were required, but not provided ===<br />
<br />
If you attempt to connect to a network using {{ic|nmcli device wifi connect ''SSID'' password ''password''}} and received the following error:<br />
<br />
Error: Connection activation failed: (7) Secrets were required, but not provided<br />
<br />
The error can be resolved by deleting the connection profile and creating a new one:<br />
<br />
$ nmcli connection delete ''SSID''<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
=== WPA Enterprise connection with NetworkManager ===<br />
<br />
If you try to connect to an WPA Enterprise network like 'eduroam' with NetworkManager with the [[iwd]] backend then you will get the following error from NetworkManager:<br />
<br />
Connection 'eduroam' is not avialable on device wlan0 because profile is not compatible with device (802.1x connections must have IWD provisioning files)<br />
<br />
This is because NetworkManager can not configure a WPA Enterprise network. Therefore you have to configure it using an iwd config file {{ic|/var/lib/iwd/''essid''.8021x}} like described in [[iwd#WPA Enterprise]].<br />
<br />
== See also ==<br />
<br />
* [https://blogs.gnome.org/dcbw/2015/02/16/networkmanager-for-administrators-part-1/ NetworkManager for Administrators Part 1]<br />
* [[Wikipedia:NetworkManager]]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=NetworkManager&diff=627203NetworkManager2020-07-30T13:15:46Z<p>Tobbebobbe: /* Automatically connect to VNP */ added commands for save and quit, brief explanation</p>
<hr />
<div>[[Category:Network managers]]<br />
[[Category:Red Hat]]<br />
[[cs:NetworkManager]]<br />
[[de:Networkmanager]]<br />
[[es:NetworkManager]]<br />
[[fr:NetworkManager]]<br />
[[it:NetworkManager]]<br />
[[ja:NetworkManager]]<br />
[[pt:NetworkManager]]<br />
[[zh-hans:NetworkManager]]<br />
{{Related articles start}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related articles end}}<br />
[https://wiki.gnome.org/Projects/NetworkManager/ NetworkManager] is a program for providing detection and configuration for systems to automatically connect to networks. NetworkManager's functionality can be useful for both wireless and wired networks. For wireless networks, NetworkManager prefers known wireless networks and has the ability to switch to the most reliable network. NetworkManager-aware applications can switch from online and offline mode. NetworkManager also prefers wired connections over wireless ones, has support for modem connections and certain types of VPN. NetworkManager was originally developed by Red Hat and now is hosted by the [[GNOME]] project.<br />
<br />
{{Expansion|Clear text storage of secrets is not limited to just Wi-Fi passwords. The secrets are stored in files (and folder) only accesible to root.}}<br />
<br />
{{Warning|By default, Wi-Fi passwords are stored in clear text, see [[#Encrypted Wi-Fi passwords]].}}<br />
<br />
== Installation ==<br />
<br />
NetworkManager can be [[install]]ed with the package {{Pkg|networkmanager}}, which contains a daemon, a command line interface ({{ic|nmcli}}) and a curses‐based interface ({{ic|nmtui}}). <br />
<br />
=== Enable NetworkManager ===<br />
<br />
After installation, you should [[start/enable]] {{ic|NetworkManager.service}}. Once the NetworkManager daemon is started, it will automatically connect to any available "system connections" that have already been configured. Any "user connections" or unconfigured connections will need ''nmcli'' or an applet to configure and connect.<br />
<br />
=== Additional interfaces ===<br />
<br />
* {{Pkg|nm-connection-editor}} for a graphical user interface,<br />
* {{Pkg|network-manager-applet}} for a system tray applet ({{ic|nm-applet}}).<br />
<br />
{{Note|You must ensure that no other service that wants to configure the network is running; in fact, multiple networking services will conflict. You can find a list of the currently running services with {{ic|1=systemctl --type=service}} and then [[stop]] them. See [[#Configuration]] to enable the NetworkManager service.}}<br />
<br />
=== Mobile broadband support ===<br />
<br />
[[Install]] {{Pkg|modemmanager}}, {{Pkg|mobile-broadband-provider-info}} and {{Pkg|usb_modeswitch}} packages for mobile broadband connection support. See [[USB 3G Modem#NetworkManager]] for details.<br />
<br />
=== PPPoE / DSL support ===<br />
<br />
[[Install]] {{Pkg|rp-pppoe}} package for PPPoE / DSL connection support. To actually add PPPoE connection, use {{ic|1=nm-connection-editor}} and add new DSL/PPPoE connection.<br />
<br />
=== VPN support ===<br />
<br />
NetworkManager since version 1.16 has native support for [[WireGuard]], all it needs is the {{ic|wireguard}} kernel module. Read the [https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-networkmanager/ WireGuard in NetworkManager blog post] for details.<br />
<br />
Support for other VPN types is based on a plug-in system. They are provided in the following packages:<br />
<br />
* {{Pkg|networkmanager-openconnect}} for [[OpenConnect]]<br />
* [[networkmanager-openvpn]] for [[OpenVPN]]<br />
* {{Pkg|networkmanager-pptp}} for [[PPTP Client]]<br />
* {{Pkg|networkmanager-vpnc}} for [[Vpnc]]<br />
* {{Pkg|networkmanager-strongswan}} for [[strongSwan]]<br />
* {{AUR|networkmanager-fortisslvpn-git}}<br />
* {{AUR|networkmanager-iodine-git}}<br />
* {{AUR|networkmanager-libreswan}}<br />
* {{AUR|networkmanager-l2tp}}<br />
* {{AUR|networkmanager-ssh-git}}<br />
* {{Pkg|network-manager-sstp}}<br />
<br />
{{Warning|1=There are a lot of [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues?search=VPN&state=opened bugs] (and [https://bugzilla.gnome.org/buglist.cgi?bug_status=__open__&content=VPN&product=NetworkManager old bugs]) related to VPN support. Check the daemon processes options set via the GUI correctly and double-check with each package release.}}<br />
<br />
{{Note|To have fully functioning DNS resolution when using VPN, you should set up [[#DNS caching and conditional forwarding|conditional forwarding]].}}<br />
<br />
== Usage ==<br />
<br />
NetworkManager comes with {{man|1|nmcli}} and {{man|1|nmtui}}.<br />
<br />
=== nmcli examples ===<br />
<br />
List nearby wifi networks:<br />
<br />
$ nmcli device wifi list<br />
<br />
Connect to a wifi network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
Connect to a hidden network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' hidden yes<br />
<br />
Connect to a wifi on the {{ic|wlan1}} wifi interface:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' ifname wlan1 ''profile_name''<br />
<br />
Disconnect an interface:<br />
<br />
$ nmcli device disconnect ifname eth0<br />
<br />
Reconnect an interface marked as disconnected:<br />
<br />
$ nmcli connection up uuid ''UUID''<br />
<br />
Get a list of UUIDs:<br />
<br />
$ nmcli connection show<br />
<br />
See a list of network devices and their state:<br />
<br />
$ nmcli device<br />
<br />
Turn off wifi:<br />
<br />
$ nmcli radio wifi off<br />
<br />
=== Edit a connection ===<br />
<br />
For a comprehensive list of settings, see {{man|5|nm-settings}}.<br />
<br />
Firstly you need to get list of connections:<br />
<br />
{{hc|$ nmcli connection|<nowiki><br />
NAME UUID TYPE DEVICE<br />
Wired connection 2 e7054040-a421-3bef-965d-bb7d60b7cecf ethernet enp5s0<br />
Wired connection 1 997f2782-f0fc-301d-bfba-15421a2735d8 ethernet enp0s25<br />
MY-HOME-WIFI-5G 92a0f7b3-2eba-49ab-a899-24d83978f308 wifi --<br />
</nowiki>}}<br />
<br />
Here you can use the first column as connection-id used later. In this example we pick {{ic|Wired connection 2}} as a connection-id.<br />
<br />
You have three methods to configure a connection {{ic|Wired connection 2}} after it has been created:<br />
<br />
; nmcli interactive editor<br />
: {{ic|nmcli connection edit 'Wired connection 2'}}.<br> Usage is well documented from the editor.<br />
<br />
; nmcli command line interface<br />
: {{ic|nmcli connection modify 'Wired connection 2' ''setting''.''property'' ''value''}}. See {{man|1|nmcli}} for usage. For example you can change its IPv4 route metric to 200 using {{ic|nmcli connection modify 'Wired connection 2' ipv4.route-metric 200}} command.<br />
<br />
; Connection file<br />
: In {{ic|/etc/NetworkManager/system-connections/}}, modify the corresponding {{ic|Wired connection 2.nmconnection}} file .<br> Do not forget to reload the configuration file with {{ic|nmcli connection reload}}.<br />
<br />
== Front-ends ==<br />
<br />
To configure and have easy access to NetworkManager, most users will want to install an applet. This GUI front-end usually resides in the system tray (or notification area) and allows network selection and configuration of NetworkManager. Various desktop environments have their own applet. Otherwise you can use [[#nm-applet]].<br />
<br />
=== GNOME ===<br />
<br />
[[GNOME]] has a built-in tool, accessible from the Network settings.<br />
<br />
=== KDE Plasma ===<br />
<br />
[[Install]] the {{Pkg|plasma-nm}} package. After that, add it to the KDE taskbar via the ''Panel options > Add widgets > Networks'' menu.<br />
<br />
=== nm-applet ===<br />
<br />
{{Pkg|network-manager-applet}} is a GTK 3 front-end which works under Xorg environments with a systray.<br />
<br />
To store connection secrets install and configure [[GNOME/Keyring]].<br />
<br />
Be aware that after enabling the tick-box option {{ic|Make available to other users}} for a connection, NetworkManager stores the password in plain-text, though the respective file is accessible only to root (or other users via {{ic|nm-applet}}). See [[#Encrypted Wi-Fi passwords]].<br />
<br />
In order to run {{ic|nm-applet}} without a systray, you can use {{Pkg|trayer}} or {{Pkg|stalonetray}}. For example, you can add a script like this one in your path:<br />
<br />
{{hc|nmgui|<nowiki><br />
#!/bin/sh<br />
nm-applet 2>&1 > /dev/null &<br />
stalonetray 2>&1 > /dev/null<br />
killall nm-applet<br />
</nowiki>}}<br />
<br />
When you close the ''stalonetray'' window, it closes {{ic|nm-applet}} too, so no extra memory is used once you are done with network settings.<br />
<br />
The applet can show notifications for events such as connecting to or disconnecting from a WiFi network. For these notifications to display, ensure that you have a notification server installed - see [[Desktop notifications]]. If you use the applet without a notification server, you might see some messages in stdout/stderr, and the app might hang. See [https://bugzilla.gnome.org/show_bug.cgi?id=788313].<br />
<br />
In order to run {{ic|nm-applet}} with such notifications disabled, start the applet with the following command:<br />
<br />
$ nm-applet --no-agent<br />
<br />
{{Tip|{{ic|nm-applet}} might be started automatically with a [[XDG Autostart|autostart desktop file]], to add the --no-agent option modify the Exec line there, i.e.<br />
<br />
{{bc|1=Exec=nm-applet --no-agent}}<br />
<br />
}}<br />
<br />
{{Warning|On [[i3]], if nm-applet is started with the {{ic|--no-agent}} option, it is not possible to connect to a new encrypted WiFi network by clicking on the item list because no password input dialogue window will pop out. [[journal]] will show {{ic|no secrets: No agents were available for this request}}.}}<br />
<br />
==== Appindicator ====<br />
<br />
As of version 1.18.0 Appindicator support is [https://github.com/archlinux/svntogit-packages/commit/7640a2bd557fe84813207ef4d5e35bb5aece6c54 available] in the official {{Pkg|network-manager-applet}} package. To use nm-applet in an Appindicator environment start the applet with the following command:<br />
<br />
$ nm-applet --indicator<br />
<br />
=== networkmanager-dmenu ===<br />
<br />
Alternatively there is {{AUR|networkmanager-dmenu-git}} which is a small script to manage NetworkManager connections with [[dmenu]] or [[rofi]] instead of {{ic|nm-applet}}. It provides all essential features such as connection to existing NetworkManager wifi or wired connections, connect to new wifi connections, requests passphrase if required, connect to existing VPN connections, enable/disable networking, launch ''nm-connection-editor'' GUI, connect to Bluetooth networks.<br />
<br />
== Configuration ==<br />
<br />
NetworkManager will require some additional steps to be able run properly. Make sure you have configured {{ic|/etc/hosts}} as described in [[Network configuration#Set the hostname]] section.<br />
<br />
NetworkManager has a global configuration file at {{ic|/etc/NetworkManager/NetworkManager.conf}}. Addition configuration files can be placed in {{ic|/etc/NetworkManager/conf.d/}}. Usually no configuration needs to be done to the global defaults.<br />
<br />
After editing a configuration file, the changes can be applied by running:<br />
<br />
# nmcli general reload<br />
<br />
=== Enable NetworkManager Wait Online ===<br />
<br />
{{Out of date|{{ic|NetworkManager.service}} has {{ic|1=Also=NetworkManager-wait-online.service}} in the {{ic|[Install]}} section.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/167e42a87e97ed7fb26a4263c22f1774716ac51b] If {{ic|NetworkManager.service}} was [[enable]]d before the change, it needs to be [[enable|reenabled]].}}<br />
<br />
If you have services which fail if they are started before the network is up, you may use {{ic|NetworkManager-wait-online.service}} in addition to {{ic|NetworkManager.service}}. This is, however, rarely necessary because most networked daemons start up okay, even if the network has not been configured yet.<br />
<br />
In some cases, the service will still fail to start successfully on boot due to the timeout setting in {{ic|/usr/lib/systemd/system/NetworkManager-wait-online.service}} being too short. Change the default timeout from 30 to a higher value.<br />
<br />
=== Set up PolicyKit permissions ===<br />
<br />
See [[General troubleshooting#Session permissions]] for setting up a working session.<br />
<br />
With a working session, you have several options for granting the necessary privileges to NetworkManager:<br />
<br />
* ''Option 1.'' Run a [[Polkit]] authentication agent when you log in, such as {{ic|/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1}} (part of {{Pkg|polkit-gnome}}). You will be prompted for your password whenever you add or remove a network connection.<br />
* ''Option 2.'' [[Users and groups#Group management|Add]] yourself to the {{ic|wheel}} group. You will not have to enter your password, but your user account may be granted other permissions as well, such as the ability to use [[sudo]] without entering the root password.<br />
* ''Option 3.'' [[Users and groups#Group management|Add]] yourself to the {{ic|network}} group and create the following file:<br />
<br />
{{hc|/etc/polkit-1/rules.d/50-org.freedesktop.NetworkManager.rules|<nowiki><br />
polkit.addRule(function(action, subject) {<br />
if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0 && subject.isInGroup("network")) {<br />
return polkit.Result.YES;<br />
}<br />
});<br />
</nowiki>}}<br />
<br />
: All users in the {{ic|network}} group will be able to add and remove networks without a password. This will not work under [[systemd]] if you do not have an active session with ''systemd-logind''.<br />
<br />
=== Proxy settings ===<br />
<br />
NetworkManager does not directly handle proxy settings, but if you are using [[GNOME]] or [[KDE]], you could use [http://marin.jb.free.fr/proxydriver/ proxydriver] which handles proxy settings using NetworkManager's information. proxydriver is found in the package {{AUR|proxydriver}}.<br />
<br />
In order for ''proxydriver'' to be able to change the proxy settings, you would need to execute this command, as part of the GNOME startup process (see [[GNOME#Autostart]]).<br />
<br />
xhost +si:localuser:''username''<br />
<br />
See also [[Proxy settings]].<br />
<br />
=== Checking connectivity ===<br />
<br />
NetworkManager can try to reach a page on Internet when connecting to a network. {{Pkg|networkmanager}} is configured by default in {{ic|/usr/lib/NetworkManager/conf.d/20-connectivity.conf}} to check connectivity to archlinux.org. To use a different webserver or disable connectivity checking create {{ic|/etc/NetworkManager/conf.d/20-connectivity.conf}}, see {{man|5|NetworkManager.conf|CONNECTIVITY SECTION}}. Below is an example of using GNOME servers (it does not require the use of [[GNOME]]):<br />
<br />
{{hc|/etc/NetworkManager/conf.d/20-connectivity.conf|<nowiki><br />
[connectivity]<br />
uri=http://nmcheck.gnome.org/check_network_status.txt<br />
</nowiki>}}<br />
<br />
{{Note|Although automatic connectivity checks are a potential privacy leak, the official archlinux.org default connectivity URL is committed to not logging any access. See [https://gitlab.archlinux.org/archlinux/infrastructure/-/commit/68fbaca2ef9f31f624f117899848f4288d6b39d1].}}<br />
<br />
=== Captive portals ===<br />
<br />
{{Style|Complex scripts should not be maintained on the wiki.}}<br />
<br />
For those behind a [[Wikipedia:Captive portal|captive portal]], the desktop manager may automatically open a window asking for credentials. If your desktop does not, you can use {{Pkg|capnet-assist}} package (however, it currently it has a broken NetworkManager dispatcher script). Alternatively, you can create a NetworkManager dispatcher script with the following content:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/90-open_captive_portal|<nowiki><br />
#!/bin/sh -e<br />
# Script to dispatch NetworkManager events<br />
#<br />
# Runs shows a login webpage on walled garden networks.<br />
# See NetworkManager(8) for further documentation of the dispatcher events.<br />
<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin<br />
<br />
if [ -x "/usr/bin/logger" ]; then<br />
logger="/usr/bin/logger -s -t captive-portal"<br />
else<br />
logger=":"<br />
fi<br />
<br />
wait_for_process() {<br />
PNAME=$1<br />
while [ -z "$(/usr/bin/pgrep $PNAME)" ]; do<br />
sleep 3;<br />
done<br />
}<br />
<br />
#launch the browser, but on boot we need to wait that nm-applet starts<br />
start_browser() {<br />
local user="$1"<br />
local display="$2"<br />
<br />
export DISPLAY="$display"<br />
wait_for_process nm-applet<br />
<br />
export XAUTHORITY="/home/$user/.Xauthority"<br />
<br />
$logger "Running browser as '$user' with display '$display' to login in captive portal"<br />
sudo -u "$user" --preserve-env=DISPLAY,XAUTHORITY -H xdg-open http://capnet.elementary.io 2>&1 > /dev/null<br />
}<br />
<br />
# Run the right scripts<br />
case "$2" in<br />
connectivity-change)<br />
$logger -p user.debug "dispatcher script triggered on connectivity change: $CONNECTIVITY_STATE"<br />
if [ "$CONNECTIVITY_STATE" = "PORTAL" ]; then<br />
# Match last column of who's output with ' :[at least one digit] '<br />
who | awk '$NF ~ /\(:[0-9]+\)/ { print $1 " " substr($NF, 2, length($NF)-2) };' | \<br />
while read user display; do<br />
start_browser $user $display || $logger -p user.err "Failed for user: '$user' display: '$display'"<br />
done<br />
fi<br />
;;<br />
*)<br />
# In a down phase<br />
exit 0<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
You will need to [[restart]] {{ic|NetworkManager.service}} or reboot for this to start working. Once you do, the dispatcher script should open a login window once it detects you are behind a captive portal.<br />
<br />
Another solution is {{AUR|captive-browser-git}} based on Google Chrome.<br />
<br />
=== DHCP client ===<br />
<br />
By default NetworkManager uses its internal DHCP client. The internal DHCPv4 plugin is based on the [https://nettools.github.io/n-dhcp4/ nettools' n-dhcp4] library, while the internal DHCPv6 plugin is made from code based on systemd-networkd.<br />
<br />
To use ISC’s DHCP client, [[install]] {{Pkg|dhclient}}. To change the DHCP client backend, set the option {{ic|1=main.dhcp=''dhcp_client_name''}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}. E.g.:<br />
<br />
{{hc|1=/etc/NetworkManager/conf.d/dhcp-client.conf|2=<br />
[main]<br />
dhcp=dhclient<br />
}}<br />
<br />
{{Note|<br />
* Do not enable the systemd units shipped with the {{Pkg|dhclient}} and {{Pkg|dhcpcd}} packages. They will conflict with NetworkManager, see the note in [[#Installation]] for details.<br />
* NetworkManger does not support dhcpcd ≥ 9.0.0. See {{Bug|66231}}.<br />
}}<br />
<br />
=== DNS management ===<br />
<br />
NetworkManager's DNS management is described in the GNOME project's wiki page—[https://wiki.gnome.org/Projects/NetworkManager/DNS Projects/NetworkManager/DNS].<br />
<br />
==== DNS caching and conditional forwarding ====<br />
<br />
NetworkManager has a plugin to enable DNS caching and conditional forwarding ([https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/143 previously] called "split DNS" in NetworkManager's documentation) using [[dnsmasq]] or [[systemd-resolved]]. The advantages of this setup is that DNS lookups will be cached, shortening resolve times, and DNS lookups of VPN hosts will be routed to the relevant VPN's DNS servers. This is especially useful if you are connected to more than one VPN.<br />
<br />
===== dnsmasq =====<br />
<br />
Make sure {{Pkg|dnsmasq}} has been installed. Then set {{ic|1=main.dns=dnsmasq}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=dnsmasq<br />
}}<br />
<br />
Now run {{ic|nmcli general reload}} as root. NetworkManager will automatically start dnsmasq and add {{ic|127.0.0.1}} to {{ic|/etc/resolv.conf}}. The original DNS servers can be found in {{ic|/run/NetworkManager/no-stub-resolv.conf}}. You can verify dnsmasq is being used by doing the same DNS lookup twice with {{ic|drill example.com}} and verifying the server and query times.<br />
<br />
{{Note|<br />
* You do not need to start {{ic|dnsmasq.service}} or edit {{ic|/etc/dnsmasq.conf}}. NetworkManager will start dnsmasq without using the systemd service and without reading the dnsmasq's default configuration file(s).<br />
* The dnsmasq instance started by NetworkManager will bind to {{ic|127.0.0.1:53}}, you cannot run any other software (including {{ic|dnsmasq.service}}) on the same address and port.<br />
}}<br />
<br />
====== Custom dnsmasq configuration ======<br />
<br />
Custom configurations can be created for ''dnsmasq'' by creating configuration files in {{ic|/etc/NetworkManager/dnsmasq.d/}}. For example, to change the size of the DNS cache (which is stored in RAM):<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/cache.conf|2=<br />
cache-size=1000<br />
}}<br />
<br />
{{Tip|Check the configuration file syntax with {{ic|1=dnsmasq --test --conf-file=/dev/null --conf-dir=/etc/NetworkManager/dnsmasq.d}}.}}<br />
<br />
See {{man|8|dnsmasq}} for all available options.<br />
<br />
====== IPv6 ======<br />
<br />
{{Accuracy|This does not solve the issue because NetworkManager does not add {{ic|::1}} to {{ic|/etc/resolv.conf}}. Unless {{ic|@::1}} is manually passed to drill, it will still fail with {{ic|Error: error sending query: No (valid) nameservers defined in the resolver}}.}}<br />
<br />
Enabling {{ic|dnsmasq}} in NetworkManager may break IPv6-only DNS lookups (i.e. {{ic|drill -6 [hostname]}}) which would otherwise work. In order to resolve this, creating the following file will configure ''dnsmasq'' to also listen to the IPv6 loopback:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/ipv6-listen.conf|2=<br />
listen-address=::1<br />
}}<br />
<br />
In addition, {{ic|dnsmasq}} also does not prioritize upstream IPv6 DNS. Unfortunately NetworkManager does not do this ([https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/936712 Ubuntu Bug]). A workaround would be to disable IPv4 DNS in the NetworkManager config, assuming one exists<br />
<br />
====== DNSSEC ======<br />
<br />
The dnsmasq instance started by NetworkManager by default will not validate [[DNSSEC]] since it is started with the {{ic|--proxy-dnssec}} option. It will trust whatever DNSSEC information it gets from the upstream DNS server.<br />
<br />
For dnsmasq to properly validate DNSSEC, thus breaking DNS resolution with name servers that do not support it, create the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/dnssec.conf|2=<br />
conf-file=/usr/share/dnsmasq/trust-anchors.conf<br />
dnssec<br />
}}<br />
<br />
===== systemd-resolved =====<br />
<br />
{{Expansion|NetworkManager 1.16 adds a new setting {{ic|main.systemd-resolved}}[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383] (enabled by default). It unconditionally sends DNS configuration to systemd-resolved. Related to "Preserving resolv.conf" from [[systemd-resolved#DNS]]?}}<br />
<br />
NetworkManager can use [[systemd-resolved]] as a DNS resolver and cache. Make sure that ''systemd-resolved'' is properly configured and that {{ic|systemd-resolved.service}} is [[started]] before using it.<br />
<br />
systemd-resolved will be used automatically if {{ic|/etc/resolv.conf}} is a [[Systemd-resolved#DNS|symlink]] to {{ic|/run/systemd/resolve/stub-resolv.conf}}, {{ic|/run/systemd/resolve/resolv.conf}} or {{ic|/usr/lib/systemd/resolv.conf}}.<br />
<br />
You can enable it explicitly by setting {{ic|1=main.dns=systemd-resolved}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=systemd-resolved<br />
}}<br />
<br />
===== DNS resolver with an openresolv subscriber =====<br />
<br />
If [[openresolv]] has a subscriber for your local [[DNS resolver]], set up the subscriber and [[#Use openresolv|configure NetworkManager to use openresolv]].<br />
<br />
Because NetworkManager advertises a single "interface" to ''resolvconf'', it is not possible to implement conditional forwarding between two NetworkManager connections. See [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 NetworkManager issue 153].<br />
<br />
This can be partially mitigated if you set {{ic|1=private="*"}} in {{ic|/etc/resolvconf.conf}}[https://roy.marples.name/projects/openresolv/configuration.html]. Any queries for domains that are not in search domain list will not get forwarded. They will be handled according to the local resolver's configuration, for example, forwarded to another DNS server or resolved recursively from the DNS root.<br />
<br />
==== Custom DNS servers ====<br />
<br />
===== Setting custom global DNS servers =====<br />
<br />
To set DNS servers for all connections, specify them in {{man|5|NetworkManager.conf}} using the syntax {{ic|1=servers=''serveripaddress1'',''serveripaddress2'',''serveripaddress3''}} in a section named {{ic|[global-dns-domain-*]}}. For example:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns-servers.conf|2=<br />
[global-dns-domain-*]<br />
servers=::1,127.0.0.1<br />
}}<br />
<br />
{{Note|<br />
* If you use [[#DNS caching and conditional forwarding|NetworkManager's dnsmasq or systemd-resolved plugin]] or [[#DNS resolver with an openresolv subscriber|openresolv subscribers]], then do not specify loopback addresses with the {{ic|1=servers=}} option, it can break DNS resolution.<br />
* The specified servers do not get sent to [[systemd-resolved]], the connection's DNS servers are used instead.<br />
}}<br />
<br />
===== Setting custom DNS servers in a connection =====<br />
<br />
====== Setting custom DNS servers in a connection (GUI) ======<br />
<br />
Setup will depend on the type of front-end used; the process usually involves right-clicking on the applet, editing (or creating) a profile, and then choosing DHCP type as ''Automatic (specify addresses)''. The DNS addresses will need to be entered and are usually in this form: {{ic|127.0.0.1, ''DNS-server-one'', ...}}.<br />
<br />
====== Setting custom DNS servers in a connection (nmcli / connection file) ======<br />
<br />
To setup DNS Servers per connection, you can use the {{ic|dns}} field (and the associated {{ic|dns-search}} and {{ic|dns-options}}) in the [[#Edit a connection|connection settings]]. <br />
<br />
If {{ic|method}} is set to {{ic|auto}} (when you use DHCP), you need to set {{ic|ignore-auto-dns}} to {{ic|yes}}.<br />
<br />
==== /etc/resolv.conf ====<br />
<br />
By default {{ic|/etc/resolv.conf}} is managed by ''NetworkManager'' unless it is a symlink.<br />
<br />
It can be configured to write it through [[#Use openresolv|openresolv]] or to [[#Unmanaged /etc/resolv.conf|not touch it at all]].<br />
<br />
Using openresolv allows NetworkManager to coexists with other ''resolvconf'' supporting software or, for example, to run a local DNS caching and split-DNS resolver for which openresolv has a [[openresolv#Subscribers|subscriber]].<br />
<br />
{{Note|Conditional forwarding is [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 not yet fully supported] when using NetworkManager with openresolv.}}<br />
<br />
''NetworkManager'' also offers hooks via so called dispatcher scripts that can be used to alter the {{ic|/etc/resolv.conf}} after network changes. See [[#Network services with NetworkManager dispatcher]] and {{man|8|NetworkManager}} for more information.<br />
<br />
{{Note|<br />
* If NetworkManager is configured to use either [[#dnsmasq|dnsmasq]] or [[#systemd-resolved|systemd-resolved]], then the appropriate loopback addresses will be written to {{ic|/etc/resolv.conf}}.<br />
* The {{ic|resolv.conf}} file NetworkManager writes or would write to {{ic|/etc/resolv.conf}} can be found at {{ic|/run/NetworkManager/resolv.conf}}.<br />
* A {{ic|resolv.conf}} file with the acquired name servers and search domains can be found at {{ic|/run/NetworkManager/no-stub-resolv.conf}}.<br />
}}<br />
<br />
===== Unmanaged /etc/resolv.conf =====<br />
<br />
To stop NetworkManager from touching {{ic|/etc/resolv.conf}}, set {{ic|1=main.dns=none}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=none<br />
}}<br />
<br />
{{Tip|You might also want to set {{ic|1=main.systemd-resolved=false}}, so that NetworkManager does not send the DNS configuration to [[systemd-resolved]].}}<br />
<br />
{{Note|See [[#DNS caching and conditional forwarding]], to configure NetworkManager using other DNS backends like [[dnsmasq]] and [[systemd-resolved]], instead of using {{ic|1=main.dns=none}}.}}<br />
<br />
After that {{ic|/etc/resolv.conf}} might be a broken symlink that you will need to remove. Then, just create a new {{ic|/etc/resolv.conf}} file.<br />
<br />
===== Use openresolv =====<br />
<br />
{{Note|Do not set {{ic|1=rc-manager=resolvconf}} when {{Pkg|systemd-resolvconf}} is installed. ''systemd-resolved'' provides limited support for the ''resolvconf'' interface and NetworkManager supports communicating with systemd-resolved through D-Bus without using ''resolvconf''.}}<br />
<br />
To configure NetworkManager to use [[openresolv]], set {{ic|1=main.rc-manager=resolvconf}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/rc-manager.conf|2=<br />
[main]<br />
rc-manager=resolvconf<br />
}}<br />
<br />
=== Firewall ===<br />
<br />
You can assign a [[firewalld]] zone based on your current connection. For example a restrictive firewall when at work, and a less restrictive one when at home.<br />
<br />
This can also be done with [[#Network services with NetworkManager dispatcher|NetworkManager dispatcher]].<br />
<br />
=== 802.1x / PEAP configuration ===<br />
<br />
A PEAP and 802.1x network can be added by adding a config file to {{ic|/etc/NetworkManager/system-connections/''name''}}.<br />
<br />
Here is an example configuration file for IPv4 with IPv6 disabled:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''name''|2=<br />
[ipv6]<br />
method=ignore<br />
<br />
[ipv4]<br />
method=auto<br />
<br />
[connection]<br />
#id=XXXXXXXXX<br />
#uuid=XXXXXXXXX<br />
type=802-11-wireless<br />
#timestamp=XXXX<br />
<br />
[802-11-wireless-security]<br />
key-mgmt=wpa-eap<br />
<br />
[802-11-wireless]<br />
ssid=ssid<br />
mode=infrastructure<br />
#seen-bssids=XXXXXXXXX<br />
security=802-11-wireless-security<br />
<br />
[802-1x]<br />
eap=peap;<br />
identity=user<br />
password=password<br />
phase2-auth=mschapv2<br />
}}<br />
<br />
The number sign (#) defines comments.<br />
<br />
=== Automatically connect to VNP ===<br />
<br />
NetworkManager can be set to automatically connect to a VPN when connecting to the internet, on a per network basis. The VPN connection itself can be added in the Gnome gui, but to make it automatically use the VPN {{ic|nmcli}} must be used.<br />
<br />
First, make sure to make the VPN connection available to all users. In the Gnome gui this is a matter of checking a box under the {{ic|details}} tab. Then under the {{ic|Identity}} tab, in the password field, click the icon on the right side in the field, and set it to {{ic|Store the password for all users}}.<br />
<br />
Then use the {{ic|nmcli}} tool via command line:<br />
<br />
# nmcli connection<br />
<br />
To list your connections. Then enter configuration mode for the internet connection you want to automatically connect to a VPN<br />
<br />
# nmcli connection edit <NAME of Internet Connection><br />
<br />
Please note that it is the Internet connection and not the VPN you should edit. Here you do not need to use the UUID of the Internet connection, the NAME is fine. Then make the setting with the command:<br />
<br />
# set connection.secondaries <UUID of VPN><br />
<br />
Here the UUID of the VPN must be used, but {{ic|tab}} works for autocompletion.<br />
<br />
Finally save and quit:<br />
<br />
# save<br />
# quit<br />
<br />
Now when NetworkManager is restarted and you connect to the Internet connection you have configured, you should automatically get connected to the VPN.<br />
<br />
== Network services with NetworkManager dispatcher ==<br />
<br />
There are quite a few network services that you will not want running until NetworkManager brings up an interface. NetworkManager has the ability to start services when you connect to a network and stop them when you disconnect (e.g. when using [[NFS]], [[SMB]] and [[NTPd]]).<br />
<br />
To activate the feature you need to [[enable]] and [[start]] the {{ic|NetworkManager-dispatcher.service}}.<br />
<br />
Once the service is active, scripts can be added to the {{ic|/etc/NetworkManager/dispatcher.d}} directory.<br />
<br />
Scripts must be owned by '''root''', otherwise the dispatcher will not execute them. For added security, set group [[ownership]] to root as well:<br />
<br />
# chown root:root /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
Make sure the file has correct permissions:<br />
<br />
# chmod 755 /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
The scripts will be run in alphabetical order at connection time, and in reverse alphabetical order at disconnect time. To ensure what order they come up in, it is common to use numerical characters prior to the name of the script (e.g. {{ic|10-portmap}} or {{ic|30-netfs}} (which ensures that the ''portmapper'' is up before NFS mounts are attempted).<br />
<br />
Scripts will receive the following arguments:<br />
<br />
* '''Interface name:''' e.g. {{ic|eth0}}<br />
* '''Interface status:''' ''up'' or ''down''<br />
* '''VPN status:''' ''vpn-up'' or ''vpn-down''<br />
<br />
{{Warning|If you connect to foreign or public networks, be aware of what services you are starting and what servers you expect to be available for them to connect to. You could make a security hole by starting the wrong services while connected to a public network.}}<br />
<br />
=== Avoiding the dispatcher timeout ===<br />
<br />
If the above is working, then this section is not relevant. However, there is a general problem related to running dispatcher scripts which take longer to be executed. Initially an internal timeout of three seconds only was used. If the called script did not complete in time, it was killed. Later the timeout was extended to about 20 seconds (see the [https://bugzilla.redhat.com/show_bug.cgi?id=982734 Bugtracker] for more information). If the timeout still creates the problem, a work around may be to modify the dispatcher service file {{ic|/usr/lib/systemd/system/NetworkManager-dispatcher.service}} to remain active after exit: <br />
<br />
{{hc|/etc/systemd/system/NetworkManager-dispatcher.service.d/remain_after_exit.conf|2=<br />
[Service]<br />
RemainAfterExit=yes<br />
}}<br />
<br />
Now start and enable the modified {{ic|NetworkManager-dispatcher}} service.<br />
<br />
{{Warning|Adding the {{ic|RemainAfterExit}} line to it will prevent the dispatcher from closing. Unfortunately, the dispatcher '''has''' to close before it can run your scripts again. With it the dispatcher will not time out but it also will not close, which means that the scripts will only run once per boot. Therefore, do not add the line unless the timeout is definitely causing a problem.}}<br />
<br />
=== Dispatcher examples ===<br />
<br />
==== Mount remote folder with sshfs ====<br />
<br />
As the script is run in a very restrictive environment, you have to export {{ic|SSH_AUTH_SOCK}} in order to connect to your SSH agent. There are different ways to accomplish this, see [https://bbs.archlinux.org/viewtopic.php?pid=1042030#p1042030 this message] for more information. The example below works with [[GNOME Keyring]], and will ask you for the password if not unlocked already. In case NetworkManager connects automatically on login, it is likely ''gnome-keyring'' has not yet started and the export will fail (hence the sleep). The {{ic|UUID}} to match can be found with the command {{ic|nmcli connection status}} or {{ic|nmcli connection list}}. <br />
<br />
{{bc|<nowiki><br />
#!/bin/sh<br />
USER='username'<br />
REMOTE='user@host:/remote/path'<br />
LOCAL='/local/path'<br />
<br />
interface=$1 status=$2<br />
if [ "$CONNECTION_UUID" = "</nowiki>''uuid''<nowiki>" ]; then<br />
case $status in<br />
up)<br />
SSH_AUTH_SOCK=$(find /tmp -maxdepth 1 -type s -user "$USER" -name 'ssh')<br />
export SSH_AUTH_SOCK<br />
su "$USER" -c "sshfs $REMOTE $LOCAL"<br />
;;<br />
down)<br />
fusermount -u "$LOCAL"<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
==== Mounting of SMB shares ====<br />
<br />
Some [[SMB]] shares are only available on certain networks or locations (e.g. at home). You can use the dispatcher to only mount SMB shares that are present at your current location.<br />
<br />
The following script will check if we connected to a specific network and mount shares accordingly:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-mount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
# Find the connection UUID with "nmcli connection show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
if [ "$2" = "up" ]; then<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
mount /your/mount/point & <br />
# add more shares as needed<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The following script will unmount all SMB shares before a software initiated disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/pre-down.d/30-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|Make sure this script is located in the {{ic|pre-down.d}} sub-directory as shown above, otherwise it will unmount all shares on any connection state change.}}<br />
<br />
The following script will attempt to unmount all SMB shares following an unexpected disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/40-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
if [ "$2" = "down" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|<br />
* Since NetworkManager 0.9.8, the ''pre-down'' and ''down'' events are not executed on shutdown or restart, see [https://bugzilla.gnome.org/show_bug.cgi?id&#61;701242 this bug report] for more info.<br />
* The previous ''umount'' scripts are still prone to leaving applications actually accessing the mount to 'hang'.<br />
}}<br />
<br />
An alternative is to use the script as seen in [[NFS#Using a NetworkManager dispatcher]]:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-smb.sh|<nowiki><br />
#!/bin/bash<br />
<br />
# Find the connection UUID with "nmcli con show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
WANTED_CON_UUID="CHANGE-ME-NOW-9c7eff15-010a-4b1c-a786-9b4efa218ba9"<br />
<br />
if [[ "$CONNECTION_UUID" == "$WANTED_CON_UUID" ]]; then<br />
<br />
# Script parameter $1: NetworkManager connection name, not used<br />
# Script parameter $2: dispatched event<br />
<br />
case "$2" in<br />
"up")<br />
mount -a -t cifs<br />
;;<br />
"pre-down");&<br />
"vpn-pre-down")<br />
umount -l -a -t cifs >/dev/null<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|This script ignores mounts with the {{ic|noauto}} option, remove this mount option or use {{ic|auto}} to allow the dispatcher to manage these mounts.}}<br />
<br />
Create a symlink inside {{ic|/etc/NetworkManager/dispatcher.d/pre-down/}} to catch the {{ic|pre-down}} events:<br />
<br />
# ln -s ../30-smb.sh /etc/NetworkManager/dispatcher.d/pre-down.d/30-smb.sh<br />
<br />
==== Mounting of NFS shares ====<br />
<br />
See [[NFS#Using a NetworkManager dispatcher]].<br />
<br />
==== Use dispatcher to automatically toggle wireless depending on LAN cable being plugged in ====<br />
<br />
The idea is to only turn Wi-Fi on when the LAN cable is unplugged (for example when detaching from a laptop dock), and for Wi-Fi to be automatically disabled, once a LAN cable is plugged in again. <br />
<br />
Create the following dispatcher script[https://superuser.com/questions/233448/disable-wlan-if-wired-cable-network-is-available], replacing {{ic|1=LAN_interface}} with yours.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/wlan_auto_toggle.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$1" = "LAN_interface" ]; then<br />
case "$2" in<br />
up)<br />
nmcli radio wifi off<br />
;;<br />
down)<br />
nmcli radio wifi on<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|You can get a list of interfaces using [[#nmcli examples|nmcli]]. The ethernet (LAN) interfaces start with {{ic|en}}, e.g. {{ic|1=enp0s5}}}}<br />
<br />
==== Use dispatcher to connect to a VPN after a network connection is established ====<br />
<br />
In this example we want to connect automatically to a previously defined VPN connection after connecting to a specific Wi-Fi network. First thing to do is to create the dispatcher script that defines what to do after we are connected to the network.<br />
<br />
{{Note|This script will require {{Pkg|wireless_tools}} in order to use {{ic|iwgetid}}.}}<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME"<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you would like to attempt to automatically connect to VPN for all Wi-Fi networks, you can use the following definition of the ESSID: {{ic|1=ESSID=$(iwgetid -r)}}. Remember to set the script's permissions [[#Network services with NetworkManager dispatcher|accordingly]]. <br />
<br />
Trying to connect with the above script may still fail with {{ic|NetworkManager-dispatcher.service}} complaining about 'no valid VPN secrets', because of [https://developer.gnome.org/NetworkManager/0.9/secrets-flags.html the way VPN secrets are stored]. Fortunately, there are different options to give the above script access to your VPN password.<br />
<br />
1: One of them requires editing the VPN connection configuration file to make NetworkManager store the secrets by itself rather than inside a keyring [https://bugzilla.redhat.com/show_bug.cgi?id=710552 that will be inaccessible for root]: open up {{ic|/etc/NetworkManager/system-connections/''name of your VPN connection''}} and change the {{ic|password-flags}} and {{ic|secret-flags}} from {{ic|1}} to {{ic|0}}.<br />
<br />
If that alone does not work, you may have to create a {{ic|passwd-file}} in a safe location with the same permissions and ownership as the dispatcher script, containing the following:<br />
<br />
{{hc|/path/to/passwd-file|<br />
vpn.secrets.password:YOUR_PASSWORD<br />
}}<br />
<br />
The script must be changed accordingly, so that it gets the password from the file:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME" passwd-file /path/to/passwd-file<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
2: Alternatively, change the {{ic|password-flags}} and put the password directly in the configuration file adding the section {{ic|vpn-secrets}}:<br />
<br />
[vpn]<br />
....<br />
password-flags=0<br />
<br />
[vpn-secrets]<br />
password=''your_password''<br />
<br />
{{Note|It may now be necessary to re-open the NetworkManager connection editor and save the VPN passwords/secrets again.}}<br />
<br />
==== Use dispatcher to disable IPv6 on VPN provider connections ====<br />
<br />
Many [[:Category:VPN providers|commercial VPN providers]] support only IPv4. That means all IPv6 traffic bypasses the VPN and renders it virtually useless. To avoid this, dispatcher can be used to disable all IPv6 traffic for the time a VPN connection is up.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/10-vpn-ipv6|<nowiki><br />
#!/bin/sh<br />
<br />
case "$2" in<br />
vpn-up)<br />
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
vpn-down)<br />
echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
==== OpenNTPD ====<br />
<br />
See [[OpenNTPD#Using NetworkManager dispatcher]].<br />
<br />
== Testing ==<br />
<br />
NetworkManager applets are designed to load upon login so no further configuration should be necessary for most users. If you have already disabled your previous network settings and disconnected from your network, you can now test if NetworkManager will work. The first step is to [[start]] {{ic|NetworkManager.service}}.<br />
<br />
Some applets will provide you with a {{ic|.desktop}} file so that the NetworkManager applet can be loaded through the application menu. If it does not, you are going to either have to discover the command to use or logout and login again to start the applet. Once the applet is started, it will likely begin polling network connections with for auto-configuration with a DHCP server.<br />
<br />
To start the GNOME applet in non-xdg-compliant window managers like [[awesome]]:<br />
<br />
nm-applet --sm-disable &<br />
<br />
For static IP addresses, you will have to configure NetworkManager to understand them. The process usually involves right-clicking the applet and selecting something like 'Edit Connections'.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Encrypted Wi-Fi passwords ===<br />
<br />
By default, NetworkManager stores passwords in clear text in the connection files at {{ic|/etc/NetworkManager/system-connections/}}. To print the stored passwords, use the following command:<br />
<br />
# grep -r '^psk=' /etc/NetworkManager/system-connections/<br />
<br />
The passwords are accessible to the root user in the filesystem and to users with access to settings via the GUI (e.g. {{ic|nm-applet}}). <br />
<br />
It is preferable to save the passwords in encrypted form in a keyring instead of clear text. The downside of using a keyring is that the connections have to be set up for each user.<br />
<br />
==== Using GNOME Keyring ====<br />
<br />
The keyring daemon has to be started and the keyring needs to be unlocked for the following to work.<br />
<br />
Furthermore, NetworkManager needs to be configured not to store the password for all users. Using GNOME {{ic|nm-applet}}, run {{ic|nm-connection-editor}} from a terminal, select a network connection, click {{ic|Edit}}, select the {{ic|Wifi-Security}} tab and click on the right icon of password and check {{ic|Store the password only for this user}}.<br />
<br />
==== Using KDE Wallet ====<br />
<br />
Using KDE's {{Pkg|plasma-nm}}, click the applet, click on the top right {{ic|Settings}} icon, click on a network connection, in the {{ic|General settings}} tab, untick {{ic|all users may connect to this network}}. If the option is ticked, the passwords will still be stored in clear text, even if a keyring daemon is running.<br />
<br />
If the option was selected previously and you un-tick it, you may have to use the {{ic|reset}} option first to make the password disappear from the file. Alternatively, delete the connection first and set it up again.<br />
<br />
=== Sharing internet connection over Wi-Fi ===<br />
<br />
You can share your internet connection (e.g. 3G or wired) with a few clicks. Please note that a [[firewall]] may interfere with internet sharing.<br />
<br />
You will need a Wi-Fi card which supports AP mode, see [[Software access point#Wi-Fi device must support AP mode]] for details.<br />
<br />
[[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
<br />
Create the shared connection:<br />
<br />
* Click on applet and choose ''Create new wireless network''.<br />
* Follow wizard (choose WPA2 or higher, be sure to use at least 8 character long password, lower lengths will fail).<br />
** Choose either [[Fedora:Features/RealHotspot|Hotspot]] or Ad-hoc as Wi-Fi mode.<br />
<br />
The connection will be saved and remain stored for the next time you need it.<br />
<br />
{{Note|Android does not support connecting to Ad-hoc networks. To share a connection with Android use infrastructure mode (i.e. set Wi-Fi mode to "Hotspot").}}<br />
<br />
=== Sharing internet connection over Ethernet ===<br />
<br />
Scenario: your device has internet connection over wi-fi and you want to share the internet connection to other devices over ethernet.<br />
<br />
Requirements:<br />
<br />
* [[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
* Your internet connected device and the other devices are connected over a suitable ethernet cable (this usually means a cross over cable or a switch in between).<br />
* Internet sharing is not blocked by a [[firewall]].<br />
<br />
Steps:<br />
<br />
{{Style|{{Pkg|nm-connection-editor}} is not a dependency of {{Pkg|networkmanager}} and needs to be installed separately.}}<br />
<br />
* Run {{ic|nm-connection-editor}} from terminal.<br />
* Add a new ethernet connection.<br />
* Give it some sensible name. For example "Shared Internet"<br />
* Go to "IPv4 Settings".<br />
* For "Method:" select "Shared to other computers".<br />
* Save<br />
<br />
Now you should have a new option "Shared Internet" under the Wired connections in NetworkManager.<br />
<br />
=== Checking if networking is up inside a cron job or script ===<br />
<br />
{{Out of date|''nm-tool'' was remove from NetworkManager for long time now[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/bb8c75bd536d4f8fb80a4366025a279078f0ec81]. ''nmcli'' should be used instead.}}<br />
<br />
Some ''cron'' jobs require networking to be up to succeed. You may wish to avoid running these jobs when the network is down. To accomplish this, add an '''if''' test for networking that queries NetworkManager's ''nm-tool'' and checks the state of networking. The test shown here succeeds if any interface is up, and fails if they are all down. This is convenient for laptops that might be hardwired, might be on wireless, or might be off the network.<br />
<br />
{{bc|<nowiki><br />
if [ $(nm-tool|grep State|cut -f2 -d' ') == "connected" ]; then<br />
#Whatever you want to do if the network is online<br />
else<br />
#Whatever you want to do if the network is offline - note, this and the else above are optional<br />
fi<br />
</nowiki>}}<br />
<br />
This useful for a {{ic|cron.hourly}} script that runs ''fpupdate'' for the F-Prot virus scanner signature update, as an example. Another way it might be useful, with a little modification, is to differentiate between networks using various parts of the output from ''nm-tool''; for example, since the active wireless network is denoted with an asterisk, you could grep for the network name and then grep for a literal asterisk.<br />
<br />
=== Connect to network with secret on boot ===<br />
<br />
By default, NetworkManager will not connect to networks requiring a secret automatically on boot. This is because it locks such connections to the user who makes it by default, only connecting after they have logged in. To change this, do the following:<br />
<br />
# Right click on the {{ic|nm-applet}} icon in your panel and select Edit Connections and open the Wireless tab<br />
# Select the connection you want to work with and click the Edit button<br />
# Check the boxes “Connect Automatically” and “Available to all users”<br />
# Additionally, ensure that under "Wi-Fi Security", "Store password for all users (not encrypted)" is selected<br />
<br />
Log out and log back in to complete.<br />
<br />
=== OpenConnect with password in KWallet ===<br />
<br />
While you may type both values at connection time, {{Pkg|plasma-nm}} 0.9.3.2-1 and above are capable of retrieving OpenConnect username and password directly from [[KWallet]].<br />
<br />
Open "KDE Wallet Manager" and look up your OpenConnect VPN connection under "Network Management|Maps". Click "Show values" and <br />
enter your credentials in key "VpnSecrets" in this form (replace ''username'' and ''password'' accordingly):<br />
<br />
form:main:username%SEP%''username''%SEP%form:main:password%SEP%''password''<br />
<br />
Next time you connect, username and password should appear in the "VPN secrets" dialog box.<br />
<br />
=== Ignore specific devices ===<br />
<br />
Sometimes it may be desired that NetworkManager ignores specific devices and does not try to configure addresses and routes for them. You can quickly and easily ignore devices by MAC or interface-name by using the following in {{ic|/etc/NetworkManager/conf.d/unmanaged.conf}}:<br />
<br />
[keyfile]<br />
unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth0<br />
<br />
After editing the file, run {{ic|nmcli general reload}} as root. Afterwards you should be able to configure interfaces without NetworkManager altering what you have set.<br />
<br />
=== Configuring MAC address randomization ===<br />
<br />
{{Note|1=Disabling MAC address randomization may be needed to get (stable) link connection [https://bbs.archlinux.org/viewtopic.php?id=220101] and/or networks that restrict devices based on their MAC Address or have a limit network capacity.}}<br />
<br />
MAC randomization can be used for increased privacy by not disclosing your real MAC address to the network.<br />
<br />
NetworkManager supports two types MAC Address Randomization: randomization during scanning, and for network connections. Both modes can be configured by modifying {{ic|/etc/NetworkManager/NetworkManager.conf}} or by creating a separate configuration file in {{ic|/etc/NetworkManager/conf.d/}} which is recommended since the aforementioned config file may be overwritten by NetworkManager.<br />
<br />
Randomization during Wi-Fi scanning is enabled by default, but it may be disabled by adding the following lines to {{ic|/etc/NetworkManager/NetworkManager.conf}} or a dedicated configuration file under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device]<br />
wifi.scan-rand-mac-address=no<br />
}}<br />
<br />
MAC randomization for network connections can be set to different modes for both wireless and ethernet interfaces. See the [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details on the different modes. <br />
<br />
In terms of MAC randomization the most important modes are {{ic|stable}} and {{ic|random}}. {{ic|stable}} generates a random MAC address when you connect to a new network and associates the two permanently. This means that you will use the same MAC address every time you connect to that network. In contrast, {{ic|random}} will generate a new MAC address every time you connect to a network, new or previously known. You can configure the MAC randomization by adding the desired configuration under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device-mac-randomization]<br />
# "yes" is already the default for scanning<br />
wifi.scan-rand-mac-address=yes<br />
<br />
[connection-mac-randomization]<br />
# Randomize MAC for every ethernet connection<br />
ethernet.cloned-mac-address=random<br />
# Generate a random MAC for each WiFi and associate the two permanently.<br />
wifi.cloned-mac-address=stable<br />
}}<br />
<br />
See the following [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details.<br />
<br />
=== Enable IPv6 Privacy Extensions ===<br />
<br />
See [[IPv6#NetworkManager]].<br />
<br />
=== Working with wired connections ===<br />
<br />
By default, NetworkManager generates a connection profile for each wired ethernet connection it finds. At the point when generating the connection, it does not know whether there will be more ethernet adapters available. Hence, it calls the first wired connection "Wired connection 1". You can avoid generating this connection, by configuring {{ic|no-auto-default}} (see {{man|5|NetworkManager.conf}}), or by simply deleting it. Then NetworkManager will remember not to generate a connection for this interface again.<br />
<br />
You can also edit the connection (and persist it to disk) or delete it. NetworkManager will not re-generate a new connection. Then you can change the name to whatever you want. You can use something like nm-connection-editor for this task.<br />
<br />
=== Using iwd as the Wi-Fi backend ===<br />
<br />
Install {{AUR|networkmanager-iwd}} or enable the experimental [[iwd]] backend creating the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_backend.conf|2=<br />
[device]<br />
wifi.backend=iwd<br />
}}<br />
<br />
=== Running in a network namespace ===<br />
<br />
If you would like to run NetworkManager inside a network namespace (e.g., to manage a specific device which should be use by selected applications), bring the device down before moving it to the namespace:<br />
<br />
$ ip link set dev ''MY_DEVICE'' down<br />
$ ip link set dev ''MY_DEVICE'' netns ''MY_NAMESPACE''<br />
$ ip netns exec ''MY_NAMESPACE'' NetworkManager<br />
...<br />
$ ip netns exec ''MY_NAMESPACE'' killall NetworkManager<br />
<br />
otherwise NetworkManager will later fail to establish the connection with a {{ic|device is strictly unmanaged}} error.<br />
<br />
== Troubleshooting ==<br />
<br />
=== No prompt for password of secured Wi-Fi networks ===<br />
<br />
When trying to connect to a secured Wi-Fi network, no prompt for a password is shown and no connection is established. This happens when no keyring package is installed. An easy solution is to install {{Pkg|gnome-keyring}}. If you want the passwords to be stored in encrypted form, follow [[GNOME Keyring]] to set up the ''gnome-keyring-daemon''.<br />
<br />
=== Network management disabled ===<br />
<br />
When NetworkManager shuts down but the pid (state) file is not removed, you will see a {{ic|Network management disabled}} message. If this happens, remove the file manually:<br />
<br />
# rm /var/lib/NetworkManager/NetworkManager.state<br />
<br />
=== Problems with internal DHCP client ===<br />
<br />
If you have problems with getting an IP address using the internal DHCP client, consider using another DHCP client, see [[#DHCP client]] for instructions. This workaround might solve problems in big wireless networks like eduroam.<br />
<br />
=== DHCP problems with dhclient ===<br />
<br />
If you have problems with getting an IP address via DHCP, try to add the following to your {{ic|/etc/dhclient.conf}}:<br />
<br />
interface "eth0" {<br />
send dhcp-client-identifier 01:''aa:bb:cc:dd:ee:ff'';<br />
}<br />
<br />
Where {{ic|''aa:bb:cc:dd:ee:ff''}} is the MAC address of this NIC. The MAC address can be found using the {{ic|ip link show ''interface''}} command from the {{Pkg|iproute2}} package.<br />
<br />
=== 3G modem not detected ===<br />
<br />
See [[USB 3G Modem#NetworkManager]].<br />
<br />
=== Switching off WLAN on laptops ===<br />
<br />
Sometimes NetworkManager will not work when you disable your Wi-Fi adapter with a switch on your laptop and try to enable it again afterwards. This is often a problem with ''rfkill''. To check if the driver notifies ''rfkill'' about the wireless adapter's status, use:<br />
<br />
$ watch -n1 rfkill list all<br />
<br />
If one identifier stays blocked after you switch on the adapter you could try to manually unblock it with (where X is the number of the identifier provided by the above output):<br />
<br />
# rfkill event unblock X<br />
<br />
=== Static IP address settings revert to DHCP ===<br />
<br />
Due to an unresolved bug, when changing default connections to a static IP address, {{ic|nm-applet}} may not properly store the configuration change, and will revert to automatic DHCP.<br />
<br />
To work around this issue you have to edit the default connection (e.g. "Auto eth0") in {{ic|nm-applet}}, change the connection name (e.g. "my eth0"), uncheck the "Available to all users" checkbox, change your static IP address settings as desired, and click '''Apply'''. This will save a new connection with the given name.<br />
<br />
Next, you will want to make the default connection not connect automatically. To do so, run {{ic|nm-connection-editor}} ('''not''' as root). In the connection editor, edit the default connection (e.g. "Auto eth0") and uncheck "Connect automatically". Click '''Apply''' and close the connection editor.<br />
<br />
=== Cannot edit connections as normal user ===<br />
<br />
See [[#Set up PolicyKit permissions]].<br />
<br />
=== Forget hidden wireless network ===<br />
<br />
Since hidden networks are not displayed in the selection list of the Wireless view, they cannot be forgotten (removed) with the GUI. You can delete one with the following command:<br />
<br />
# rm /etc/NetworkManager/system-connections/''SSID''<br />
<br />
This works for any other connection.<br />
<br />
=== VPN not working in GNOME ===<br />
<br />
When setting up OpenConnect or vpnc connections in NetworkManager while using GNOME, you will sometimes never see the dialog box pop up and the following error appears in {{ic|/var/log/errors.log}}:<br />
<br />
localhost NetworkManager[399]: <error> [1361719690.10506] [nm-vpn-connection.c:1405] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.<br />
<br />
This is caused by the GNOME NM Applet expecting dialog scripts to be at {{ic|/usr/lib/gnome-shell}}, when NetworkManager's packages put them in {{ic|/usr/lib/networkmanager}}.<br />
As a "temporary" fix (this bug has been around for a while now), make the following symlink(s):<br />
<br />
* For OpenConnect: {{ic|ln -s /usr/lib/networkmanager/nm-openconnect-auth-dialog /usr/lib/gnome-shell/}}<br />
* For VPNC (i.e. Cisco VPN): {{ic|ln -s /usr/lib/networkmanager/nm-vpnc-auth-dialog /usr/lib/gnome-shell/}}<br />
<br />
This may need to be done for any other NM VPN plugins as well, but these are the two most common.<br />
<br />
=== Unable to connect to visible European wireless networks ===<br />
<br />
WLAN chips are shipped with a default [[Wireless network configuration#Respecting the regulatory domain|regulatory domain]]. If your access point does not operate within these limitations, you will not be able to connect to the network. Fixing this is easy:<br />
<br />
# [[Install]] {{Pkg|crda}}<br />
# Uncomment the correct Country Code in {{ic|/etc/conf.d/wireless-regdom}}<br />
# Reboot the system, because the setting is only read on boot<br />
<br />
=== Automatic connect to VPN on boot is not working ===<br />
<br />
The problem occurs when the system (i.e. NetworkManager running as the root user) tries to establish a VPN connection, but the password is not accessible because it is stored in the GNOME keyring of a particular user. <br />
<br />
A solution is to keep the password to your VPN in plaintext, as described in step (2.) of [[#Use dispatcher to connect to a VPN after a network connection is established]]. <br />
<br />
You do not need to use the dispatcher described in step (1.) to auto-connect anymore, if you use the new "auto-connect VPN" option from the {{ic|nm-applet}} GUI.<br />
<br />
=== Systemd Bottleneck ===<br />
<br />
Over time the log files ({{ic|/var/log/journal}}) can become very large. This can have a big impact on boot performance when using NetworkManager, see: [[Systemd#Boot time increasing over time]].<br />
<br />
=== Regular network disconnects, latency and lost packets (WiFi) ===<br />
<br />
NetworkManager does a scan every 2 minutes.<br />
<br />
Some WiFi drivers have issues when scanning for base stations whilst connected/associated. Symptoms include VPN disconnects/reconnects and lost packets, web pages failing to load and then refresh fine.<br />
<br />
Running {{ic|journalctl -f}} will indicate that this is taking place, messages like the following will be contained in the logs at regular intervals.<br />
<br />
NetworkManager[410]: <info> (wlp3s0): roamed from BSSID 00:14:48:11:20:CF (my-wifi-name) to (none) ((none))<br />
<br />
There is a patched version of NetworkManager which should prevent this type of scanning: {{AUR|networkmanager-noscan}}.<br />
<br />
Alternatively, if roaming is not important, the periodic scanning behavior can be disabled by locking the BSSID of the access point in the WiFi connection profile.<br />
<br />
=== Unable to turn on wi-fi with Lenovo laptop (IdeaPad, Legion, etc.) ===<br />
<br />
There is an issue with the {{ic|ideapad_laptop}} module on some Lenovo models due to the wi-fi driver incorrectly reporting a soft block. The card can still be manipulated with {{ic|netctl}}, but managers like NetworkManager break. You can verify that this is the problem by checking the output of {{ic|rfkill list}} after toggling your hardware switch and seeing that the soft block persists.<br />
<br />
{{Accuracy|Try to use {{ic|rfkill.default_state}} and {{ic|rfkill.master_switch_mode}} (see [https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt kernel-parameters.txt]) to fix the rfkill problem.}}<br />
<br />
[[modprobe|Unloading]] the {{ic|ideapad_laptop}} module should fix this. ('''warning''': this may disable the laptop keyboard and touchpad also!).<br />
<br />
=== Turn off hostname sending ===<br />
<br />
NetworkManager by default sends the hostname to the DHCP server. Hostname sending can only be disabled per connection not globally ([https://bugzilla.gnome.org/show_bug.cgi?id=768076 GNOME Bug 768076]).<br />
<br />
To disable sending your hostname to the DHCP server for a specific connection, add the following to your network connection file:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''your_connection_file''|2=<br />
...<br />
[ipv4]<br />
dhcp-send-hostname=false<br />
...<br />
[ipv6]<br />
dhcp-send-hostname=false<br />
...<br />
}}<br />
<br />
=== nm-applet disappears in i3wm ===<br />
<br />
If you use the {{ic|xfce4-notifyd.service}} for notifications you must [[edit]] the unit and add the following:<br />
<br />
{{hc|/etc/systemd/user/xfce4-notifyd.service.d/display_env.conf|2=<br />
[Service]<br />
Environment="DISPLAY=:0.0"<br />
}}<br />
<br />
After reloading the daemons [[restart]] {{ic|xfce4-notifyd.service}}. Exit i3 and start it back up again and the applet should show on the tray.<br />
<br />
=== nm-applet tray icons display wrongly ===<br />
<br />
Currently the tray icons of nm-applet are drawn on top of one another, i.e. the icon displaying wireless strength might show on top of the icon indicating no wired connection.<br />
This is apparently a GTK3 bug/problem: https://gitlab.gnome.org/GNOME/gtk/issues/1280 .<br />
<br />
A patched version of GTK3 exists in AUR, which apparently fixes the tray icon bug: {{AUR|gtk3-mushrooms}} .<br />
<br />
=== Unit dbus-org.freedesktop.resolve1.service not found ===<br />
<br />
If {{ic|systemd-resolved.service}} is not started, NetworkManager will try to start it using D-Bus and fail:<br />
<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
dbus-daemon[991]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
<br />
This is because NetworkManager will try to send DNS information to [[systemd-resolved]] regardless of the {{ic|1=main.dns=}} setting in {{man|5|NetworkManager.conf}}.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383]<br />
<br />
This can be disabled with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/no-systemd-resolved.conf|2=<br />
[main]<br />
systemd-resolved=false<br />
}}<br />
<br />
See {{Bug|62138}}.<br />
<br />
=== Secrets were required, but not provided ===<br />
<br />
If you attempt to connect to a network using {{ic|nmcli device wifi connect ''SSID'' password ''password''}} and received the following error:<br />
<br />
Error: Connection activation failed: (7) Secrets were required, but not provided<br />
<br />
The error can be resolved by deleting the connection profile and creating a new one:<br />
<br />
$ nmcli connection delete ''SSID''<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
=== WPA Enterprise connection with NetworkManager ===<br />
<br />
If you try to connect to an WPA Enterprise network like 'eduroam' with NetworkManager with the [[iwd]] backend then you will get the following error from NetworkManager:<br />
<br />
Connection 'eduroam' is not avialable on device wlan0 because profile is not compatible with device (802.1x connections must have IWD provisioning files)<br />
<br />
This is because NetworkManager can not configure a WPA Enterprise network. Therefore you have to configure it using an iwd config file {{ic|/var/lib/iwd/''essid''.8021x}} like described in [[iwd#WPA Enterprise]].<br />
<br />
== See also ==<br />
<br />
* [https://blogs.gnome.org/dcbw/2015/02/16/networkmanager-for-administrators-part-1/ NetworkManager for Administrators Part 1]<br />
* [[Wikipedia:NetworkManager]]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=NetworkManager&diff=627201NetworkManager2020-07-30T13:11:50Z<p>Tobbebobbe: /* Automatically connect to VNP */ spelling</p>
<hr />
<div>[[Category:Network managers]]<br />
[[Category:Red Hat]]<br />
[[cs:NetworkManager]]<br />
[[de:Networkmanager]]<br />
[[es:NetworkManager]]<br />
[[fr:NetworkManager]]<br />
[[it:NetworkManager]]<br />
[[ja:NetworkManager]]<br />
[[pt:NetworkManager]]<br />
[[zh-hans:NetworkManager]]<br />
{{Related articles start}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related articles end}}<br />
[https://wiki.gnome.org/Projects/NetworkManager/ NetworkManager] is a program for providing detection and configuration for systems to automatically connect to networks. NetworkManager's functionality can be useful for both wireless and wired networks. For wireless networks, NetworkManager prefers known wireless networks and has the ability to switch to the most reliable network. NetworkManager-aware applications can switch from online and offline mode. NetworkManager also prefers wired connections over wireless ones, has support for modem connections and certain types of VPN. NetworkManager was originally developed by Red Hat and now is hosted by the [[GNOME]] project.<br />
<br />
{{Expansion|Clear text storage of secrets is not limited to just Wi-Fi passwords. The secrets are stored in files (and folder) only accesible to root.}}<br />
<br />
{{Warning|By default, Wi-Fi passwords are stored in clear text, see [[#Encrypted Wi-Fi passwords]].}}<br />
<br />
== Installation ==<br />
<br />
NetworkManager can be [[install]]ed with the package {{Pkg|networkmanager}}, which contains a daemon, a command line interface ({{ic|nmcli}}) and a curses‐based interface ({{ic|nmtui}}). <br />
<br />
=== Enable NetworkManager ===<br />
<br />
After installation, you should [[start/enable]] {{ic|NetworkManager.service}}. Once the NetworkManager daemon is started, it will automatically connect to any available "system connections" that have already been configured. Any "user connections" or unconfigured connections will need ''nmcli'' or an applet to configure and connect.<br />
<br />
=== Additional interfaces ===<br />
<br />
* {{Pkg|nm-connection-editor}} for a graphical user interface,<br />
* {{Pkg|network-manager-applet}} for a system tray applet ({{ic|nm-applet}}).<br />
<br />
{{Note|You must ensure that no other service that wants to configure the network is running; in fact, multiple networking services will conflict. You can find a list of the currently running services with {{ic|1=systemctl --type=service}} and then [[stop]] them. See [[#Configuration]] to enable the NetworkManager service.}}<br />
<br />
=== Mobile broadband support ===<br />
<br />
[[Install]] {{Pkg|modemmanager}}, {{Pkg|mobile-broadband-provider-info}} and {{Pkg|usb_modeswitch}} packages for mobile broadband connection support. See [[USB 3G Modem#NetworkManager]] for details.<br />
<br />
=== PPPoE / DSL support ===<br />
<br />
[[Install]] {{Pkg|rp-pppoe}} package for PPPoE / DSL connection support. To actually add PPPoE connection, use {{ic|1=nm-connection-editor}} and add new DSL/PPPoE connection.<br />
<br />
=== VPN support ===<br />
<br />
NetworkManager since version 1.16 has native support for [[WireGuard]], all it needs is the {{ic|wireguard}} kernel module. Read the [https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-networkmanager/ WireGuard in NetworkManager blog post] for details.<br />
<br />
Support for other VPN types is based on a plug-in system. They are provided in the following packages:<br />
<br />
* {{Pkg|networkmanager-openconnect}} for [[OpenConnect]]<br />
* [[networkmanager-openvpn]] for [[OpenVPN]]<br />
* {{Pkg|networkmanager-pptp}} for [[PPTP Client]]<br />
* {{Pkg|networkmanager-vpnc}} for [[Vpnc]]<br />
* {{Pkg|networkmanager-strongswan}} for [[strongSwan]]<br />
* {{AUR|networkmanager-fortisslvpn-git}}<br />
* {{AUR|networkmanager-iodine-git}}<br />
* {{AUR|networkmanager-libreswan}}<br />
* {{AUR|networkmanager-l2tp}}<br />
* {{AUR|networkmanager-ssh-git}}<br />
* {{Pkg|network-manager-sstp}}<br />
<br />
{{Warning|1=There are a lot of [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues?search=VPN&state=opened bugs] (and [https://bugzilla.gnome.org/buglist.cgi?bug_status=__open__&content=VPN&product=NetworkManager old bugs]) related to VPN support. Check the daemon processes options set via the GUI correctly and double-check with each package release.}}<br />
<br />
{{Note|To have fully functioning DNS resolution when using VPN, you should set up [[#DNS caching and conditional forwarding|conditional forwarding]].}}<br />
<br />
== Usage ==<br />
<br />
NetworkManager comes with {{man|1|nmcli}} and {{man|1|nmtui}}.<br />
<br />
=== nmcli examples ===<br />
<br />
List nearby wifi networks:<br />
<br />
$ nmcli device wifi list<br />
<br />
Connect to a wifi network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
Connect to a hidden network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' hidden yes<br />
<br />
Connect to a wifi on the {{ic|wlan1}} wifi interface:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' ifname wlan1 ''profile_name''<br />
<br />
Disconnect an interface:<br />
<br />
$ nmcli device disconnect ifname eth0<br />
<br />
Reconnect an interface marked as disconnected:<br />
<br />
$ nmcli connection up uuid ''UUID''<br />
<br />
Get a list of UUIDs:<br />
<br />
$ nmcli connection show<br />
<br />
See a list of network devices and their state:<br />
<br />
$ nmcli device<br />
<br />
Turn off wifi:<br />
<br />
$ nmcli radio wifi off<br />
<br />
=== Edit a connection ===<br />
<br />
For a comprehensive list of settings, see {{man|5|nm-settings}}.<br />
<br />
Firstly you need to get list of connections:<br />
<br />
{{hc|$ nmcli connection|<nowiki><br />
NAME UUID TYPE DEVICE<br />
Wired connection 2 e7054040-a421-3bef-965d-bb7d60b7cecf ethernet enp5s0<br />
Wired connection 1 997f2782-f0fc-301d-bfba-15421a2735d8 ethernet enp0s25<br />
MY-HOME-WIFI-5G 92a0f7b3-2eba-49ab-a899-24d83978f308 wifi --<br />
</nowiki>}}<br />
<br />
Here you can use the first column as connection-id used later. In this example we pick {{ic|Wired connection 2}} as a connection-id.<br />
<br />
You have three methods to configure a connection {{ic|Wired connection 2}} after it has been created:<br />
<br />
; nmcli interactive editor<br />
: {{ic|nmcli connection edit 'Wired connection 2'}}.<br> Usage is well documented from the editor.<br />
<br />
; nmcli command line interface<br />
: {{ic|nmcli connection modify 'Wired connection 2' ''setting''.''property'' ''value''}}. See {{man|1|nmcli}} for usage. For example you can change its IPv4 route metric to 200 using {{ic|nmcli connection modify 'Wired connection 2' ipv4.route-metric 200}} command.<br />
<br />
; Connection file<br />
: In {{ic|/etc/NetworkManager/system-connections/}}, modify the corresponding {{ic|Wired connection 2.nmconnection}} file .<br> Do not forget to reload the configuration file with {{ic|nmcli connection reload}}.<br />
<br />
== Front-ends ==<br />
<br />
To configure and have easy access to NetworkManager, most users will want to install an applet. This GUI front-end usually resides in the system tray (or notification area) and allows network selection and configuration of NetworkManager. Various desktop environments have their own applet. Otherwise you can use [[#nm-applet]].<br />
<br />
=== GNOME ===<br />
<br />
[[GNOME]] has a built-in tool, accessible from the Network settings.<br />
<br />
=== KDE Plasma ===<br />
<br />
[[Install]] the {{Pkg|plasma-nm}} package. After that, add it to the KDE taskbar via the ''Panel options > Add widgets > Networks'' menu.<br />
<br />
=== nm-applet ===<br />
<br />
{{Pkg|network-manager-applet}} is a GTK 3 front-end which works under Xorg environments with a systray.<br />
<br />
To store connection secrets install and configure [[GNOME/Keyring]].<br />
<br />
Be aware that after enabling the tick-box option {{ic|Make available to other users}} for a connection, NetworkManager stores the password in plain-text, though the respective file is accessible only to root (or other users via {{ic|nm-applet}}). See [[#Encrypted Wi-Fi passwords]].<br />
<br />
In order to run {{ic|nm-applet}} without a systray, you can use {{Pkg|trayer}} or {{Pkg|stalonetray}}. For example, you can add a script like this one in your path:<br />
<br />
{{hc|nmgui|<nowiki><br />
#!/bin/sh<br />
nm-applet 2>&1 > /dev/null &<br />
stalonetray 2>&1 > /dev/null<br />
killall nm-applet<br />
</nowiki>}}<br />
<br />
When you close the ''stalonetray'' window, it closes {{ic|nm-applet}} too, so no extra memory is used once you are done with network settings.<br />
<br />
The applet can show notifications for events such as connecting to or disconnecting from a WiFi network. For these notifications to display, ensure that you have a notification server installed - see [[Desktop notifications]]. If you use the applet without a notification server, you might see some messages in stdout/stderr, and the app might hang. See [https://bugzilla.gnome.org/show_bug.cgi?id=788313].<br />
<br />
In order to run {{ic|nm-applet}} with such notifications disabled, start the applet with the following command:<br />
<br />
$ nm-applet --no-agent<br />
<br />
{{Tip|{{ic|nm-applet}} might be started automatically with a [[XDG Autostart|autostart desktop file]], to add the --no-agent option modify the Exec line there, i.e.<br />
<br />
{{bc|1=Exec=nm-applet --no-agent}}<br />
<br />
}}<br />
<br />
{{Warning|On [[i3]], if nm-applet is started with the {{ic|--no-agent}} option, it is not possible to connect to a new encrypted WiFi network by clicking on the item list because no password input dialogue window will pop out. [[journal]] will show {{ic|no secrets: No agents were available for this request}}.}}<br />
<br />
==== Appindicator ====<br />
<br />
As of version 1.18.0 Appindicator support is [https://github.com/archlinux/svntogit-packages/commit/7640a2bd557fe84813207ef4d5e35bb5aece6c54 available] in the official {{Pkg|network-manager-applet}} package. To use nm-applet in an Appindicator environment start the applet with the following command:<br />
<br />
$ nm-applet --indicator<br />
<br />
=== networkmanager-dmenu ===<br />
<br />
Alternatively there is {{AUR|networkmanager-dmenu-git}} which is a small script to manage NetworkManager connections with [[dmenu]] or [[rofi]] instead of {{ic|nm-applet}}. It provides all essential features such as connection to existing NetworkManager wifi or wired connections, connect to new wifi connections, requests passphrase if required, connect to existing VPN connections, enable/disable networking, launch ''nm-connection-editor'' GUI, connect to Bluetooth networks.<br />
<br />
== Configuration ==<br />
<br />
NetworkManager will require some additional steps to be able run properly. Make sure you have configured {{ic|/etc/hosts}} as described in [[Network configuration#Set the hostname]] section.<br />
<br />
NetworkManager has a global configuration file at {{ic|/etc/NetworkManager/NetworkManager.conf}}. Addition configuration files can be placed in {{ic|/etc/NetworkManager/conf.d/}}. Usually no configuration needs to be done to the global defaults.<br />
<br />
After editing a configuration file, the changes can be applied by running:<br />
<br />
# nmcli general reload<br />
<br />
=== Enable NetworkManager Wait Online ===<br />
<br />
{{Out of date|{{ic|NetworkManager.service}} has {{ic|1=Also=NetworkManager-wait-online.service}} in the {{ic|[Install]}} section.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/167e42a87e97ed7fb26a4263c22f1774716ac51b] If {{ic|NetworkManager.service}} was [[enable]]d before the change, it needs to be [[enable|reenabled]].}}<br />
<br />
If you have services which fail if they are started before the network is up, you may use {{ic|NetworkManager-wait-online.service}} in addition to {{ic|NetworkManager.service}}. This is, however, rarely necessary because most networked daemons start up okay, even if the network has not been configured yet.<br />
<br />
In some cases, the service will still fail to start successfully on boot due to the timeout setting in {{ic|/usr/lib/systemd/system/NetworkManager-wait-online.service}} being too short. Change the default timeout from 30 to a higher value.<br />
<br />
=== Set up PolicyKit permissions ===<br />
<br />
See [[General troubleshooting#Session permissions]] for setting up a working session.<br />
<br />
With a working session, you have several options for granting the necessary privileges to NetworkManager:<br />
<br />
* ''Option 1.'' Run a [[Polkit]] authentication agent when you log in, such as {{ic|/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1}} (part of {{Pkg|polkit-gnome}}). You will be prompted for your password whenever you add or remove a network connection.<br />
* ''Option 2.'' [[Users and groups#Group management|Add]] yourself to the {{ic|wheel}} group. You will not have to enter your password, but your user account may be granted other permissions as well, such as the ability to use [[sudo]] without entering the root password.<br />
* ''Option 3.'' [[Users and groups#Group management|Add]] yourself to the {{ic|network}} group and create the following file:<br />
<br />
{{hc|/etc/polkit-1/rules.d/50-org.freedesktop.NetworkManager.rules|<nowiki><br />
polkit.addRule(function(action, subject) {<br />
if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0 && subject.isInGroup("network")) {<br />
return polkit.Result.YES;<br />
}<br />
});<br />
</nowiki>}}<br />
<br />
: All users in the {{ic|network}} group will be able to add and remove networks without a password. This will not work under [[systemd]] if you do not have an active session with ''systemd-logind''.<br />
<br />
=== Proxy settings ===<br />
<br />
NetworkManager does not directly handle proxy settings, but if you are using [[GNOME]] or [[KDE]], you could use [http://marin.jb.free.fr/proxydriver/ proxydriver] which handles proxy settings using NetworkManager's information. proxydriver is found in the package {{AUR|proxydriver}}.<br />
<br />
In order for ''proxydriver'' to be able to change the proxy settings, you would need to execute this command, as part of the GNOME startup process (see [[GNOME#Autostart]]).<br />
<br />
xhost +si:localuser:''username''<br />
<br />
See also [[Proxy settings]].<br />
<br />
=== Checking connectivity ===<br />
<br />
NetworkManager can try to reach a page on Internet when connecting to a network. {{Pkg|networkmanager}} is configured by default in {{ic|/usr/lib/NetworkManager/conf.d/20-connectivity.conf}} to check connectivity to archlinux.org. To use a different webserver or disable connectivity checking create {{ic|/etc/NetworkManager/conf.d/20-connectivity.conf}}, see {{man|5|NetworkManager.conf|CONNECTIVITY SECTION}}. Below is an example of using GNOME servers (it does not require the use of [[GNOME]]):<br />
<br />
{{hc|/etc/NetworkManager/conf.d/20-connectivity.conf|<nowiki><br />
[connectivity]<br />
uri=http://nmcheck.gnome.org/check_network_status.txt<br />
</nowiki>}}<br />
<br />
{{Note|Although automatic connectivity checks are a potential privacy leak, the official archlinux.org default connectivity URL is committed to not logging any access. See [https://gitlab.archlinux.org/archlinux/infrastructure/-/commit/68fbaca2ef9f31f624f117899848f4288d6b39d1].}}<br />
<br />
=== Captive portals ===<br />
<br />
{{Style|Complex scripts should not be maintained on the wiki.}}<br />
<br />
For those behind a [[Wikipedia:Captive portal|captive portal]], the desktop manager may automatically open a window asking for credentials. If your desktop does not, you can use {{Pkg|capnet-assist}} package (however, it currently it has a broken NetworkManager dispatcher script). Alternatively, you can create a NetworkManager dispatcher script with the following content:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/90-open_captive_portal|<nowiki><br />
#!/bin/sh -e<br />
# Script to dispatch NetworkManager events<br />
#<br />
# Runs shows a login webpage on walled garden networks.<br />
# See NetworkManager(8) for further documentation of the dispatcher events.<br />
<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin<br />
<br />
if [ -x "/usr/bin/logger" ]; then<br />
logger="/usr/bin/logger -s -t captive-portal"<br />
else<br />
logger=":"<br />
fi<br />
<br />
wait_for_process() {<br />
PNAME=$1<br />
while [ -z "$(/usr/bin/pgrep $PNAME)" ]; do<br />
sleep 3;<br />
done<br />
}<br />
<br />
#launch the browser, but on boot we need to wait that nm-applet starts<br />
start_browser() {<br />
local user="$1"<br />
local display="$2"<br />
<br />
export DISPLAY="$display"<br />
wait_for_process nm-applet<br />
<br />
export XAUTHORITY="/home/$user/.Xauthority"<br />
<br />
$logger "Running browser as '$user' with display '$display' to login in captive portal"<br />
sudo -u "$user" --preserve-env=DISPLAY,XAUTHORITY -H xdg-open http://capnet.elementary.io 2>&1 > /dev/null<br />
}<br />
<br />
# Run the right scripts<br />
case "$2" in<br />
connectivity-change)<br />
$logger -p user.debug "dispatcher script triggered on connectivity change: $CONNECTIVITY_STATE"<br />
if [ "$CONNECTIVITY_STATE" = "PORTAL" ]; then<br />
# Match last column of who's output with ' :[at least one digit] '<br />
who | awk '$NF ~ /\(:[0-9]+\)/ { print $1 " " substr($NF, 2, length($NF)-2) };' | \<br />
while read user display; do<br />
start_browser $user $display || $logger -p user.err "Failed for user: '$user' display: '$display'"<br />
done<br />
fi<br />
;;<br />
*)<br />
# In a down phase<br />
exit 0<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
You will need to [[restart]] {{ic|NetworkManager.service}} or reboot for this to start working. Once you do, the dispatcher script should open a login window once it detects you are behind a captive portal.<br />
<br />
Another solution is {{AUR|captive-browser-git}} based on Google Chrome.<br />
<br />
=== DHCP client ===<br />
<br />
By default NetworkManager uses its internal DHCP client. The internal DHCPv4 plugin is based on the [https://nettools.github.io/n-dhcp4/ nettools' n-dhcp4] library, while the internal DHCPv6 plugin is made from code based on systemd-networkd.<br />
<br />
To use ISC’s DHCP client, [[install]] {{Pkg|dhclient}}. To change the DHCP client backend, set the option {{ic|1=main.dhcp=''dhcp_client_name''}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}. E.g.:<br />
<br />
{{hc|1=/etc/NetworkManager/conf.d/dhcp-client.conf|2=<br />
[main]<br />
dhcp=dhclient<br />
}}<br />
<br />
{{Note|<br />
* Do not enable the systemd units shipped with the {{Pkg|dhclient}} and {{Pkg|dhcpcd}} packages. They will conflict with NetworkManager, see the note in [[#Installation]] for details.<br />
* NetworkManger does not support dhcpcd ≥ 9.0.0. See {{Bug|66231}}.<br />
}}<br />
<br />
=== DNS management ===<br />
<br />
NetworkManager's DNS management is described in the GNOME project's wiki page—[https://wiki.gnome.org/Projects/NetworkManager/DNS Projects/NetworkManager/DNS].<br />
<br />
==== DNS caching and conditional forwarding ====<br />
<br />
NetworkManager has a plugin to enable DNS caching and conditional forwarding ([https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/143 previously] called "split DNS" in NetworkManager's documentation) using [[dnsmasq]] or [[systemd-resolved]]. The advantages of this setup is that DNS lookups will be cached, shortening resolve times, and DNS lookups of VPN hosts will be routed to the relevant VPN's DNS servers. This is especially useful if you are connected to more than one VPN.<br />
<br />
===== dnsmasq =====<br />
<br />
Make sure {{Pkg|dnsmasq}} has been installed. Then set {{ic|1=main.dns=dnsmasq}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=dnsmasq<br />
}}<br />
<br />
Now run {{ic|nmcli general reload}} as root. NetworkManager will automatically start dnsmasq and add {{ic|127.0.0.1}} to {{ic|/etc/resolv.conf}}. The original DNS servers can be found in {{ic|/run/NetworkManager/no-stub-resolv.conf}}. You can verify dnsmasq is being used by doing the same DNS lookup twice with {{ic|drill example.com}} and verifying the server and query times.<br />
<br />
{{Note|<br />
* You do not need to start {{ic|dnsmasq.service}} or edit {{ic|/etc/dnsmasq.conf}}. NetworkManager will start dnsmasq without using the systemd service and without reading the dnsmasq's default configuration file(s).<br />
* The dnsmasq instance started by NetworkManager will bind to {{ic|127.0.0.1:53}}, you cannot run any other software (including {{ic|dnsmasq.service}}) on the same address and port.<br />
}}<br />
<br />
====== Custom dnsmasq configuration ======<br />
<br />
Custom configurations can be created for ''dnsmasq'' by creating configuration files in {{ic|/etc/NetworkManager/dnsmasq.d/}}. For example, to change the size of the DNS cache (which is stored in RAM):<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/cache.conf|2=<br />
cache-size=1000<br />
}}<br />
<br />
{{Tip|Check the configuration file syntax with {{ic|1=dnsmasq --test --conf-file=/dev/null --conf-dir=/etc/NetworkManager/dnsmasq.d}}.}}<br />
<br />
See {{man|8|dnsmasq}} for all available options.<br />
<br />
====== IPv6 ======<br />
<br />
{{Accuracy|This does not solve the issue because NetworkManager does not add {{ic|::1}} to {{ic|/etc/resolv.conf}}. Unless {{ic|@::1}} is manually passed to drill, it will still fail with {{ic|Error: error sending query: No (valid) nameservers defined in the resolver}}.}}<br />
<br />
Enabling {{ic|dnsmasq}} in NetworkManager may break IPv6-only DNS lookups (i.e. {{ic|drill -6 [hostname]}}) which would otherwise work. In order to resolve this, creating the following file will configure ''dnsmasq'' to also listen to the IPv6 loopback:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/ipv6-listen.conf|2=<br />
listen-address=::1<br />
}}<br />
<br />
In addition, {{ic|dnsmasq}} also does not prioritize upstream IPv6 DNS. Unfortunately NetworkManager does not do this ([https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/936712 Ubuntu Bug]). A workaround would be to disable IPv4 DNS in the NetworkManager config, assuming one exists<br />
<br />
====== DNSSEC ======<br />
<br />
The dnsmasq instance started by NetworkManager by default will not validate [[DNSSEC]] since it is started with the {{ic|--proxy-dnssec}} option. It will trust whatever DNSSEC information it gets from the upstream DNS server.<br />
<br />
For dnsmasq to properly validate DNSSEC, thus breaking DNS resolution with name servers that do not support it, create the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/dnssec.conf|2=<br />
conf-file=/usr/share/dnsmasq/trust-anchors.conf<br />
dnssec<br />
}}<br />
<br />
===== systemd-resolved =====<br />
<br />
{{Expansion|NetworkManager 1.16 adds a new setting {{ic|main.systemd-resolved}}[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383] (enabled by default). It unconditionally sends DNS configuration to systemd-resolved. Related to "Preserving resolv.conf" from [[systemd-resolved#DNS]]?}}<br />
<br />
NetworkManager can use [[systemd-resolved]] as a DNS resolver and cache. Make sure that ''systemd-resolved'' is properly configured and that {{ic|systemd-resolved.service}} is [[started]] before using it.<br />
<br />
systemd-resolved will be used automatically if {{ic|/etc/resolv.conf}} is a [[Systemd-resolved#DNS|symlink]] to {{ic|/run/systemd/resolve/stub-resolv.conf}}, {{ic|/run/systemd/resolve/resolv.conf}} or {{ic|/usr/lib/systemd/resolv.conf}}.<br />
<br />
You can enable it explicitly by setting {{ic|1=main.dns=systemd-resolved}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=systemd-resolved<br />
}}<br />
<br />
===== DNS resolver with an openresolv subscriber =====<br />
<br />
If [[openresolv]] has a subscriber for your local [[DNS resolver]], set up the subscriber and [[#Use openresolv|configure NetworkManager to use openresolv]].<br />
<br />
Because NetworkManager advertises a single "interface" to ''resolvconf'', it is not possible to implement conditional forwarding between two NetworkManager connections. See [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 NetworkManager issue 153].<br />
<br />
This can be partially mitigated if you set {{ic|1=private="*"}} in {{ic|/etc/resolvconf.conf}}[https://roy.marples.name/projects/openresolv/configuration.html]. Any queries for domains that are not in search domain list will not get forwarded. They will be handled according to the local resolver's configuration, for example, forwarded to another DNS server or resolved recursively from the DNS root.<br />
<br />
==== Custom DNS servers ====<br />
<br />
===== Setting custom global DNS servers =====<br />
<br />
To set DNS servers for all connections, specify them in {{man|5|NetworkManager.conf}} using the syntax {{ic|1=servers=''serveripaddress1'',''serveripaddress2'',''serveripaddress3''}} in a section named {{ic|[global-dns-domain-*]}}. For example:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns-servers.conf|2=<br />
[global-dns-domain-*]<br />
servers=::1,127.0.0.1<br />
}}<br />
<br />
{{Note|<br />
* If you use [[#DNS caching and conditional forwarding|NetworkManager's dnsmasq or systemd-resolved plugin]] or [[#DNS resolver with an openresolv subscriber|openresolv subscribers]], then do not specify loopback addresses with the {{ic|1=servers=}} option, it can break DNS resolution.<br />
* The specified servers do not get sent to [[systemd-resolved]], the connection's DNS servers are used instead.<br />
}}<br />
<br />
===== Setting custom DNS servers in a connection =====<br />
<br />
====== Setting custom DNS servers in a connection (GUI) ======<br />
<br />
Setup will depend on the type of front-end used; the process usually involves right-clicking on the applet, editing (or creating) a profile, and then choosing DHCP type as ''Automatic (specify addresses)''. The DNS addresses will need to be entered and are usually in this form: {{ic|127.0.0.1, ''DNS-server-one'', ...}}.<br />
<br />
====== Setting custom DNS servers in a connection (nmcli / connection file) ======<br />
<br />
To setup DNS Servers per connection, you can use the {{ic|dns}} field (and the associated {{ic|dns-search}} and {{ic|dns-options}}) in the [[#Edit a connection|connection settings]]. <br />
<br />
If {{ic|method}} is set to {{ic|auto}} (when you use DHCP), you need to set {{ic|ignore-auto-dns}} to {{ic|yes}}.<br />
<br />
==== /etc/resolv.conf ====<br />
<br />
By default {{ic|/etc/resolv.conf}} is managed by ''NetworkManager'' unless it is a symlink.<br />
<br />
It can be configured to write it through [[#Use openresolv|openresolv]] or to [[#Unmanaged /etc/resolv.conf|not touch it at all]].<br />
<br />
Using openresolv allows NetworkManager to coexists with other ''resolvconf'' supporting software or, for example, to run a local DNS caching and split-DNS resolver for which openresolv has a [[openresolv#Subscribers|subscriber]].<br />
<br />
{{Note|Conditional forwarding is [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 not yet fully supported] when using NetworkManager with openresolv.}}<br />
<br />
''NetworkManager'' also offers hooks via so called dispatcher scripts that can be used to alter the {{ic|/etc/resolv.conf}} after network changes. See [[#Network services with NetworkManager dispatcher]] and {{man|8|NetworkManager}} for more information.<br />
<br />
{{Note|<br />
* If NetworkManager is configured to use either [[#dnsmasq|dnsmasq]] or [[#systemd-resolved|systemd-resolved]], then the appropriate loopback addresses will be written to {{ic|/etc/resolv.conf}}.<br />
* The {{ic|resolv.conf}} file NetworkManager writes or would write to {{ic|/etc/resolv.conf}} can be found at {{ic|/run/NetworkManager/resolv.conf}}.<br />
* A {{ic|resolv.conf}} file with the acquired name servers and search domains can be found at {{ic|/run/NetworkManager/no-stub-resolv.conf}}.<br />
}}<br />
<br />
===== Unmanaged /etc/resolv.conf =====<br />
<br />
To stop NetworkManager from touching {{ic|/etc/resolv.conf}}, set {{ic|1=main.dns=none}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=none<br />
}}<br />
<br />
{{Tip|You might also want to set {{ic|1=main.systemd-resolved=false}}, so that NetworkManager does not send the DNS configuration to [[systemd-resolved]].}}<br />
<br />
{{Note|See [[#DNS caching and conditional forwarding]], to configure NetworkManager using other DNS backends like [[dnsmasq]] and [[systemd-resolved]], instead of using {{ic|1=main.dns=none}}.}}<br />
<br />
After that {{ic|/etc/resolv.conf}} might be a broken symlink that you will need to remove. Then, just create a new {{ic|/etc/resolv.conf}} file.<br />
<br />
===== Use openresolv =====<br />
<br />
{{Note|Do not set {{ic|1=rc-manager=resolvconf}} when {{Pkg|systemd-resolvconf}} is installed. ''systemd-resolved'' provides limited support for the ''resolvconf'' interface and NetworkManager supports communicating with systemd-resolved through D-Bus without using ''resolvconf''.}}<br />
<br />
To configure NetworkManager to use [[openresolv]], set {{ic|1=main.rc-manager=resolvconf}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/rc-manager.conf|2=<br />
[main]<br />
rc-manager=resolvconf<br />
}}<br />
<br />
=== Firewall ===<br />
<br />
You can assign a [[firewalld]] zone based on your current connection. For example a restrictive firewall when at work, and a less restrictive one when at home.<br />
<br />
This can also be done with [[#Network services with NetworkManager dispatcher|NetworkManager dispatcher]].<br />
<br />
=== 802.1x / PEAP configuration ===<br />
<br />
A PEAP and 802.1x network can be added by adding a config file to {{ic|/etc/NetworkManager/system-connections/''name''}}.<br />
<br />
Here is an example configuration file for IPv4 with IPv6 disabled:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''name''|2=<br />
[ipv6]<br />
method=ignore<br />
<br />
[ipv4]<br />
method=auto<br />
<br />
[connection]<br />
#id=XXXXXXXXX<br />
#uuid=XXXXXXXXX<br />
type=802-11-wireless<br />
#timestamp=XXXX<br />
<br />
[802-11-wireless-security]<br />
key-mgmt=wpa-eap<br />
<br />
[802-11-wireless]<br />
ssid=ssid<br />
mode=infrastructure<br />
#seen-bssids=XXXXXXXXX<br />
security=802-11-wireless-security<br />
<br />
[802-1x]<br />
eap=peap;<br />
identity=user<br />
password=password<br />
phase2-auth=mschapv2<br />
}}<br />
<br />
The number sign (#) defines comments.<br />
<br />
=== Automatically connect to VNP ===<br />
<br />
NetworkManager can be set to automatically connect to a VPN when connecting to the internet, on a per network basis. The VPN connection itself can be added in the Gnome gui, but to make it automatically use the VPN {{ic|nmcli}} must be used.<br />
<br />
First, make sure to make the VPN connection available to all users. In the Gnome gui this is a matter of checking a box under the {{ic|details}} tab. Then under the {{ic|Identity}} tab, in the password field, click the icon on the right side in the field, and set it to {{ic|Store the password for all users}}.<br />
<br />
Then use the {{ic|nmcli}} tool via command line:<br />
<br />
# nmcli connection<br />
<br />
To list your connections. Then enter configuration mode for the internet connection you want to automatically connect to a VPN<br />
<br />
# nmcli connection edit <NAME of Internet Connection><br />
<br />
Please note that it is the Internet connection and not the VPN you should edit. Here you do not need to use the UUID of the Internet connection, the NAME is fine. Then make the setting with the command:<br />
<br />
# set connection.secondaries <UUID of VPN><br />
<br />
Here the UUID of the VPN must be used, but {{ic|tab}} works for autocompletion.<br />
<br />
== Network services with NetworkManager dispatcher ==<br />
<br />
There are quite a few network services that you will not want running until NetworkManager brings up an interface. NetworkManager has the ability to start services when you connect to a network and stop them when you disconnect (e.g. when using [[NFS]], [[SMB]] and [[NTPd]]).<br />
<br />
To activate the feature you need to [[enable]] and [[start]] the {{ic|NetworkManager-dispatcher.service}}.<br />
<br />
Once the service is active, scripts can be added to the {{ic|/etc/NetworkManager/dispatcher.d}} directory.<br />
<br />
Scripts must be owned by '''root''', otherwise the dispatcher will not execute them. For added security, set group [[ownership]] to root as well:<br />
<br />
# chown root:root /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
Make sure the file has correct permissions:<br />
<br />
# chmod 755 /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
The scripts will be run in alphabetical order at connection time, and in reverse alphabetical order at disconnect time. To ensure what order they come up in, it is common to use numerical characters prior to the name of the script (e.g. {{ic|10-portmap}} or {{ic|30-netfs}} (which ensures that the ''portmapper'' is up before NFS mounts are attempted).<br />
<br />
Scripts will receive the following arguments:<br />
<br />
* '''Interface name:''' e.g. {{ic|eth0}}<br />
* '''Interface status:''' ''up'' or ''down''<br />
* '''VPN status:''' ''vpn-up'' or ''vpn-down''<br />
<br />
{{Warning|If you connect to foreign or public networks, be aware of what services you are starting and what servers you expect to be available for them to connect to. You could make a security hole by starting the wrong services while connected to a public network.}}<br />
<br />
=== Avoiding the dispatcher timeout ===<br />
<br />
If the above is working, then this section is not relevant. However, there is a general problem related to running dispatcher scripts which take longer to be executed. Initially an internal timeout of three seconds only was used. If the called script did not complete in time, it was killed. Later the timeout was extended to about 20 seconds (see the [https://bugzilla.redhat.com/show_bug.cgi?id=982734 Bugtracker] for more information). If the timeout still creates the problem, a work around may be to modify the dispatcher service file {{ic|/usr/lib/systemd/system/NetworkManager-dispatcher.service}} to remain active after exit: <br />
<br />
{{hc|/etc/systemd/system/NetworkManager-dispatcher.service.d/remain_after_exit.conf|2=<br />
[Service]<br />
RemainAfterExit=yes<br />
}}<br />
<br />
Now start and enable the modified {{ic|NetworkManager-dispatcher}} service.<br />
<br />
{{Warning|Adding the {{ic|RemainAfterExit}} line to it will prevent the dispatcher from closing. Unfortunately, the dispatcher '''has''' to close before it can run your scripts again. With it the dispatcher will not time out but it also will not close, which means that the scripts will only run once per boot. Therefore, do not add the line unless the timeout is definitely causing a problem.}}<br />
<br />
=== Dispatcher examples ===<br />
<br />
==== Mount remote folder with sshfs ====<br />
<br />
As the script is run in a very restrictive environment, you have to export {{ic|SSH_AUTH_SOCK}} in order to connect to your SSH agent. There are different ways to accomplish this, see [https://bbs.archlinux.org/viewtopic.php?pid=1042030#p1042030 this message] for more information. The example below works with [[GNOME Keyring]], and will ask you for the password if not unlocked already. In case NetworkManager connects automatically on login, it is likely ''gnome-keyring'' has not yet started and the export will fail (hence the sleep). The {{ic|UUID}} to match can be found with the command {{ic|nmcli connection status}} or {{ic|nmcli connection list}}. <br />
<br />
{{bc|<nowiki><br />
#!/bin/sh<br />
USER='username'<br />
REMOTE='user@host:/remote/path'<br />
LOCAL='/local/path'<br />
<br />
interface=$1 status=$2<br />
if [ "$CONNECTION_UUID" = "</nowiki>''uuid''<nowiki>" ]; then<br />
case $status in<br />
up)<br />
SSH_AUTH_SOCK=$(find /tmp -maxdepth 1 -type s -user "$USER" -name 'ssh')<br />
export SSH_AUTH_SOCK<br />
su "$USER" -c "sshfs $REMOTE $LOCAL"<br />
;;<br />
down)<br />
fusermount -u "$LOCAL"<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
==== Mounting of SMB shares ====<br />
<br />
Some [[SMB]] shares are only available on certain networks or locations (e.g. at home). You can use the dispatcher to only mount SMB shares that are present at your current location.<br />
<br />
The following script will check if we connected to a specific network and mount shares accordingly:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-mount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
# Find the connection UUID with "nmcli connection show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
if [ "$2" = "up" ]; then<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
mount /your/mount/point & <br />
# add more shares as needed<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The following script will unmount all SMB shares before a software initiated disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/pre-down.d/30-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|Make sure this script is located in the {{ic|pre-down.d}} sub-directory as shown above, otherwise it will unmount all shares on any connection state change.}}<br />
<br />
The following script will attempt to unmount all SMB shares following an unexpected disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/40-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
if [ "$2" = "down" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|<br />
* Since NetworkManager 0.9.8, the ''pre-down'' and ''down'' events are not executed on shutdown or restart, see [https://bugzilla.gnome.org/show_bug.cgi?id&#61;701242 this bug report] for more info.<br />
* The previous ''umount'' scripts are still prone to leaving applications actually accessing the mount to 'hang'.<br />
}}<br />
<br />
An alternative is to use the script as seen in [[NFS#Using a NetworkManager dispatcher]]:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-smb.sh|<nowiki><br />
#!/bin/bash<br />
<br />
# Find the connection UUID with "nmcli con show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
WANTED_CON_UUID="CHANGE-ME-NOW-9c7eff15-010a-4b1c-a786-9b4efa218ba9"<br />
<br />
if [[ "$CONNECTION_UUID" == "$WANTED_CON_UUID" ]]; then<br />
<br />
# Script parameter $1: NetworkManager connection name, not used<br />
# Script parameter $2: dispatched event<br />
<br />
case "$2" in<br />
"up")<br />
mount -a -t cifs<br />
;;<br />
"pre-down");&<br />
"vpn-pre-down")<br />
umount -l -a -t cifs >/dev/null<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|This script ignores mounts with the {{ic|noauto}} option, remove this mount option or use {{ic|auto}} to allow the dispatcher to manage these mounts.}}<br />
<br />
Create a symlink inside {{ic|/etc/NetworkManager/dispatcher.d/pre-down/}} to catch the {{ic|pre-down}} events:<br />
<br />
# ln -s ../30-smb.sh /etc/NetworkManager/dispatcher.d/pre-down.d/30-smb.sh<br />
<br />
==== Mounting of NFS shares ====<br />
<br />
See [[NFS#Using a NetworkManager dispatcher]].<br />
<br />
==== Use dispatcher to automatically toggle wireless depending on LAN cable being plugged in ====<br />
<br />
The idea is to only turn Wi-Fi on when the LAN cable is unplugged (for example when detaching from a laptop dock), and for Wi-Fi to be automatically disabled, once a LAN cable is plugged in again. <br />
<br />
Create the following dispatcher script[https://superuser.com/questions/233448/disable-wlan-if-wired-cable-network-is-available], replacing {{ic|1=LAN_interface}} with yours.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/wlan_auto_toggle.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$1" = "LAN_interface" ]; then<br />
case "$2" in<br />
up)<br />
nmcli radio wifi off<br />
;;<br />
down)<br />
nmcli radio wifi on<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|You can get a list of interfaces using [[#nmcli examples|nmcli]]. The ethernet (LAN) interfaces start with {{ic|en}}, e.g. {{ic|1=enp0s5}}}}<br />
<br />
==== Use dispatcher to connect to a VPN after a network connection is established ====<br />
<br />
In this example we want to connect automatically to a previously defined VPN connection after connecting to a specific Wi-Fi network. First thing to do is to create the dispatcher script that defines what to do after we are connected to the network.<br />
<br />
{{Note|This script will require {{Pkg|wireless_tools}} in order to use {{ic|iwgetid}}.}}<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME"<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you would like to attempt to automatically connect to VPN for all Wi-Fi networks, you can use the following definition of the ESSID: {{ic|1=ESSID=$(iwgetid -r)}}. Remember to set the script's permissions [[#Network services with NetworkManager dispatcher|accordingly]]. <br />
<br />
Trying to connect with the above script may still fail with {{ic|NetworkManager-dispatcher.service}} complaining about 'no valid VPN secrets', because of [https://developer.gnome.org/NetworkManager/0.9/secrets-flags.html the way VPN secrets are stored]. Fortunately, there are different options to give the above script access to your VPN password.<br />
<br />
1: One of them requires editing the VPN connection configuration file to make NetworkManager store the secrets by itself rather than inside a keyring [https://bugzilla.redhat.com/show_bug.cgi?id=710552 that will be inaccessible for root]: open up {{ic|/etc/NetworkManager/system-connections/''name of your VPN connection''}} and change the {{ic|password-flags}} and {{ic|secret-flags}} from {{ic|1}} to {{ic|0}}.<br />
<br />
If that alone does not work, you may have to create a {{ic|passwd-file}} in a safe location with the same permissions and ownership as the dispatcher script, containing the following:<br />
<br />
{{hc|/path/to/passwd-file|<br />
vpn.secrets.password:YOUR_PASSWORD<br />
}}<br />
<br />
The script must be changed accordingly, so that it gets the password from the file:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME" passwd-file /path/to/passwd-file<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
2: Alternatively, change the {{ic|password-flags}} and put the password directly in the configuration file adding the section {{ic|vpn-secrets}}:<br />
<br />
[vpn]<br />
....<br />
password-flags=0<br />
<br />
[vpn-secrets]<br />
password=''your_password''<br />
<br />
{{Note|It may now be necessary to re-open the NetworkManager connection editor and save the VPN passwords/secrets again.}}<br />
<br />
==== Use dispatcher to disable IPv6 on VPN provider connections ====<br />
<br />
Many [[:Category:VPN providers|commercial VPN providers]] support only IPv4. That means all IPv6 traffic bypasses the VPN and renders it virtually useless. To avoid this, dispatcher can be used to disable all IPv6 traffic for the time a VPN connection is up.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/10-vpn-ipv6|<nowiki><br />
#!/bin/sh<br />
<br />
case "$2" in<br />
vpn-up)<br />
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
vpn-down)<br />
echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
==== OpenNTPD ====<br />
<br />
See [[OpenNTPD#Using NetworkManager dispatcher]].<br />
<br />
== Testing ==<br />
<br />
NetworkManager applets are designed to load upon login so no further configuration should be necessary for most users. If you have already disabled your previous network settings and disconnected from your network, you can now test if NetworkManager will work. The first step is to [[start]] {{ic|NetworkManager.service}}.<br />
<br />
Some applets will provide you with a {{ic|.desktop}} file so that the NetworkManager applet can be loaded through the application menu. If it does not, you are going to either have to discover the command to use or logout and login again to start the applet. Once the applet is started, it will likely begin polling network connections with for auto-configuration with a DHCP server.<br />
<br />
To start the GNOME applet in non-xdg-compliant window managers like [[awesome]]:<br />
<br />
nm-applet --sm-disable &<br />
<br />
For static IP addresses, you will have to configure NetworkManager to understand them. The process usually involves right-clicking the applet and selecting something like 'Edit Connections'.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Encrypted Wi-Fi passwords ===<br />
<br />
By default, NetworkManager stores passwords in clear text in the connection files at {{ic|/etc/NetworkManager/system-connections/}}. To print the stored passwords, use the following command:<br />
<br />
# grep -r '^psk=' /etc/NetworkManager/system-connections/<br />
<br />
The passwords are accessible to the root user in the filesystem and to users with access to settings via the GUI (e.g. {{ic|nm-applet}}). <br />
<br />
It is preferable to save the passwords in encrypted form in a keyring instead of clear text. The downside of using a keyring is that the connections have to be set up for each user.<br />
<br />
==== Using GNOME Keyring ====<br />
<br />
The keyring daemon has to be started and the keyring needs to be unlocked for the following to work.<br />
<br />
Furthermore, NetworkManager needs to be configured not to store the password for all users. Using GNOME {{ic|nm-applet}}, run {{ic|nm-connection-editor}} from a terminal, select a network connection, click {{ic|Edit}}, select the {{ic|Wifi-Security}} tab and click on the right icon of password and check {{ic|Store the password only for this user}}.<br />
<br />
==== Using KDE Wallet ====<br />
<br />
Using KDE's {{Pkg|plasma-nm}}, click the applet, click on the top right {{ic|Settings}} icon, click on a network connection, in the {{ic|General settings}} tab, untick {{ic|all users may connect to this network}}. If the option is ticked, the passwords will still be stored in clear text, even if a keyring daemon is running.<br />
<br />
If the option was selected previously and you un-tick it, you may have to use the {{ic|reset}} option first to make the password disappear from the file. Alternatively, delete the connection first and set it up again.<br />
<br />
=== Sharing internet connection over Wi-Fi ===<br />
<br />
You can share your internet connection (e.g. 3G or wired) with a few clicks. Please note that a [[firewall]] may interfere with internet sharing.<br />
<br />
You will need a Wi-Fi card which supports AP mode, see [[Software access point#Wi-Fi device must support AP mode]] for details.<br />
<br />
[[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
<br />
Create the shared connection:<br />
<br />
* Click on applet and choose ''Create new wireless network''.<br />
* Follow wizard (choose WPA2 or higher, be sure to use at least 8 character long password, lower lengths will fail).<br />
** Choose either [[Fedora:Features/RealHotspot|Hotspot]] or Ad-hoc as Wi-Fi mode.<br />
<br />
The connection will be saved and remain stored for the next time you need it.<br />
<br />
{{Note|Android does not support connecting to Ad-hoc networks. To share a connection with Android use infrastructure mode (i.e. set Wi-Fi mode to "Hotspot").}}<br />
<br />
=== Sharing internet connection over Ethernet ===<br />
<br />
Scenario: your device has internet connection over wi-fi and you want to share the internet connection to other devices over ethernet.<br />
<br />
Requirements:<br />
<br />
* [[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
* Your internet connected device and the other devices are connected over a suitable ethernet cable (this usually means a cross over cable or a switch in between).<br />
* Internet sharing is not blocked by a [[firewall]].<br />
<br />
Steps:<br />
<br />
{{Style|{{Pkg|nm-connection-editor}} is not a dependency of {{Pkg|networkmanager}} and needs to be installed separately.}}<br />
<br />
* Run {{ic|nm-connection-editor}} from terminal.<br />
* Add a new ethernet connection.<br />
* Give it some sensible name. For example "Shared Internet"<br />
* Go to "IPv4 Settings".<br />
* For "Method:" select "Shared to other computers".<br />
* Save<br />
<br />
Now you should have a new option "Shared Internet" under the Wired connections in NetworkManager.<br />
<br />
=== Checking if networking is up inside a cron job or script ===<br />
<br />
{{Out of date|''nm-tool'' was remove from NetworkManager for long time now[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/bb8c75bd536d4f8fb80a4366025a279078f0ec81]. ''nmcli'' should be used instead.}}<br />
<br />
Some ''cron'' jobs require networking to be up to succeed. You may wish to avoid running these jobs when the network is down. To accomplish this, add an '''if''' test for networking that queries NetworkManager's ''nm-tool'' and checks the state of networking. The test shown here succeeds if any interface is up, and fails if they are all down. This is convenient for laptops that might be hardwired, might be on wireless, or might be off the network.<br />
<br />
{{bc|<nowiki><br />
if [ $(nm-tool|grep State|cut -f2 -d' ') == "connected" ]; then<br />
#Whatever you want to do if the network is online<br />
else<br />
#Whatever you want to do if the network is offline - note, this and the else above are optional<br />
fi<br />
</nowiki>}}<br />
<br />
This useful for a {{ic|cron.hourly}} script that runs ''fpupdate'' for the F-Prot virus scanner signature update, as an example. Another way it might be useful, with a little modification, is to differentiate between networks using various parts of the output from ''nm-tool''; for example, since the active wireless network is denoted with an asterisk, you could grep for the network name and then grep for a literal asterisk.<br />
<br />
=== Connect to network with secret on boot ===<br />
<br />
By default, NetworkManager will not connect to networks requiring a secret automatically on boot. This is because it locks such connections to the user who makes it by default, only connecting after they have logged in. To change this, do the following:<br />
<br />
# Right click on the {{ic|nm-applet}} icon in your panel and select Edit Connections and open the Wireless tab<br />
# Select the connection you want to work with and click the Edit button<br />
# Check the boxes “Connect Automatically” and “Available to all users”<br />
# Additionally, ensure that under "Wi-Fi Security", "Store password for all users (not encrypted)" is selected<br />
<br />
Log out and log back in to complete.<br />
<br />
=== OpenConnect with password in KWallet ===<br />
<br />
While you may type both values at connection time, {{Pkg|plasma-nm}} 0.9.3.2-1 and above are capable of retrieving OpenConnect username and password directly from [[KWallet]].<br />
<br />
Open "KDE Wallet Manager" and look up your OpenConnect VPN connection under "Network Management|Maps". Click "Show values" and <br />
enter your credentials in key "VpnSecrets" in this form (replace ''username'' and ''password'' accordingly):<br />
<br />
form:main:username%SEP%''username''%SEP%form:main:password%SEP%''password''<br />
<br />
Next time you connect, username and password should appear in the "VPN secrets" dialog box.<br />
<br />
=== Ignore specific devices ===<br />
<br />
Sometimes it may be desired that NetworkManager ignores specific devices and does not try to configure addresses and routes for them. You can quickly and easily ignore devices by MAC or interface-name by using the following in {{ic|/etc/NetworkManager/conf.d/unmanaged.conf}}:<br />
<br />
[keyfile]<br />
unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth0<br />
<br />
After editing the file, run {{ic|nmcli general reload}} as root. Afterwards you should be able to configure interfaces without NetworkManager altering what you have set.<br />
<br />
=== Configuring MAC address randomization ===<br />
<br />
{{Note|1=Disabling MAC address randomization may be needed to get (stable) link connection [https://bbs.archlinux.org/viewtopic.php?id=220101] and/or networks that restrict devices based on their MAC Address or have a limit network capacity.}}<br />
<br />
MAC randomization can be used for increased privacy by not disclosing your real MAC address to the network.<br />
<br />
NetworkManager supports two types MAC Address Randomization: randomization during scanning, and for network connections. Both modes can be configured by modifying {{ic|/etc/NetworkManager/NetworkManager.conf}} or by creating a separate configuration file in {{ic|/etc/NetworkManager/conf.d/}} which is recommended since the aforementioned config file may be overwritten by NetworkManager.<br />
<br />
Randomization during Wi-Fi scanning is enabled by default, but it may be disabled by adding the following lines to {{ic|/etc/NetworkManager/NetworkManager.conf}} or a dedicated configuration file under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device]<br />
wifi.scan-rand-mac-address=no<br />
}}<br />
<br />
MAC randomization for network connections can be set to different modes for both wireless and ethernet interfaces. See the [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details on the different modes. <br />
<br />
In terms of MAC randomization the most important modes are {{ic|stable}} and {{ic|random}}. {{ic|stable}} generates a random MAC address when you connect to a new network and associates the two permanently. This means that you will use the same MAC address every time you connect to that network. In contrast, {{ic|random}} will generate a new MAC address every time you connect to a network, new or previously known. You can configure the MAC randomization by adding the desired configuration under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device-mac-randomization]<br />
# "yes" is already the default for scanning<br />
wifi.scan-rand-mac-address=yes<br />
<br />
[connection-mac-randomization]<br />
# Randomize MAC for every ethernet connection<br />
ethernet.cloned-mac-address=random<br />
# Generate a random MAC for each WiFi and associate the two permanently.<br />
wifi.cloned-mac-address=stable<br />
}}<br />
<br />
See the following [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details.<br />
<br />
=== Enable IPv6 Privacy Extensions ===<br />
<br />
See [[IPv6#NetworkManager]].<br />
<br />
=== Working with wired connections ===<br />
<br />
By default, NetworkManager generates a connection profile for each wired ethernet connection it finds. At the point when generating the connection, it does not know whether there will be more ethernet adapters available. Hence, it calls the first wired connection "Wired connection 1". You can avoid generating this connection, by configuring {{ic|no-auto-default}} (see {{man|5|NetworkManager.conf}}), or by simply deleting it. Then NetworkManager will remember not to generate a connection for this interface again.<br />
<br />
You can also edit the connection (and persist it to disk) or delete it. NetworkManager will not re-generate a new connection. Then you can change the name to whatever you want. You can use something like nm-connection-editor for this task.<br />
<br />
=== Using iwd as the Wi-Fi backend ===<br />
<br />
Install {{AUR|networkmanager-iwd}} or enable the experimental [[iwd]] backend creating the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_backend.conf|2=<br />
[device]<br />
wifi.backend=iwd<br />
}}<br />
<br />
=== Running in a network namespace ===<br />
<br />
If you would like to run NetworkManager inside a network namespace (e.g., to manage a specific device which should be use by selected applications), bring the device down before moving it to the namespace:<br />
<br />
$ ip link set dev ''MY_DEVICE'' down<br />
$ ip link set dev ''MY_DEVICE'' netns ''MY_NAMESPACE''<br />
$ ip netns exec ''MY_NAMESPACE'' NetworkManager<br />
...<br />
$ ip netns exec ''MY_NAMESPACE'' killall NetworkManager<br />
<br />
otherwise NetworkManager will later fail to establish the connection with a {{ic|device is strictly unmanaged}} error.<br />
<br />
== Troubleshooting ==<br />
<br />
=== No prompt for password of secured Wi-Fi networks ===<br />
<br />
When trying to connect to a secured Wi-Fi network, no prompt for a password is shown and no connection is established. This happens when no keyring package is installed. An easy solution is to install {{Pkg|gnome-keyring}}. If you want the passwords to be stored in encrypted form, follow [[GNOME Keyring]] to set up the ''gnome-keyring-daemon''.<br />
<br />
=== Network management disabled ===<br />
<br />
When NetworkManager shuts down but the pid (state) file is not removed, you will see a {{ic|Network management disabled}} message. If this happens, remove the file manually:<br />
<br />
# rm /var/lib/NetworkManager/NetworkManager.state<br />
<br />
=== Problems with internal DHCP client ===<br />
<br />
If you have problems with getting an IP address using the internal DHCP client, consider using another DHCP client, see [[#DHCP client]] for instructions. This workaround might solve problems in big wireless networks like eduroam.<br />
<br />
=== DHCP problems with dhclient ===<br />
<br />
If you have problems with getting an IP address via DHCP, try to add the following to your {{ic|/etc/dhclient.conf}}:<br />
<br />
interface "eth0" {<br />
send dhcp-client-identifier 01:''aa:bb:cc:dd:ee:ff'';<br />
}<br />
<br />
Where {{ic|''aa:bb:cc:dd:ee:ff''}} is the MAC address of this NIC. The MAC address can be found using the {{ic|ip link show ''interface''}} command from the {{Pkg|iproute2}} package.<br />
<br />
=== 3G modem not detected ===<br />
<br />
See [[USB 3G Modem#NetworkManager]].<br />
<br />
=== Switching off WLAN on laptops ===<br />
<br />
Sometimes NetworkManager will not work when you disable your Wi-Fi adapter with a switch on your laptop and try to enable it again afterwards. This is often a problem with ''rfkill''. To check if the driver notifies ''rfkill'' about the wireless adapter's status, use:<br />
<br />
$ watch -n1 rfkill list all<br />
<br />
If one identifier stays blocked after you switch on the adapter you could try to manually unblock it with (where X is the number of the identifier provided by the above output):<br />
<br />
# rfkill event unblock X<br />
<br />
=== Static IP address settings revert to DHCP ===<br />
<br />
Due to an unresolved bug, when changing default connections to a static IP address, {{ic|nm-applet}} may not properly store the configuration change, and will revert to automatic DHCP.<br />
<br />
To work around this issue you have to edit the default connection (e.g. "Auto eth0") in {{ic|nm-applet}}, change the connection name (e.g. "my eth0"), uncheck the "Available to all users" checkbox, change your static IP address settings as desired, and click '''Apply'''. This will save a new connection with the given name.<br />
<br />
Next, you will want to make the default connection not connect automatically. To do so, run {{ic|nm-connection-editor}} ('''not''' as root). In the connection editor, edit the default connection (e.g. "Auto eth0") and uncheck "Connect automatically". Click '''Apply''' and close the connection editor.<br />
<br />
=== Cannot edit connections as normal user ===<br />
<br />
See [[#Set up PolicyKit permissions]].<br />
<br />
=== Forget hidden wireless network ===<br />
<br />
Since hidden networks are not displayed in the selection list of the Wireless view, they cannot be forgotten (removed) with the GUI. You can delete one with the following command:<br />
<br />
# rm /etc/NetworkManager/system-connections/''SSID''<br />
<br />
This works for any other connection.<br />
<br />
=== VPN not working in GNOME ===<br />
<br />
When setting up OpenConnect or vpnc connections in NetworkManager while using GNOME, you will sometimes never see the dialog box pop up and the following error appears in {{ic|/var/log/errors.log}}:<br />
<br />
localhost NetworkManager[399]: <error> [1361719690.10506] [nm-vpn-connection.c:1405] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.<br />
<br />
This is caused by the GNOME NM Applet expecting dialog scripts to be at {{ic|/usr/lib/gnome-shell}}, when NetworkManager's packages put them in {{ic|/usr/lib/networkmanager}}.<br />
As a "temporary" fix (this bug has been around for a while now), make the following symlink(s):<br />
<br />
* For OpenConnect: {{ic|ln -s /usr/lib/networkmanager/nm-openconnect-auth-dialog /usr/lib/gnome-shell/}}<br />
* For VPNC (i.e. Cisco VPN): {{ic|ln -s /usr/lib/networkmanager/nm-vpnc-auth-dialog /usr/lib/gnome-shell/}}<br />
<br />
This may need to be done for any other NM VPN plugins as well, but these are the two most common.<br />
<br />
=== Unable to connect to visible European wireless networks ===<br />
<br />
WLAN chips are shipped with a default [[Wireless network configuration#Respecting the regulatory domain|regulatory domain]]. If your access point does not operate within these limitations, you will not be able to connect to the network. Fixing this is easy:<br />
<br />
# [[Install]] {{Pkg|crda}}<br />
# Uncomment the correct Country Code in {{ic|/etc/conf.d/wireless-regdom}}<br />
# Reboot the system, because the setting is only read on boot<br />
<br />
=== Automatic connect to VPN on boot is not working ===<br />
<br />
The problem occurs when the system (i.e. NetworkManager running as the root user) tries to establish a VPN connection, but the password is not accessible because it is stored in the GNOME keyring of a particular user. <br />
<br />
A solution is to keep the password to your VPN in plaintext, as described in step (2.) of [[#Use dispatcher to connect to a VPN after a network connection is established]]. <br />
<br />
You do not need to use the dispatcher described in step (1.) to auto-connect anymore, if you use the new "auto-connect VPN" option from the {{ic|nm-applet}} GUI.<br />
<br />
=== Systemd Bottleneck ===<br />
<br />
Over time the log files ({{ic|/var/log/journal}}) can become very large. This can have a big impact on boot performance when using NetworkManager, see: [[Systemd#Boot time increasing over time]].<br />
<br />
=== Regular network disconnects, latency and lost packets (WiFi) ===<br />
<br />
NetworkManager does a scan every 2 minutes.<br />
<br />
Some WiFi drivers have issues when scanning for base stations whilst connected/associated. Symptoms include VPN disconnects/reconnects and lost packets, web pages failing to load and then refresh fine.<br />
<br />
Running {{ic|journalctl -f}} will indicate that this is taking place, messages like the following will be contained in the logs at regular intervals.<br />
<br />
NetworkManager[410]: <info> (wlp3s0): roamed from BSSID 00:14:48:11:20:CF (my-wifi-name) to (none) ((none))<br />
<br />
There is a patched version of NetworkManager which should prevent this type of scanning: {{AUR|networkmanager-noscan}}.<br />
<br />
Alternatively, if roaming is not important, the periodic scanning behavior can be disabled by locking the BSSID of the access point in the WiFi connection profile.<br />
<br />
=== Unable to turn on wi-fi with Lenovo laptop (IdeaPad, Legion, etc.) ===<br />
<br />
There is an issue with the {{ic|ideapad_laptop}} module on some Lenovo models due to the wi-fi driver incorrectly reporting a soft block. The card can still be manipulated with {{ic|netctl}}, but managers like NetworkManager break. You can verify that this is the problem by checking the output of {{ic|rfkill list}} after toggling your hardware switch and seeing that the soft block persists.<br />
<br />
{{Accuracy|Try to use {{ic|rfkill.default_state}} and {{ic|rfkill.master_switch_mode}} (see [https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt kernel-parameters.txt]) to fix the rfkill problem.}}<br />
<br />
[[modprobe|Unloading]] the {{ic|ideapad_laptop}} module should fix this. ('''warning''': this may disable the laptop keyboard and touchpad also!).<br />
<br />
=== Turn off hostname sending ===<br />
<br />
NetworkManager by default sends the hostname to the DHCP server. Hostname sending can only be disabled per connection not globally ([https://bugzilla.gnome.org/show_bug.cgi?id=768076 GNOME Bug 768076]).<br />
<br />
To disable sending your hostname to the DHCP server for a specific connection, add the following to your network connection file:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''your_connection_file''|2=<br />
...<br />
[ipv4]<br />
dhcp-send-hostname=false<br />
...<br />
[ipv6]<br />
dhcp-send-hostname=false<br />
...<br />
}}<br />
<br />
=== nm-applet disappears in i3wm ===<br />
<br />
If you use the {{ic|xfce4-notifyd.service}} for notifications you must [[edit]] the unit and add the following:<br />
<br />
{{hc|/etc/systemd/user/xfce4-notifyd.service.d/display_env.conf|2=<br />
[Service]<br />
Environment="DISPLAY=:0.0"<br />
}}<br />
<br />
After reloading the daemons [[restart]] {{ic|xfce4-notifyd.service}}. Exit i3 and start it back up again and the applet should show on the tray.<br />
<br />
=== nm-applet tray icons display wrongly ===<br />
<br />
Currently the tray icons of nm-applet are drawn on top of one another, i.e. the icon displaying wireless strength might show on top of the icon indicating no wired connection.<br />
This is apparently a GTK3 bug/problem: https://gitlab.gnome.org/GNOME/gtk/issues/1280 .<br />
<br />
A patched version of GTK3 exists in AUR, which apparently fixes the tray icon bug: {{AUR|gtk3-mushrooms}} .<br />
<br />
=== Unit dbus-org.freedesktop.resolve1.service not found ===<br />
<br />
If {{ic|systemd-resolved.service}} is not started, NetworkManager will try to start it using D-Bus and fail:<br />
<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
dbus-daemon[991]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
<br />
This is because NetworkManager will try to send DNS information to [[systemd-resolved]] regardless of the {{ic|1=main.dns=}} setting in {{man|5|NetworkManager.conf}}.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383]<br />
<br />
This can be disabled with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/no-systemd-resolved.conf|2=<br />
[main]<br />
systemd-resolved=false<br />
}}<br />
<br />
See {{Bug|62138}}.<br />
<br />
=== Secrets were required, but not provided ===<br />
<br />
If you attempt to connect to a network using {{ic|nmcli device wifi connect ''SSID'' password ''password''}} and received the following error:<br />
<br />
Error: Connection activation failed: (7) Secrets were required, but not provided<br />
<br />
The error can be resolved by deleting the connection profile and creating a new one:<br />
<br />
$ nmcli connection delete ''SSID''<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
=== WPA Enterprise connection with NetworkManager ===<br />
<br />
If you try to connect to an WPA Enterprise network like 'eduroam' with NetworkManager with the [[iwd]] backend then you will get the following error from NetworkManager:<br />
<br />
Connection 'eduroam' is not avialable on device wlan0 because profile is not compatible with device (802.1x connections must have IWD provisioning files)<br />
<br />
This is because NetworkManager can not configure a WPA Enterprise network. Therefore you have to configure it using an iwd config file {{ic|/var/lib/iwd/''essid''.8021x}} like described in [[iwd#WPA Enterprise]].<br />
<br />
== See also ==<br />
<br />
* [https://blogs.gnome.org/dcbw/2015/02/16/networkmanager-for-administrators-part-1/ NetworkManager for Administrators Part 1]<br />
* [[Wikipedia:NetworkManager]]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=NetworkManager&diff=627200NetworkManager2020-07-30T13:10:29Z<p>Tobbebobbe: /* Automatically connect to VNP */ corrected highlight</p>
<hr />
<div>[[Category:Network managers]]<br />
[[Category:Red Hat]]<br />
[[cs:NetworkManager]]<br />
[[de:Networkmanager]]<br />
[[es:NetworkManager]]<br />
[[fr:NetworkManager]]<br />
[[it:NetworkManager]]<br />
[[ja:NetworkManager]]<br />
[[pt:NetworkManager]]<br />
[[zh-hans:NetworkManager]]<br />
{{Related articles start}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related articles end}}<br />
[https://wiki.gnome.org/Projects/NetworkManager/ NetworkManager] is a program for providing detection and configuration for systems to automatically connect to networks. NetworkManager's functionality can be useful for both wireless and wired networks. For wireless networks, NetworkManager prefers known wireless networks and has the ability to switch to the most reliable network. NetworkManager-aware applications can switch from online and offline mode. NetworkManager also prefers wired connections over wireless ones, has support for modem connections and certain types of VPN. NetworkManager was originally developed by Red Hat and now is hosted by the [[GNOME]] project.<br />
<br />
{{Expansion|Clear text storage of secrets is not limited to just Wi-Fi passwords. The secrets are stored in files (and folder) only accesible to root.}}<br />
<br />
{{Warning|By default, Wi-Fi passwords are stored in clear text, see [[#Encrypted Wi-Fi passwords]].}}<br />
<br />
== Installation ==<br />
<br />
NetworkManager can be [[install]]ed with the package {{Pkg|networkmanager}}, which contains a daemon, a command line interface ({{ic|nmcli}}) and a curses‐based interface ({{ic|nmtui}}). <br />
<br />
=== Enable NetworkManager ===<br />
<br />
After installation, you should [[start/enable]] {{ic|NetworkManager.service}}. Once the NetworkManager daemon is started, it will automatically connect to any available "system connections" that have already been configured. Any "user connections" or unconfigured connections will need ''nmcli'' or an applet to configure and connect.<br />
<br />
=== Additional interfaces ===<br />
<br />
* {{Pkg|nm-connection-editor}} for a graphical user interface,<br />
* {{Pkg|network-manager-applet}} for a system tray applet ({{ic|nm-applet}}).<br />
<br />
{{Note|You must ensure that no other service that wants to configure the network is running; in fact, multiple networking services will conflict. You can find a list of the currently running services with {{ic|1=systemctl --type=service}} and then [[stop]] them. See [[#Configuration]] to enable the NetworkManager service.}}<br />
<br />
=== Mobile broadband support ===<br />
<br />
[[Install]] {{Pkg|modemmanager}}, {{Pkg|mobile-broadband-provider-info}} and {{Pkg|usb_modeswitch}} packages for mobile broadband connection support. See [[USB 3G Modem#NetworkManager]] for details.<br />
<br />
=== PPPoE / DSL support ===<br />
<br />
[[Install]] {{Pkg|rp-pppoe}} package for PPPoE / DSL connection support. To actually add PPPoE connection, use {{ic|1=nm-connection-editor}} and add new DSL/PPPoE connection.<br />
<br />
=== VPN support ===<br />
<br />
NetworkManager since version 1.16 has native support for [[WireGuard]], all it needs is the {{ic|wireguard}} kernel module. Read the [https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-networkmanager/ WireGuard in NetworkManager blog post] for details.<br />
<br />
Support for other VPN types is based on a plug-in system. They are provided in the following packages:<br />
<br />
* {{Pkg|networkmanager-openconnect}} for [[OpenConnect]]<br />
* [[networkmanager-openvpn]] for [[OpenVPN]]<br />
* {{Pkg|networkmanager-pptp}} for [[PPTP Client]]<br />
* {{Pkg|networkmanager-vpnc}} for [[Vpnc]]<br />
* {{Pkg|networkmanager-strongswan}} for [[strongSwan]]<br />
* {{AUR|networkmanager-fortisslvpn-git}}<br />
* {{AUR|networkmanager-iodine-git}}<br />
* {{AUR|networkmanager-libreswan}}<br />
* {{AUR|networkmanager-l2tp}}<br />
* {{AUR|networkmanager-ssh-git}}<br />
* {{Pkg|network-manager-sstp}}<br />
<br />
{{Warning|1=There are a lot of [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues?search=VPN&state=opened bugs] (and [https://bugzilla.gnome.org/buglist.cgi?bug_status=__open__&content=VPN&product=NetworkManager old bugs]) related to VPN support. Check the daemon processes options set via the GUI correctly and double-check with each package release.}}<br />
<br />
{{Note|To have fully functioning DNS resolution when using VPN, you should set up [[#DNS caching and conditional forwarding|conditional forwarding]].}}<br />
<br />
== Usage ==<br />
<br />
NetworkManager comes with {{man|1|nmcli}} and {{man|1|nmtui}}.<br />
<br />
=== nmcli examples ===<br />
<br />
List nearby wifi networks:<br />
<br />
$ nmcli device wifi list<br />
<br />
Connect to a wifi network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
Connect to a hidden network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' hidden yes<br />
<br />
Connect to a wifi on the {{ic|wlan1}} wifi interface:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' ifname wlan1 ''profile_name''<br />
<br />
Disconnect an interface:<br />
<br />
$ nmcli device disconnect ifname eth0<br />
<br />
Reconnect an interface marked as disconnected:<br />
<br />
$ nmcli connection up uuid ''UUID''<br />
<br />
Get a list of UUIDs:<br />
<br />
$ nmcli connection show<br />
<br />
See a list of network devices and their state:<br />
<br />
$ nmcli device<br />
<br />
Turn off wifi:<br />
<br />
$ nmcli radio wifi off<br />
<br />
=== Edit a connection ===<br />
<br />
For a comprehensive list of settings, see {{man|5|nm-settings}}.<br />
<br />
Firstly you need to get list of connections:<br />
<br />
{{hc|$ nmcli connection|<nowiki><br />
NAME UUID TYPE DEVICE<br />
Wired connection 2 e7054040-a421-3bef-965d-bb7d60b7cecf ethernet enp5s0<br />
Wired connection 1 997f2782-f0fc-301d-bfba-15421a2735d8 ethernet enp0s25<br />
MY-HOME-WIFI-5G 92a0f7b3-2eba-49ab-a899-24d83978f308 wifi --<br />
</nowiki>}}<br />
<br />
Here you can use the first column as connection-id used later. In this example we pick {{ic|Wired connection 2}} as a connection-id.<br />
<br />
You have three methods to configure a connection {{ic|Wired connection 2}} after it has been created:<br />
<br />
; nmcli interactive editor<br />
: {{ic|nmcli connection edit 'Wired connection 2'}}.<br> Usage is well documented from the editor.<br />
<br />
; nmcli command line interface<br />
: {{ic|nmcli connection modify 'Wired connection 2' ''setting''.''property'' ''value''}}. See {{man|1|nmcli}} for usage. For example you can change its IPv4 route metric to 200 using {{ic|nmcli connection modify 'Wired connection 2' ipv4.route-metric 200}} command.<br />
<br />
; Connection file<br />
: In {{ic|/etc/NetworkManager/system-connections/}}, modify the corresponding {{ic|Wired connection 2.nmconnection}} file .<br> Do not forget to reload the configuration file with {{ic|nmcli connection reload}}.<br />
<br />
== Front-ends ==<br />
<br />
To configure and have easy access to NetworkManager, most users will want to install an applet. This GUI front-end usually resides in the system tray (or notification area) and allows network selection and configuration of NetworkManager. Various desktop environments have their own applet. Otherwise you can use [[#nm-applet]].<br />
<br />
=== GNOME ===<br />
<br />
[[GNOME]] has a built-in tool, accessible from the Network settings.<br />
<br />
=== KDE Plasma ===<br />
<br />
[[Install]] the {{Pkg|plasma-nm}} package. After that, add it to the KDE taskbar via the ''Panel options > Add widgets > Networks'' menu.<br />
<br />
=== nm-applet ===<br />
<br />
{{Pkg|network-manager-applet}} is a GTK 3 front-end which works under Xorg environments with a systray.<br />
<br />
To store connection secrets install and configure [[GNOME/Keyring]].<br />
<br />
Be aware that after enabling the tick-box option {{ic|Make available to other users}} for a connection, NetworkManager stores the password in plain-text, though the respective file is accessible only to root (or other users via {{ic|nm-applet}}). See [[#Encrypted Wi-Fi passwords]].<br />
<br />
In order to run {{ic|nm-applet}} without a systray, you can use {{Pkg|trayer}} or {{Pkg|stalonetray}}. For example, you can add a script like this one in your path:<br />
<br />
{{hc|nmgui|<nowiki><br />
#!/bin/sh<br />
nm-applet 2>&1 > /dev/null &<br />
stalonetray 2>&1 > /dev/null<br />
killall nm-applet<br />
</nowiki>}}<br />
<br />
When you close the ''stalonetray'' window, it closes {{ic|nm-applet}} too, so no extra memory is used once you are done with network settings.<br />
<br />
The applet can show notifications for events such as connecting to or disconnecting from a WiFi network. For these notifications to display, ensure that you have a notification server installed - see [[Desktop notifications]]. If you use the applet without a notification server, you might see some messages in stdout/stderr, and the app might hang. See [https://bugzilla.gnome.org/show_bug.cgi?id=788313].<br />
<br />
In order to run {{ic|nm-applet}} with such notifications disabled, start the applet with the following command:<br />
<br />
$ nm-applet --no-agent<br />
<br />
{{Tip|{{ic|nm-applet}} might be started automatically with a [[XDG Autostart|autostart desktop file]], to add the --no-agent option modify the Exec line there, i.e.<br />
<br />
{{bc|1=Exec=nm-applet --no-agent}}<br />
<br />
}}<br />
<br />
{{Warning|On [[i3]], if nm-applet is started with the {{ic|--no-agent}} option, it is not possible to connect to a new encrypted WiFi network by clicking on the item list because no password input dialogue window will pop out. [[journal]] will show {{ic|no secrets: No agents were available for this request}}.}}<br />
<br />
==== Appindicator ====<br />
<br />
As of version 1.18.0 Appindicator support is [https://github.com/archlinux/svntogit-packages/commit/7640a2bd557fe84813207ef4d5e35bb5aece6c54 available] in the official {{Pkg|network-manager-applet}} package. To use nm-applet in an Appindicator environment start the applet with the following command:<br />
<br />
$ nm-applet --indicator<br />
<br />
=== networkmanager-dmenu ===<br />
<br />
Alternatively there is {{AUR|networkmanager-dmenu-git}} which is a small script to manage NetworkManager connections with [[dmenu]] or [[rofi]] instead of {{ic|nm-applet}}. It provides all essential features such as connection to existing NetworkManager wifi or wired connections, connect to new wifi connections, requests passphrase if required, connect to existing VPN connections, enable/disable networking, launch ''nm-connection-editor'' GUI, connect to Bluetooth networks.<br />
<br />
== Configuration ==<br />
<br />
NetworkManager will require some additional steps to be able run properly. Make sure you have configured {{ic|/etc/hosts}} as described in [[Network configuration#Set the hostname]] section.<br />
<br />
NetworkManager has a global configuration file at {{ic|/etc/NetworkManager/NetworkManager.conf}}. Addition configuration files can be placed in {{ic|/etc/NetworkManager/conf.d/}}. Usually no configuration needs to be done to the global defaults.<br />
<br />
After editing a configuration file, the changes can be applied by running:<br />
<br />
# nmcli general reload<br />
<br />
=== Enable NetworkManager Wait Online ===<br />
<br />
{{Out of date|{{ic|NetworkManager.service}} has {{ic|1=Also=NetworkManager-wait-online.service}} in the {{ic|[Install]}} section.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/167e42a87e97ed7fb26a4263c22f1774716ac51b] If {{ic|NetworkManager.service}} was [[enable]]d before the change, it needs to be [[enable|reenabled]].}}<br />
<br />
If you have services which fail if they are started before the network is up, you may use {{ic|NetworkManager-wait-online.service}} in addition to {{ic|NetworkManager.service}}. This is, however, rarely necessary because most networked daemons start up okay, even if the network has not been configured yet.<br />
<br />
In some cases, the service will still fail to start successfully on boot due to the timeout setting in {{ic|/usr/lib/systemd/system/NetworkManager-wait-online.service}} being too short. Change the default timeout from 30 to a higher value.<br />
<br />
=== Set up PolicyKit permissions ===<br />
<br />
See [[General troubleshooting#Session permissions]] for setting up a working session.<br />
<br />
With a working session, you have several options for granting the necessary privileges to NetworkManager:<br />
<br />
* ''Option 1.'' Run a [[Polkit]] authentication agent when you log in, such as {{ic|/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1}} (part of {{Pkg|polkit-gnome}}). You will be prompted for your password whenever you add or remove a network connection.<br />
* ''Option 2.'' [[Users and groups#Group management|Add]] yourself to the {{ic|wheel}} group. You will not have to enter your password, but your user account may be granted other permissions as well, such as the ability to use [[sudo]] without entering the root password.<br />
* ''Option 3.'' [[Users and groups#Group management|Add]] yourself to the {{ic|network}} group and create the following file:<br />
<br />
{{hc|/etc/polkit-1/rules.d/50-org.freedesktop.NetworkManager.rules|<nowiki><br />
polkit.addRule(function(action, subject) {<br />
if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0 && subject.isInGroup("network")) {<br />
return polkit.Result.YES;<br />
}<br />
});<br />
</nowiki>}}<br />
<br />
: All users in the {{ic|network}} group will be able to add and remove networks without a password. This will not work under [[systemd]] if you do not have an active session with ''systemd-logind''.<br />
<br />
=== Proxy settings ===<br />
<br />
NetworkManager does not directly handle proxy settings, but if you are using [[GNOME]] or [[KDE]], you could use [http://marin.jb.free.fr/proxydriver/ proxydriver] which handles proxy settings using NetworkManager's information. proxydriver is found in the package {{AUR|proxydriver}}.<br />
<br />
In order for ''proxydriver'' to be able to change the proxy settings, you would need to execute this command, as part of the GNOME startup process (see [[GNOME#Autostart]]).<br />
<br />
xhost +si:localuser:''username''<br />
<br />
See also [[Proxy settings]].<br />
<br />
=== Checking connectivity ===<br />
<br />
NetworkManager can try to reach a page on Internet when connecting to a network. {{Pkg|networkmanager}} is configured by default in {{ic|/usr/lib/NetworkManager/conf.d/20-connectivity.conf}} to check connectivity to archlinux.org. To use a different webserver or disable connectivity checking create {{ic|/etc/NetworkManager/conf.d/20-connectivity.conf}}, see {{man|5|NetworkManager.conf|CONNECTIVITY SECTION}}. Below is an example of using GNOME servers (it does not require the use of [[GNOME]]):<br />
<br />
{{hc|/etc/NetworkManager/conf.d/20-connectivity.conf|<nowiki><br />
[connectivity]<br />
uri=http://nmcheck.gnome.org/check_network_status.txt<br />
</nowiki>}}<br />
<br />
{{Note|Although automatic connectivity checks are a potential privacy leak, the official archlinux.org default connectivity URL is committed to not logging any access. See [https://gitlab.archlinux.org/archlinux/infrastructure/-/commit/68fbaca2ef9f31f624f117899848f4288d6b39d1].}}<br />
<br />
=== Captive portals ===<br />
<br />
{{Style|Complex scripts should not be maintained on the wiki.}}<br />
<br />
For those behind a [[Wikipedia:Captive portal|captive portal]], the desktop manager may automatically open a window asking for credentials. If your desktop does not, you can use {{Pkg|capnet-assist}} package (however, it currently it has a broken NetworkManager dispatcher script). Alternatively, you can create a NetworkManager dispatcher script with the following content:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/90-open_captive_portal|<nowiki><br />
#!/bin/sh -e<br />
# Script to dispatch NetworkManager events<br />
#<br />
# Runs shows a login webpage on walled garden networks.<br />
# See NetworkManager(8) for further documentation of the dispatcher events.<br />
<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin<br />
<br />
if [ -x "/usr/bin/logger" ]; then<br />
logger="/usr/bin/logger -s -t captive-portal"<br />
else<br />
logger=":"<br />
fi<br />
<br />
wait_for_process() {<br />
PNAME=$1<br />
while [ -z "$(/usr/bin/pgrep $PNAME)" ]; do<br />
sleep 3;<br />
done<br />
}<br />
<br />
#launch the browser, but on boot we need to wait that nm-applet starts<br />
start_browser() {<br />
local user="$1"<br />
local display="$2"<br />
<br />
export DISPLAY="$display"<br />
wait_for_process nm-applet<br />
<br />
export XAUTHORITY="/home/$user/.Xauthority"<br />
<br />
$logger "Running browser as '$user' with display '$display' to login in captive portal"<br />
sudo -u "$user" --preserve-env=DISPLAY,XAUTHORITY -H xdg-open http://capnet.elementary.io 2>&1 > /dev/null<br />
}<br />
<br />
# Run the right scripts<br />
case "$2" in<br />
connectivity-change)<br />
$logger -p user.debug "dispatcher script triggered on connectivity change: $CONNECTIVITY_STATE"<br />
if [ "$CONNECTIVITY_STATE" = "PORTAL" ]; then<br />
# Match last column of who's output with ' :[at least one digit] '<br />
who | awk '$NF ~ /\(:[0-9]+\)/ { print $1 " " substr($NF, 2, length($NF)-2) };' | \<br />
while read user display; do<br />
start_browser $user $display || $logger -p user.err "Failed for user: '$user' display: '$display'"<br />
done<br />
fi<br />
;;<br />
*)<br />
# In a down phase<br />
exit 0<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
You will need to [[restart]] {{ic|NetworkManager.service}} or reboot for this to start working. Once you do, the dispatcher script should open a login window once it detects you are behind a captive portal.<br />
<br />
Another solution is {{AUR|captive-browser-git}} based on Google Chrome.<br />
<br />
=== DHCP client ===<br />
<br />
By default NetworkManager uses its internal DHCP client. The internal DHCPv4 plugin is based on the [https://nettools.github.io/n-dhcp4/ nettools' n-dhcp4] library, while the internal DHCPv6 plugin is made from code based on systemd-networkd.<br />
<br />
To use ISC’s DHCP client, [[install]] {{Pkg|dhclient}}. To change the DHCP client backend, set the option {{ic|1=main.dhcp=''dhcp_client_name''}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}. E.g.:<br />
<br />
{{hc|1=/etc/NetworkManager/conf.d/dhcp-client.conf|2=<br />
[main]<br />
dhcp=dhclient<br />
}}<br />
<br />
{{Note|<br />
* Do not enable the systemd units shipped with the {{Pkg|dhclient}} and {{Pkg|dhcpcd}} packages. They will conflict with NetworkManager, see the note in [[#Installation]] for details.<br />
* NetworkManger does not support dhcpcd ≥ 9.0.0. See {{Bug|66231}}.<br />
}}<br />
<br />
=== DNS management ===<br />
<br />
NetworkManager's DNS management is described in the GNOME project's wiki page—[https://wiki.gnome.org/Projects/NetworkManager/DNS Projects/NetworkManager/DNS].<br />
<br />
==== DNS caching and conditional forwarding ====<br />
<br />
NetworkManager has a plugin to enable DNS caching and conditional forwarding ([https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/143 previously] called "split DNS" in NetworkManager's documentation) using [[dnsmasq]] or [[systemd-resolved]]. The advantages of this setup is that DNS lookups will be cached, shortening resolve times, and DNS lookups of VPN hosts will be routed to the relevant VPN's DNS servers. This is especially useful if you are connected to more than one VPN.<br />
<br />
===== dnsmasq =====<br />
<br />
Make sure {{Pkg|dnsmasq}} has been installed. Then set {{ic|1=main.dns=dnsmasq}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=dnsmasq<br />
}}<br />
<br />
Now run {{ic|nmcli general reload}} as root. NetworkManager will automatically start dnsmasq and add {{ic|127.0.0.1}} to {{ic|/etc/resolv.conf}}. The original DNS servers can be found in {{ic|/run/NetworkManager/no-stub-resolv.conf}}. You can verify dnsmasq is being used by doing the same DNS lookup twice with {{ic|drill example.com}} and verifying the server and query times.<br />
<br />
{{Note|<br />
* You do not need to start {{ic|dnsmasq.service}} or edit {{ic|/etc/dnsmasq.conf}}. NetworkManager will start dnsmasq without using the systemd service and without reading the dnsmasq's default configuration file(s).<br />
* The dnsmasq instance started by NetworkManager will bind to {{ic|127.0.0.1:53}}, you cannot run any other software (including {{ic|dnsmasq.service}}) on the same address and port.<br />
}}<br />
<br />
====== Custom dnsmasq configuration ======<br />
<br />
Custom configurations can be created for ''dnsmasq'' by creating configuration files in {{ic|/etc/NetworkManager/dnsmasq.d/}}. For example, to change the size of the DNS cache (which is stored in RAM):<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/cache.conf|2=<br />
cache-size=1000<br />
}}<br />
<br />
{{Tip|Check the configuration file syntax with {{ic|1=dnsmasq --test --conf-file=/dev/null --conf-dir=/etc/NetworkManager/dnsmasq.d}}.}}<br />
<br />
See {{man|8|dnsmasq}} for all available options.<br />
<br />
====== IPv6 ======<br />
<br />
{{Accuracy|This does not solve the issue because NetworkManager does not add {{ic|::1}} to {{ic|/etc/resolv.conf}}. Unless {{ic|@::1}} is manually passed to drill, it will still fail with {{ic|Error: error sending query: No (valid) nameservers defined in the resolver}}.}}<br />
<br />
Enabling {{ic|dnsmasq}} in NetworkManager may break IPv6-only DNS lookups (i.e. {{ic|drill -6 [hostname]}}) which would otherwise work. In order to resolve this, creating the following file will configure ''dnsmasq'' to also listen to the IPv6 loopback:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/ipv6-listen.conf|2=<br />
listen-address=::1<br />
}}<br />
<br />
In addition, {{ic|dnsmasq}} also does not prioritize upstream IPv6 DNS. Unfortunately NetworkManager does not do this ([https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/936712 Ubuntu Bug]). A workaround would be to disable IPv4 DNS in the NetworkManager config, assuming one exists<br />
<br />
====== DNSSEC ======<br />
<br />
The dnsmasq instance started by NetworkManager by default will not validate [[DNSSEC]] since it is started with the {{ic|--proxy-dnssec}} option. It will trust whatever DNSSEC information it gets from the upstream DNS server.<br />
<br />
For dnsmasq to properly validate DNSSEC, thus breaking DNS resolution with name servers that do not support it, create the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/dnssec.conf|2=<br />
conf-file=/usr/share/dnsmasq/trust-anchors.conf<br />
dnssec<br />
}}<br />
<br />
===== systemd-resolved =====<br />
<br />
{{Expansion|NetworkManager 1.16 adds a new setting {{ic|main.systemd-resolved}}[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383] (enabled by default). It unconditionally sends DNS configuration to systemd-resolved. Related to "Preserving resolv.conf" from [[systemd-resolved#DNS]]?}}<br />
<br />
NetworkManager can use [[systemd-resolved]] as a DNS resolver and cache. Make sure that ''systemd-resolved'' is properly configured and that {{ic|systemd-resolved.service}} is [[started]] before using it.<br />
<br />
systemd-resolved will be used automatically if {{ic|/etc/resolv.conf}} is a [[Systemd-resolved#DNS|symlink]] to {{ic|/run/systemd/resolve/stub-resolv.conf}}, {{ic|/run/systemd/resolve/resolv.conf}} or {{ic|/usr/lib/systemd/resolv.conf}}.<br />
<br />
You can enable it explicitly by setting {{ic|1=main.dns=systemd-resolved}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=systemd-resolved<br />
}}<br />
<br />
===== DNS resolver with an openresolv subscriber =====<br />
<br />
If [[openresolv]] has a subscriber for your local [[DNS resolver]], set up the subscriber and [[#Use openresolv|configure NetworkManager to use openresolv]].<br />
<br />
Because NetworkManager advertises a single "interface" to ''resolvconf'', it is not possible to implement conditional forwarding between two NetworkManager connections. See [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 NetworkManager issue 153].<br />
<br />
This can be partially mitigated if you set {{ic|1=private="*"}} in {{ic|/etc/resolvconf.conf}}[https://roy.marples.name/projects/openresolv/configuration.html]. Any queries for domains that are not in search domain list will not get forwarded. They will be handled according to the local resolver's configuration, for example, forwarded to another DNS server or resolved recursively from the DNS root.<br />
<br />
==== Custom DNS servers ====<br />
<br />
===== Setting custom global DNS servers =====<br />
<br />
To set DNS servers for all connections, specify them in {{man|5|NetworkManager.conf}} using the syntax {{ic|1=servers=''serveripaddress1'',''serveripaddress2'',''serveripaddress3''}} in a section named {{ic|[global-dns-domain-*]}}. For example:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns-servers.conf|2=<br />
[global-dns-domain-*]<br />
servers=::1,127.0.0.1<br />
}}<br />
<br />
{{Note|<br />
* If you use [[#DNS caching and conditional forwarding|NetworkManager's dnsmasq or systemd-resolved plugin]] or [[#DNS resolver with an openresolv subscriber|openresolv subscribers]], then do not specify loopback addresses with the {{ic|1=servers=}} option, it can break DNS resolution.<br />
* The specified servers do not get sent to [[systemd-resolved]], the connection's DNS servers are used instead.<br />
}}<br />
<br />
===== Setting custom DNS servers in a connection =====<br />
<br />
====== Setting custom DNS servers in a connection (GUI) ======<br />
<br />
Setup will depend on the type of front-end used; the process usually involves right-clicking on the applet, editing (or creating) a profile, and then choosing DHCP type as ''Automatic (specify addresses)''. The DNS addresses will need to be entered and are usually in this form: {{ic|127.0.0.1, ''DNS-server-one'', ...}}.<br />
<br />
====== Setting custom DNS servers in a connection (nmcli / connection file) ======<br />
<br />
To setup DNS Servers per connection, you can use the {{ic|dns}} field (and the associated {{ic|dns-search}} and {{ic|dns-options}}) in the [[#Edit a connection|connection settings]]. <br />
<br />
If {{ic|method}} is set to {{ic|auto}} (when you use DHCP), you need to set {{ic|ignore-auto-dns}} to {{ic|yes}}.<br />
<br />
==== /etc/resolv.conf ====<br />
<br />
By default {{ic|/etc/resolv.conf}} is managed by ''NetworkManager'' unless it is a symlink.<br />
<br />
It can be configured to write it through [[#Use openresolv|openresolv]] or to [[#Unmanaged /etc/resolv.conf|not touch it at all]].<br />
<br />
Using openresolv allows NetworkManager to coexists with other ''resolvconf'' supporting software or, for example, to run a local DNS caching and split-DNS resolver for which openresolv has a [[openresolv#Subscribers|subscriber]].<br />
<br />
{{Note|Conditional forwarding is [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 not yet fully supported] when using NetworkManager with openresolv.}}<br />
<br />
''NetworkManager'' also offers hooks via so called dispatcher scripts that can be used to alter the {{ic|/etc/resolv.conf}} after network changes. See [[#Network services with NetworkManager dispatcher]] and {{man|8|NetworkManager}} for more information.<br />
<br />
{{Note|<br />
* If NetworkManager is configured to use either [[#dnsmasq|dnsmasq]] or [[#systemd-resolved|systemd-resolved]], then the appropriate loopback addresses will be written to {{ic|/etc/resolv.conf}}.<br />
* The {{ic|resolv.conf}} file NetworkManager writes or would write to {{ic|/etc/resolv.conf}} can be found at {{ic|/run/NetworkManager/resolv.conf}}.<br />
* A {{ic|resolv.conf}} file with the acquired name servers and search domains can be found at {{ic|/run/NetworkManager/no-stub-resolv.conf}}.<br />
}}<br />
<br />
===== Unmanaged /etc/resolv.conf =====<br />
<br />
To stop NetworkManager from touching {{ic|/etc/resolv.conf}}, set {{ic|1=main.dns=none}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=none<br />
}}<br />
<br />
{{Tip|You might also want to set {{ic|1=main.systemd-resolved=false}}, so that NetworkManager does not send the DNS configuration to [[systemd-resolved]].}}<br />
<br />
{{Note|See [[#DNS caching and conditional forwarding]], to configure NetworkManager using other DNS backends like [[dnsmasq]] and [[systemd-resolved]], instead of using {{ic|1=main.dns=none}}.}}<br />
<br />
After that {{ic|/etc/resolv.conf}} might be a broken symlink that you will need to remove. Then, just create a new {{ic|/etc/resolv.conf}} file.<br />
<br />
===== Use openresolv =====<br />
<br />
{{Note|Do not set {{ic|1=rc-manager=resolvconf}} when {{Pkg|systemd-resolvconf}} is installed. ''systemd-resolved'' provides limited support for the ''resolvconf'' interface and NetworkManager supports communicating with systemd-resolved through D-Bus without using ''resolvconf''.}}<br />
<br />
To configure NetworkManager to use [[openresolv]], set {{ic|1=main.rc-manager=resolvconf}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/rc-manager.conf|2=<br />
[main]<br />
rc-manager=resolvconf<br />
}}<br />
<br />
=== Firewall ===<br />
<br />
You can assign a [[firewalld]] zone based on your current connection. For example a restrictive firewall when at work, and a less restrictive one when at home.<br />
<br />
This can also be done with [[#Network services with NetworkManager dispatcher|NetworkManager dispatcher]].<br />
<br />
=== 802.1x / PEAP configuration ===<br />
<br />
A PEAP and 802.1x network can be added by adding a config file to {{ic|/etc/NetworkManager/system-connections/''name''}}.<br />
<br />
Here is an example configuration file for IPv4 with IPv6 disabled:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''name''|2=<br />
[ipv6]<br />
method=ignore<br />
<br />
[ipv4]<br />
method=auto<br />
<br />
[connection]<br />
#id=XXXXXXXXX<br />
#uuid=XXXXXXXXX<br />
type=802-11-wireless<br />
#timestamp=XXXX<br />
<br />
[802-11-wireless-security]<br />
key-mgmt=wpa-eap<br />
<br />
[802-11-wireless]<br />
ssid=ssid<br />
mode=infrastructure<br />
#seen-bssids=XXXXXXXXX<br />
security=802-11-wireless-security<br />
<br />
[802-1x]<br />
eap=peap;<br />
identity=user<br />
password=password<br />
phase2-auth=mschapv2<br />
}}<br />
<br />
The number sign (#) defines comments.<br />
<br />
=== Automatically connect to VNP ===<br />
<br />
NetworkManager can be set to automatically connect to a VPN when connecting to the internet, on a per network basis. While the VPN connection itself can be added in the Gnome gui, but to make it automatically use the VPN {{ic|nmcli}} must be used.<br />
<br />
First, make sure to make the VPN connection available to all users. In the Gnome gui this is a matter of checking a box under the {{ic|details}} tab. Then under the {{ic|Identity}} tab, in the password field, click the icon on the right side in the field, and set it to {{ic|Store the password for all users}}.<br />
<br />
Then use the {{ic|nmcli}} tool via command line:<br />
<br />
# nmcli connection<br />
<br />
To list your connections. Then enter configuration mode for the internet connection you want to automatically connect to a VPN<br />
<br />
# nmcli connection edit <NAME of Internet Connection><br />
<br />
Please note that it is the Internet connection and not the VPN you should edit. Here you do not need to use the UUID of the Internet connection, the NAME is fine. Then make the setting with the command:<br />
<br />
# set connection.secondaries <UUID of VPN><br />
<br />
Here the UUID of the VPN must be used, but {{ic|tab}} works for autocompletion.<br />
<br />
== Network services with NetworkManager dispatcher ==<br />
<br />
There are quite a few network services that you will not want running until NetworkManager brings up an interface. NetworkManager has the ability to start services when you connect to a network and stop them when you disconnect (e.g. when using [[NFS]], [[SMB]] and [[NTPd]]).<br />
<br />
To activate the feature you need to [[enable]] and [[start]] the {{ic|NetworkManager-dispatcher.service}}.<br />
<br />
Once the service is active, scripts can be added to the {{ic|/etc/NetworkManager/dispatcher.d}} directory.<br />
<br />
Scripts must be owned by '''root''', otherwise the dispatcher will not execute them. For added security, set group [[ownership]] to root as well:<br />
<br />
# chown root:root /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
Make sure the file has correct permissions:<br />
<br />
# chmod 755 /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
The scripts will be run in alphabetical order at connection time, and in reverse alphabetical order at disconnect time. To ensure what order they come up in, it is common to use numerical characters prior to the name of the script (e.g. {{ic|10-portmap}} or {{ic|30-netfs}} (which ensures that the ''portmapper'' is up before NFS mounts are attempted).<br />
<br />
Scripts will receive the following arguments:<br />
<br />
* '''Interface name:''' e.g. {{ic|eth0}}<br />
* '''Interface status:''' ''up'' or ''down''<br />
* '''VPN status:''' ''vpn-up'' or ''vpn-down''<br />
<br />
{{Warning|If you connect to foreign or public networks, be aware of what services you are starting and what servers you expect to be available for them to connect to. You could make a security hole by starting the wrong services while connected to a public network.}}<br />
<br />
=== Avoiding the dispatcher timeout ===<br />
<br />
If the above is working, then this section is not relevant. However, there is a general problem related to running dispatcher scripts which take longer to be executed. Initially an internal timeout of three seconds only was used. If the called script did not complete in time, it was killed. Later the timeout was extended to about 20 seconds (see the [https://bugzilla.redhat.com/show_bug.cgi?id=982734 Bugtracker] for more information). If the timeout still creates the problem, a work around may be to modify the dispatcher service file {{ic|/usr/lib/systemd/system/NetworkManager-dispatcher.service}} to remain active after exit: <br />
<br />
{{hc|/etc/systemd/system/NetworkManager-dispatcher.service.d/remain_after_exit.conf|2=<br />
[Service]<br />
RemainAfterExit=yes<br />
}}<br />
<br />
Now start and enable the modified {{ic|NetworkManager-dispatcher}} service.<br />
<br />
{{Warning|Adding the {{ic|RemainAfterExit}} line to it will prevent the dispatcher from closing. Unfortunately, the dispatcher '''has''' to close before it can run your scripts again. With it the dispatcher will not time out but it also will not close, which means that the scripts will only run once per boot. Therefore, do not add the line unless the timeout is definitely causing a problem.}}<br />
<br />
=== Dispatcher examples ===<br />
<br />
==== Mount remote folder with sshfs ====<br />
<br />
As the script is run in a very restrictive environment, you have to export {{ic|SSH_AUTH_SOCK}} in order to connect to your SSH agent. There are different ways to accomplish this, see [https://bbs.archlinux.org/viewtopic.php?pid=1042030#p1042030 this message] for more information. The example below works with [[GNOME Keyring]], and will ask you for the password if not unlocked already. In case NetworkManager connects automatically on login, it is likely ''gnome-keyring'' has not yet started and the export will fail (hence the sleep). The {{ic|UUID}} to match can be found with the command {{ic|nmcli connection status}} or {{ic|nmcli connection list}}. <br />
<br />
{{bc|<nowiki><br />
#!/bin/sh<br />
USER='username'<br />
REMOTE='user@host:/remote/path'<br />
LOCAL='/local/path'<br />
<br />
interface=$1 status=$2<br />
if [ "$CONNECTION_UUID" = "</nowiki>''uuid''<nowiki>" ]; then<br />
case $status in<br />
up)<br />
SSH_AUTH_SOCK=$(find /tmp -maxdepth 1 -type s -user "$USER" -name 'ssh')<br />
export SSH_AUTH_SOCK<br />
su "$USER" -c "sshfs $REMOTE $LOCAL"<br />
;;<br />
down)<br />
fusermount -u "$LOCAL"<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
==== Mounting of SMB shares ====<br />
<br />
Some [[SMB]] shares are only available on certain networks or locations (e.g. at home). You can use the dispatcher to only mount SMB shares that are present at your current location.<br />
<br />
The following script will check if we connected to a specific network and mount shares accordingly:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-mount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
# Find the connection UUID with "nmcli connection show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
if [ "$2" = "up" ]; then<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
mount /your/mount/point & <br />
# add more shares as needed<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The following script will unmount all SMB shares before a software initiated disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/pre-down.d/30-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|Make sure this script is located in the {{ic|pre-down.d}} sub-directory as shown above, otherwise it will unmount all shares on any connection state change.}}<br />
<br />
The following script will attempt to unmount all SMB shares following an unexpected disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/40-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
if [ "$2" = "down" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|<br />
* Since NetworkManager 0.9.8, the ''pre-down'' and ''down'' events are not executed on shutdown or restart, see [https://bugzilla.gnome.org/show_bug.cgi?id&#61;701242 this bug report] for more info.<br />
* The previous ''umount'' scripts are still prone to leaving applications actually accessing the mount to 'hang'.<br />
}}<br />
<br />
An alternative is to use the script as seen in [[NFS#Using a NetworkManager dispatcher]]:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-smb.sh|<nowiki><br />
#!/bin/bash<br />
<br />
# Find the connection UUID with "nmcli con show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
WANTED_CON_UUID="CHANGE-ME-NOW-9c7eff15-010a-4b1c-a786-9b4efa218ba9"<br />
<br />
if [[ "$CONNECTION_UUID" == "$WANTED_CON_UUID" ]]; then<br />
<br />
# Script parameter $1: NetworkManager connection name, not used<br />
# Script parameter $2: dispatched event<br />
<br />
case "$2" in<br />
"up")<br />
mount -a -t cifs<br />
;;<br />
"pre-down");&<br />
"vpn-pre-down")<br />
umount -l -a -t cifs >/dev/null<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|This script ignores mounts with the {{ic|noauto}} option, remove this mount option or use {{ic|auto}} to allow the dispatcher to manage these mounts.}}<br />
<br />
Create a symlink inside {{ic|/etc/NetworkManager/dispatcher.d/pre-down/}} to catch the {{ic|pre-down}} events:<br />
<br />
# ln -s ../30-smb.sh /etc/NetworkManager/dispatcher.d/pre-down.d/30-smb.sh<br />
<br />
==== Mounting of NFS shares ====<br />
<br />
See [[NFS#Using a NetworkManager dispatcher]].<br />
<br />
==== Use dispatcher to automatically toggle wireless depending on LAN cable being plugged in ====<br />
<br />
The idea is to only turn Wi-Fi on when the LAN cable is unplugged (for example when detaching from a laptop dock), and for Wi-Fi to be automatically disabled, once a LAN cable is plugged in again. <br />
<br />
Create the following dispatcher script[https://superuser.com/questions/233448/disable-wlan-if-wired-cable-network-is-available], replacing {{ic|1=LAN_interface}} with yours.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/wlan_auto_toggle.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$1" = "LAN_interface" ]; then<br />
case "$2" in<br />
up)<br />
nmcli radio wifi off<br />
;;<br />
down)<br />
nmcli radio wifi on<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|You can get a list of interfaces using [[#nmcli examples|nmcli]]. The ethernet (LAN) interfaces start with {{ic|en}}, e.g. {{ic|1=enp0s5}}}}<br />
<br />
==== Use dispatcher to connect to a VPN after a network connection is established ====<br />
<br />
In this example we want to connect automatically to a previously defined VPN connection after connecting to a specific Wi-Fi network. First thing to do is to create the dispatcher script that defines what to do after we are connected to the network.<br />
<br />
{{Note|This script will require {{Pkg|wireless_tools}} in order to use {{ic|iwgetid}}.}}<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME"<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you would like to attempt to automatically connect to VPN for all Wi-Fi networks, you can use the following definition of the ESSID: {{ic|1=ESSID=$(iwgetid -r)}}. Remember to set the script's permissions [[#Network services with NetworkManager dispatcher|accordingly]]. <br />
<br />
Trying to connect with the above script may still fail with {{ic|NetworkManager-dispatcher.service}} complaining about 'no valid VPN secrets', because of [https://developer.gnome.org/NetworkManager/0.9/secrets-flags.html the way VPN secrets are stored]. Fortunately, there are different options to give the above script access to your VPN password.<br />
<br />
1: One of them requires editing the VPN connection configuration file to make NetworkManager store the secrets by itself rather than inside a keyring [https://bugzilla.redhat.com/show_bug.cgi?id=710552 that will be inaccessible for root]: open up {{ic|/etc/NetworkManager/system-connections/''name of your VPN connection''}} and change the {{ic|password-flags}} and {{ic|secret-flags}} from {{ic|1}} to {{ic|0}}.<br />
<br />
If that alone does not work, you may have to create a {{ic|passwd-file}} in a safe location with the same permissions and ownership as the dispatcher script, containing the following:<br />
<br />
{{hc|/path/to/passwd-file|<br />
vpn.secrets.password:YOUR_PASSWORD<br />
}}<br />
<br />
The script must be changed accordingly, so that it gets the password from the file:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME" passwd-file /path/to/passwd-file<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
2: Alternatively, change the {{ic|password-flags}} and put the password directly in the configuration file adding the section {{ic|vpn-secrets}}:<br />
<br />
[vpn]<br />
....<br />
password-flags=0<br />
<br />
[vpn-secrets]<br />
password=''your_password''<br />
<br />
{{Note|It may now be necessary to re-open the NetworkManager connection editor and save the VPN passwords/secrets again.}}<br />
<br />
==== Use dispatcher to disable IPv6 on VPN provider connections ====<br />
<br />
Many [[:Category:VPN providers|commercial VPN providers]] support only IPv4. That means all IPv6 traffic bypasses the VPN and renders it virtually useless. To avoid this, dispatcher can be used to disable all IPv6 traffic for the time a VPN connection is up.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/10-vpn-ipv6|<nowiki><br />
#!/bin/sh<br />
<br />
case "$2" in<br />
vpn-up)<br />
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
vpn-down)<br />
echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
==== OpenNTPD ====<br />
<br />
See [[OpenNTPD#Using NetworkManager dispatcher]].<br />
<br />
== Testing ==<br />
<br />
NetworkManager applets are designed to load upon login so no further configuration should be necessary for most users. If you have already disabled your previous network settings and disconnected from your network, you can now test if NetworkManager will work. The first step is to [[start]] {{ic|NetworkManager.service}}.<br />
<br />
Some applets will provide you with a {{ic|.desktop}} file so that the NetworkManager applet can be loaded through the application menu. If it does not, you are going to either have to discover the command to use or logout and login again to start the applet. Once the applet is started, it will likely begin polling network connections with for auto-configuration with a DHCP server.<br />
<br />
To start the GNOME applet in non-xdg-compliant window managers like [[awesome]]:<br />
<br />
nm-applet --sm-disable &<br />
<br />
For static IP addresses, you will have to configure NetworkManager to understand them. The process usually involves right-clicking the applet and selecting something like 'Edit Connections'.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Encrypted Wi-Fi passwords ===<br />
<br />
By default, NetworkManager stores passwords in clear text in the connection files at {{ic|/etc/NetworkManager/system-connections/}}. To print the stored passwords, use the following command:<br />
<br />
# grep -r '^psk=' /etc/NetworkManager/system-connections/<br />
<br />
The passwords are accessible to the root user in the filesystem and to users with access to settings via the GUI (e.g. {{ic|nm-applet}}). <br />
<br />
It is preferable to save the passwords in encrypted form in a keyring instead of clear text. The downside of using a keyring is that the connections have to be set up for each user.<br />
<br />
==== Using GNOME Keyring ====<br />
<br />
The keyring daemon has to be started and the keyring needs to be unlocked for the following to work.<br />
<br />
Furthermore, NetworkManager needs to be configured not to store the password for all users. Using GNOME {{ic|nm-applet}}, run {{ic|nm-connection-editor}} from a terminal, select a network connection, click {{ic|Edit}}, select the {{ic|Wifi-Security}} tab and click on the right icon of password and check {{ic|Store the password only for this user}}.<br />
<br />
==== Using KDE Wallet ====<br />
<br />
Using KDE's {{Pkg|plasma-nm}}, click the applet, click on the top right {{ic|Settings}} icon, click on a network connection, in the {{ic|General settings}} tab, untick {{ic|all users may connect to this network}}. If the option is ticked, the passwords will still be stored in clear text, even if a keyring daemon is running.<br />
<br />
If the option was selected previously and you un-tick it, you may have to use the {{ic|reset}} option first to make the password disappear from the file. Alternatively, delete the connection first and set it up again.<br />
<br />
=== Sharing internet connection over Wi-Fi ===<br />
<br />
You can share your internet connection (e.g. 3G or wired) with a few clicks. Please note that a [[firewall]] may interfere with internet sharing.<br />
<br />
You will need a Wi-Fi card which supports AP mode, see [[Software access point#Wi-Fi device must support AP mode]] for details.<br />
<br />
[[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
<br />
Create the shared connection:<br />
<br />
* Click on applet and choose ''Create new wireless network''.<br />
* Follow wizard (choose WPA2 or higher, be sure to use at least 8 character long password, lower lengths will fail).<br />
** Choose either [[Fedora:Features/RealHotspot|Hotspot]] or Ad-hoc as Wi-Fi mode.<br />
<br />
The connection will be saved and remain stored for the next time you need it.<br />
<br />
{{Note|Android does not support connecting to Ad-hoc networks. To share a connection with Android use infrastructure mode (i.e. set Wi-Fi mode to "Hotspot").}}<br />
<br />
=== Sharing internet connection over Ethernet ===<br />
<br />
Scenario: your device has internet connection over wi-fi and you want to share the internet connection to other devices over ethernet.<br />
<br />
Requirements:<br />
<br />
* [[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
* Your internet connected device and the other devices are connected over a suitable ethernet cable (this usually means a cross over cable or a switch in between).<br />
* Internet sharing is not blocked by a [[firewall]].<br />
<br />
Steps:<br />
<br />
{{Style|{{Pkg|nm-connection-editor}} is not a dependency of {{Pkg|networkmanager}} and needs to be installed separately.}}<br />
<br />
* Run {{ic|nm-connection-editor}} from terminal.<br />
* Add a new ethernet connection.<br />
* Give it some sensible name. For example "Shared Internet"<br />
* Go to "IPv4 Settings".<br />
* For "Method:" select "Shared to other computers".<br />
* Save<br />
<br />
Now you should have a new option "Shared Internet" under the Wired connections in NetworkManager.<br />
<br />
=== Checking if networking is up inside a cron job or script ===<br />
<br />
{{Out of date|''nm-tool'' was remove from NetworkManager for long time now[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/bb8c75bd536d4f8fb80a4366025a279078f0ec81]. ''nmcli'' should be used instead.}}<br />
<br />
Some ''cron'' jobs require networking to be up to succeed. You may wish to avoid running these jobs when the network is down. To accomplish this, add an '''if''' test for networking that queries NetworkManager's ''nm-tool'' and checks the state of networking. The test shown here succeeds if any interface is up, and fails if they are all down. This is convenient for laptops that might be hardwired, might be on wireless, or might be off the network.<br />
<br />
{{bc|<nowiki><br />
if [ $(nm-tool|grep State|cut -f2 -d' ') == "connected" ]; then<br />
#Whatever you want to do if the network is online<br />
else<br />
#Whatever you want to do if the network is offline - note, this and the else above are optional<br />
fi<br />
</nowiki>}}<br />
<br />
This useful for a {{ic|cron.hourly}} script that runs ''fpupdate'' for the F-Prot virus scanner signature update, as an example. Another way it might be useful, with a little modification, is to differentiate between networks using various parts of the output from ''nm-tool''; for example, since the active wireless network is denoted with an asterisk, you could grep for the network name and then grep for a literal asterisk.<br />
<br />
=== Connect to network with secret on boot ===<br />
<br />
By default, NetworkManager will not connect to networks requiring a secret automatically on boot. This is because it locks such connections to the user who makes it by default, only connecting after they have logged in. To change this, do the following:<br />
<br />
# Right click on the {{ic|nm-applet}} icon in your panel and select Edit Connections and open the Wireless tab<br />
# Select the connection you want to work with and click the Edit button<br />
# Check the boxes “Connect Automatically” and “Available to all users”<br />
# Additionally, ensure that under "Wi-Fi Security", "Store password for all users (not encrypted)" is selected<br />
<br />
Log out and log back in to complete.<br />
<br />
=== OpenConnect with password in KWallet ===<br />
<br />
While you may type both values at connection time, {{Pkg|plasma-nm}} 0.9.3.2-1 and above are capable of retrieving OpenConnect username and password directly from [[KWallet]].<br />
<br />
Open "KDE Wallet Manager" and look up your OpenConnect VPN connection under "Network Management|Maps". Click "Show values" and <br />
enter your credentials in key "VpnSecrets" in this form (replace ''username'' and ''password'' accordingly):<br />
<br />
form:main:username%SEP%''username''%SEP%form:main:password%SEP%''password''<br />
<br />
Next time you connect, username and password should appear in the "VPN secrets" dialog box.<br />
<br />
=== Ignore specific devices ===<br />
<br />
Sometimes it may be desired that NetworkManager ignores specific devices and does not try to configure addresses and routes for them. You can quickly and easily ignore devices by MAC or interface-name by using the following in {{ic|/etc/NetworkManager/conf.d/unmanaged.conf}}:<br />
<br />
[keyfile]<br />
unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth0<br />
<br />
After editing the file, run {{ic|nmcli general reload}} as root. Afterwards you should be able to configure interfaces without NetworkManager altering what you have set.<br />
<br />
=== Configuring MAC address randomization ===<br />
<br />
{{Note|1=Disabling MAC address randomization may be needed to get (stable) link connection [https://bbs.archlinux.org/viewtopic.php?id=220101] and/or networks that restrict devices based on their MAC Address or have a limit network capacity.}}<br />
<br />
MAC randomization can be used for increased privacy by not disclosing your real MAC address to the network.<br />
<br />
NetworkManager supports two types MAC Address Randomization: randomization during scanning, and for network connections. Both modes can be configured by modifying {{ic|/etc/NetworkManager/NetworkManager.conf}} or by creating a separate configuration file in {{ic|/etc/NetworkManager/conf.d/}} which is recommended since the aforementioned config file may be overwritten by NetworkManager.<br />
<br />
Randomization during Wi-Fi scanning is enabled by default, but it may be disabled by adding the following lines to {{ic|/etc/NetworkManager/NetworkManager.conf}} or a dedicated configuration file under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device]<br />
wifi.scan-rand-mac-address=no<br />
}}<br />
<br />
MAC randomization for network connections can be set to different modes for both wireless and ethernet interfaces. See the [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details on the different modes. <br />
<br />
In terms of MAC randomization the most important modes are {{ic|stable}} and {{ic|random}}. {{ic|stable}} generates a random MAC address when you connect to a new network and associates the two permanently. This means that you will use the same MAC address every time you connect to that network. In contrast, {{ic|random}} will generate a new MAC address every time you connect to a network, new or previously known. You can configure the MAC randomization by adding the desired configuration under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device-mac-randomization]<br />
# "yes" is already the default for scanning<br />
wifi.scan-rand-mac-address=yes<br />
<br />
[connection-mac-randomization]<br />
# Randomize MAC for every ethernet connection<br />
ethernet.cloned-mac-address=random<br />
# Generate a random MAC for each WiFi and associate the two permanently.<br />
wifi.cloned-mac-address=stable<br />
}}<br />
<br />
See the following [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details.<br />
<br />
=== Enable IPv6 Privacy Extensions ===<br />
<br />
See [[IPv6#NetworkManager]].<br />
<br />
=== Working with wired connections ===<br />
<br />
By default, NetworkManager generates a connection profile for each wired ethernet connection it finds. At the point when generating the connection, it does not know whether there will be more ethernet adapters available. Hence, it calls the first wired connection "Wired connection 1". You can avoid generating this connection, by configuring {{ic|no-auto-default}} (see {{man|5|NetworkManager.conf}}), or by simply deleting it. Then NetworkManager will remember not to generate a connection for this interface again.<br />
<br />
You can also edit the connection (and persist it to disk) or delete it. NetworkManager will not re-generate a new connection. Then you can change the name to whatever you want. You can use something like nm-connection-editor for this task.<br />
<br />
=== Using iwd as the Wi-Fi backend ===<br />
<br />
Install {{AUR|networkmanager-iwd}} or enable the experimental [[iwd]] backend creating the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_backend.conf|2=<br />
[device]<br />
wifi.backend=iwd<br />
}}<br />
<br />
=== Running in a network namespace ===<br />
<br />
If you would like to run NetworkManager inside a network namespace (e.g., to manage a specific device which should be use by selected applications), bring the device down before moving it to the namespace:<br />
<br />
$ ip link set dev ''MY_DEVICE'' down<br />
$ ip link set dev ''MY_DEVICE'' netns ''MY_NAMESPACE''<br />
$ ip netns exec ''MY_NAMESPACE'' NetworkManager<br />
...<br />
$ ip netns exec ''MY_NAMESPACE'' killall NetworkManager<br />
<br />
otherwise NetworkManager will later fail to establish the connection with a {{ic|device is strictly unmanaged}} error.<br />
<br />
== Troubleshooting ==<br />
<br />
=== No prompt for password of secured Wi-Fi networks ===<br />
<br />
When trying to connect to a secured Wi-Fi network, no prompt for a password is shown and no connection is established. This happens when no keyring package is installed. An easy solution is to install {{Pkg|gnome-keyring}}. If you want the passwords to be stored in encrypted form, follow [[GNOME Keyring]] to set up the ''gnome-keyring-daemon''.<br />
<br />
=== Network management disabled ===<br />
<br />
When NetworkManager shuts down but the pid (state) file is not removed, you will see a {{ic|Network management disabled}} message. If this happens, remove the file manually:<br />
<br />
# rm /var/lib/NetworkManager/NetworkManager.state<br />
<br />
=== Problems with internal DHCP client ===<br />
<br />
If you have problems with getting an IP address using the internal DHCP client, consider using another DHCP client, see [[#DHCP client]] for instructions. This workaround might solve problems in big wireless networks like eduroam.<br />
<br />
=== DHCP problems with dhclient ===<br />
<br />
If you have problems with getting an IP address via DHCP, try to add the following to your {{ic|/etc/dhclient.conf}}:<br />
<br />
interface "eth0" {<br />
send dhcp-client-identifier 01:''aa:bb:cc:dd:ee:ff'';<br />
}<br />
<br />
Where {{ic|''aa:bb:cc:dd:ee:ff''}} is the MAC address of this NIC. The MAC address can be found using the {{ic|ip link show ''interface''}} command from the {{Pkg|iproute2}} package.<br />
<br />
=== 3G modem not detected ===<br />
<br />
See [[USB 3G Modem#NetworkManager]].<br />
<br />
=== Switching off WLAN on laptops ===<br />
<br />
Sometimes NetworkManager will not work when you disable your Wi-Fi adapter with a switch on your laptop and try to enable it again afterwards. This is often a problem with ''rfkill''. To check if the driver notifies ''rfkill'' about the wireless adapter's status, use:<br />
<br />
$ watch -n1 rfkill list all<br />
<br />
If one identifier stays blocked after you switch on the adapter you could try to manually unblock it with (where X is the number of the identifier provided by the above output):<br />
<br />
# rfkill event unblock X<br />
<br />
=== Static IP address settings revert to DHCP ===<br />
<br />
Due to an unresolved bug, when changing default connections to a static IP address, {{ic|nm-applet}} may not properly store the configuration change, and will revert to automatic DHCP.<br />
<br />
To work around this issue you have to edit the default connection (e.g. "Auto eth0") in {{ic|nm-applet}}, change the connection name (e.g. "my eth0"), uncheck the "Available to all users" checkbox, change your static IP address settings as desired, and click '''Apply'''. This will save a new connection with the given name.<br />
<br />
Next, you will want to make the default connection not connect automatically. To do so, run {{ic|nm-connection-editor}} ('''not''' as root). In the connection editor, edit the default connection (e.g. "Auto eth0") and uncheck "Connect automatically". Click '''Apply''' and close the connection editor.<br />
<br />
=== Cannot edit connections as normal user ===<br />
<br />
See [[#Set up PolicyKit permissions]].<br />
<br />
=== Forget hidden wireless network ===<br />
<br />
Since hidden networks are not displayed in the selection list of the Wireless view, they cannot be forgotten (removed) with the GUI. You can delete one with the following command:<br />
<br />
# rm /etc/NetworkManager/system-connections/''SSID''<br />
<br />
This works for any other connection.<br />
<br />
=== VPN not working in GNOME ===<br />
<br />
When setting up OpenConnect or vpnc connections in NetworkManager while using GNOME, you will sometimes never see the dialog box pop up and the following error appears in {{ic|/var/log/errors.log}}:<br />
<br />
localhost NetworkManager[399]: <error> [1361719690.10506] [nm-vpn-connection.c:1405] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.<br />
<br />
This is caused by the GNOME NM Applet expecting dialog scripts to be at {{ic|/usr/lib/gnome-shell}}, when NetworkManager's packages put them in {{ic|/usr/lib/networkmanager}}.<br />
As a "temporary" fix (this bug has been around for a while now), make the following symlink(s):<br />
<br />
* For OpenConnect: {{ic|ln -s /usr/lib/networkmanager/nm-openconnect-auth-dialog /usr/lib/gnome-shell/}}<br />
* For VPNC (i.e. Cisco VPN): {{ic|ln -s /usr/lib/networkmanager/nm-vpnc-auth-dialog /usr/lib/gnome-shell/}}<br />
<br />
This may need to be done for any other NM VPN plugins as well, but these are the two most common.<br />
<br />
=== Unable to connect to visible European wireless networks ===<br />
<br />
WLAN chips are shipped with a default [[Wireless network configuration#Respecting the regulatory domain|regulatory domain]]. If your access point does not operate within these limitations, you will not be able to connect to the network. Fixing this is easy:<br />
<br />
# [[Install]] {{Pkg|crda}}<br />
# Uncomment the correct Country Code in {{ic|/etc/conf.d/wireless-regdom}}<br />
# Reboot the system, because the setting is only read on boot<br />
<br />
=== Automatic connect to VPN on boot is not working ===<br />
<br />
The problem occurs when the system (i.e. NetworkManager running as the root user) tries to establish a VPN connection, but the password is not accessible because it is stored in the GNOME keyring of a particular user. <br />
<br />
A solution is to keep the password to your VPN in plaintext, as described in step (2.) of [[#Use dispatcher to connect to a VPN after a network connection is established]]. <br />
<br />
You do not need to use the dispatcher described in step (1.) to auto-connect anymore, if you use the new "auto-connect VPN" option from the {{ic|nm-applet}} GUI.<br />
<br />
=== Systemd Bottleneck ===<br />
<br />
Over time the log files ({{ic|/var/log/journal}}) can become very large. This can have a big impact on boot performance when using NetworkManager, see: [[Systemd#Boot time increasing over time]].<br />
<br />
=== Regular network disconnects, latency and lost packets (WiFi) ===<br />
<br />
NetworkManager does a scan every 2 minutes.<br />
<br />
Some WiFi drivers have issues when scanning for base stations whilst connected/associated. Symptoms include VPN disconnects/reconnects and lost packets, web pages failing to load and then refresh fine.<br />
<br />
Running {{ic|journalctl -f}} will indicate that this is taking place, messages like the following will be contained in the logs at regular intervals.<br />
<br />
NetworkManager[410]: <info> (wlp3s0): roamed from BSSID 00:14:48:11:20:CF (my-wifi-name) to (none) ((none))<br />
<br />
There is a patched version of NetworkManager which should prevent this type of scanning: {{AUR|networkmanager-noscan}}.<br />
<br />
Alternatively, if roaming is not important, the periodic scanning behavior can be disabled by locking the BSSID of the access point in the WiFi connection profile.<br />
<br />
=== Unable to turn on wi-fi with Lenovo laptop (IdeaPad, Legion, etc.) ===<br />
<br />
There is an issue with the {{ic|ideapad_laptop}} module on some Lenovo models due to the wi-fi driver incorrectly reporting a soft block. The card can still be manipulated with {{ic|netctl}}, but managers like NetworkManager break. You can verify that this is the problem by checking the output of {{ic|rfkill list}} after toggling your hardware switch and seeing that the soft block persists.<br />
<br />
{{Accuracy|Try to use {{ic|rfkill.default_state}} and {{ic|rfkill.master_switch_mode}} (see [https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt kernel-parameters.txt]) to fix the rfkill problem.}}<br />
<br />
[[modprobe|Unloading]] the {{ic|ideapad_laptop}} module should fix this. ('''warning''': this may disable the laptop keyboard and touchpad also!).<br />
<br />
=== Turn off hostname sending ===<br />
<br />
NetworkManager by default sends the hostname to the DHCP server. Hostname sending can only be disabled per connection not globally ([https://bugzilla.gnome.org/show_bug.cgi?id=768076 GNOME Bug 768076]).<br />
<br />
To disable sending your hostname to the DHCP server for a specific connection, add the following to your network connection file:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''your_connection_file''|2=<br />
...<br />
[ipv4]<br />
dhcp-send-hostname=false<br />
...<br />
[ipv6]<br />
dhcp-send-hostname=false<br />
...<br />
}}<br />
<br />
=== nm-applet disappears in i3wm ===<br />
<br />
If you use the {{ic|xfce4-notifyd.service}} for notifications you must [[edit]] the unit and add the following:<br />
<br />
{{hc|/etc/systemd/user/xfce4-notifyd.service.d/display_env.conf|2=<br />
[Service]<br />
Environment="DISPLAY=:0.0"<br />
}}<br />
<br />
After reloading the daemons [[restart]] {{ic|xfce4-notifyd.service}}. Exit i3 and start it back up again and the applet should show on the tray.<br />
<br />
=== nm-applet tray icons display wrongly ===<br />
<br />
Currently the tray icons of nm-applet are drawn on top of one another, i.e. the icon displaying wireless strength might show on top of the icon indicating no wired connection.<br />
This is apparently a GTK3 bug/problem: https://gitlab.gnome.org/GNOME/gtk/issues/1280 .<br />
<br />
A patched version of GTK3 exists in AUR, which apparently fixes the tray icon bug: {{AUR|gtk3-mushrooms}} .<br />
<br />
=== Unit dbus-org.freedesktop.resolve1.service not found ===<br />
<br />
If {{ic|systemd-resolved.service}} is not started, NetworkManager will try to start it using D-Bus and fail:<br />
<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
dbus-daemon[991]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
<br />
This is because NetworkManager will try to send DNS information to [[systemd-resolved]] regardless of the {{ic|1=main.dns=}} setting in {{man|5|NetworkManager.conf}}.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383]<br />
<br />
This can be disabled with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/no-systemd-resolved.conf|2=<br />
[main]<br />
systemd-resolved=false<br />
}}<br />
<br />
See {{Bug|62138}}.<br />
<br />
=== Secrets were required, but not provided ===<br />
<br />
If you attempt to connect to a network using {{ic|nmcli device wifi connect ''SSID'' password ''password''}} and received the following error:<br />
<br />
Error: Connection activation failed: (7) Secrets were required, but not provided<br />
<br />
The error can be resolved by deleting the connection profile and creating a new one:<br />
<br />
$ nmcli connection delete ''SSID''<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
=== WPA Enterprise connection with NetworkManager ===<br />
<br />
If you try to connect to an WPA Enterprise network like 'eduroam' with NetworkManager with the [[iwd]] backend then you will get the following error from NetworkManager:<br />
<br />
Connection 'eduroam' is not avialable on device wlan0 because profile is not compatible with device (802.1x connections must have IWD provisioning files)<br />
<br />
This is because NetworkManager can not configure a WPA Enterprise network. Therefore you have to configure it using an iwd config file {{ic|/var/lib/iwd/''essid''.8021x}} like described in [[iwd#WPA Enterprise]].<br />
<br />
== See also ==<br />
<br />
* [https://blogs.gnome.org/dcbw/2015/02/16/networkmanager-for-administrators-part-1/ NetworkManager for Administrators Part 1]<br />
* [[Wikipedia:NetworkManager]]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=NetworkManager&diff=627199NetworkManager2020-07-30T13:09:57Z<p>Tobbebobbe: /* Automatically connect to VNP */ corrected command line highlight</p>
<hr />
<div>[[Category:Network managers]]<br />
[[Category:Red Hat]]<br />
[[cs:NetworkManager]]<br />
[[de:Networkmanager]]<br />
[[es:NetworkManager]]<br />
[[fr:NetworkManager]]<br />
[[it:NetworkManager]]<br />
[[ja:NetworkManager]]<br />
[[pt:NetworkManager]]<br />
[[zh-hans:NetworkManager]]<br />
{{Related articles start}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related articles end}}<br />
[https://wiki.gnome.org/Projects/NetworkManager/ NetworkManager] is a program for providing detection and configuration for systems to automatically connect to networks. NetworkManager's functionality can be useful for both wireless and wired networks. For wireless networks, NetworkManager prefers known wireless networks and has the ability to switch to the most reliable network. NetworkManager-aware applications can switch from online and offline mode. NetworkManager also prefers wired connections over wireless ones, has support for modem connections and certain types of VPN. NetworkManager was originally developed by Red Hat and now is hosted by the [[GNOME]] project.<br />
<br />
{{Expansion|Clear text storage of secrets is not limited to just Wi-Fi passwords. The secrets are stored in files (and folder) only accesible to root.}}<br />
<br />
{{Warning|By default, Wi-Fi passwords are stored in clear text, see [[#Encrypted Wi-Fi passwords]].}}<br />
<br />
== Installation ==<br />
<br />
NetworkManager can be [[install]]ed with the package {{Pkg|networkmanager}}, which contains a daemon, a command line interface ({{ic|nmcli}}) and a curses‐based interface ({{ic|nmtui}}). <br />
<br />
=== Enable NetworkManager ===<br />
<br />
After installation, you should [[start/enable]] {{ic|NetworkManager.service}}. Once the NetworkManager daemon is started, it will automatically connect to any available "system connections" that have already been configured. Any "user connections" or unconfigured connections will need ''nmcli'' or an applet to configure and connect.<br />
<br />
=== Additional interfaces ===<br />
<br />
* {{Pkg|nm-connection-editor}} for a graphical user interface,<br />
* {{Pkg|network-manager-applet}} for a system tray applet ({{ic|nm-applet}}).<br />
<br />
{{Note|You must ensure that no other service that wants to configure the network is running; in fact, multiple networking services will conflict. You can find a list of the currently running services with {{ic|1=systemctl --type=service}} and then [[stop]] them. See [[#Configuration]] to enable the NetworkManager service.}}<br />
<br />
=== Mobile broadband support ===<br />
<br />
[[Install]] {{Pkg|modemmanager}}, {{Pkg|mobile-broadband-provider-info}} and {{Pkg|usb_modeswitch}} packages for mobile broadband connection support. See [[USB 3G Modem#NetworkManager]] for details.<br />
<br />
=== PPPoE / DSL support ===<br />
<br />
[[Install]] {{Pkg|rp-pppoe}} package for PPPoE / DSL connection support. To actually add PPPoE connection, use {{ic|1=nm-connection-editor}} and add new DSL/PPPoE connection.<br />
<br />
=== VPN support ===<br />
<br />
NetworkManager since version 1.16 has native support for [[WireGuard]], all it needs is the {{ic|wireguard}} kernel module. Read the [https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-networkmanager/ WireGuard in NetworkManager blog post] for details.<br />
<br />
Support for other VPN types is based on a plug-in system. They are provided in the following packages:<br />
<br />
* {{Pkg|networkmanager-openconnect}} for [[OpenConnect]]<br />
* [[networkmanager-openvpn]] for [[OpenVPN]]<br />
* {{Pkg|networkmanager-pptp}} for [[PPTP Client]]<br />
* {{Pkg|networkmanager-vpnc}} for [[Vpnc]]<br />
* {{Pkg|networkmanager-strongswan}} for [[strongSwan]]<br />
* {{AUR|networkmanager-fortisslvpn-git}}<br />
* {{AUR|networkmanager-iodine-git}}<br />
* {{AUR|networkmanager-libreswan}}<br />
* {{AUR|networkmanager-l2tp}}<br />
* {{AUR|networkmanager-ssh-git}}<br />
* {{Pkg|network-manager-sstp}}<br />
<br />
{{Warning|1=There are a lot of [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues?search=VPN&state=opened bugs] (and [https://bugzilla.gnome.org/buglist.cgi?bug_status=__open__&content=VPN&product=NetworkManager old bugs]) related to VPN support. Check the daemon processes options set via the GUI correctly and double-check with each package release.}}<br />
<br />
{{Note|To have fully functioning DNS resolution when using VPN, you should set up [[#DNS caching and conditional forwarding|conditional forwarding]].}}<br />
<br />
== Usage ==<br />
<br />
NetworkManager comes with {{man|1|nmcli}} and {{man|1|nmtui}}.<br />
<br />
=== nmcli examples ===<br />
<br />
List nearby wifi networks:<br />
<br />
$ nmcli device wifi list<br />
<br />
Connect to a wifi network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
Connect to a hidden network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' hidden yes<br />
<br />
Connect to a wifi on the {{ic|wlan1}} wifi interface:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' ifname wlan1 ''profile_name''<br />
<br />
Disconnect an interface:<br />
<br />
$ nmcli device disconnect ifname eth0<br />
<br />
Reconnect an interface marked as disconnected:<br />
<br />
$ nmcli connection up uuid ''UUID''<br />
<br />
Get a list of UUIDs:<br />
<br />
$ nmcli connection show<br />
<br />
See a list of network devices and their state:<br />
<br />
$ nmcli device<br />
<br />
Turn off wifi:<br />
<br />
$ nmcli radio wifi off<br />
<br />
=== Edit a connection ===<br />
<br />
For a comprehensive list of settings, see {{man|5|nm-settings}}.<br />
<br />
Firstly you need to get list of connections:<br />
<br />
{{hc|$ nmcli connection|<nowiki><br />
NAME UUID TYPE DEVICE<br />
Wired connection 2 e7054040-a421-3bef-965d-bb7d60b7cecf ethernet enp5s0<br />
Wired connection 1 997f2782-f0fc-301d-bfba-15421a2735d8 ethernet enp0s25<br />
MY-HOME-WIFI-5G 92a0f7b3-2eba-49ab-a899-24d83978f308 wifi --<br />
</nowiki>}}<br />
<br />
Here you can use the first column as connection-id used later. In this example we pick {{ic|Wired connection 2}} as a connection-id.<br />
<br />
You have three methods to configure a connection {{ic|Wired connection 2}} after it has been created:<br />
<br />
; nmcli interactive editor<br />
: {{ic|nmcli connection edit 'Wired connection 2'}}.<br> Usage is well documented from the editor.<br />
<br />
; nmcli command line interface<br />
: {{ic|nmcli connection modify 'Wired connection 2' ''setting''.''property'' ''value''}}. See {{man|1|nmcli}} for usage. For example you can change its IPv4 route metric to 200 using {{ic|nmcli connection modify 'Wired connection 2' ipv4.route-metric 200}} command.<br />
<br />
; Connection file<br />
: In {{ic|/etc/NetworkManager/system-connections/}}, modify the corresponding {{ic|Wired connection 2.nmconnection}} file .<br> Do not forget to reload the configuration file with {{ic|nmcli connection reload}}.<br />
<br />
== Front-ends ==<br />
<br />
To configure and have easy access to NetworkManager, most users will want to install an applet. This GUI front-end usually resides in the system tray (or notification area) and allows network selection and configuration of NetworkManager. Various desktop environments have their own applet. Otherwise you can use [[#nm-applet]].<br />
<br />
=== GNOME ===<br />
<br />
[[GNOME]] has a built-in tool, accessible from the Network settings.<br />
<br />
=== KDE Plasma ===<br />
<br />
[[Install]] the {{Pkg|plasma-nm}} package. After that, add it to the KDE taskbar via the ''Panel options > Add widgets > Networks'' menu.<br />
<br />
=== nm-applet ===<br />
<br />
{{Pkg|network-manager-applet}} is a GTK 3 front-end which works under Xorg environments with a systray.<br />
<br />
To store connection secrets install and configure [[GNOME/Keyring]].<br />
<br />
Be aware that after enabling the tick-box option {{ic|Make available to other users}} for a connection, NetworkManager stores the password in plain-text, though the respective file is accessible only to root (or other users via {{ic|nm-applet}}). See [[#Encrypted Wi-Fi passwords]].<br />
<br />
In order to run {{ic|nm-applet}} without a systray, you can use {{Pkg|trayer}} or {{Pkg|stalonetray}}. For example, you can add a script like this one in your path:<br />
<br />
{{hc|nmgui|<nowiki><br />
#!/bin/sh<br />
nm-applet 2>&1 > /dev/null &<br />
stalonetray 2>&1 > /dev/null<br />
killall nm-applet<br />
</nowiki>}}<br />
<br />
When you close the ''stalonetray'' window, it closes {{ic|nm-applet}} too, so no extra memory is used once you are done with network settings.<br />
<br />
The applet can show notifications for events such as connecting to or disconnecting from a WiFi network. For these notifications to display, ensure that you have a notification server installed - see [[Desktop notifications]]. If you use the applet without a notification server, you might see some messages in stdout/stderr, and the app might hang. See [https://bugzilla.gnome.org/show_bug.cgi?id=788313].<br />
<br />
In order to run {{ic|nm-applet}} with such notifications disabled, start the applet with the following command:<br />
<br />
$ nm-applet --no-agent<br />
<br />
{{Tip|{{ic|nm-applet}} might be started automatically with a [[XDG Autostart|autostart desktop file]], to add the --no-agent option modify the Exec line there, i.e.<br />
<br />
{{bc|1=Exec=nm-applet --no-agent}}<br />
<br />
}}<br />
<br />
{{Warning|On [[i3]], if nm-applet is started with the {{ic|--no-agent}} option, it is not possible to connect to a new encrypted WiFi network by clicking on the item list because no password input dialogue window will pop out. [[journal]] will show {{ic|no secrets: No agents were available for this request}}.}}<br />
<br />
==== Appindicator ====<br />
<br />
As of version 1.18.0 Appindicator support is [https://github.com/archlinux/svntogit-packages/commit/7640a2bd557fe84813207ef4d5e35bb5aece6c54 available] in the official {{Pkg|network-manager-applet}} package. To use nm-applet in an Appindicator environment start the applet with the following command:<br />
<br />
$ nm-applet --indicator<br />
<br />
=== networkmanager-dmenu ===<br />
<br />
Alternatively there is {{AUR|networkmanager-dmenu-git}} which is a small script to manage NetworkManager connections with [[dmenu]] or [[rofi]] instead of {{ic|nm-applet}}. It provides all essential features such as connection to existing NetworkManager wifi or wired connections, connect to new wifi connections, requests passphrase if required, connect to existing VPN connections, enable/disable networking, launch ''nm-connection-editor'' GUI, connect to Bluetooth networks.<br />
<br />
== Configuration ==<br />
<br />
NetworkManager will require some additional steps to be able run properly. Make sure you have configured {{ic|/etc/hosts}} as described in [[Network configuration#Set the hostname]] section.<br />
<br />
NetworkManager has a global configuration file at {{ic|/etc/NetworkManager/NetworkManager.conf}}. Addition configuration files can be placed in {{ic|/etc/NetworkManager/conf.d/}}. Usually no configuration needs to be done to the global defaults.<br />
<br />
After editing a configuration file, the changes can be applied by running:<br />
<br />
# nmcli general reload<br />
<br />
=== Enable NetworkManager Wait Online ===<br />
<br />
{{Out of date|{{ic|NetworkManager.service}} has {{ic|1=Also=NetworkManager-wait-online.service}} in the {{ic|[Install]}} section.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/167e42a87e97ed7fb26a4263c22f1774716ac51b] If {{ic|NetworkManager.service}} was [[enable]]d before the change, it needs to be [[enable|reenabled]].}}<br />
<br />
If you have services which fail if they are started before the network is up, you may use {{ic|NetworkManager-wait-online.service}} in addition to {{ic|NetworkManager.service}}. This is, however, rarely necessary because most networked daemons start up okay, even if the network has not been configured yet.<br />
<br />
In some cases, the service will still fail to start successfully on boot due to the timeout setting in {{ic|/usr/lib/systemd/system/NetworkManager-wait-online.service}} being too short. Change the default timeout from 30 to a higher value.<br />
<br />
=== Set up PolicyKit permissions ===<br />
<br />
See [[General troubleshooting#Session permissions]] for setting up a working session.<br />
<br />
With a working session, you have several options for granting the necessary privileges to NetworkManager:<br />
<br />
* ''Option 1.'' Run a [[Polkit]] authentication agent when you log in, such as {{ic|/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1}} (part of {{Pkg|polkit-gnome}}). You will be prompted for your password whenever you add or remove a network connection.<br />
* ''Option 2.'' [[Users and groups#Group management|Add]] yourself to the {{ic|wheel}} group. You will not have to enter your password, but your user account may be granted other permissions as well, such as the ability to use [[sudo]] without entering the root password.<br />
* ''Option 3.'' [[Users and groups#Group management|Add]] yourself to the {{ic|network}} group and create the following file:<br />
<br />
{{hc|/etc/polkit-1/rules.d/50-org.freedesktop.NetworkManager.rules|<nowiki><br />
polkit.addRule(function(action, subject) {<br />
if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0 && subject.isInGroup("network")) {<br />
return polkit.Result.YES;<br />
}<br />
});<br />
</nowiki>}}<br />
<br />
: All users in the {{ic|network}} group will be able to add and remove networks without a password. This will not work under [[systemd]] if you do not have an active session with ''systemd-logind''.<br />
<br />
=== Proxy settings ===<br />
<br />
NetworkManager does not directly handle proxy settings, but if you are using [[GNOME]] or [[KDE]], you could use [http://marin.jb.free.fr/proxydriver/ proxydriver] which handles proxy settings using NetworkManager's information. proxydriver is found in the package {{AUR|proxydriver}}.<br />
<br />
In order for ''proxydriver'' to be able to change the proxy settings, you would need to execute this command, as part of the GNOME startup process (see [[GNOME#Autostart]]).<br />
<br />
xhost +si:localuser:''username''<br />
<br />
See also [[Proxy settings]].<br />
<br />
=== Checking connectivity ===<br />
<br />
NetworkManager can try to reach a page on Internet when connecting to a network. {{Pkg|networkmanager}} is configured by default in {{ic|/usr/lib/NetworkManager/conf.d/20-connectivity.conf}} to check connectivity to archlinux.org. To use a different webserver or disable connectivity checking create {{ic|/etc/NetworkManager/conf.d/20-connectivity.conf}}, see {{man|5|NetworkManager.conf|CONNECTIVITY SECTION}}. Below is an example of using GNOME servers (it does not require the use of [[GNOME]]):<br />
<br />
{{hc|/etc/NetworkManager/conf.d/20-connectivity.conf|<nowiki><br />
[connectivity]<br />
uri=http://nmcheck.gnome.org/check_network_status.txt<br />
</nowiki>}}<br />
<br />
{{Note|Although automatic connectivity checks are a potential privacy leak, the official archlinux.org default connectivity URL is committed to not logging any access. See [https://gitlab.archlinux.org/archlinux/infrastructure/-/commit/68fbaca2ef9f31f624f117899848f4288d6b39d1].}}<br />
<br />
=== Captive portals ===<br />
<br />
{{Style|Complex scripts should not be maintained on the wiki.}}<br />
<br />
For those behind a [[Wikipedia:Captive portal|captive portal]], the desktop manager may automatically open a window asking for credentials. If your desktop does not, you can use {{Pkg|capnet-assist}} package (however, it currently it has a broken NetworkManager dispatcher script). Alternatively, you can create a NetworkManager dispatcher script with the following content:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/90-open_captive_portal|<nowiki><br />
#!/bin/sh -e<br />
# Script to dispatch NetworkManager events<br />
#<br />
# Runs shows a login webpage on walled garden networks.<br />
# See NetworkManager(8) for further documentation of the dispatcher events.<br />
<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin<br />
<br />
if [ -x "/usr/bin/logger" ]; then<br />
logger="/usr/bin/logger -s -t captive-portal"<br />
else<br />
logger=":"<br />
fi<br />
<br />
wait_for_process() {<br />
PNAME=$1<br />
while [ -z "$(/usr/bin/pgrep $PNAME)" ]; do<br />
sleep 3;<br />
done<br />
}<br />
<br />
#launch the browser, but on boot we need to wait that nm-applet starts<br />
start_browser() {<br />
local user="$1"<br />
local display="$2"<br />
<br />
export DISPLAY="$display"<br />
wait_for_process nm-applet<br />
<br />
export XAUTHORITY="/home/$user/.Xauthority"<br />
<br />
$logger "Running browser as '$user' with display '$display' to login in captive portal"<br />
sudo -u "$user" --preserve-env=DISPLAY,XAUTHORITY -H xdg-open http://capnet.elementary.io 2>&1 > /dev/null<br />
}<br />
<br />
# Run the right scripts<br />
case "$2" in<br />
connectivity-change)<br />
$logger -p user.debug "dispatcher script triggered on connectivity change: $CONNECTIVITY_STATE"<br />
if [ "$CONNECTIVITY_STATE" = "PORTAL" ]; then<br />
# Match last column of who's output with ' :[at least one digit] '<br />
who | awk '$NF ~ /\(:[0-9]+\)/ { print $1 " " substr($NF, 2, length($NF)-2) };' | \<br />
while read user display; do<br />
start_browser $user $display || $logger -p user.err "Failed for user: '$user' display: '$display'"<br />
done<br />
fi<br />
;;<br />
*)<br />
# In a down phase<br />
exit 0<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
You will need to [[restart]] {{ic|NetworkManager.service}} or reboot for this to start working. Once you do, the dispatcher script should open a login window once it detects you are behind a captive portal.<br />
<br />
Another solution is {{AUR|captive-browser-git}} based on Google Chrome.<br />
<br />
=== DHCP client ===<br />
<br />
By default NetworkManager uses its internal DHCP client. The internal DHCPv4 plugin is based on the [https://nettools.github.io/n-dhcp4/ nettools' n-dhcp4] library, while the internal DHCPv6 plugin is made from code based on systemd-networkd.<br />
<br />
To use ISC’s DHCP client, [[install]] {{Pkg|dhclient}}. To change the DHCP client backend, set the option {{ic|1=main.dhcp=''dhcp_client_name''}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}. E.g.:<br />
<br />
{{hc|1=/etc/NetworkManager/conf.d/dhcp-client.conf|2=<br />
[main]<br />
dhcp=dhclient<br />
}}<br />
<br />
{{Note|<br />
* Do not enable the systemd units shipped with the {{Pkg|dhclient}} and {{Pkg|dhcpcd}} packages. They will conflict with NetworkManager, see the note in [[#Installation]] for details.<br />
* NetworkManger does not support dhcpcd ≥ 9.0.0. See {{Bug|66231}}.<br />
}}<br />
<br />
=== DNS management ===<br />
<br />
NetworkManager's DNS management is described in the GNOME project's wiki page—[https://wiki.gnome.org/Projects/NetworkManager/DNS Projects/NetworkManager/DNS].<br />
<br />
==== DNS caching and conditional forwarding ====<br />
<br />
NetworkManager has a plugin to enable DNS caching and conditional forwarding ([https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/143 previously] called "split DNS" in NetworkManager's documentation) using [[dnsmasq]] or [[systemd-resolved]]. The advantages of this setup is that DNS lookups will be cached, shortening resolve times, and DNS lookups of VPN hosts will be routed to the relevant VPN's DNS servers. This is especially useful if you are connected to more than one VPN.<br />
<br />
===== dnsmasq =====<br />
<br />
Make sure {{Pkg|dnsmasq}} has been installed. Then set {{ic|1=main.dns=dnsmasq}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=dnsmasq<br />
}}<br />
<br />
Now run {{ic|nmcli general reload}} as root. NetworkManager will automatically start dnsmasq and add {{ic|127.0.0.1}} to {{ic|/etc/resolv.conf}}. The original DNS servers can be found in {{ic|/run/NetworkManager/no-stub-resolv.conf}}. You can verify dnsmasq is being used by doing the same DNS lookup twice with {{ic|drill example.com}} and verifying the server and query times.<br />
<br />
{{Note|<br />
* You do not need to start {{ic|dnsmasq.service}} or edit {{ic|/etc/dnsmasq.conf}}. NetworkManager will start dnsmasq without using the systemd service and without reading the dnsmasq's default configuration file(s).<br />
* The dnsmasq instance started by NetworkManager will bind to {{ic|127.0.0.1:53}}, you cannot run any other software (including {{ic|dnsmasq.service}}) on the same address and port.<br />
}}<br />
<br />
====== Custom dnsmasq configuration ======<br />
<br />
Custom configurations can be created for ''dnsmasq'' by creating configuration files in {{ic|/etc/NetworkManager/dnsmasq.d/}}. For example, to change the size of the DNS cache (which is stored in RAM):<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/cache.conf|2=<br />
cache-size=1000<br />
}}<br />
<br />
{{Tip|Check the configuration file syntax with {{ic|1=dnsmasq --test --conf-file=/dev/null --conf-dir=/etc/NetworkManager/dnsmasq.d}}.}}<br />
<br />
See {{man|8|dnsmasq}} for all available options.<br />
<br />
====== IPv6 ======<br />
<br />
{{Accuracy|This does not solve the issue because NetworkManager does not add {{ic|::1}} to {{ic|/etc/resolv.conf}}. Unless {{ic|@::1}} is manually passed to drill, it will still fail with {{ic|Error: error sending query: No (valid) nameservers defined in the resolver}}.}}<br />
<br />
Enabling {{ic|dnsmasq}} in NetworkManager may break IPv6-only DNS lookups (i.e. {{ic|drill -6 [hostname]}}) which would otherwise work. In order to resolve this, creating the following file will configure ''dnsmasq'' to also listen to the IPv6 loopback:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/ipv6-listen.conf|2=<br />
listen-address=::1<br />
}}<br />
<br />
In addition, {{ic|dnsmasq}} also does not prioritize upstream IPv6 DNS. Unfortunately NetworkManager does not do this ([https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/936712 Ubuntu Bug]). A workaround would be to disable IPv4 DNS in the NetworkManager config, assuming one exists<br />
<br />
====== DNSSEC ======<br />
<br />
The dnsmasq instance started by NetworkManager by default will not validate [[DNSSEC]] since it is started with the {{ic|--proxy-dnssec}} option. It will trust whatever DNSSEC information it gets from the upstream DNS server.<br />
<br />
For dnsmasq to properly validate DNSSEC, thus breaking DNS resolution with name servers that do not support it, create the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/dnssec.conf|2=<br />
conf-file=/usr/share/dnsmasq/trust-anchors.conf<br />
dnssec<br />
}}<br />
<br />
===== systemd-resolved =====<br />
<br />
{{Expansion|NetworkManager 1.16 adds a new setting {{ic|main.systemd-resolved}}[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383] (enabled by default). It unconditionally sends DNS configuration to systemd-resolved. Related to "Preserving resolv.conf" from [[systemd-resolved#DNS]]?}}<br />
<br />
NetworkManager can use [[systemd-resolved]] as a DNS resolver and cache. Make sure that ''systemd-resolved'' is properly configured and that {{ic|systemd-resolved.service}} is [[started]] before using it.<br />
<br />
systemd-resolved will be used automatically if {{ic|/etc/resolv.conf}} is a [[Systemd-resolved#DNS|symlink]] to {{ic|/run/systemd/resolve/stub-resolv.conf}}, {{ic|/run/systemd/resolve/resolv.conf}} or {{ic|/usr/lib/systemd/resolv.conf}}.<br />
<br />
You can enable it explicitly by setting {{ic|1=main.dns=systemd-resolved}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=systemd-resolved<br />
}}<br />
<br />
===== DNS resolver with an openresolv subscriber =====<br />
<br />
If [[openresolv]] has a subscriber for your local [[DNS resolver]], set up the subscriber and [[#Use openresolv|configure NetworkManager to use openresolv]].<br />
<br />
Because NetworkManager advertises a single "interface" to ''resolvconf'', it is not possible to implement conditional forwarding between two NetworkManager connections. See [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 NetworkManager issue 153].<br />
<br />
This can be partially mitigated if you set {{ic|1=private="*"}} in {{ic|/etc/resolvconf.conf}}[https://roy.marples.name/projects/openresolv/configuration.html]. Any queries for domains that are not in search domain list will not get forwarded. They will be handled according to the local resolver's configuration, for example, forwarded to another DNS server or resolved recursively from the DNS root.<br />
<br />
==== Custom DNS servers ====<br />
<br />
===== Setting custom global DNS servers =====<br />
<br />
To set DNS servers for all connections, specify them in {{man|5|NetworkManager.conf}} using the syntax {{ic|1=servers=''serveripaddress1'',''serveripaddress2'',''serveripaddress3''}} in a section named {{ic|[global-dns-domain-*]}}. For example:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns-servers.conf|2=<br />
[global-dns-domain-*]<br />
servers=::1,127.0.0.1<br />
}}<br />
<br />
{{Note|<br />
* If you use [[#DNS caching and conditional forwarding|NetworkManager's dnsmasq or systemd-resolved plugin]] or [[#DNS resolver with an openresolv subscriber|openresolv subscribers]], then do not specify loopback addresses with the {{ic|1=servers=}} option, it can break DNS resolution.<br />
* The specified servers do not get sent to [[systemd-resolved]], the connection's DNS servers are used instead.<br />
}}<br />
<br />
===== Setting custom DNS servers in a connection =====<br />
<br />
====== Setting custom DNS servers in a connection (GUI) ======<br />
<br />
Setup will depend on the type of front-end used; the process usually involves right-clicking on the applet, editing (or creating) a profile, and then choosing DHCP type as ''Automatic (specify addresses)''. The DNS addresses will need to be entered and are usually in this form: {{ic|127.0.0.1, ''DNS-server-one'', ...}}.<br />
<br />
====== Setting custom DNS servers in a connection (nmcli / connection file) ======<br />
<br />
To setup DNS Servers per connection, you can use the {{ic|dns}} field (and the associated {{ic|dns-search}} and {{ic|dns-options}}) in the [[#Edit a connection|connection settings]]. <br />
<br />
If {{ic|method}} is set to {{ic|auto}} (when you use DHCP), you need to set {{ic|ignore-auto-dns}} to {{ic|yes}}.<br />
<br />
==== /etc/resolv.conf ====<br />
<br />
By default {{ic|/etc/resolv.conf}} is managed by ''NetworkManager'' unless it is a symlink.<br />
<br />
It can be configured to write it through [[#Use openresolv|openresolv]] or to [[#Unmanaged /etc/resolv.conf|not touch it at all]].<br />
<br />
Using openresolv allows NetworkManager to coexists with other ''resolvconf'' supporting software or, for example, to run a local DNS caching and split-DNS resolver for which openresolv has a [[openresolv#Subscribers|subscriber]].<br />
<br />
{{Note|Conditional forwarding is [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 not yet fully supported] when using NetworkManager with openresolv.}}<br />
<br />
''NetworkManager'' also offers hooks via so called dispatcher scripts that can be used to alter the {{ic|/etc/resolv.conf}} after network changes. See [[#Network services with NetworkManager dispatcher]] and {{man|8|NetworkManager}} for more information.<br />
<br />
{{Note|<br />
* If NetworkManager is configured to use either [[#dnsmasq|dnsmasq]] or [[#systemd-resolved|systemd-resolved]], then the appropriate loopback addresses will be written to {{ic|/etc/resolv.conf}}.<br />
* The {{ic|resolv.conf}} file NetworkManager writes or would write to {{ic|/etc/resolv.conf}} can be found at {{ic|/run/NetworkManager/resolv.conf}}.<br />
* A {{ic|resolv.conf}} file with the acquired name servers and search domains can be found at {{ic|/run/NetworkManager/no-stub-resolv.conf}}.<br />
}}<br />
<br />
===== Unmanaged /etc/resolv.conf =====<br />
<br />
To stop NetworkManager from touching {{ic|/etc/resolv.conf}}, set {{ic|1=main.dns=none}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=none<br />
}}<br />
<br />
{{Tip|You might also want to set {{ic|1=main.systemd-resolved=false}}, so that NetworkManager does not send the DNS configuration to [[systemd-resolved]].}}<br />
<br />
{{Note|See [[#DNS caching and conditional forwarding]], to configure NetworkManager using other DNS backends like [[dnsmasq]] and [[systemd-resolved]], instead of using {{ic|1=main.dns=none}}.}}<br />
<br />
After that {{ic|/etc/resolv.conf}} might be a broken symlink that you will need to remove. Then, just create a new {{ic|/etc/resolv.conf}} file.<br />
<br />
===== Use openresolv =====<br />
<br />
{{Note|Do not set {{ic|1=rc-manager=resolvconf}} when {{Pkg|systemd-resolvconf}} is installed. ''systemd-resolved'' provides limited support for the ''resolvconf'' interface and NetworkManager supports communicating with systemd-resolved through D-Bus without using ''resolvconf''.}}<br />
<br />
To configure NetworkManager to use [[openresolv]], set {{ic|1=main.rc-manager=resolvconf}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/rc-manager.conf|2=<br />
[main]<br />
rc-manager=resolvconf<br />
}}<br />
<br />
=== Firewall ===<br />
<br />
You can assign a [[firewalld]] zone based on your current connection. For example a restrictive firewall when at work, and a less restrictive one when at home.<br />
<br />
This can also be done with [[#Network services with NetworkManager dispatcher|NetworkManager dispatcher]].<br />
<br />
=== 802.1x / PEAP configuration ===<br />
<br />
A PEAP and 802.1x network can be added by adding a config file to {{ic|/etc/NetworkManager/system-connections/''name''}}.<br />
<br />
Here is an example configuration file for IPv4 with IPv6 disabled:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''name''|2=<br />
[ipv6]<br />
method=ignore<br />
<br />
[ipv4]<br />
method=auto<br />
<br />
[connection]<br />
#id=XXXXXXXXX<br />
#uuid=XXXXXXXXX<br />
type=802-11-wireless<br />
#timestamp=XXXX<br />
<br />
[802-11-wireless-security]<br />
key-mgmt=wpa-eap<br />
<br />
[802-11-wireless]<br />
ssid=ssid<br />
mode=infrastructure<br />
#seen-bssids=XXXXXXXXX<br />
security=802-11-wireless-security<br />
<br />
[802-1x]<br />
eap=peap;<br />
identity=user<br />
password=password<br />
phase2-auth=mschapv2<br />
}}<br />
<br />
The number sign (#) defines comments.<br />
<br />
=== Automatically connect to VNP ===<br />
<br />
NetworkManager can be set to automatically connect to a VPN when connecting to the internet, on a per network basis. While the VPN connection itself can be added in the Gnome gui, but to make it automatically use the VPN {{ic|nmcli}} must be used.<br />
<br />
First, make sure to make the VPN connection available to all users. In the Gnome gui this is a matter of checking a box under the {{ic|details}} tab. Then under the {{ic|Identity}} tab, in the password field, click the icon on the right side in the field, and set it to {{ic|Store the password for all users}}.<br />
<br />
Then use the {{ic|nmcli}} tool via command line:<br />
<br />
# nmcli connection<br />
<br />
To list your connections. Then enter configuration mode for the internet connection you want to automatically connect to a VPN<br />
<br />
# nmcli connection edit <NAME of Internet Connection><br />
<br />
Please note that it is the Internet connection and not the VPN you should edit. Here you do not need to use the UUID of the Internet connection, the NAME is fine. Then make the setting with the command:<br />
<br />
# set connection.secondaries <UUID of VPN><br />
<br />
Here the UUID of the VPN must be used, but {{tab}} works for autocompletion.<br />
<br />
== Network services with NetworkManager dispatcher ==<br />
<br />
There are quite a few network services that you will not want running until NetworkManager brings up an interface. NetworkManager has the ability to start services when you connect to a network and stop them when you disconnect (e.g. when using [[NFS]], [[SMB]] and [[NTPd]]).<br />
<br />
To activate the feature you need to [[enable]] and [[start]] the {{ic|NetworkManager-dispatcher.service}}.<br />
<br />
Once the service is active, scripts can be added to the {{ic|/etc/NetworkManager/dispatcher.d}} directory.<br />
<br />
Scripts must be owned by '''root''', otherwise the dispatcher will not execute them. For added security, set group [[ownership]] to root as well:<br />
<br />
# chown root:root /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
Make sure the file has correct permissions:<br />
<br />
# chmod 755 /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
The scripts will be run in alphabetical order at connection time, and in reverse alphabetical order at disconnect time. To ensure what order they come up in, it is common to use numerical characters prior to the name of the script (e.g. {{ic|10-portmap}} or {{ic|30-netfs}} (which ensures that the ''portmapper'' is up before NFS mounts are attempted).<br />
<br />
Scripts will receive the following arguments:<br />
<br />
* '''Interface name:''' e.g. {{ic|eth0}}<br />
* '''Interface status:''' ''up'' or ''down''<br />
* '''VPN status:''' ''vpn-up'' or ''vpn-down''<br />
<br />
{{Warning|If you connect to foreign or public networks, be aware of what services you are starting and what servers you expect to be available for them to connect to. You could make a security hole by starting the wrong services while connected to a public network.}}<br />
<br />
=== Avoiding the dispatcher timeout ===<br />
<br />
If the above is working, then this section is not relevant. However, there is a general problem related to running dispatcher scripts which take longer to be executed. Initially an internal timeout of three seconds only was used. If the called script did not complete in time, it was killed. Later the timeout was extended to about 20 seconds (see the [https://bugzilla.redhat.com/show_bug.cgi?id=982734 Bugtracker] for more information). If the timeout still creates the problem, a work around may be to modify the dispatcher service file {{ic|/usr/lib/systemd/system/NetworkManager-dispatcher.service}} to remain active after exit: <br />
<br />
{{hc|/etc/systemd/system/NetworkManager-dispatcher.service.d/remain_after_exit.conf|2=<br />
[Service]<br />
RemainAfterExit=yes<br />
}}<br />
<br />
Now start and enable the modified {{ic|NetworkManager-dispatcher}} service.<br />
<br />
{{Warning|Adding the {{ic|RemainAfterExit}} line to it will prevent the dispatcher from closing. Unfortunately, the dispatcher '''has''' to close before it can run your scripts again. With it the dispatcher will not time out but it also will not close, which means that the scripts will only run once per boot. Therefore, do not add the line unless the timeout is definitely causing a problem.}}<br />
<br />
=== Dispatcher examples ===<br />
<br />
==== Mount remote folder with sshfs ====<br />
<br />
As the script is run in a very restrictive environment, you have to export {{ic|SSH_AUTH_SOCK}} in order to connect to your SSH agent. There are different ways to accomplish this, see [https://bbs.archlinux.org/viewtopic.php?pid=1042030#p1042030 this message] for more information. The example below works with [[GNOME Keyring]], and will ask you for the password if not unlocked already. In case NetworkManager connects automatically on login, it is likely ''gnome-keyring'' has not yet started and the export will fail (hence the sleep). The {{ic|UUID}} to match can be found with the command {{ic|nmcli connection status}} or {{ic|nmcli connection list}}. <br />
<br />
{{bc|<nowiki><br />
#!/bin/sh<br />
USER='username'<br />
REMOTE='user@host:/remote/path'<br />
LOCAL='/local/path'<br />
<br />
interface=$1 status=$2<br />
if [ "$CONNECTION_UUID" = "</nowiki>''uuid''<nowiki>" ]; then<br />
case $status in<br />
up)<br />
SSH_AUTH_SOCK=$(find /tmp -maxdepth 1 -type s -user "$USER" -name 'ssh')<br />
export SSH_AUTH_SOCK<br />
su "$USER" -c "sshfs $REMOTE $LOCAL"<br />
;;<br />
down)<br />
fusermount -u "$LOCAL"<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
==== Mounting of SMB shares ====<br />
<br />
Some [[SMB]] shares are only available on certain networks or locations (e.g. at home). You can use the dispatcher to only mount SMB shares that are present at your current location.<br />
<br />
The following script will check if we connected to a specific network and mount shares accordingly:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-mount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
# Find the connection UUID with "nmcli connection show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
if [ "$2" = "up" ]; then<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
mount /your/mount/point & <br />
# add more shares as needed<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The following script will unmount all SMB shares before a software initiated disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/pre-down.d/30-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|Make sure this script is located in the {{ic|pre-down.d}} sub-directory as shown above, otherwise it will unmount all shares on any connection state change.}}<br />
<br />
The following script will attempt to unmount all SMB shares following an unexpected disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/40-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
if [ "$2" = "down" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|<br />
* Since NetworkManager 0.9.8, the ''pre-down'' and ''down'' events are not executed on shutdown or restart, see [https://bugzilla.gnome.org/show_bug.cgi?id&#61;701242 this bug report] for more info.<br />
* The previous ''umount'' scripts are still prone to leaving applications actually accessing the mount to 'hang'.<br />
}}<br />
<br />
An alternative is to use the script as seen in [[NFS#Using a NetworkManager dispatcher]]:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-smb.sh|<nowiki><br />
#!/bin/bash<br />
<br />
# Find the connection UUID with "nmcli con show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
WANTED_CON_UUID="CHANGE-ME-NOW-9c7eff15-010a-4b1c-a786-9b4efa218ba9"<br />
<br />
if [[ "$CONNECTION_UUID" == "$WANTED_CON_UUID" ]]; then<br />
<br />
# Script parameter $1: NetworkManager connection name, not used<br />
# Script parameter $2: dispatched event<br />
<br />
case "$2" in<br />
"up")<br />
mount -a -t cifs<br />
;;<br />
"pre-down");&<br />
"vpn-pre-down")<br />
umount -l -a -t cifs >/dev/null<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|This script ignores mounts with the {{ic|noauto}} option, remove this mount option or use {{ic|auto}} to allow the dispatcher to manage these mounts.}}<br />
<br />
Create a symlink inside {{ic|/etc/NetworkManager/dispatcher.d/pre-down/}} to catch the {{ic|pre-down}} events:<br />
<br />
# ln -s ../30-smb.sh /etc/NetworkManager/dispatcher.d/pre-down.d/30-smb.sh<br />
<br />
==== Mounting of NFS shares ====<br />
<br />
See [[NFS#Using a NetworkManager dispatcher]].<br />
<br />
==== Use dispatcher to automatically toggle wireless depending on LAN cable being plugged in ====<br />
<br />
The idea is to only turn Wi-Fi on when the LAN cable is unplugged (for example when detaching from a laptop dock), and for Wi-Fi to be automatically disabled, once a LAN cable is plugged in again. <br />
<br />
Create the following dispatcher script[https://superuser.com/questions/233448/disable-wlan-if-wired-cable-network-is-available], replacing {{ic|1=LAN_interface}} with yours.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/wlan_auto_toggle.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$1" = "LAN_interface" ]; then<br />
case "$2" in<br />
up)<br />
nmcli radio wifi off<br />
;;<br />
down)<br />
nmcli radio wifi on<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|You can get a list of interfaces using [[#nmcli examples|nmcli]]. The ethernet (LAN) interfaces start with {{ic|en}}, e.g. {{ic|1=enp0s5}}}}<br />
<br />
==== Use dispatcher to connect to a VPN after a network connection is established ====<br />
<br />
In this example we want to connect automatically to a previously defined VPN connection after connecting to a specific Wi-Fi network. First thing to do is to create the dispatcher script that defines what to do after we are connected to the network.<br />
<br />
{{Note|This script will require {{Pkg|wireless_tools}} in order to use {{ic|iwgetid}}.}}<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME"<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you would like to attempt to automatically connect to VPN for all Wi-Fi networks, you can use the following definition of the ESSID: {{ic|1=ESSID=$(iwgetid -r)}}. Remember to set the script's permissions [[#Network services with NetworkManager dispatcher|accordingly]]. <br />
<br />
Trying to connect with the above script may still fail with {{ic|NetworkManager-dispatcher.service}} complaining about 'no valid VPN secrets', because of [https://developer.gnome.org/NetworkManager/0.9/secrets-flags.html the way VPN secrets are stored]. Fortunately, there are different options to give the above script access to your VPN password.<br />
<br />
1: One of them requires editing the VPN connection configuration file to make NetworkManager store the secrets by itself rather than inside a keyring [https://bugzilla.redhat.com/show_bug.cgi?id=710552 that will be inaccessible for root]: open up {{ic|/etc/NetworkManager/system-connections/''name of your VPN connection''}} and change the {{ic|password-flags}} and {{ic|secret-flags}} from {{ic|1}} to {{ic|0}}.<br />
<br />
If that alone does not work, you may have to create a {{ic|passwd-file}} in a safe location with the same permissions and ownership as the dispatcher script, containing the following:<br />
<br />
{{hc|/path/to/passwd-file|<br />
vpn.secrets.password:YOUR_PASSWORD<br />
}}<br />
<br />
The script must be changed accordingly, so that it gets the password from the file:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME" passwd-file /path/to/passwd-file<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
2: Alternatively, change the {{ic|password-flags}} and put the password directly in the configuration file adding the section {{ic|vpn-secrets}}:<br />
<br />
[vpn]<br />
....<br />
password-flags=0<br />
<br />
[vpn-secrets]<br />
password=''your_password''<br />
<br />
{{Note|It may now be necessary to re-open the NetworkManager connection editor and save the VPN passwords/secrets again.}}<br />
<br />
==== Use dispatcher to disable IPv6 on VPN provider connections ====<br />
<br />
Many [[:Category:VPN providers|commercial VPN providers]] support only IPv4. That means all IPv6 traffic bypasses the VPN and renders it virtually useless. To avoid this, dispatcher can be used to disable all IPv6 traffic for the time a VPN connection is up.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/10-vpn-ipv6|<nowiki><br />
#!/bin/sh<br />
<br />
case "$2" in<br />
vpn-up)<br />
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
vpn-down)<br />
echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
==== OpenNTPD ====<br />
<br />
See [[OpenNTPD#Using NetworkManager dispatcher]].<br />
<br />
== Testing ==<br />
<br />
NetworkManager applets are designed to load upon login so no further configuration should be necessary for most users. If you have already disabled your previous network settings and disconnected from your network, you can now test if NetworkManager will work. The first step is to [[start]] {{ic|NetworkManager.service}}.<br />
<br />
Some applets will provide you with a {{ic|.desktop}} file so that the NetworkManager applet can be loaded through the application menu. If it does not, you are going to either have to discover the command to use or logout and login again to start the applet. Once the applet is started, it will likely begin polling network connections with for auto-configuration with a DHCP server.<br />
<br />
To start the GNOME applet in non-xdg-compliant window managers like [[awesome]]:<br />
<br />
nm-applet --sm-disable &<br />
<br />
For static IP addresses, you will have to configure NetworkManager to understand them. The process usually involves right-clicking the applet and selecting something like 'Edit Connections'.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Encrypted Wi-Fi passwords ===<br />
<br />
By default, NetworkManager stores passwords in clear text in the connection files at {{ic|/etc/NetworkManager/system-connections/}}. To print the stored passwords, use the following command:<br />
<br />
# grep -r '^psk=' /etc/NetworkManager/system-connections/<br />
<br />
The passwords are accessible to the root user in the filesystem and to users with access to settings via the GUI (e.g. {{ic|nm-applet}}). <br />
<br />
It is preferable to save the passwords in encrypted form in a keyring instead of clear text. The downside of using a keyring is that the connections have to be set up for each user.<br />
<br />
==== Using GNOME Keyring ====<br />
<br />
The keyring daemon has to be started and the keyring needs to be unlocked for the following to work.<br />
<br />
Furthermore, NetworkManager needs to be configured not to store the password for all users. Using GNOME {{ic|nm-applet}}, run {{ic|nm-connection-editor}} from a terminal, select a network connection, click {{ic|Edit}}, select the {{ic|Wifi-Security}} tab and click on the right icon of password and check {{ic|Store the password only for this user}}.<br />
<br />
==== Using KDE Wallet ====<br />
<br />
Using KDE's {{Pkg|plasma-nm}}, click the applet, click on the top right {{ic|Settings}} icon, click on a network connection, in the {{ic|General settings}} tab, untick {{ic|all users may connect to this network}}. If the option is ticked, the passwords will still be stored in clear text, even if a keyring daemon is running.<br />
<br />
If the option was selected previously and you un-tick it, you may have to use the {{ic|reset}} option first to make the password disappear from the file. Alternatively, delete the connection first and set it up again.<br />
<br />
=== Sharing internet connection over Wi-Fi ===<br />
<br />
You can share your internet connection (e.g. 3G or wired) with a few clicks. Please note that a [[firewall]] may interfere with internet sharing.<br />
<br />
You will need a Wi-Fi card which supports AP mode, see [[Software access point#Wi-Fi device must support AP mode]] for details.<br />
<br />
[[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
<br />
Create the shared connection:<br />
<br />
* Click on applet and choose ''Create new wireless network''.<br />
* Follow wizard (choose WPA2 or higher, be sure to use at least 8 character long password, lower lengths will fail).<br />
** Choose either [[Fedora:Features/RealHotspot|Hotspot]] or Ad-hoc as Wi-Fi mode.<br />
<br />
The connection will be saved and remain stored for the next time you need it.<br />
<br />
{{Note|Android does not support connecting to Ad-hoc networks. To share a connection with Android use infrastructure mode (i.e. set Wi-Fi mode to "Hotspot").}}<br />
<br />
=== Sharing internet connection over Ethernet ===<br />
<br />
Scenario: your device has internet connection over wi-fi and you want to share the internet connection to other devices over ethernet.<br />
<br />
Requirements:<br />
<br />
* [[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
* Your internet connected device and the other devices are connected over a suitable ethernet cable (this usually means a cross over cable or a switch in between).<br />
* Internet sharing is not blocked by a [[firewall]].<br />
<br />
Steps:<br />
<br />
{{Style|{{Pkg|nm-connection-editor}} is not a dependency of {{Pkg|networkmanager}} and needs to be installed separately.}}<br />
<br />
* Run {{ic|nm-connection-editor}} from terminal.<br />
* Add a new ethernet connection.<br />
* Give it some sensible name. For example "Shared Internet"<br />
* Go to "IPv4 Settings".<br />
* For "Method:" select "Shared to other computers".<br />
* Save<br />
<br />
Now you should have a new option "Shared Internet" under the Wired connections in NetworkManager.<br />
<br />
=== Checking if networking is up inside a cron job or script ===<br />
<br />
{{Out of date|''nm-tool'' was remove from NetworkManager for long time now[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/bb8c75bd536d4f8fb80a4366025a279078f0ec81]. ''nmcli'' should be used instead.}}<br />
<br />
Some ''cron'' jobs require networking to be up to succeed. You may wish to avoid running these jobs when the network is down. To accomplish this, add an '''if''' test for networking that queries NetworkManager's ''nm-tool'' and checks the state of networking. The test shown here succeeds if any interface is up, and fails if they are all down. This is convenient for laptops that might be hardwired, might be on wireless, or might be off the network.<br />
<br />
{{bc|<nowiki><br />
if [ $(nm-tool|grep State|cut -f2 -d' ') == "connected" ]; then<br />
#Whatever you want to do if the network is online<br />
else<br />
#Whatever you want to do if the network is offline - note, this and the else above are optional<br />
fi<br />
</nowiki>}}<br />
<br />
This useful for a {{ic|cron.hourly}} script that runs ''fpupdate'' for the F-Prot virus scanner signature update, as an example. Another way it might be useful, with a little modification, is to differentiate between networks using various parts of the output from ''nm-tool''; for example, since the active wireless network is denoted with an asterisk, you could grep for the network name and then grep for a literal asterisk.<br />
<br />
=== Connect to network with secret on boot ===<br />
<br />
By default, NetworkManager will not connect to networks requiring a secret automatically on boot. This is because it locks such connections to the user who makes it by default, only connecting after they have logged in. To change this, do the following:<br />
<br />
# Right click on the {{ic|nm-applet}} icon in your panel and select Edit Connections and open the Wireless tab<br />
# Select the connection you want to work with and click the Edit button<br />
# Check the boxes “Connect Automatically” and “Available to all users”<br />
# Additionally, ensure that under "Wi-Fi Security", "Store password for all users (not encrypted)" is selected<br />
<br />
Log out and log back in to complete.<br />
<br />
=== OpenConnect with password in KWallet ===<br />
<br />
While you may type both values at connection time, {{Pkg|plasma-nm}} 0.9.3.2-1 and above are capable of retrieving OpenConnect username and password directly from [[KWallet]].<br />
<br />
Open "KDE Wallet Manager" and look up your OpenConnect VPN connection under "Network Management|Maps". Click "Show values" and <br />
enter your credentials in key "VpnSecrets" in this form (replace ''username'' and ''password'' accordingly):<br />
<br />
form:main:username%SEP%''username''%SEP%form:main:password%SEP%''password''<br />
<br />
Next time you connect, username and password should appear in the "VPN secrets" dialog box.<br />
<br />
=== Ignore specific devices ===<br />
<br />
Sometimes it may be desired that NetworkManager ignores specific devices and does not try to configure addresses and routes for them. You can quickly and easily ignore devices by MAC or interface-name by using the following in {{ic|/etc/NetworkManager/conf.d/unmanaged.conf}}:<br />
<br />
[keyfile]<br />
unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth0<br />
<br />
After editing the file, run {{ic|nmcli general reload}} as root. Afterwards you should be able to configure interfaces without NetworkManager altering what you have set.<br />
<br />
=== Configuring MAC address randomization ===<br />
<br />
{{Note|1=Disabling MAC address randomization may be needed to get (stable) link connection [https://bbs.archlinux.org/viewtopic.php?id=220101] and/or networks that restrict devices based on their MAC Address or have a limit network capacity.}}<br />
<br />
MAC randomization can be used for increased privacy by not disclosing your real MAC address to the network.<br />
<br />
NetworkManager supports two types MAC Address Randomization: randomization during scanning, and for network connections. Both modes can be configured by modifying {{ic|/etc/NetworkManager/NetworkManager.conf}} or by creating a separate configuration file in {{ic|/etc/NetworkManager/conf.d/}} which is recommended since the aforementioned config file may be overwritten by NetworkManager.<br />
<br />
Randomization during Wi-Fi scanning is enabled by default, but it may be disabled by adding the following lines to {{ic|/etc/NetworkManager/NetworkManager.conf}} or a dedicated configuration file under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device]<br />
wifi.scan-rand-mac-address=no<br />
}}<br />
<br />
MAC randomization for network connections can be set to different modes for both wireless and ethernet interfaces. See the [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details on the different modes. <br />
<br />
In terms of MAC randomization the most important modes are {{ic|stable}} and {{ic|random}}. {{ic|stable}} generates a random MAC address when you connect to a new network and associates the two permanently. This means that you will use the same MAC address every time you connect to that network. In contrast, {{ic|random}} will generate a new MAC address every time you connect to a network, new or previously known. You can configure the MAC randomization by adding the desired configuration under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device-mac-randomization]<br />
# "yes" is already the default for scanning<br />
wifi.scan-rand-mac-address=yes<br />
<br />
[connection-mac-randomization]<br />
# Randomize MAC for every ethernet connection<br />
ethernet.cloned-mac-address=random<br />
# Generate a random MAC for each WiFi and associate the two permanently.<br />
wifi.cloned-mac-address=stable<br />
}}<br />
<br />
See the following [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details.<br />
<br />
=== Enable IPv6 Privacy Extensions ===<br />
<br />
See [[IPv6#NetworkManager]].<br />
<br />
=== Working with wired connections ===<br />
<br />
By default, NetworkManager generates a connection profile for each wired ethernet connection it finds. At the point when generating the connection, it does not know whether there will be more ethernet adapters available. Hence, it calls the first wired connection "Wired connection 1". You can avoid generating this connection, by configuring {{ic|no-auto-default}} (see {{man|5|NetworkManager.conf}}), or by simply deleting it. Then NetworkManager will remember not to generate a connection for this interface again.<br />
<br />
You can also edit the connection (and persist it to disk) or delete it. NetworkManager will not re-generate a new connection. Then you can change the name to whatever you want. You can use something like nm-connection-editor for this task.<br />
<br />
=== Using iwd as the Wi-Fi backend ===<br />
<br />
Install {{AUR|networkmanager-iwd}} or enable the experimental [[iwd]] backend creating the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_backend.conf|2=<br />
[device]<br />
wifi.backend=iwd<br />
}}<br />
<br />
=== Running in a network namespace ===<br />
<br />
If you would like to run NetworkManager inside a network namespace (e.g., to manage a specific device which should be use by selected applications), bring the device down before moving it to the namespace:<br />
<br />
$ ip link set dev ''MY_DEVICE'' down<br />
$ ip link set dev ''MY_DEVICE'' netns ''MY_NAMESPACE''<br />
$ ip netns exec ''MY_NAMESPACE'' NetworkManager<br />
...<br />
$ ip netns exec ''MY_NAMESPACE'' killall NetworkManager<br />
<br />
otherwise NetworkManager will later fail to establish the connection with a {{ic|device is strictly unmanaged}} error.<br />
<br />
== Troubleshooting ==<br />
<br />
=== No prompt for password of secured Wi-Fi networks ===<br />
<br />
When trying to connect to a secured Wi-Fi network, no prompt for a password is shown and no connection is established. This happens when no keyring package is installed. An easy solution is to install {{Pkg|gnome-keyring}}. If you want the passwords to be stored in encrypted form, follow [[GNOME Keyring]] to set up the ''gnome-keyring-daemon''.<br />
<br />
=== Network management disabled ===<br />
<br />
When NetworkManager shuts down but the pid (state) file is not removed, you will see a {{ic|Network management disabled}} message. If this happens, remove the file manually:<br />
<br />
# rm /var/lib/NetworkManager/NetworkManager.state<br />
<br />
=== Problems with internal DHCP client ===<br />
<br />
If you have problems with getting an IP address using the internal DHCP client, consider using another DHCP client, see [[#DHCP client]] for instructions. This workaround might solve problems in big wireless networks like eduroam.<br />
<br />
=== DHCP problems with dhclient ===<br />
<br />
If you have problems with getting an IP address via DHCP, try to add the following to your {{ic|/etc/dhclient.conf}}:<br />
<br />
interface "eth0" {<br />
send dhcp-client-identifier 01:''aa:bb:cc:dd:ee:ff'';<br />
}<br />
<br />
Where {{ic|''aa:bb:cc:dd:ee:ff''}} is the MAC address of this NIC. The MAC address can be found using the {{ic|ip link show ''interface''}} command from the {{Pkg|iproute2}} package.<br />
<br />
=== 3G modem not detected ===<br />
<br />
See [[USB 3G Modem#NetworkManager]].<br />
<br />
=== Switching off WLAN on laptops ===<br />
<br />
Sometimes NetworkManager will not work when you disable your Wi-Fi adapter with a switch on your laptop and try to enable it again afterwards. This is often a problem with ''rfkill''. To check if the driver notifies ''rfkill'' about the wireless adapter's status, use:<br />
<br />
$ watch -n1 rfkill list all<br />
<br />
If one identifier stays blocked after you switch on the adapter you could try to manually unblock it with (where X is the number of the identifier provided by the above output):<br />
<br />
# rfkill event unblock X<br />
<br />
=== Static IP address settings revert to DHCP ===<br />
<br />
Due to an unresolved bug, when changing default connections to a static IP address, {{ic|nm-applet}} may not properly store the configuration change, and will revert to automatic DHCP.<br />
<br />
To work around this issue you have to edit the default connection (e.g. "Auto eth0") in {{ic|nm-applet}}, change the connection name (e.g. "my eth0"), uncheck the "Available to all users" checkbox, change your static IP address settings as desired, and click '''Apply'''. This will save a new connection with the given name.<br />
<br />
Next, you will want to make the default connection not connect automatically. To do so, run {{ic|nm-connection-editor}} ('''not''' as root). In the connection editor, edit the default connection (e.g. "Auto eth0") and uncheck "Connect automatically". Click '''Apply''' and close the connection editor.<br />
<br />
=== Cannot edit connections as normal user ===<br />
<br />
See [[#Set up PolicyKit permissions]].<br />
<br />
=== Forget hidden wireless network ===<br />
<br />
Since hidden networks are not displayed in the selection list of the Wireless view, they cannot be forgotten (removed) with the GUI. You can delete one with the following command:<br />
<br />
# rm /etc/NetworkManager/system-connections/''SSID''<br />
<br />
This works for any other connection.<br />
<br />
=== VPN not working in GNOME ===<br />
<br />
When setting up OpenConnect or vpnc connections in NetworkManager while using GNOME, you will sometimes never see the dialog box pop up and the following error appears in {{ic|/var/log/errors.log}}:<br />
<br />
localhost NetworkManager[399]: <error> [1361719690.10506] [nm-vpn-connection.c:1405] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.<br />
<br />
This is caused by the GNOME NM Applet expecting dialog scripts to be at {{ic|/usr/lib/gnome-shell}}, when NetworkManager's packages put them in {{ic|/usr/lib/networkmanager}}.<br />
As a "temporary" fix (this bug has been around for a while now), make the following symlink(s):<br />
<br />
* For OpenConnect: {{ic|ln -s /usr/lib/networkmanager/nm-openconnect-auth-dialog /usr/lib/gnome-shell/}}<br />
* For VPNC (i.e. Cisco VPN): {{ic|ln -s /usr/lib/networkmanager/nm-vpnc-auth-dialog /usr/lib/gnome-shell/}}<br />
<br />
This may need to be done for any other NM VPN plugins as well, but these are the two most common.<br />
<br />
=== Unable to connect to visible European wireless networks ===<br />
<br />
WLAN chips are shipped with a default [[Wireless network configuration#Respecting the regulatory domain|regulatory domain]]. If your access point does not operate within these limitations, you will not be able to connect to the network. Fixing this is easy:<br />
<br />
# [[Install]] {{Pkg|crda}}<br />
# Uncomment the correct Country Code in {{ic|/etc/conf.d/wireless-regdom}}<br />
# Reboot the system, because the setting is only read on boot<br />
<br />
=== Automatic connect to VPN on boot is not working ===<br />
<br />
The problem occurs when the system (i.e. NetworkManager running as the root user) tries to establish a VPN connection, but the password is not accessible because it is stored in the GNOME keyring of a particular user. <br />
<br />
A solution is to keep the password to your VPN in plaintext, as described in step (2.) of [[#Use dispatcher to connect to a VPN after a network connection is established]]. <br />
<br />
You do not need to use the dispatcher described in step (1.) to auto-connect anymore, if you use the new "auto-connect VPN" option from the {{ic|nm-applet}} GUI.<br />
<br />
=== Systemd Bottleneck ===<br />
<br />
Over time the log files ({{ic|/var/log/journal}}) can become very large. This can have a big impact on boot performance when using NetworkManager, see: [[Systemd#Boot time increasing over time]].<br />
<br />
=== Regular network disconnects, latency and lost packets (WiFi) ===<br />
<br />
NetworkManager does a scan every 2 minutes.<br />
<br />
Some WiFi drivers have issues when scanning for base stations whilst connected/associated. Symptoms include VPN disconnects/reconnects and lost packets, web pages failing to load and then refresh fine.<br />
<br />
Running {{ic|journalctl -f}} will indicate that this is taking place, messages like the following will be contained in the logs at regular intervals.<br />
<br />
NetworkManager[410]: <info> (wlp3s0): roamed from BSSID 00:14:48:11:20:CF (my-wifi-name) to (none) ((none))<br />
<br />
There is a patched version of NetworkManager which should prevent this type of scanning: {{AUR|networkmanager-noscan}}.<br />
<br />
Alternatively, if roaming is not important, the periodic scanning behavior can be disabled by locking the BSSID of the access point in the WiFi connection profile.<br />
<br />
=== Unable to turn on wi-fi with Lenovo laptop (IdeaPad, Legion, etc.) ===<br />
<br />
There is an issue with the {{ic|ideapad_laptop}} module on some Lenovo models due to the wi-fi driver incorrectly reporting a soft block. The card can still be manipulated with {{ic|netctl}}, but managers like NetworkManager break. You can verify that this is the problem by checking the output of {{ic|rfkill list}} after toggling your hardware switch and seeing that the soft block persists.<br />
<br />
{{Accuracy|Try to use {{ic|rfkill.default_state}} and {{ic|rfkill.master_switch_mode}} (see [https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt kernel-parameters.txt]) to fix the rfkill problem.}}<br />
<br />
[[modprobe|Unloading]] the {{ic|ideapad_laptop}} module should fix this. ('''warning''': this may disable the laptop keyboard and touchpad also!).<br />
<br />
=== Turn off hostname sending ===<br />
<br />
NetworkManager by default sends the hostname to the DHCP server. Hostname sending can only be disabled per connection not globally ([https://bugzilla.gnome.org/show_bug.cgi?id=768076 GNOME Bug 768076]).<br />
<br />
To disable sending your hostname to the DHCP server for a specific connection, add the following to your network connection file:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''your_connection_file''|2=<br />
...<br />
[ipv4]<br />
dhcp-send-hostname=false<br />
...<br />
[ipv6]<br />
dhcp-send-hostname=false<br />
...<br />
}}<br />
<br />
=== nm-applet disappears in i3wm ===<br />
<br />
If you use the {{ic|xfce4-notifyd.service}} for notifications you must [[edit]] the unit and add the following:<br />
<br />
{{hc|/etc/systemd/user/xfce4-notifyd.service.d/display_env.conf|2=<br />
[Service]<br />
Environment="DISPLAY=:0.0"<br />
}}<br />
<br />
After reloading the daemons [[restart]] {{ic|xfce4-notifyd.service}}. Exit i3 and start it back up again and the applet should show on the tray.<br />
<br />
=== nm-applet tray icons display wrongly ===<br />
<br />
Currently the tray icons of nm-applet are drawn on top of one another, i.e. the icon displaying wireless strength might show on top of the icon indicating no wired connection.<br />
This is apparently a GTK3 bug/problem: https://gitlab.gnome.org/GNOME/gtk/issues/1280 .<br />
<br />
A patched version of GTK3 exists in AUR, which apparently fixes the tray icon bug: {{AUR|gtk3-mushrooms}} .<br />
<br />
=== Unit dbus-org.freedesktop.resolve1.service not found ===<br />
<br />
If {{ic|systemd-resolved.service}} is not started, NetworkManager will try to start it using D-Bus and fail:<br />
<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
dbus-daemon[991]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
<br />
This is because NetworkManager will try to send DNS information to [[systemd-resolved]] regardless of the {{ic|1=main.dns=}} setting in {{man|5|NetworkManager.conf}}.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383]<br />
<br />
This can be disabled with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/no-systemd-resolved.conf|2=<br />
[main]<br />
systemd-resolved=false<br />
}}<br />
<br />
See {{Bug|62138}}.<br />
<br />
=== Secrets were required, but not provided ===<br />
<br />
If you attempt to connect to a network using {{ic|nmcli device wifi connect ''SSID'' password ''password''}} and received the following error:<br />
<br />
Error: Connection activation failed: (7) Secrets were required, but not provided<br />
<br />
The error can be resolved by deleting the connection profile and creating a new one:<br />
<br />
$ nmcli connection delete ''SSID''<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
=== WPA Enterprise connection with NetworkManager ===<br />
<br />
If you try to connect to an WPA Enterprise network like 'eduroam' with NetworkManager with the [[iwd]] backend then you will get the following error from NetworkManager:<br />
<br />
Connection 'eduroam' is not avialable on device wlan0 because profile is not compatible with device (802.1x connections must have IWD provisioning files)<br />
<br />
This is because NetworkManager can not configure a WPA Enterprise network. Therefore you have to configure it using an iwd config file {{ic|/var/lib/iwd/''essid''.8021x}} like described in [[iwd#WPA Enterprise]].<br />
<br />
== See also ==<br />
<br />
* [https://blogs.gnome.org/dcbw/2015/02/16/networkmanager-for-administrators-part-1/ NetworkManager for Administrators Part 1]<br />
* [[Wikipedia:NetworkManager]]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=NetworkManager&diff=627197NetworkManager2020-07-30T13:08:24Z<p>Tobbebobbe: /* Automatically connect to VNP */ Spelling error</p>
<hr />
<div>[[Category:Network managers]]<br />
[[Category:Red Hat]]<br />
[[cs:NetworkManager]]<br />
[[de:Networkmanager]]<br />
[[es:NetworkManager]]<br />
[[fr:NetworkManager]]<br />
[[it:NetworkManager]]<br />
[[ja:NetworkManager]]<br />
[[pt:NetworkManager]]<br />
[[zh-hans:NetworkManager]]<br />
{{Related articles start}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related articles end}}<br />
[https://wiki.gnome.org/Projects/NetworkManager/ NetworkManager] is a program for providing detection and configuration for systems to automatically connect to networks. NetworkManager's functionality can be useful for both wireless and wired networks. For wireless networks, NetworkManager prefers known wireless networks and has the ability to switch to the most reliable network. NetworkManager-aware applications can switch from online and offline mode. NetworkManager also prefers wired connections over wireless ones, has support for modem connections and certain types of VPN. NetworkManager was originally developed by Red Hat and now is hosted by the [[GNOME]] project.<br />
<br />
{{Expansion|Clear text storage of secrets is not limited to just Wi-Fi passwords. The secrets are stored in files (and folder) only accesible to root.}}<br />
<br />
{{Warning|By default, Wi-Fi passwords are stored in clear text, see [[#Encrypted Wi-Fi passwords]].}}<br />
<br />
== Installation ==<br />
<br />
NetworkManager can be [[install]]ed with the package {{Pkg|networkmanager}}, which contains a daemon, a command line interface ({{ic|nmcli}}) and a curses‐based interface ({{ic|nmtui}}). <br />
<br />
=== Enable NetworkManager ===<br />
<br />
After installation, you should [[start/enable]] {{ic|NetworkManager.service}}. Once the NetworkManager daemon is started, it will automatically connect to any available "system connections" that have already been configured. Any "user connections" or unconfigured connections will need ''nmcli'' or an applet to configure and connect.<br />
<br />
=== Additional interfaces ===<br />
<br />
* {{Pkg|nm-connection-editor}} for a graphical user interface,<br />
* {{Pkg|network-manager-applet}} for a system tray applet ({{ic|nm-applet}}).<br />
<br />
{{Note|You must ensure that no other service that wants to configure the network is running; in fact, multiple networking services will conflict. You can find a list of the currently running services with {{ic|1=systemctl --type=service}} and then [[stop]] them. See [[#Configuration]] to enable the NetworkManager service.}}<br />
<br />
=== Mobile broadband support ===<br />
<br />
[[Install]] {{Pkg|modemmanager}}, {{Pkg|mobile-broadband-provider-info}} and {{Pkg|usb_modeswitch}} packages for mobile broadband connection support. See [[USB 3G Modem#NetworkManager]] for details.<br />
<br />
=== PPPoE / DSL support ===<br />
<br />
[[Install]] {{Pkg|rp-pppoe}} package for PPPoE / DSL connection support. To actually add PPPoE connection, use {{ic|1=nm-connection-editor}} and add new DSL/PPPoE connection.<br />
<br />
=== VPN support ===<br />
<br />
NetworkManager since version 1.16 has native support for [[WireGuard]], all it needs is the {{ic|wireguard}} kernel module. Read the [https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-networkmanager/ WireGuard in NetworkManager blog post] for details.<br />
<br />
Support for other VPN types is based on a plug-in system. They are provided in the following packages:<br />
<br />
* {{Pkg|networkmanager-openconnect}} for [[OpenConnect]]<br />
* [[networkmanager-openvpn]] for [[OpenVPN]]<br />
* {{Pkg|networkmanager-pptp}} for [[PPTP Client]]<br />
* {{Pkg|networkmanager-vpnc}} for [[Vpnc]]<br />
* {{Pkg|networkmanager-strongswan}} for [[strongSwan]]<br />
* {{AUR|networkmanager-fortisslvpn-git}}<br />
* {{AUR|networkmanager-iodine-git}}<br />
* {{AUR|networkmanager-libreswan}}<br />
* {{AUR|networkmanager-l2tp}}<br />
* {{AUR|networkmanager-ssh-git}}<br />
* {{Pkg|network-manager-sstp}}<br />
<br />
{{Warning|1=There are a lot of [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues?search=VPN&state=opened bugs] (and [https://bugzilla.gnome.org/buglist.cgi?bug_status=__open__&content=VPN&product=NetworkManager old bugs]) related to VPN support. Check the daemon processes options set via the GUI correctly and double-check with each package release.}}<br />
<br />
{{Note|To have fully functioning DNS resolution when using VPN, you should set up [[#DNS caching and conditional forwarding|conditional forwarding]].}}<br />
<br />
== Usage ==<br />
<br />
NetworkManager comes with {{man|1|nmcli}} and {{man|1|nmtui}}.<br />
<br />
=== nmcli examples ===<br />
<br />
List nearby wifi networks:<br />
<br />
$ nmcli device wifi list<br />
<br />
Connect to a wifi network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
Connect to a hidden network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' hidden yes<br />
<br />
Connect to a wifi on the {{ic|wlan1}} wifi interface:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' ifname wlan1 ''profile_name''<br />
<br />
Disconnect an interface:<br />
<br />
$ nmcli device disconnect ifname eth0<br />
<br />
Reconnect an interface marked as disconnected:<br />
<br />
$ nmcli connection up uuid ''UUID''<br />
<br />
Get a list of UUIDs:<br />
<br />
$ nmcli connection show<br />
<br />
See a list of network devices and their state:<br />
<br />
$ nmcli device<br />
<br />
Turn off wifi:<br />
<br />
$ nmcli radio wifi off<br />
<br />
=== Edit a connection ===<br />
<br />
For a comprehensive list of settings, see {{man|5|nm-settings}}.<br />
<br />
Firstly you need to get list of connections:<br />
<br />
{{hc|$ nmcli connection|<nowiki><br />
NAME UUID TYPE DEVICE<br />
Wired connection 2 e7054040-a421-3bef-965d-bb7d60b7cecf ethernet enp5s0<br />
Wired connection 1 997f2782-f0fc-301d-bfba-15421a2735d8 ethernet enp0s25<br />
MY-HOME-WIFI-5G 92a0f7b3-2eba-49ab-a899-24d83978f308 wifi --<br />
</nowiki>}}<br />
<br />
Here you can use the first column as connection-id used later. In this example we pick {{ic|Wired connection 2}} as a connection-id.<br />
<br />
You have three methods to configure a connection {{ic|Wired connection 2}} after it has been created:<br />
<br />
; nmcli interactive editor<br />
: {{ic|nmcli connection edit 'Wired connection 2'}}.<br> Usage is well documented from the editor.<br />
<br />
; nmcli command line interface<br />
: {{ic|nmcli connection modify 'Wired connection 2' ''setting''.''property'' ''value''}}. See {{man|1|nmcli}} for usage. For example you can change its IPv4 route metric to 200 using {{ic|nmcli connection modify 'Wired connection 2' ipv4.route-metric 200}} command.<br />
<br />
; Connection file<br />
: In {{ic|/etc/NetworkManager/system-connections/}}, modify the corresponding {{ic|Wired connection 2.nmconnection}} file .<br> Do not forget to reload the configuration file with {{ic|nmcli connection reload}}.<br />
<br />
== Front-ends ==<br />
<br />
To configure and have easy access to NetworkManager, most users will want to install an applet. This GUI front-end usually resides in the system tray (or notification area) and allows network selection and configuration of NetworkManager. Various desktop environments have their own applet. Otherwise you can use [[#nm-applet]].<br />
<br />
=== GNOME ===<br />
<br />
[[GNOME]] has a built-in tool, accessible from the Network settings.<br />
<br />
=== KDE Plasma ===<br />
<br />
[[Install]] the {{Pkg|plasma-nm}} package. After that, add it to the KDE taskbar via the ''Panel options > Add widgets > Networks'' menu.<br />
<br />
=== nm-applet ===<br />
<br />
{{Pkg|network-manager-applet}} is a GTK 3 front-end which works under Xorg environments with a systray.<br />
<br />
To store connection secrets install and configure [[GNOME/Keyring]].<br />
<br />
Be aware that after enabling the tick-box option {{ic|Make available to other users}} for a connection, NetworkManager stores the password in plain-text, though the respective file is accessible only to root (or other users via {{ic|nm-applet}}). See [[#Encrypted Wi-Fi passwords]].<br />
<br />
In order to run {{ic|nm-applet}} without a systray, you can use {{Pkg|trayer}} or {{Pkg|stalonetray}}. For example, you can add a script like this one in your path:<br />
<br />
{{hc|nmgui|<nowiki><br />
#!/bin/sh<br />
nm-applet 2>&1 > /dev/null &<br />
stalonetray 2>&1 > /dev/null<br />
killall nm-applet<br />
</nowiki>}}<br />
<br />
When you close the ''stalonetray'' window, it closes {{ic|nm-applet}} too, so no extra memory is used once you are done with network settings.<br />
<br />
The applet can show notifications for events such as connecting to or disconnecting from a WiFi network. For these notifications to display, ensure that you have a notification server installed - see [[Desktop notifications]]. If you use the applet without a notification server, you might see some messages in stdout/stderr, and the app might hang. See [https://bugzilla.gnome.org/show_bug.cgi?id=788313].<br />
<br />
In order to run {{ic|nm-applet}} with such notifications disabled, start the applet with the following command:<br />
<br />
$ nm-applet --no-agent<br />
<br />
{{Tip|{{ic|nm-applet}} might be started automatically with a [[XDG Autostart|autostart desktop file]], to add the --no-agent option modify the Exec line there, i.e.<br />
<br />
{{bc|1=Exec=nm-applet --no-agent}}<br />
<br />
}}<br />
<br />
{{Warning|On [[i3]], if nm-applet is started with the {{ic|--no-agent}} option, it is not possible to connect to a new encrypted WiFi network by clicking on the item list because no password input dialogue window will pop out. [[journal]] will show {{ic|no secrets: No agents were available for this request}}.}}<br />
<br />
==== Appindicator ====<br />
<br />
As of version 1.18.0 Appindicator support is [https://github.com/archlinux/svntogit-packages/commit/7640a2bd557fe84813207ef4d5e35bb5aece6c54 available] in the official {{Pkg|network-manager-applet}} package. To use nm-applet in an Appindicator environment start the applet with the following command:<br />
<br />
$ nm-applet --indicator<br />
<br />
=== networkmanager-dmenu ===<br />
<br />
Alternatively there is {{AUR|networkmanager-dmenu-git}} which is a small script to manage NetworkManager connections with [[dmenu]] or [[rofi]] instead of {{ic|nm-applet}}. It provides all essential features such as connection to existing NetworkManager wifi or wired connections, connect to new wifi connections, requests passphrase if required, connect to existing VPN connections, enable/disable networking, launch ''nm-connection-editor'' GUI, connect to Bluetooth networks.<br />
<br />
== Configuration ==<br />
<br />
NetworkManager will require some additional steps to be able run properly. Make sure you have configured {{ic|/etc/hosts}} as described in [[Network configuration#Set the hostname]] section.<br />
<br />
NetworkManager has a global configuration file at {{ic|/etc/NetworkManager/NetworkManager.conf}}. Addition configuration files can be placed in {{ic|/etc/NetworkManager/conf.d/}}. Usually no configuration needs to be done to the global defaults.<br />
<br />
After editing a configuration file, the changes can be applied by running:<br />
<br />
# nmcli general reload<br />
<br />
=== Enable NetworkManager Wait Online ===<br />
<br />
{{Out of date|{{ic|NetworkManager.service}} has {{ic|1=Also=NetworkManager-wait-online.service}} in the {{ic|[Install]}} section.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/167e42a87e97ed7fb26a4263c22f1774716ac51b] If {{ic|NetworkManager.service}} was [[enable]]d before the change, it needs to be [[enable|reenabled]].}}<br />
<br />
If you have services which fail if they are started before the network is up, you may use {{ic|NetworkManager-wait-online.service}} in addition to {{ic|NetworkManager.service}}. This is, however, rarely necessary because most networked daemons start up okay, even if the network has not been configured yet.<br />
<br />
In some cases, the service will still fail to start successfully on boot due to the timeout setting in {{ic|/usr/lib/systemd/system/NetworkManager-wait-online.service}} being too short. Change the default timeout from 30 to a higher value.<br />
<br />
=== Set up PolicyKit permissions ===<br />
<br />
See [[General troubleshooting#Session permissions]] for setting up a working session.<br />
<br />
With a working session, you have several options for granting the necessary privileges to NetworkManager:<br />
<br />
* ''Option 1.'' Run a [[Polkit]] authentication agent when you log in, such as {{ic|/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1}} (part of {{Pkg|polkit-gnome}}). You will be prompted for your password whenever you add or remove a network connection.<br />
* ''Option 2.'' [[Users and groups#Group management|Add]] yourself to the {{ic|wheel}} group. You will not have to enter your password, but your user account may be granted other permissions as well, such as the ability to use [[sudo]] without entering the root password.<br />
* ''Option 3.'' [[Users and groups#Group management|Add]] yourself to the {{ic|network}} group and create the following file:<br />
<br />
{{hc|/etc/polkit-1/rules.d/50-org.freedesktop.NetworkManager.rules|<nowiki><br />
polkit.addRule(function(action, subject) {<br />
if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0 && subject.isInGroup("network")) {<br />
return polkit.Result.YES;<br />
}<br />
});<br />
</nowiki>}}<br />
<br />
: All users in the {{ic|network}} group will be able to add and remove networks without a password. This will not work under [[systemd]] if you do not have an active session with ''systemd-logind''.<br />
<br />
=== Proxy settings ===<br />
<br />
NetworkManager does not directly handle proxy settings, but if you are using [[GNOME]] or [[KDE]], you could use [http://marin.jb.free.fr/proxydriver/ proxydriver] which handles proxy settings using NetworkManager's information. proxydriver is found in the package {{AUR|proxydriver}}.<br />
<br />
In order for ''proxydriver'' to be able to change the proxy settings, you would need to execute this command, as part of the GNOME startup process (see [[GNOME#Autostart]]).<br />
<br />
xhost +si:localuser:''username''<br />
<br />
See also [[Proxy settings]].<br />
<br />
=== Checking connectivity ===<br />
<br />
NetworkManager can try to reach a page on Internet when connecting to a network. {{Pkg|networkmanager}} is configured by default in {{ic|/usr/lib/NetworkManager/conf.d/20-connectivity.conf}} to check connectivity to archlinux.org. To use a different webserver or disable connectivity checking create {{ic|/etc/NetworkManager/conf.d/20-connectivity.conf}}, see {{man|5|NetworkManager.conf|CONNECTIVITY SECTION}}. Below is an example of using GNOME servers (it does not require the use of [[GNOME]]):<br />
<br />
{{hc|/etc/NetworkManager/conf.d/20-connectivity.conf|<nowiki><br />
[connectivity]<br />
uri=http://nmcheck.gnome.org/check_network_status.txt<br />
</nowiki>}}<br />
<br />
{{Note|Although automatic connectivity checks are a potential privacy leak, the official archlinux.org default connectivity URL is committed to not logging any access. See [https://gitlab.archlinux.org/archlinux/infrastructure/-/commit/68fbaca2ef9f31f624f117899848f4288d6b39d1].}}<br />
<br />
=== Captive portals ===<br />
<br />
{{Style|Complex scripts should not be maintained on the wiki.}}<br />
<br />
For those behind a [[Wikipedia:Captive portal|captive portal]], the desktop manager may automatically open a window asking for credentials. If your desktop does not, you can use {{Pkg|capnet-assist}} package (however, it currently it has a broken NetworkManager dispatcher script). Alternatively, you can create a NetworkManager dispatcher script with the following content:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/90-open_captive_portal|<nowiki><br />
#!/bin/sh -e<br />
# Script to dispatch NetworkManager events<br />
#<br />
# Runs shows a login webpage on walled garden networks.<br />
# See NetworkManager(8) for further documentation of the dispatcher events.<br />
<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin<br />
<br />
if [ -x "/usr/bin/logger" ]; then<br />
logger="/usr/bin/logger -s -t captive-portal"<br />
else<br />
logger=":"<br />
fi<br />
<br />
wait_for_process() {<br />
PNAME=$1<br />
while [ -z "$(/usr/bin/pgrep $PNAME)" ]; do<br />
sleep 3;<br />
done<br />
}<br />
<br />
#launch the browser, but on boot we need to wait that nm-applet starts<br />
start_browser() {<br />
local user="$1"<br />
local display="$2"<br />
<br />
export DISPLAY="$display"<br />
wait_for_process nm-applet<br />
<br />
export XAUTHORITY="/home/$user/.Xauthority"<br />
<br />
$logger "Running browser as '$user' with display '$display' to login in captive portal"<br />
sudo -u "$user" --preserve-env=DISPLAY,XAUTHORITY -H xdg-open http://capnet.elementary.io 2>&1 > /dev/null<br />
}<br />
<br />
# Run the right scripts<br />
case "$2" in<br />
connectivity-change)<br />
$logger -p user.debug "dispatcher script triggered on connectivity change: $CONNECTIVITY_STATE"<br />
if [ "$CONNECTIVITY_STATE" = "PORTAL" ]; then<br />
# Match last column of who's output with ' :[at least one digit] '<br />
who | awk '$NF ~ /\(:[0-9]+\)/ { print $1 " " substr($NF, 2, length($NF)-2) };' | \<br />
while read user display; do<br />
start_browser $user $display || $logger -p user.err "Failed for user: '$user' display: '$display'"<br />
done<br />
fi<br />
;;<br />
*)<br />
# In a down phase<br />
exit 0<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
You will need to [[restart]] {{ic|NetworkManager.service}} or reboot for this to start working. Once you do, the dispatcher script should open a login window once it detects you are behind a captive portal.<br />
<br />
Another solution is {{AUR|captive-browser-git}} based on Google Chrome.<br />
<br />
=== DHCP client ===<br />
<br />
By default NetworkManager uses its internal DHCP client. The internal DHCPv4 plugin is based on the [https://nettools.github.io/n-dhcp4/ nettools' n-dhcp4] library, while the internal DHCPv6 plugin is made from code based on systemd-networkd.<br />
<br />
To use ISC’s DHCP client, [[install]] {{Pkg|dhclient}}. To change the DHCP client backend, set the option {{ic|1=main.dhcp=''dhcp_client_name''}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}. E.g.:<br />
<br />
{{hc|1=/etc/NetworkManager/conf.d/dhcp-client.conf|2=<br />
[main]<br />
dhcp=dhclient<br />
}}<br />
<br />
{{Note|<br />
* Do not enable the systemd units shipped with the {{Pkg|dhclient}} and {{Pkg|dhcpcd}} packages. They will conflict with NetworkManager, see the note in [[#Installation]] for details.<br />
* NetworkManger does not support dhcpcd ≥ 9.0.0. See {{Bug|66231}}.<br />
}}<br />
<br />
=== DNS management ===<br />
<br />
NetworkManager's DNS management is described in the GNOME project's wiki page—[https://wiki.gnome.org/Projects/NetworkManager/DNS Projects/NetworkManager/DNS].<br />
<br />
==== DNS caching and conditional forwarding ====<br />
<br />
NetworkManager has a plugin to enable DNS caching and conditional forwarding ([https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/143 previously] called "split DNS" in NetworkManager's documentation) using [[dnsmasq]] or [[systemd-resolved]]. The advantages of this setup is that DNS lookups will be cached, shortening resolve times, and DNS lookups of VPN hosts will be routed to the relevant VPN's DNS servers. This is especially useful if you are connected to more than one VPN.<br />
<br />
===== dnsmasq =====<br />
<br />
Make sure {{Pkg|dnsmasq}} has been installed. Then set {{ic|1=main.dns=dnsmasq}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=dnsmasq<br />
}}<br />
<br />
Now run {{ic|nmcli general reload}} as root. NetworkManager will automatically start dnsmasq and add {{ic|127.0.0.1}} to {{ic|/etc/resolv.conf}}. The original DNS servers can be found in {{ic|/run/NetworkManager/no-stub-resolv.conf}}. You can verify dnsmasq is being used by doing the same DNS lookup twice with {{ic|drill example.com}} and verifying the server and query times.<br />
<br />
{{Note|<br />
* You do not need to start {{ic|dnsmasq.service}} or edit {{ic|/etc/dnsmasq.conf}}. NetworkManager will start dnsmasq without using the systemd service and without reading the dnsmasq's default configuration file(s).<br />
* The dnsmasq instance started by NetworkManager will bind to {{ic|127.0.0.1:53}}, you cannot run any other software (including {{ic|dnsmasq.service}}) on the same address and port.<br />
}}<br />
<br />
====== Custom dnsmasq configuration ======<br />
<br />
Custom configurations can be created for ''dnsmasq'' by creating configuration files in {{ic|/etc/NetworkManager/dnsmasq.d/}}. For example, to change the size of the DNS cache (which is stored in RAM):<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/cache.conf|2=<br />
cache-size=1000<br />
}}<br />
<br />
{{Tip|Check the configuration file syntax with {{ic|1=dnsmasq --test --conf-file=/dev/null --conf-dir=/etc/NetworkManager/dnsmasq.d}}.}}<br />
<br />
See {{man|8|dnsmasq}} for all available options.<br />
<br />
====== IPv6 ======<br />
<br />
{{Accuracy|This does not solve the issue because NetworkManager does not add {{ic|::1}} to {{ic|/etc/resolv.conf}}. Unless {{ic|@::1}} is manually passed to drill, it will still fail with {{ic|Error: error sending query: No (valid) nameservers defined in the resolver}}.}}<br />
<br />
Enabling {{ic|dnsmasq}} in NetworkManager may break IPv6-only DNS lookups (i.e. {{ic|drill -6 [hostname]}}) which would otherwise work. In order to resolve this, creating the following file will configure ''dnsmasq'' to also listen to the IPv6 loopback:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/ipv6-listen.conf|2=<br />
listen-address=::1<br />
}}<br />
<br />
In addition, {{ic|dnsmasq}} also does not prioritize upstream IPv6 DNS. Unfortunately NetworkManager does not do this ([https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/936712 Ubuntu Bug]). A workaround would be to disable IPv4 DNS in the NetworkManager config, assuming one exists<br />
<br />
====== DNSSEC ======<br />
<br />
The dnsmasq instance started by NetworkManager by default will not validate [[DNSSEC]] since it is started with the {{ic|--proxy-dnssec}} option. It will trust whatever DNSSEC information it gets from the upstream DNS server.<br />
<br />
For dnsmasq to properly validate DNSSEC, thus breaking DNS resolution with name servers that do not support it, create the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/dnssec.conf|2=<br />
conf-file=/usr/share/dnsmasq/trust-anchors.conf<br />
dnssec<br />
}}<br />
<br />
===== systemd-resolved =====<br />
<br />
{{Expansion|NetworkManager 1.16 adds a new setting {{ic|main.systemd-resolved}}[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383] (enabled by default). It unconditionally sends DNS configuration to systemd-resolved. Related to "Preserving resolv.conf" from [[systemd-resolved#DNS]]?}}<br />
<br />
NetworkManager can use [[systemd-resolved]] as a DNS resolver and cache. Make sure that ''systemd-resolved'' is properly configured and that {{ic|systemd-resolved.service}} is [[started]] before using it.<br />
<br />
systemd-resolved will be used automatically if {{ic|/etc/resolv.conf}} is a [[Systemd-resolved#DNS|symlink]] to {{ic|/run/systemd/resolve/stub-resolv.conf}}, {{ic|/run/systemd/resolve/resolv.conf}} or {{ic|/usr/lib/systemd/resolv.conf}}.<br />
<br />
You can enable it explicitly by setting {{ic|1=main.dns=systemd-resolved}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=systemd-resolved<br />
}}<br />
<br />
===== DNS resolver with an openresolv subscriber =====<br />
<br />
If [[openresolv]] has a subscriber for your local [[DNS resolver]], set up the subscriber and [[#Use openresolv|configure NetworkManager to use openresolv]].<br />
<br />
Because NetworkManager advertises a single "interface" to ''resolvconf'', it is not possible to implement conditional forwarding between two NetworkManager connections. See [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 NetworkManager issue 153].<br />
<br />
This can be partially mitigated if you set {{ic|1=private="*"}} in {{ic|/etc/resolvconf.conf}}[https://roy.marples.name/projects/openresolv/configuration.html]. Any queries for domains that are not in search domain list will not get forwarded. They will be handled according to the local resolver's configuration, for example, forwarded to another DNS server or resolved recursively from the DNS root.<br />
<br />
==== Custom DNS servers ====<br />
<br />
===== Setting custom global DNS servers =====<br />
<br />
To set DNS servers for all connections, specify them in {{man|5|NetworkManager.conf}} using the syntax {{ic|1=servers=''serveripaddress1'',''serveripaddress2'',''serveripaddress3''}} in a section named {{ic|[global-dns-domain-*]}}. For example:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns-servers.conf|2=<br />
[global-dns-domain-*]<br />
servers=::1,127.0.0.1<br />
}}<br />
<br />
{{Note|<br />
* If you use [[#DNS caching and conditional forwarding|NetworkManager's dnsmasq or systemd-resolved plugin]] or [[#DNS resolver with an openresolv subscriber|openresolv subscribers]], then do not specify loopback addresses with the {{ic|1=servers=}} option, it can break DNS resolution.<br />
* The specified servers do not get sent to [[systemd-resolved]], the connection's DNS servers are used instead.<br />
}}<br />
<br />
===== Setting custom DNS servers in a connection =====<br />
<br />
====== Setting custom DNS servers in a connection (GUI) ======<br />
<br />
Setup will depend on the type of front-end used; the process usually involves right-clicking on the applet, editing (or creating) a profile, and then choosing DHCP type as ''Automatic (specify addresses)''. The DNS addresses will need to be entered and are usually in this form: {{ic|127.0.0.1, ''DNS-server-one'', ...}}.<br />
<br />
====== Setting custom DNS servers in a connection (nmcli / connection file) ======<br />
<br />
To setup DNS Servers per connection, you can use the {{ic|dns}} field (and the associated {{ic|dns-search}} and {{ic|dns-options}}) in the [[#Edit a connection|connection settings]]. <br />
<br />
If {{ic|method}} is set to {{ic|auto}} (when you use DHCP), you need to set {{ic|ignore-auto-dns}} to {{ic|yes}}.<br />
<br />
==== /etc/resolv.conf ====<br />
<br />
By default {{ic|/etc/resolv.conf}} is managed by ''NetworkManager'' unless it is a symlink.<br />
<br />
It can be configured to write it through [[#Use openresolv|openresolv]] or to [[#Unmanaged /etc/resolv.conf|not touch it at all]].<br />
<br />
Using openresolv allows NetworkManager to coexists with other ''resolvconf'' supporting software or, for example, to run a local DNS caching and split-DNS resolver for which openresolv has a [[openresolv#Subscribers|subscriber]].<br />
<br />
{{Note|Conditional forwarding is [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 not yet fully supported] when using NetworkManager with openresolv.}}<br />
<br />
''NetworkManager'' also offers hooks via so called dispatcher scripts that can be used to alter the {{ic|/etc/resolv.conf}} after network changes. See [[#Network services with NetworkManager dispatcher]] and {{man|8|NetworkManager}} for more information.<br />
<br />
{{Note|<br />
* If NetworkManager is configured to use either [[#dnsmasq|dnsmasq]] or [[#systemd-resolved|systemd-resolved]], then the appropriate loopback addresses will be written to {{ic|/etc/resolv.conf}}.<br />
* The {{ic|resolv.conf}} file NetworkManager writes or would write to {{ic|/etc/resolv.conf}} can be found at {{ic|/run/NetworkManager/resolv.conf}}.<br />
* A {{ic|resolv.conf}} file with the acquired name servers and search domains can be found at {{ic|/run/NetworkManager/no-stub-resolv.conf}}.<br />
}}<br />
<br />
===== Unmanaged /etc/resolv.conf =====<br />
<br />
To stop NetworkManager from touching {{ic|/etc/resolv.conf}}, set {{ic|1=main.dns=none}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=none<br />
}}<br />
<br />
{{Tip|You might also want to set {{ic|1=main.systemd-resolved=false}}, so that NetworkManager does not send the DNS configuration to [[systemd-resolved]].}}<br />
<br />
{{Note|See [[#DNS caching and conditional forwarding]], to configure NetworkManager using other DNS backends like [[dnsmasq]] and [[systemd-resolved]], instead of using {{ic|1=main.dns=none}}.}}<br />
<br />
After that {{ic|/etc/resolv.conf}} might be a broken symlink that you will need to remove. Then, just create a new {{ic|/etc/resolv.conf}} file.<br />
<br />
===== Use openresolv =====<br />
<br />
{{Note|Do not set {{ic|1=rc-manager=resolvconf}} when {{Pkg|systemd-resolvconf}} is installed. ''systemd-resolved'' provides limited support for the ''resolvconf'' interface and NetworkManager supports communicating with systemd-resolved through D-Bus without using ''resolvconf''.}}<br />
<br />
To configure NetworkManager to use [[openresolv]], set {{ic|1=main.rc-manager=resolvconf}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/rc-manager.conf|2=<br />
[main]<br />
rc-manager=resolvconf<br />
}}<br />
<br />
=== Firewall ===<br />
<br />
You can assign a [[firewalld]] zone based on your current connection. For example a restrictive firewall when at work, and a less restrictive one when at home.<br />
<br />
This can also be done with [[#Network services with NetworkManager dispatcher|NetworkManager dispatcher]].<br />
<br />
=== 802.1x / PEAP configuration ===<br />
<br />
A PEAP and 802.1x network can be added by adding a config file to {{ic|/etc/NetworkManager/system-connections/''name''}}.<br />
<br />
Here is an example configuration file for IPv4 with IPv6 disabled:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''name''|2=<br />
[ipv6]<br />
method=ignore<br />
<br />
[ipv4]<br />
method=auto<br />
<br />
[connection]<br />
#id=XXXXXXXXX<br />
#uuid=XXXXXXXXX<br />
type=802-11-wireless<br />
#timestamp=XXXX<br />
<br />
[802-11-wireless-security]<br />
key-mgmt=wpa-eap<br />
<br />
[802-11-wireless]<br />
ssid=ssid<br />
mode=infrastructure<br />
#seen-bssids=XXXXXXXXX<br />
security=802-11-wireless-security<br />
<br />
[802-1x]<br />
eap=peap;<br />
identity=user<br />
password=password<br />
phase2-auth=mschapv2<br />
}}<br />
<br />
The number sign (#) defines comments.<br />
<br />
=== Automatically connect to VNP ===<br />
<br />
NetworkManager can be set to automatically connect to a VPN when connecting to the internet, on a per network basis. While the VPN connection itself can be added in the Gnome gui, but to make it automatically use the VPN {{ic|nmcli}} must be used.<br />
<br />
First, make sure to make the VPN connection available to all users. In the Gnome gui this is a matter of checking a box under the {{ic|details}} tab. Then under the {{ic|Identity}} tab, in the password field, click the icon on the right side in the field, and set it to {{ic|Store the password for all users}}.<br />
<br />
Then use the {{ic|nmcli}} tool via command line:<br />
<br />
# nmcli connection<br />
<br />
To list your connections. Then enter configuration mode for the internet connection you want to automatically connect to a VPN<br />
<br />
# nmcli connection edit <NAME of Internet Connection><br />
<br />
Please note that it is the Internet connection and not the VPN you should edit. Here you do not need to use the UUID of the Internet connection, the NAME is fine. Then make the setting with the command:<br />
<br />
# set connection.secondaries <UUID of VPN><br />
<br />
Here the UUID of the VPN must be used, but {{tab}} works for autocompletion.<br />
<br />
== Network services with NetworkManager dispatcher ==<br />
<br />
There are quite a few network services that you will not want running until NetworkManager brings up an interface. NetworkManager has the ability to start services when you connect to a network and stop them when you disconnect (e.g. when using [[NFS]], [[SMB]] and [[NTPd]]).<br />
<br />
To activate the feature you need to [[enable]] and [[start]] the {{ic|NetworkManager-dispatcher.service}}.<br />
<br />
Once the service is active, scripts can be added to the {{ic|/etc/NetworkManager/dispatcher.d}} directory.<br />
<br />
Scripts must be owned by '''root''', otherwise the dispatcher will not execute them. For added security, set group [[ownership]] to root as well:<br />
<br />
# chown root:root /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
Make sure the file has correct permissions:<br />
<br />
# chmod 755 /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
The scripts will be run in alphabetical order at connection time, and in reverse alphabetical order at disconnect time. To ensure what order they come up in, it is common to use numerical characters prior to the name of the script (e.g. {{ic|10-portmap}} or {{ic|30-netfs}} (which ensures that the ''portmapper'' is up before NFS mounts are attempted).<br />
<br />
Scripts will receive the following arguments:<br />
<br />
* '''Interface name:''' e.g. {{ic|eth0}}<br />
* '''Interface status:''' ''up'' or ''down''<br />
* '''VPN status:''' ''vpn-up'' or ''vpn-down''<br />
<br />
{{Warning|If you connect to foreign or public networks, be aware of what services you are starting and what servers you expect to be available for them to connect to. You could make a security hole by starting the wrong services while connected to a public network.}}<br />
<br />
=== Avoiding the dispatcher timeout ===<br />
<br />
If the above is working, then this section is not relevant. However, there is a general problem related to running dispatcher scripts which take longer to be executed. Initially an internal timeout of three seconds only was used. If the called script did not complete in time, it was killed. Later the timeout was extended to about 20 seconds (see the [https://bugzilla.redhat.com/show_bug.cgi?id=982734 Bugtracker] for more information). If the timeout still creates the problem, a work around may be to modify the dispatcher service file {{ic|/usr/lib/systemd/system/NetworkManager-dispatcher.service}} to remain active after exit: <br />
<br />
{{hc|/etc/systemd/system/NetworkManager-dispatcher.service.d/remain_after_exit.conf|2=<br />
[Service]<br />
RemainAfterExit=yes<br />
}}<br />
<br />
Now start and enable the modified {{ic|NetworkManager-dispatcher}} service.<br />
<br />
{{Warning|Adding the {{ic|RemainAfterExit}} line to it will prevent the dispatcher from closing. Unfortunately, the dispatcher '''has''' to close before it can run your scripts again. With it the dispatcher will not time out but it also will not close, which means that the scripts will only run once per boot. Therefore, do not add the line unless the timeout is definitely causing a problem.}}<br />
<br />
=== Dispatcher examples ===<br />
<br />
==== Mount remote folder with sshfs ====<br />
<br />
As the script is run in a very restrictive environment, you have to export {{ic|SSH_AUTH_SOCK}} in order to connect to your SSH agent. There are different ways to accomplish this, see [https://bbs.archlinux.org/viewtopic.php?pid=1042030#p1042030 this message] for more information. The example below works with [[GNOME Keyring]], and will ask you for the password if not unlocked already. In case NetworkManager connects automatically on login, it is likely ''gnome-keyring'' has not yet started and the export will fail (hence the sleep). The {{ic|UUID}} to match can be found with the command {{ic|nmcli connection status}} or {{ic|nmcli connection list}}. <br />
<br />
{{bc|<nowiki><br />
#!/bin/sh<br />
USER='username'<br />
REMOTE='user@host:/remote/path'<br />
LOCAL='/local/path'<br />
<br />
interface=$1 status=$2<br />
if [ "$CONNECTION_UUID" = "</nowiki>''uuid''<nowiki>" ]; then<br />
case $status in<br />
up)<br />
SSH_AUTH_SOCK=$(find /tmp -maxdepth 1 -type s -user "$USER" -name 'ssh')<br />
export SSH_AUTH_SOCK<br />
su "$USER" -c "sshfs $REMOTE $LOCAL"<br />
;;<br />
down)<br />
fusermount -u "$LOCAL"<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
==== Mounting of SMB shares ====<br />
<br />
Some [[SMB]] shares are only available on certain networks or locations (e.g. at home). You can use the dispatcher to only mount SMB shares that are present at your current location.<br />
<br />
The following script will check if we connected to a specific network and mount shares accordingly:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-mount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
# Find the connection UUID with "nmcli connection show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
if [ "$2" = "up" ]; then<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
mount /your/mount/point & <br />
# add more shares as needed<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The following script will unmount all SMB shares before a software initiated disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/pre-down.d/30-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|Make sure this script is located in the {{ic|pre-down.d}} sub-directory as shown above, otherwise it will unmount all shares on any connection state change.}}<br />
<br />
The following script will attempt to unmount all SMB shares following an unexpected disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/40-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
if [ "$2" = "down" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|<br />
* Since NetworkManager 0.9.8, the ''pre-down'' and ''down'' events are not executed on shutdown or restart, see [https://bugzilla.gnome.org/show_bug.cgi?id&#61;701242 this bug report] for more info.<br />
* The previous ''umount'' scripts are still prone to leaving applications actually accessing the mount to 'hang'.<br />
}}<br />
<br />
An alternative is to use the script as seen in [[NFS#Using a NetworkManager dispatcher]]:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-smb.sh|<nowiki><br />
#!/bin/bash<br />
<br />
# Find the connection UUID with "nmcli con show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
WANTED_CON_UUID="CHANGE-ME-NOW-9c7eff15-010a-4b1c-a786-9b4efa218ba9"<br />
<br />
if [[ "$CONNECTION_UUID" == "$WANTED_CON_UUID" ]]; then<br />
<br />
# Script parameter $1: NetworkManager connection name, not used<br />
# Script parameter $2: dispatched event<br />
<br />
case "$2" in<br />
"up")<br />
mount -a -t cifs<br />
;;<br />
"pre-down");&<br />
"vpn-pre-down")<br />
umount -l -a -t cifs >/dev/null<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|This script ignores mounts with the {{ic|noauto}} option, remove this mount option or use {{ic|auto}} to allow the dispatcher to manage these mounts.}}<br />
<br />
Create a symlink inside {{ic|/etc/NetworkManager/dispatcher.d/pre-down/}} to catch the {{ic|pre-down}} events:<br />
<br />
# ln -s ../30-smb.sh /etc/NetworkManager/dispatcher.d/pre-down.d/30-smb.sh<br />
<br />
==== Mounting of NFS shares ====<br />
<br />
See [[NFS#Using a NetworkManager dispatcher]].<br />
<br />
==== Use dispatcher to automatically toggle wireless depending on LAN cable being plugged in ====<br />
<br />
The idea is to only turn Wi-Fi on when the LAN cable is unplugged (for example when detaching from a laptop dock), and for Wi-Fi to be automatically disabled, once a LAN cable is plugged in again. <br />
<br />
Create the following dispatcher script[https://superuser.com/questions/233448/disable-wlan-if-wired-cable-network-is-available], replacing {{ic|1=LAN_interface}} with yours.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/wlan_auto_toggle.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$1" = "LAN_interface" ]; then<br />
case "$2" in<br />
up)<br />
nmcli radio wifi off<br />
;;<br />
down)<br />
nmcli radio wifi on<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|You can get a list of interfaces using [[#nmcli examples|nmcli]]. The ethernet (LAN) interfaces start with {{ic|en}}, e.g. {{ic|1=enp0s5}}}}<br />
<br />
==== Use dispatcher to connect to a VPN after a network connection is established ====<br />
<br />
In this example we want to connect automatically to a previously defined VPN connection after connecting to a specific Wi-Fi network. First thing to do is to create the dispatcher script that defines what to do after we are connected to the network.<br />
<br />
{{Note|This script will require {{Pkg|wireless_tools}} in order to use {{ic|iwgetid}}.}}<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME"<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you would like to attempt to automatically connect to VPN for all Wi-Fi networks, you can use the following definition of the ESSID: {{ic|1=ESSID=$(iwgetid -r)}}. Remember to set the script's permissions [[#Network services with NetworkManager dispatcher|accordingly]]. <br />
<br />
Trying to connect with the above script may still fail with {{ic|NetworkManager-dispatcher.service}} complaining about 'no valid VPN secrets', because of [https://developer.gnome.org/NetworkManager/0.9/secrets-flags.html the way VPN secrets are stored]. Fortunately, there are different options to give the above script access to your VPN password.<br />
<br />
1: One of them requires editing the VPN connection configuration file to make NetworkManager store the secrets by itself rather than inside a keyring [https://bugzilla.redhat.com/show_bug.cgi?id=710552 that will be inaccessible for root]: open up {{ic|/etc/NetworkManager/system-connections/''name of your VPN connection''}} and change the {{ic|password-flags}} and {{ic|secret-flags}} from {{ic|1}} to {{ic|0}}.<br />
<br />
If that alone does not work, you may have to create a {{ic|passwd-file}} in a safe location with the same permissions and ownership as the dispatcher script, containing the following:<br />
<br />
{{hc|/path/to/passwd-file|<br />
vpn.secrets.password:YOUR_PASSWORD<br />
}}<br />
<br />
The script must be changed accordingly, so that it gets the password from the file:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME" passwd-file /path/to/passwd-file<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
2: Alternatively, change the {{ic|password-flags}} and put the password directly in the configuration file adding the section {{ic|vpn-secrets}}:<br />
<br />
[vpn]<br />
....<br />
password-flags=0<br />
<br />
[vpn-secrets]<br />
password=''your_password''<br />
<br />
{{Note|It may now be necessary to re-open the NetworkManager connection editor and save the VPN passwords/secrets again.}}<br />
<br />
==== Use dispatcher to disable IPv6 on VPN provider connections ====<br />
<br />
Many [[:Category:VPN providers|commercial VPN providers]] support only IPv4. That means all IPv6 traffic bypasses the VPN and renders it virtually useless. To avoid this, dispatcher can be used to disable all IPv6 traffic for the time a VPN connection is up.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/10-vpn-ipv6|<nowiki><br />
#!/bin/sh<br />
<br />
case "$2" in<br />
vpn-up)<br />
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
vpn-down)<br />
echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
==== OpenNTPD ====<br />
<br />
See [[OpenNTPD#Using NetworkManager dispatcher]].<br />
<br />
== Testing ==<br />
<br />
NetworkManager applets are designed to load upon login so no further configuration should be necessary for most users. If you have already disabled your previous network settings and disconnected from your network, you can now test if NetworkManager will work. The first step is to [[start]] {{ic|NetworkManager.service}}.<br />
<br />
Some applets will provide you with a {{ic|.desktop}} file so that the NetworkManager applet can be loaded through the application menu. If it does not, you are going to either have to discover the command to use or logout and login again to start the applet. Once the applet is started, it will likely begin polling network connections with for auto-configuration with a DHCP server.<br />
<br />
To start the GNOME applet in non-xdg-compliant window managers like [[awesome]]:<br />
<br />
nm-applet --sm-disable &<br />
<br />
For static IP addresses, you will have to configure NetworkManager to understand them. The process usually involves right-clicking the applet and selecting something like 'Edit Connections'.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Encrypted Wi-Fi passwords ===<br />
<br />
By default, NetworkManager stores passwords in clear text in the connection files at {{ic|/etc/NetworkManager/system-connections/}}. To print the stored passwords, use the following command:<br />
<br />
# grep -r '^psk=' /etc/NetworkManager/system-connections/<br />
<br />
The passwords are accessible to the root user in the filesystem and to users with access to settings via the GUI (e.g. {{ic|nm-applet}}). <br />
<br />
It is preferable to save the passwords in encrypted form in a keyring instead of clear text. The downside of using a keyring is that the connections have to be set up for each user.<br />
<br />
==== Using GNOME Keyring ====<br />
<br />
The keyring daemon has to be started and the keyring needs to be unlocked for the following to work.<br />
<br />
Furthermore, NetworkManager needs to be configured not to store the password for all users. Using GNOME {{ic|nm-applet}}, run {{ic|nm-connection-editor}} from a terminal, select a network connection, click {{ic|Edit}}, select the {{ic|Wifi-Security}} tab and click on the right icon of password and check {{ic|Store the password only for this user}}.<br />
<br />
==== Using KDE Wallet ====<br />
<br />
Using KDE's {{Pkg|plasma-nm}}, click the applet, click on the top right {{ic|Settings}} icon, click on a network connection, in the {{ic|General settings}} tab, untick {{ic|all users may connect to this network}}. If the option is ticked, the passwords will still be stored in clear text, even if a keyring daemon is running.<br />
<br />
If the option was selected previously and you un-tick it, you may have to use the {{ic|reset}} option first to make the password disappear from the file. Alternatively, delete the connection first and set it up again.<br />
<br />
=== Sharing internet connection over Wi-Fi ===<br />
<br />
You can share your internet connection (e.g. 3G or wired) with a few clicks. Please note that a [[firewall]] may interfere with internet sharing.<br />
<br />
You will need a Wi-Fi card which supports AP mode, see [[Software access point#Wi-Fi device must support AP mode]] for details.<br />
<br />
[[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
<br />
Create the shared connection:<br />
<br />
* Click on applet and choose ''Create new wireless network''.<br />
* Follow wizard (choose WPA2 or higher, be sure to use at least 8 character long password, lower lengths will fail).<br />
** Choose either [[Fedora:Features/RealHotspot|Hotspot]] or Ad-hoc as Wi-Fi mode.<br />
<br />
The connection will be saved and remain stored for the next time you need it.<br />
<br />
{{Note|Android does not support connecting to Ad-hoc networks. To share a connection with Android use infrastructure mode (i.e. set Wi-Fi mode to "Hotspot").}}<br />
<br />
=== Sharing internet connection over Ethernet ===<br />
<br />
Scenario: your device has internet connection over wi-fi and you want to share the internet connection to other devices over ethernet.<br />
<br />
Requirements:<br />
<br />
* [[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
* Your internet connected device and the other devices are connected over a suitable ethernet cable (this usually means a cross over cable or a switch in between).<br />
* Internet sharing is not blocked by a [[firewall]].<br />
<br />
Steps:<br />
<br />
{{Style|{{Pkg|nm-connection-editor}} is not a dependency of {{Pkg|networkmanager}} and needs to be installed separately.}}<br />
<br />
* Run {{ic|nm-connection-editor}} from terminal.<br />
* Add a new ethernet connection.<br />
* Give it some sensible name. For example "Shared Internet"<br />
* Go to "IPv4 Settings".<br />
* For "Method:" select "Shared to other computers".<br />
* Save<br />
<br />
Now you should have a new option "Shared Internet" under the Wired connections in NetworkManager.<br />
<br />
=== Checking if networking is up inside a cron job or script ===<br />
<br />
{{Out of date|''nm-tool'' was remove from NetworkManager for long time now[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/bb8c75bd536d4f8fb80a4366025a279078f0ec81]. ''nmcli'' should be used instead.}}<br />
<br />
Some ''cron'' jobs require networking to be up to succeed. You may wish to avoid running these jobs when the network is down. To accomplish this, add an '''if''' test for networking that queries NetworkManager's ''nm-tool'' and checks the state of networking. The test shown here succeeds if any interface is up, and fails if they are all down. This is convenient for laptops that might be hardwired, might be on wireless, or might be off the network.<br />
<br />
{{bc|<nowiki><br />
if [ $(nm-tool|grep State|cut -f2 -d' ') == "connected" ]; then<br />
#Whatever you want to do if the network is online<br />
else<br />
#Whatever you want to do if the network is offline - note, this and the else above are optional<br />
fi<br />
</nowiki>}}<br />
<br />
This useful for a {{ic|cron.hourly}} script that runs ''fpupdate'' for the F-Prot virus scanner signature update, as an example. Another way it might be useful, with a little modification, is to differentiate between networks using various parts of the output from ''nm-tool''; for example, since the active wireless network is denoted with an asterisk, you could grep for the network name and then grep for a literal asterisk.<br />
<br />
=== Connect to network with secret on boot ===<br />
<br />
By default, NetworkManager will not connect to networks requiring a secret automatically on boot. This is because it locks such connections to the user who makes it by default, only connecting after they have logged in. To change this, do the following:<br />
<br />
# Right click on the {{ic|nm-applet}} icon in your panel and select Edit Connections and open the Wireless tab<br />
# Select the connection you want to work with and click the Edit button<br />
# Check the boxes “Connect Automatically” and “Available to all users”<br />
# Additionally, ensure that under "Wi-Fi Security", "Store password for all users (not encrypted)" is selected<br />
<br />
Log out and log back in to complete.<br />
<br />
=== OpenConnect with password in KWallet ===<br />
<br />
While you may type both values at connection time, {{Pkg|plasma-nm}} 0.9.3.2-1 and above are capable of retrieving OpenConnect username and password directly from [[KWallet]].<br />
<br />
Open "KDE Wallet Manager" and look up your OpenConnect VPN connection under "Network Management|Maps". Click "Show values" and <br />
enter your credentials in key "VpnSecrets" in this form (replace ''username'' and ''password'' accordingly):<br />
<br />
form:main:username%SEP%''username''%SEP%form:main:password%SEP%''password''<br />
<br />
Next time you connect, username and password should appear in the "VPN secrets" dialog box.<br />
<br />
=== Ignore specific devices ===<br />
<br />
Sometimes it may be desired that NetworkManager ignores specific devices and does not try to configure addresses and routes for them. You can quickly and easily ignore devices by MAC or interface-name by using the following in {{ic|/etc/NetworkManager/conf.d/unmanaged.conf}}:<br />
<br />
[keyfile]<br />
unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth0<br />
<br />
After editing the file, run {{ic|nmcli general reload}} as root. Afterwards you should be able to configure interfaces without NetworkManager altering what you have set.<br />
<br />
=== Configuring MAC address randomization ===<br />
<br />
{{Note|1=Disabling MAC address randomization may be needed to get (stable) link connection [https://bbs.archlinux.org/viewtopic.php?id=220101] and/or networks that restrict devices based on their MAC Address or have a limit network capacity.}}<br />
<br />
MAC randomization can be used for increased privacy by not disclosing your real MAC address to the network.<br />
<br />
NetworkManager supports two types MAC Address Randomization: randomization during scanning, and for network connections. Both modes can be configured by modifying {{ic|/etc/NetworkManager/NetworkManager.conf}} or by creating a separate configuration file in {{ic|/etc/NetworkManager/conf.d/}} which is recommended since the aforementioned config file may be overwritten by NetworkManager.<br />
<br />
Randomization during Wi-Fi scanning is enabled by default, but it may be disabled by adding the following lines to {{ic|/etc/NetworkManager/NetworkManager.conf}} or a dedicated configuration file under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device]<br />
wifi.scan-rand-mac-address=no<br />
}}<br />
<br />
MAC randomization for network connections can be set to different modes for both wireless and ethernet interfaces. See the [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details on the different modes. <br />
<br />
In terms of MAC randomization the most important modes are {{ic|stable}} and {{ic|random}}. {{ic|stable}} generates a random MAC address when you connect to a new network and associates the two permanently. This means that you will use the same MAC address every time you connect to that network. In contrast, {{ic|random}} will generate a new MAC address every time you connect to a network, new or previously known. You can configure the MAC randomization by adding the desired configuration under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device-mac-randomization]<br />
# "yes" is already the default for scanning<br />
wifi.scan-rand-mac-address=yes<br />
<br />
[connection-mac-randomization]<br />
# Randomize MAC for every ethernet connection<br />
ethernet.cloned-mac-address=random<br />
# Generate a random MAC for each WiFi and associate the two permanently.<br />
wifi.cloned-mac-address=stable<br />
}}<br />
<br />
See the following [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details.<br />
<br />
=== Enable IPv6 Privacy Extensions ===<br />
<br />
See [[IPv6#NetworkManager]].<br />
<br />
=== Working with wired connections ===<br />
<br />
By default, NetworkManager generates a connection profile for each wired ethernet connection it finds. At the point when generating the connection, it does not know whether there will be more ethernet adapters available. Hence, it calls the first wired connection "Wired connection 1". You can avoid generating this connection, by configuring {{ic|no-auto-default}} (see {{man|5|NetworkManager.conf}}), or by simply deleting it. Then NetworkManager will remember not to generate a connection for this interface again.<br />
<br />
You can also edit the connection (and persist it to disk) or delete it. NetworkManager will not re-generate a new connection. Then you can change the name to whatever you want. You can use something like nm-connection-editor for this task.<br />
<br />
=== Using iwd as the Wi-Fi backend ===<br />
<br />
Install {{AUR|networkmanager-iwd}} or enable the experimental [[iwd]] backend creating the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_backend.conf|2=<br />
[device]<br />
wifi.backend=iwd<br />
}}<br />
<br />
=== Running in a network namespace ===<br />
<br />
If you would like to run NetworkManager inside a network namespace (e.g., to manage a specific device which should be use by selected applications), bring the device down before moving it to the namespace:<br />
<br />
$ ip link set dev ''MY_DEVICE'' down<br />
$ ip link set dev ''MY_DEVICE'' netns ''MY_NAMESPACE''<br />
$ ip netns exec ''MY_NAMESPACE'' NetworkManager<br />
...<br />
$ ip netns exec ''MY_NAMESPACE'' killall NetworkManager<br />
<br />
otherwise NetworkManager will later fail to establish the connection with a {{ic|device is strictly unmanaged}} error.<br />
<br />
== Troubleshooting ==<br />
<br />
=== No prompt for password of secured Wi-Fi networks ===<br />
<br />
When trying to connect to a secured Wi-Fi network, no prompt for a password is shown and no connection is established. This happens when no keyring package is installed. An easy solution is to install {{Pkg|gnome-keyring}}. If you want the passwords to be stored in encrypted form, follow [[GNOME Keyring]] to set up the ''gnome-keyring-daemon''.<br />
<br />
=== Network management disabled ===<br />
<br />
When NetworkManager shuts down but the pid (state) file is not removed, you will see a {{ic|Network management disabled}} message. If this happens, remove the file manually:<br />
<br />
# rm /var/lib/NetworkManager/NetworkManager.state<br />
<br />
=== Problems with internal DHCP client ===<br />
<br />
If you have problems with getting an IP address using the internal DHCP client, consider using another DHCP client, see [[#DHCP client]] for instructions. This workaround might solve problems in big wireless networks like eduroam.<br />
<br />
=== DHCP problems with dhclient ===<br />
<br />
If you have problems with getting an IP address via DHCP, try to add the following to your {{ic|/etc/dhclient.conf}}:<br />
<br />
interface "eth0" {<br />
send dhcp-client-identifier 01:''aa:bb:cc:dd:ee:ff'';<br />
}<br />
<br />
Where {{ic|''aa:bb:cc:dd:ee:ff''}} is the MAC address of this NIC. The MAC address can be found using the {{ic|ip link show ''interface''}} command from the {{Pkg|iproute2}} package.<br />
<br />
=== 3G modem not detected ===<br />
<br />
See [[USB 3G Modem#NetworkManager]].<br />
<br />
=== Switching off WLAN on laptops ===<br />
<br />
Sometimes NetworkManager will not work when you disable your Wi-Fi adapter with a switch on your laptop and try to enable it again afterwards. This is often a problem with ''rfkill''. To check if the driver notifies ''rfkill'' about the wireless adapter's status, use:<br />
<br />
$ watch -n1 rfkill list all<br />
<br />
If one identifier stays blocked after you switch on the adapter you could try to manually unblock it with (where X is the number of the identifier provided by the above output):<br />
<br />
# rfkill event unblock X<br />
<br />
=== Static IP address settings revert to DHCP ===<br />
<br />
Due to an unresolved bug, when changing default connections to a static IP address, {{ic|nm-applet}} may not properly store the configuration change, and will revert to automatic DHCP.<br />
<br />
To work around this issue you have to edit the default connection (e.g. "Auto eth0") in {{ic|nm-applet}}, change the connection name (e.g. "my eth0"), uncheck the "Available to all users" checkbox, change your static IP address settings as desired, and click '''Apply'''. This will save a new connection with the given name.<br />
<br />
Next, you will want to make the default connection not connect automatically. To do so, run {{ic|nm-connection-editor}} ('''not''' as root). In the connection editor, edit the default connection (e.g. "Auto eth0") and uncheck "Connect automatically". Click '''Apply''' and close the connection editor.<br />
<br />
=== Cannot edit connections as normal user ===<br />
<br />
See [[#Set up PolicyKit permissions]].<br />
<br />
=== Forget hidden wireless network ===<br />
<br />
Since hidden networks are not displayed in the selection list of the Wireless view, they cannot be forgotten (removed) with the GUI. You can delete one with the following command:<br />
<br />
# rm /etc/NetworkManager/system-connections/''SSID''<br />
<br />
This works for any other connection.<br />
<br />
=== VPN not working in GNOME ===<br />
<br />
When setting up OpenConnect or vpnc connections in NetworkManager while using GNOME, you will sometimes never see the dialog box pop up and the following error appears in {{ic|/var/log/errors.log}}:<br />
<br />
localhost NetworkManager[399]: <error> [1361719690.10506] [nm-vpn-connection.c:1405] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.<br />
<br />
This is caused by the GNOME NM Applet expecting dialog scripts to be at {{ic|/usr/lib/gnome-shell}}, when NetworkManager's packages put them in {{ic|/usr/lib/networkmanager}}.<br />
As a "temporary" fix (this bug has been around for a while now), make the following symlink(s):<br />
<br />
* For OpenConnect: {{ic|ln -s /usr/lib/networkmanager/nm-openconnect-auth-dialog /usr/lib/gnome-shell/}}<br />
* For VPNC (i.e. Cisco VPN): {{ic|ln -s /usr/lib/networkmanager/nm-vpnc-auth-dialog /usr/lib/gnome-shell/}}<br />
<br />
This may need to be done for any other NM VPN plugins as well, but these are the two most common.<br />
<br />
=== Unable to connect to visible European wireless networks ===<br />
<br />
WLAN chips are shipped with a default [[Wireless network configuration#Respecting the regulatory domain|regulatory domain]]. If your access point does not operate within these limitations, you will not be able to connect to the network. Fixing this is easy:<br />
<br />
# [[Install]] {{Pkg|crda}}<br />
# Uncomment the correct Country Code in {{ic|/etc/conf.d/wireless-regdom}}<br />
# Reboot the system, because the setting is only read on boot<br />
<br />
=== Automatic connect to VPN on boot is not working ===<br />
<br />
The problem occurs when the system (i.e. NetworkManager running as the root user) tries to establish a VPN connection, but the password is not accessible because it is stored in the GNOME keyring of a particular user. <br />
<br />
A solution is to keep the password to your VPN in plaintext, as described in step (2.) of [[#Use dispatcher to connect to a VPN after a network connection is established]]. <br />
<br />
You do not need to use the dispatcher described in step (1.) to auto-connect anymore, if you use the new "auto-connect VPN" option from the {{ic|nm-applet}} GUI.<br />
<br />
=== Systemd Bottleneck ===<br />
<br />
Over time the log files ({{ic|/var/log/journal}}) can become very large. This can have a big impact on boot performance when using NetworkManager, see: [[Systemd#Boot time increasing over time]].<br />
<br />
=== Regular network disconnects, latency and lost packets (WiFi) ===<br />
<br />
NetworkManager does a scan every 2 minutes.<br />
<br />
Some WiFi drivers have issues when scanning for base stations whilst connected/associated. Symptoms include VPN disconnects/reconnects and lost packets, web pages failing to load and then refresh fine.<br />
<br />
Running {{ic|journalctl -f}} will indicate that this is taking place, messages like the following will be contained in the logs at regular intervals.<br />
<br />
NetworkManager[410]: <info> (wlp3s0): roamed from BSSID 00:14:48:11:20:CF (my-wifi-name) to (none) ((none))<br />
<br />
There is a patched version of NetworkManager which should prevent this type of scanning: {{AUR|networkmanager-noscan}}.<br />
<br />
Alternatively, if roaming is not important, the periodic scanning behavior can be disabled by locking the BSSID of the access point in the WiFi connection profile.<br />
<br />
=== Unable to turn on wi-fi with Lenovo laptop (IdeaPad, Legion, etc.) ===<br />
<br />
There is an issue with the {{ic|ideapad_laptop}} module on some Lenovo models due to the wi-fi driver incorrectly reporting a soft block. The card can still be manipulated with {{ic|netctl}}, but managers like NetworkManager break. You can verify that this is the problem by checking the output of {{ic|rfkill list}} after toggling your hardware switch and seeing that the soft block persists.<br />
<br />
{{Accuracy|Try to use {{ic|rfkill.default_state}} and {{ic|rfkill.master_switch_mode}} (see [https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt kernel-parameters.txt]) to fix the rfkill problem.}}<br />
<br />
[[modprobe|Unloading]] the {{ic|ideapad_laptop}} module should fix this. ('''warning''': this may disable the laptop keyboard and touchpad also!).<br />
<br />
=== Turn off hostname sending ===<br />
<br />
NetworkManager by default sends the hostname to the DHCP server. Hostname sending can only be disabled per connection not globally ([https://bugzilla.gnome.org/show_bug.cgi?id=768076 GNOME Bug 768076]).<br />
<br />
To disable sending your hostname to the DHCP server for a specific connection, add the following to your network connection file:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''your_connection_file''|2=<br />
...<br />
[ipv4]<br />
dhcp-send-hostname=false<br />
...<br />
[ipv6]<br />
dhcp-send-hostname=false<br />
...<br />
}}<br />
<br />
=== nm-applet disappears in i3wm ===<br />
<br />
If you use the {{ic|xfce4-notifyd.service}} for notifications you must [[edit]] the unit and add the following:<br />
<br />
{{hc|/etc/systemd/user/xfce4-notifyd.service.d/display_env.conf|2=<br />
[Service]<br />
Environment="DISPLAY=:0.0"<br />
}}<br />
<br />
After reloading the daemons [[restart]] {{ic|xfce4-notifyd.service}}. Exit i3 and start it back up again and the applet should show on the tray.<br />
<br />
=== nm-applet tray icons display wrongly ===<br />
<br />
Currently the tray icons of nm-applet are drawn on top of one another, i.e. the icon displaying wireless strength might show on top of the icon indicating no wired connection.<br />
This is apparently a GTK3 bug/problem: https://gitlab.gnome.org/GNOME/gtk/issues/1280 .<br />
<br />
A patched version of GTK3 exists in AUR, which apparently fixes the tray icon bug: {{AUR|gtk3-mushrooms}} .<br />
<br />
=== Unit dbus-org.freedesktop.resolve1.service not found ===<br />
<br />
If {{ic|systemd-resolved.service}} is not started, NetworkManager will try to start it using D-Bus and fail:<br />
<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
dbus-daemon[991]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
<br />
This is because NetworkManager will try to send DNS information to [[systemd-resolved]] regardless of the {{ic|1=main.dns=}} setting in {{man|5|NetworkManager.conf}}.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383]<br />
<br />
This can be disabled with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/no-systemd-resolved.conf|2=<br />
[main]<br />
systemd-resolved=false<br />
}}<br />
<br />
See {{Bug|62138}}.<br />
<br />
=== Secrets were required, but not provided ===<br />
<br />
If you attempt to connect to a network using {{ic|nmcli device wifi connect ''SSID'' password ''password''}} and received the following error:<br />
<br />
Error: Connection activation failed: (7) Secrets were required, but not provided<br />
<br />
The error can be resolved by deleting the connection profile and creating a new one:<br />
<br />
$ nmcli connection delete ''SSID''<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
=== WPA Enterprise connection with NetworkManager ===<br />
<br />
If you try to connect to an WPA Enterprise network like 'eduroam' with NetworkManager with the [[iwd]] backend then you will get the following error from NetworkManager:<br />
<br />
Connection 'eduroam' is not avialable on device wlan0 because profile is not compatible with device (802.1x connections must have IWD provisioning files)<br />
<br />
This is because NetworkManager can not configure a WPA Enterprise network. Therefore you have to configure it using an iwd config file {{ic|/var/lib/iwd/''essid''.8021x}} like described in [[iwd#WPA Enterprise]].<br />
<br />
== See also ==<br />
<br />
* [https://blogs.gnome.org/dcbw/2015/02/16/networkmanager-for-administrators-part-1/ NetworkManager for Administrators Part 1]<br />
* [[Wikipedia:NetworkManager]]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=NetworkManager&diff=627196NetworkManager2020-07-30T13:07:26Z<p>Tobbebobbe: /* Automatically connect to VNP */ minor edit correcting the highlights</p>
<hr />
<div>[[Category:Network managers]]<br />
[[Category:Red Hat]]<br />
[[cs:NetworkManager]]<br />
[[de:Networkmanager]]<br />
[[es:NetworkManager]]<br />
[[fr:NetworkManager]]<br />
[[it:NetworkManager]]<br />
[[ja:NetworkManager]]<br />
[[pt:NetworkManager]]<br />
[[zh-hans:NetworkManager]]<br />
{{Related articles start}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related articles end}}<br />
[https://wiki.gnome.org/Projects/NetworkManager/ NetworkManager] is a program for providing detection and configuration for systems to automatically connect to networks. NetworkManager's functionality can be useful for both wireless and wired networks. For wireless networks, NetworkManager prefers known wireless networks and has the ability to switch to the most reliable network. NetworkManager-aware applications can switch from online and offline mode. NetworkManager also prefers wired connections over wireless ones, has support for modem connections and certain types of VPN. NetworkManager was originally developed by Red Hat and now is hosted by the [[GNOME]] project.<br />
<br />
{{Expansion|Clear text storage of secrets is not limited to just Wi-Fi passwords. The secrets are stored in files (and folder) only accesible to root.}}<br />
<br />
{{Warning|By default, Wi-Fi passwords are stored in clear text, see [[#Encrypted Wi-Fi passwords]].}}<br />
<br />
== Installation ==<br />
<br />
NetworkManager can be [[install]]ed with the package {{Pkg|networkmanager}}, which contains a daemon, a command line interface ({{ic|nmcli}}) and a curses‐based interface ({{ic|nmtui}}). <br />
<br />
=== Enable NetworkManager ===<br />
<br />
After installation, you should [[start/enable]] {{ic|NetworkManager.service}}. Once the NetworkManager daemon is started, it will automatically connect to any available "system connections" that have already been configured. Any "user connections" or unconfigured connections will need ''nmcli'' or an applet to configure and connect.<br />
<br />
=== Additional interfaces ===<br />
<br />
* {{Pkg|nm-connection-editor}} for a graphical user interface,<br />
* {{Pkg|network-manager-applet}} for a system tray applet ({{ic|nm-applet}}).<br />
<br />
{{Note|You must ensure that no other service that wants to configure the network is running; in fact, multiple networking services will conflict. You can find a list of the currently running services with {{ic|1=systemctl --type=service}} and then [[stop]] them. See [[#Configuration]] to enable the NetworkManager service.}}<br />
<br />
=== Mobile broadband support ===<br />
<br />
[[Install]] {{Pkg|modemmanager}}, {{Pkg|mobile-broadband-provider-info}} and {{Pkg|usb_modeswitch}} packages for mobile broadband connection support. See [[USB 3G Modem#NetworkManager]] for details.<br />
<br />
=== PPPoE / DSL support ===<br />
<br />
[[Install]] {{Pkg|rp-pppoe}} package for PPPoE / DSL connection support. To actually add PPPoE connection, use {{ic|1=nm-connection-editor}} and add new DSL/PPPoE connection.<br />
<br />
=== VPN support ===<br />
<br />
NetworkManager since version 1.16 has native support for [[WireGuard]], all it needs is the {{ic|wireguard}} kernel module. Read the [https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-networkmanager/ WireGuard in NetworkManager blog post] for details.<br />
<br />
Support for other VPN types is based on a plug-in system. They are provided in the following packages:<br />
<br />
* {{Pkg|networkmanager-openconnect}} for [[OpenConnect]]<br />
* [[networkmanager-openvpn]] for [[OpenVPN]]<br />
* {{Pkg|networkmanager-pptp}} for [[PPTP Client]]<br />
* {{Pkg|networkmanager-vpnc}} for [[Vpnc]]<br />
* {{Pkg|networkmanager-strongswan}} for [[strongSwan]]<br />
* {{AUR|networkmanager-fortisslvpn-git}}<br />
* {{AUR|networkmanager-iodine-git}}<br />
* {{AUR|networkmanager-libreswan}}<br />
* {{AUR|networkmanager-l2tp}}<br />
* {{AUR|networkmanager-ssh-git}}<br />
* {{Pkg|network-manager-sstp}}<br />
<br />
{{Warning|1=There are a lot of [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues?search=VPN&state=opened bugs] (and [https://bugzilla.gnome.org/buglist.cgi?bug_status=__open__&content=VPN&product=NetworkManager old bugs]) related to VPN support. Check the daemon processes options set via the GUI correctly and double-check with each package release.}}<br />
<br />
{{Note|To have fully functioning DNS resolution when using VPN, you should set up [[#DNS caching and conditional forwarding|conditional forwarding]].}}<br />
<br />
== Usage ==<br />
<br />
NetworkManager comes with {{man|1|nmcli}} and {{man|1|nmtui}}.<br />
<br />
=== nmcli examples ===<br />
<br />
List nearby wifi networks:<br />
<br />
$ nmcli device wifi list<br />
<br />
Connect to a wifi network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
Connect to a hidden network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' hidden yes<br />
<br />
Connect to a wifi on the {{ic|wlan1}} wifi interface:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' ifname wlan1 ''profile_name''<br />
<br />
Disconnect an interface:<br />
<br />
$ nmcli device disconnect ifname eth0<br />
<br />
Reconnect an interface marked as disconnected:<br />
<br />
$ nmcli connection up uuid ''UUID''<br />
<br />
Get a list of UUIDs:<br />
<br />
$ nmcli connection show<br />
<br />
See a list of network devices and their state:<br />
<br />
$ nmcli device<br />
<br />
Turn off wifi:<br />
<br />
$ nmcli radio wifi off<br />
<br />
=== Edit a connection ===<br />
<br />
For a comprehensive list of settings, see {{man|5|nm-settings}}.<br />
<br />
Firstly you need to get list of connections:<br />
<br />
{{hc|$ nmcli connection|<nowiki><br />
NAME UUID TYPE DEVICE<br />
Wired connection 2 e7054040-a421-3bef-965d-bb7d60b7cecf ethernet enp5s0<br />
Wired connection 1 997f2782-f0fc-301d-bfba-15421a2735d8 ethernet enp0s25<br />
MY-HOME-WIFI-5G 92a0f7b3-2eba-49ab-a899-24d83978f308 wifi --<br />
</nowiki>}}<br />
<br />
Here you can use the first column as connection-id used later. In this example we pick {{ic|Wired connection 2}} as a connection-id.<br />
<br />
You have three methods to configure a connection {{ic|Wired connection 2}} after it has been created:<br />
<br />
; nmcli interactive editor<br />
: {{ic|nmcli connection edit 'Wired connection 2'}}.<br> Usage is well documented from the editor.<br />
<br />
; nmcli command line interface<br />
: {{ic|nmcli connection modify 'Wired connection 2' ''setting''.''property'' ''value''}}. See {{man|1|nmcli}} for usage. For example you can change its IPv4 route metric to 200 using {{ic|nmcli connection modify 'Wired connection 2' ipv4.route-metric 200}} command.<br />
<br />
; Connection file<br />
: In {{ic|/etc/NetworkManager/system-connections/}}, modify the corresponding {{ic|Wired connection 2.nmconnection}} file .<br> Do not forget to reload the configuration file with {{ic|nmcli connection reload}}.<br />
<br />
== Front-ends ==<br />
<br />
To configure and have easy access to NetworkManager, most users will want to install an applet. This GUI front-end usually resides in the system tray (or notification area) and allows network selection and configuration of NetworkManager. Various desktop environments have their own applet. Otherwise you can use [[#nm-applet]].<br />
<br />
=== GNOME ===<br />
<br />
[[GNOME]] has a built-in tool, accessible from the Network settings.<br />
<br />
=== KDE Plasma ===<br />
<br />
[[Install]] the {{Pkg|plasma-nm}} package. After that, add it to the KDE taskbar via the ''Panel options > Add widgets > Networks'' menu.<br />
<br />
=== nm-applet ===<br />
<br />
{{Pkg|network-manager-applet}} is a GTK 3 front-end which works under Xorg environments with a systray.<br />
<br />
To store connection secrets install and configure [[GNOME/Keyring]].<br />
<br />
Be aware that after enabling the tick-box option {{ic|Make available to other users}} for a connection, NetworkManager stores the password in plain-text, though the respective file is accessible only to root (or other users via {{ic|nm-applet}}). See [[#Encrypted Wi-Fi passwords]].<br />
<br />
In order to run {{ic|nm-applet}} without a systray, you can use {{Pkg|trayer}} or {{Pkg|stalonetray}}. For example, you can add a script like this one in your path:<br />
<br />
{{hc|nmgui|<nowiki><br />
#!/bin/sh<br />
nm-applet 2>&1 > /dev/null &<br />
stalonetray 2>&1 > /dev/null<br />
killall nm-applet<br />
</nowiki>}}<br />
<br />
When you close the ''stalonetray'' window, it closes {{ic|nm-applet}} too, so no extra memory is used once you are done with network settings.<br />
<br />
The applet can show notifications for events such as connecting to or disconnecting from a WiFi network. For these notifications to display, ensure that you have a notification server installed - see [[Desktop notifications]]. If you use the applet without a notification server, you might see some messages in stdout/stderr, and the app might hang. See [https://bugzilla.gnome.org/show_bug.cgi?id=788313].<br />
<br />
In order to run {{ic|nm-applet}} with such notifications disabled, start the applet with the following command:<br />
<br />
$ nm-applet --no-agent<br />
<br />
{{Tip|{{ic|nm-applet}} might be started automatically with a [[XDG Autostart|autostart desktop file]], to add the --no-agent option modify the Exec line there, i.e.<br />
<br />
{{bc|1=Exec=nm-applet --no-agent}}<br />
<br />
}}<br />
<br />
{{Warning|On [[i3]], if nm-applet is started with the {{ic|--no-agent}} option, it is not possible to connect to a new encrypted WiFi network by clicking on the item list because no password input dialogue window will pop out. [[journal]] will show {{ic|no secrets: No agents were available for this request}}.}}<br />
<br />
==== Appindicator ====<br />
<br />
As of version 1.18.0 Appindicator support is [https://github.com/archlinux/svntogit-packages/commit/7640a2bd557fe84813207ef4d5e35bb5aece6c54 available] in the official {{Pkg|network-manager-applet}} package. To use nm-applet in an Appindicator environment start the applet with the following command:<br />
<br />
$ nm-applet --indicator<br />
<br />
=== networkmanager-dmenu ===<br />
<br />
Alternatively there is {{AUR|networkmanager-dmenu-git}} which is a small script to manage NetworkManager connections with [[dmenu]] or [[rofi]] instead of {{ic|nm-applet}}. It provides all essential features such as connection to existing NetworkManager wifi or wired connections, connect to new wifi connections, requests passphrase if required, connect to existing VPN connections, enable/disable networking, launch ''nm-connection-editor'' GUI, connect to Bluetooth networks.<br />
<br />
== Configuration ==<br />
<br />
NetworkManager will require some additional steps to be able run properly. Make sure you have configured {{ic|/etc/hosts}} as described in [[Network configuration#Set the hostname]] section.<br />
<br />
NetworkManager has a global configuration file at {{ic|/etc/NetworkManager/NetworkManager.conf}}. Addition configuration files can be placed in {{ic|/etc/NetworkManager/conf.d/}}. Usually no configuration needs to be done to the global defaults.<br />
<br />
After editing a configuration file, the changes can be applied by running:<br />
<br />
# nmcli general reload<br />
<br />
=== Enable NetworkManager Wait Online ===<br />
<br />
{{Out of date|{{ic|NetworkManager.service}} has {{ic|1=Also=NetworkManager-wait-online.service}} in the {{ic|[Install]}} section.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/167e42a87e97ed7fb26a4263c22f1774716ac51b] If {{ic|NetworkManager.service}} was [[enable]]d before the change, it needs to be [[enable|reenabled]].}}<br />
<br />
If you have services which fail if they are started before the network is up, you may use {{ic|NetworkManager-wait-online.service}} in addition to {{ic|NetworkManager.service}}. This is, however, rarely necessary because most networked daemons start up okay, even if the network has not been configured yet.<br />
<br />
In some cases, the service will still fail to start successfully on boot due to the timeout setting in {{ic|/usr/lib/systemd/system/NetworkManager-wait-online.service}} being too short. Change the default timeout from 30 to a higher value.<br />
<br />
=== Set up PolicyKit permissions ===<br />
<br />
See [[General troubleshooting#Session permissions]] for setting up a working session.<br />
<br />
With a working session, you have several options for granting the necessary privileges to NetworkManager:<br />
<br />
* ''Option 1.'' Run a [[Polkit]] authentication agent when you log in, such as {{ic|/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1}} (part of {{Pkg|polkit-gnome}}). You will be prompted for your password whenever you add or remove a network connection.<br />
* ''Option 2.'' [[Users and groups#Group management|Add]] yourself to the {{ic|wheel}} group. You will not have to enter your password, but your user account may be granted other permissions as well, such as the ability to use [[sudo]] without entering the root password.<br />
* ''Option 3.'' [[Users and groups#Group management|Add]] yourself to the {{ic|network}} group and create the following file:<br />
<br />
{{hc|/etc/polkit-1/rules.d/50-org.freedesktop.NetworkManager.rules|<nowiki><br />
polkit.addRule(function(action, subject) {<br />
if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0 && subject.isInGroup("network")) {<br />
return polkit.Result.YES;<br />
}<br />
});<br />
</nowiki>}}<br />
<br />
: All users in the {{ic|network}} group will be able to add and remove networks without a password. This will not work under [[systemd]] if you do not have an active session with ''systemd-logind''.<br />
<br />
=== Proxy settings ===<br />
<br />
NetworkManager does not directly handle proxy settings, but if you are using [[GNOME]] or [[KDE]], you could use [http://marin.jb.free.fr/proxydriver/ proxydriver] which handles proxy settings using NetworkManager's information. proxydriver is found in the package {{AUR|proxydriver}}.<br />
<br />
In order for ''proxydriver'' to be able to change the proxy settings, you would need to execute this command, as part of the GNOME startup process (see [[GNOME#Autostart]]).<br />
<br />
xhost +si:localuser:''username''<br />
<br />
See also [[Proxy settings]].<br />
<br />
=== Checking connectivity ===<br />
<br />
NetworkManager can try to reach a page on Internet when connecting to a network. {{Pkg|networkmanager}} is configured by default in {{ic|/usr/lib/NetworkManager/conf.d/20-connectivity.conf}} to check connectivity to archlinux.org. To use a different webserver or disable connectivity checking create {{ic|/etc/NetworkManager/conf.d/20-connectivity.conf}}, see {{man|5|NetworkManager.conf|CONNECTIVITY SECTION}}. Below is an example of using GNOME servers (it does not require the use of [[GNOME]]):<br />
<br />
{{hc|/etc/NetworkManager/conf.d/20-connectivity.conf|<nowiki><br />
[connectivity]<br />
uri=http://nmcheck.gnome.org/check_network_status.txt<br />
</nowiki>}}<br />
<br />
{{Note|Although automatic connectivity checks are a potential privacy leak, the official archlinux.org default connectivity URL is committed to not logging any access. See [https://gitlab.archlinux.org/archlinux/infrastructure/-/commit/68fbaca2ef9f31f624f117899848f4288d6b39d1].}}<br />
<br />
=== Captive portals ===<br />
<br />
{{Style|Complex scripts should not be maintained on the wiki.}}<br />
<br />
For those behind a [[Wikipedia:Captive portal|captive portal]], the desktop manager may automatically open a window asking for credentials. If your desktop does not, you can use {{Pkg|capnet-assist}} package (however, it currently it has a broken NetworkManager dispatcher script). Alternatively, you can create a NetworkManager dispatcher script with the following content:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/90-open_captive_portal|<nowiki><br />
#!/bin/sh -e<br />
# Script to dispatch NetworkManager events<br />
#<br />
# Runs shows a login webpage on walled garden networks.<br />
# See NetworkManager(8) for further documentation of the dispatcher events.<br />
<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin<br />
<br />
if [ -x "/usr/bin/logger" ]; then<br />
logger="/usr/bin/logger -s -t captive-portal"<br />
else<br />
logger=":"<br />
fi<br />
<br />
wait_for_process() {<br />
PNAME=$1<br />
while [ -z "$(/usr/bin/pgrep $PNAME)" ]; do<br />
sleep 3;<br />
done<br />
}<br />
<br />
#launch the browser, but on boot we need to wait that nm-applet starts<br />
start_browser() {<br />
local user="$1"<br />
local display="$2"<br />
<br />
export DISPLAY="$display"<br />
wait_for_process nm-applet<br />
<br />
export XAUTHORITY="/home/$user/.Xauthority"<br />
<br />
$logger "Running browser as '$user' with display '$display' to login in captive portal"<br />
sudo -u "$user" --preserve-env=DISPLAY,XAUTHORITY -H xdg-open http://capnet.elementary.io 2>&1 > /dev/null<br />
}<br />
<br />
# Run the right scripts<br />
case "$2" in<br />
connectivity-change)<br />
$logger -p user.debug "dispatcher script triggered on connectivity change: $CONNECTIVITY_STATE"<br />
if [ "$CONNECTIVITY_STATE" = "PORTAL" ]; then<br />
# Match last column of who's output with ' :[at least one digit] '<br />
who | awk '$NF ~ /\(:[0-9]+\)/ { print $1 " " substr($NF, 2, length($NF)-2) };' | \<br />
while read user display; do<br />
start_browser $user $display || $logger -p user.err "Failed for user: '$user' display: '$display'"<br />
done<br />
fi<br />
;;<br />
*)<br />
# In a down phase<br />
exit 0<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
You will need to [[restart]] {{ic|NetworkManager.service}} or reboot for this to start working. Once you do, the dispatcher script should open a login window once it detects you are behind a captive portal.<br />
<br />
Another solution is {{AUR|captive-browser-git}} based on Google Chrome.<br />
<br />
=== DHCP client ===<br />
<br />
By default NetworkManager uses its internal DHCP client. The internal DHCPv4 plugin is based on the [https://nettools.github.io/n-dhcp4/ nettools' n-dhcp4] library, while the internal DHCPv6 plugin is made from code based on systemd-networkd.<br />
<br />
To use ISC’s DHCP client, [[install]] {{Pkg|dhclient}}. To change the DHCP client backend, set the option {{ic|1=main.dhcp=''dhcp_client_name''}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}. E.g.:<br />
<br />
{{hc|1=/etc/NetworkManager/conf.d/dhcp-client.conf|2=<br />
[main]<br />
dhcp=dhclient<br />
}}<br />
<br />
{{Note|<br />
* Do not enable the systemd units shipped with the {{Pkg|dhclient}} and {{Pkg|dhcpcd}} packages. They will conflict with NetworkManager, see the note in [[#Installation]] for details.<br />
* NetworkManger does not support dhcpcd ≥ 9.0.0. See {{Bug|66231}}.<br />
}}<br />
<br />
=== DNS management ===<br />
<br />
NetworkManager's DNS management is described in the GNOME project's wiki page—[https://wiki.gnome.org/Projects/NetworkManager/DNS Projects/NetworkManager/DNS].<br />
<br />
==== DNS caching and conditional forwarding ====<br />
<br />
NetworkManager has a plugin to enable DNS caching and conditional forwarding ([https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/143 previously] called "split DNS" in NetworkManager's documentation) using [[dnsmasq]] or [[systemd-resolved]]. The advantages of this setup is that DNS lookups will be cached, shortening resolve times, and DNS lookups of VPN hosts will be routed to the relevant VPN's DNS servers. This is especially useful if you are connected to more than one VPN.<br />
<br />
===== dnsmasq =====<br />
<br />
Make sure {{Pkg|dnsmasq}} has been installed. Then set {{ic|1=main.dns=dnsmasq}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=dnsmasq<br />
}}<br />
<br />
Now run {{ic|nmcli general reload}} as root. NetworkManager will automatically start dnsmasq and add {{ic|127.0.0.1}} to {{ic|/etc/resolv.conf}}. The original DNS servers can be found in {{ic|/run/NetworkManager/no-stub-resolv.conf}}. You can verify dnsmasq is being used by doing the same DNS lookup twice with {{ic|drill example.com}} and verifying the server and query times.<br />
<br />
{{Note|<br />
* You do not need to start {{ic|dnsmasq.service}} or edit {{ic|/etc/dnsmasq.conf}}. NetworkManager will start dnsmasq without using the systemd service and without reading the dnsmasq's default configuration file(s).<br />
* The dnsmasq instance started by NetworkManager will bind to {{ic|127.0.0.1:53}}, you cannot run any other software (including {{ic|dnsmasq.service}}) on the same address and port.<br />
}}<br />
<br />
====== Custom dnsmasq configuration ======<br />
<br />
Custom configurations can be created for ''dnsmasq'' by creating configuration files in {{ic|/etc/NetworkManager/dnsmasq.d/}}. For example, to change the size of the DNS cache (which is stored in RAM):<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/cache.conf|2=<br />
cache-size=1000<br />
}}<br />
<br />
{{Tip|Check the configuration file syntax with {{ic|1=dnsmasq --test --conf-file=/dev/null --conf-dir=/etc/NetworkManager/dnsmasq.d}}.}}<br />
<br />
See {{man|8|dnsmasq}} for all available options.<br />
<br />
====== IPv6 ======<br />
<br />
{{Accuracy|This does not solve the issue because NetworkManager does not add {{ic|::1}} to {{ic|/etc/resolv.conf}}. Unless {{ic|@::1}} is manually passed to drill, it will still fail with {{ic|Error: error sending query: No (valid) nameservers defined in the resolver}}.}}<br />
<br />
Enabling {{ic|dnsmasq}} in NetworkManager may break IPv6-only DNS lookups (i.e. {{ic|drill -6 [hostname]}}) which would otherwise work. In order to resolve this, creating the following file will configure ''dnsmasq'' to also listen to the IPv6 loopback:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/ipv6-listen.conf|2=<br />
listen-address=::1<br />
}}<br />
<br />
In addition, {{ic|dnsmasq}} also does not prioritize upstream IPv6 DNS. Unfortunately NetworkManager does not do this ([https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/936712 Ubuntu Bug]). A workaround would be to disable IPv4 DNS in the NetworkManager config, assuming one exists<br />
<br />
====== DNSSEC ======<br />
<br />
The dnsmasq instance started by NetworkManager by default will not validate [[DNSSEC]] since it is started with the {{ic|--proxy-dnssec}} option. It will trust whatever DNSSEC information it gets from the upstream DNS server.<br />
<br />
For dnsmasq to properly validate DNSSEC, thus breaking DNS resolution with name servers that do not support it, create the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/dnssec.conf|2=<br />
conf-file=/usr/share/dnsmasq/trust-anchors.conf<br />
dnssec<br />
}}<br />
<br />
===== systemd-resolved =====<br />
<br />
{{Expansion|NetworkManager 1.16 adds a new setting {{ic|main.systemd-resolved}}[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383] (enabled by default). It unconditionally sends DNS configuration to systemd-resolved. Related to "Preserving resolv.conf" from [[systemd-resolved#DNS]]?}}<br />
<br />
NetworkManager can use [[systemd-resolved]] as a DNS resolver and cache. Make sure that ''systemd-resolved'' is properly configured and that {{ic|systemd-resolved.service}} is [[started]] before using it.<br />
<br />
systemd-resolved will be used automatically if {{ic|/etc/resolv.conf}} is a [[Systemd-resolved#DNS|symlink]] to {{ic|/run/systemd/resolve/stub-resolv.conf}}, {{ic|/run/systemd/resolve/resolv.conf}} or {{ic|/usr/lib/systemd/resolv.conf}}.<br />
<br />
You can enable it explicitly by setting {{ic|1=main.dns=systemd-resolved}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=systemd-resolved<br />
}}<br />
<br />
===== DNS resolver with an openresolv subscriber =====<br />
<br />
If [[openresolv]] has a subscriber for your local [[DNS resolver]], set up the subscriber and [[#Use openresolv|configure NetworkManager to use openresolv]].<br />
<br />
Because NetworkManager advertises a single "interface" to ''resolvconf'', it is not possible to implement conditional forwarding between two NetworkManager connections. See [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 NetworkManager issue 153].<br />
<br />
This can be partially mitigated if you set {{ic|1=private="*"}} in {{ic|/etc/resolvconf.conf}}[https://roy.marples.name/projects/openresolv/configuration.html]. Any queries for domains that are not in search domain list will not get forwarded. They will be handled according to the local resolver's configuration, for example, forwarded to another DNS server or resolved recursively from the DNS root.<br />
<br />
==== Custom DNS servers ====<br />
<br />
===== Setting custom global DNS servers =====<br />
<br />
To set DNS servers for all connections, specify them in {{man|5|NetworkManager.conf}} using the syntax {{ic|1=servers=''serveripaddress1'',''serveripaddress2'',''serveripaddress3''}} in a section named {{ic|[global-dns-domain-*]}}. For example:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns-servers.conf|2=<br />
[global-dns-domain-*]<br />
servers=::1,127.0.0.1<br />
}}<br />
<br />
{{Note|<br />
* If you use [[#DNS caching and conditional forwarding|NetworkManager's dnsmasq or systemd-resolved plugin]] or [[#DNS resolver with an openresolv subscriber|openresolv subscribers]], then do not specify loopback addresses with the {{ic|1=servers=}} option, it can break DNS resolution.<br />
* The specified servers do not get sent to [[systemd-resolved]], the connection's DNS servers are used instead.<br />
}}<br />
<br />
===== Setting custom DNS servers in a connection =====<br />
<br />
====== Setting custom DNS servers in a connection (GUI) ======<br />
<br />
Setup will depend on the type of front-end used; the process usually involves right-clicking on the applet, editing (or creating) a profile, and then choosing DHCP type as ''Automatic (specify addresses)''. The DNS addresses will need to be entered and are usually in this form: {{ic|127.0.0.1, ''DNS-server-one'', ...}}.<br />
<br />
====== Setting custom DNS servers in a connection (nmcli / connection file) ======<br />
<br />
To setup DNS Servers per connection, you can use the {{ic|dns}} field (and the associated {{ic|dns-search}} and {{ic|dns-options}}) in the [[#Edit a connection|connection settings]]. <br />
<br />
If {{ic|method}} is set to {{ic|auto}} (when you use DHCP), you need to set {{ic|ignore-auto-dns}} to {{ic|yes}}.<br />
<br />
==== /etc/resolv.conf ====<br />
<br />
By default {{ic|/etc/resolv.conf}} is managed by ''NetworkManager'' unless it is a symlink.<br />
<br />
It can be configured to write it through [[#Use openresolv|openresolv]] or to [[#Unmanaged /etc/resolv.conf|not touch it at all]].<br />
<br />
Using openresolv allows NetworkManager to coexists with other ''resolvconf'' supporting software or, for example, to run a local DNS caching and split-DNS resolver for which openresolv has a [[openresolv#Subscribers|subscriber]].<br />
<br />
{{Note|Conditional forwarding is [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 not yet fully supported] when using NetworkManager with openresolv.}}<br />
<br />
''NetworkManager'' also offers hooks via so called dispatcher scripts that can be used to alter the {{ic|/etc/resolv.conf}} after network changes. See [[#Network services with NetworkManager dispatcher]] and {{man|8|NetworkManager}} for more information.<br />
<br />
{{Note|<br />
* If NetworkManager is configured to use either [[#dnsmasq|dnsmasq]] or [[#systemd-resolved|systemd-resolved]], then the appropriate loopback addresses will be written to {{ic|/etc/resolv.conf}}.<br />
* The {{ic|resolv.conf}} file NetworkManager writes or would write to {{ic|/etc/resolv.conf}} can be found at {{ic|/run/NetworkManager/resolv.conf}}.<br />
* A {{ic|resolv.conf}} file with the acquired name servers and search domains can be found at {{ic|/run/NetworkManager/no-stub-resolv.conf}}.<br />
}}<br />
<br />
===== Unmanaged /etc/resolv.conf =====<br />
<br />
To stop NetworkManager from touching {{ic|/etc/resolv.conf}}, set {{ic|1=main.dns=none}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=none<br />
}}<br />
<br />
{{Tip|You might also want to set {{ic|1=main.systemd-resolved=false}}, so that NetworkManager does not send the DNS configuration to [[systemd-resolved]].}}<br />
<br />
{{Note|See [[#DNS caching and conditional forwarding]], to configure NetworkManager using other DNS backends like [[dnsmasq]] and [[systemd-resolved]], instead of using {{ic|1=main.dns=none}}.}}<br />
<br />
After that {{ic|/etc/resolv.conf}} might be a broken symlink that you will need to remove. Then, just create a new {{ic|/etc/resolv.conf}} file.<br />
<br />
===== Use openresolv =====<br />
<br />
{{Note|Do not set {{ic|1=rc-manager=resolvconf}} when {{Pkg|systemd-resolvconf}} is installed. ''systemd-resolved'' provides limited support for the ''resolvconf'' interface and NetworkManager supports communicating with systemd-resolved through D-Bus without using ''resolvconf''.}}<br />
<br />
To configure NetworkManager to use [[openresolv]], set {{ic|1=main.rc-manager=resolvconf}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/rc-manager.conf|2=<br />
[main]<br />
rc-manager=resolvconf<br />
}}<br />
<br />
=== Firewall ===<br />
<br />
You can assign a [[firewalld]] zone based on your current connection. For example a restrictive firewall when at work, and a less restrictive one when at home.<br />
<br />
This can also be done with [[#Network services with NetworkManager dispatcher|NetworkManager dispatcher]].<br />
<br />
=== 802.1x / PEAP configuration ===<br />
<br />
A PEAP and 802.1x network can be added by adding a config file to {{ic|/etc/NetworkManager/system-connections/''name''}}.<br />
<br />
Here is an example configuration file for IPv4 with IPv6 disabled:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''name''|2=<br />
[ipv6]<br />
method=ignore<br />
<br />
[ipv4]<br />
method=auto<br />
<br />
[connection]<br />
#id=XXXXXXXXX<br />
#uuid=XXXXXXXXX<br />
type=802-11-wireless<br />
#timestamp=XXXX<br />
<br />
[802-11-wireless-security]<br />
key-mgmt=wpa-eap<br />
<br />
[802-11-wireless]<br />
ssid=ssid<br />
mode=infrastructure<br />
#seen-bssids=XXXXXXXXX<br />
security=802-11-wireless-security<br />
<br />
[802-1x]<br />
eap=peap;<br />
identity=user<br />
password=password<br />
phase2-auth=mschapv2<br />
}}<br />
<br />
The number sign (#) defines comments.<br />
<br />
=== Automatically connect to VNP ===<br />
<br />
NetworkManager can be set to automatically connect to a VPN when connecting to the internet, on a per network basis. While the VPN connection itself can be added in the Gnome gui, but to make it automatically use the VPN {{ic|nmcli}} must be used.<br />
<br />
First, make sure to make the VPN connection available to all users. I the Gnome gui this is a matter of checking a box under the {{ic|details}} tab. Then under the {{ic|Identity}} tab, in the password field, click the icon on the right side in the field, and set it to {{ic|Store the password for all users}}.<br />
<br />
Then use the {{ic|nmcli}} tool via command line:<br />
<br />
# nmcli connection<br />
<br />
To list your connections. Then enter configuration mode for the internet connection you want to automatically connect to a VPN<br />
<br />
# nmcli connection edit <NAME of Internet Connection><br />
<br />
Please note that it is the Internet connection and not the VPN you should edit. Here you do not need to use the UUID of the Internet connection, the NAME is fine. Then make the setting with the command:<br />
<br />
# set connection.secondaries <UUID of VPN><br />
<br />
Here the UUID of the VPN must be used, but {{tab}} works for autocompletion.<br />
<br />
== Network services with NetworkManager dispatcher ==<br />
<br />
There are quite a few network services that you will not want running until NetworkManager brings up an interface. NetworkManager has the ability to start services when you connect to a network and stop them when you disconnect (e.g. when using [[NFS]], [[SMB]] and [[NTPd]]).<br />
<br />
To activate the feature you need to [[enable]] and [[start]] the {{ic|NetworkManager-dispatcher.service}}.<br />
<br />
Once the service is active, scripts can be added to the {{ic|/etc/NetworkManager/dispatcher.d}} directory.<br />
<br />
Scripts must be owned by '''root''', otherwise the dispatcher will not execute them. For added security, set group [[ownership]] to root as well:<br />
<br />
# chown root:root /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
Make sure the file has correct permissions:<br />
<br />
# chmod 755 /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
The scripts will be run in alphabetical order at connection time, and in reverse alphabetical order at disconnect time. To ensure what order they come up in, it is common to use numerical characters prior to the name of the script (e.g. {{ic|10-portmap}} or {{ic|30-netfs}} (which ensures that the ''portmapper'' is up before NFS mounts are attempted).<br />
<br />
Scripts will receive the following arguments:<br />
<br />
* '''Interface name:''' e.g. {{ic|eth0}}<br />
* '''Interface status:''' ''up'' or ''down''<br />
* '''VPN status:''' ''vpn-up'' or ''vpn-down''<br />
<br />
{{Warning|If you connect to foreign or public networks, be aware of what services you are starting and what servers you expect to be available for them to connect to. You could make a security hole by starting the wrong services while connected to a public network.}}<br />
<br />
=== Avoiding the dispatcher timeout ===<br />
<br />
If the above is working, then this section is not relevant. However, there is a general problem related to running dispatcher scripts which take longer to be executed. Initially an internal timeout of three seconds only was used. If the called script did not complete in time, it was killed. Later the timeout was extended to about 20 seconds (see the [https://bugzilla.redhat.com/show_bug.cgi?id=982734 Bugtracker] for more information). If the timeout still creates the problem, a work around may be to modify the dispatcher service file {{ic|/usr/lib/systemd/system/NetworkManager-dispatcher.service}} to remain active after exit: <br />
<br />
{{hc|/etc/systemd/system/NetworkManager-dispatcher.service.d/remain_after_exit.conf|2=<br />
[Service]<br />
RemainAfterExit=yes<br />
}}<br />
<br />
Now start and enable the modified {{ic|NetworkManager-dispatcher}} service.<br />
<br />
{{Warning|Adding the {{ic|RemainAfterExit}} line to it will prevent the dispatcher from closing. Unfortunately, the dispatcher '''has''' to close before it can run your scripts again. With it the dispatcher will not time out but it also will not close, which means that the scripts will only run once per boot. Therefore, do not add the line unless the timeout is definitely causing a problem.}}<br />
<br />
=== Dispatcher examples ===<br />
<br />
==== Mount remote folder with sshfs ====<br />
<br />
As the script is run in a very restrictive environment, you have to export {{ic|SSH_AUTH_SOCK}} in order to connect to your SSH agent. There are different ways to accomplish this, see [https://bbs.archlinux.org/viewtopic.php?pid=1042030#p1042030 this message] for more information. The example below works with [[GNOME Keyring]], and will ask you for the password if not unlocked already. In case NetworkManager connects automatically on login, it is likely ''gnome-keyring'' has not yet started and the export will fail (hence the sleep). The {{ic|UUID}} to match can be found with the command {{ic|nmcli connection status}} or {{ic|nmcli connection list}}. <br />
<br />
{{bc|<nowiki><br />
#!/bin/sh<br />
USER='username'<br />
REMOTE='user@host:/remote/path'<br />
LOCAL='/local/path'<br />
<br />
interface=$1 status=$2<br />
if [ "$CONNECTION_UUID" = "</nowiki>''uuid''<nowiki>" ]; then<br />
case $status in<br />
up)<br />
SSH_AUTH_SOCK=$(find /tmp -maxdepth 1 -type s -user "$USER" -name 'ssh')<br />
export SSH_AUTH_SOCK<br />
su "$USER" -c "sshfs $REMOTE $LOCAL"<br />
;;<br />
down)<br />
fusermount -u "$LOCAL"<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
==== Mounting of SMB shares ====<br />
<br />
Some [[SMB]] shares are only available on certain networks or locations (e.g. at home). You can use the dispatcher to only mount SMB shares that are present at your current location.<br />
<br />
The following script will check if we connected to a specific network and mount shares accordingly:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-mount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
# Find the connection UUID with "nmcli connection show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
if [ "$2" = "up" ]; then<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
mount /your/mount/point & <br />
# add more shares as needed<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The following script will unmount all SMB shares before a software initiated disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/pre-down.d/30-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|Make sure this script is located in the {{ic|pre-down.d}} sub-directory as shown above, otherwise it will unmount all shares on any connection state change.}}<br />
<br />
The following script will attempt to unmount all SMB shares following an unexpected disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/40-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
if [ "$2" = "down" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|<br />
* Since NetworkManager 0.9.8, the ''pre-down'' and ''down'' events are not executed on shutdown or restart, see [https://bugzilla.gnome.org/show_bug.cgi?id&#61;701242 this bug report] for more info.<br />
* The previous ''umount'' scripts are still prone to leaving applications actually accessing the mount to 'hang'.<br />
}}<br />
<br />
An alternative is to use the script as seen in [[NFS#Using a NetworkManager dispatcher]]:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-smb.sh|<nowiki><br />
#!/bin/bash<br />
<br />
# Find the connection UUID with "nmcli con show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
WANTED_CON_UUID="CHANGE-ME-NOW-9c7eff15-010a-4b1c-a786-9b4efa218ba9"<br />
<br />
if [[ "$CONNECTION_UUID" == "$WANTED_CON_UUID" ]]; then<br />
<br />
# Script parameter $1: NetworkManager connection name, not used<br />
# Script parameter $2: dispatched event<br />
<br />
case "$2" in<br />
"up")<br />
mount -a -t cifs<br />
;;<br />
"pre-down");&<br />
"vpn-pre-down")<br />
umount -l -a -t cifs >/dev/null<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|This script ignores mounts with the {{ic|noauto}} option, remove this mount option or use {{ic|auto}} to allow the dispatcher to manage these mounts.}}<br />
<br />
Create a symlink inside {{ic|/etc/NetworkManager/dispatcher.d/pre-down/}} to catch the {{ic|pre-down}} events:<br />
<br />
# ln -s ../30-smb.sh /etc/NetworkManager/dispatcher.d/pre-down.d/30-smb.sh<br />
<br />
==== Mounting of NFS shares ====<br />
<br />
See [[NFS#Using a NetworkManager dispatcher]].<br />
<br />
==== Use dispatcher to automatically toggle wireless depending on LAN cable being plugged in ====<br />
<br />
The idea is to only turn Wi-Fi on when the LAN cable is unplugged (for example when detaching from a laptop dock), and for Wi-Fi to be automatically disabled, once a LAN cable is plugged in again. <br />
<br />
Create the following dispatcher script[https://superuser.com/questions/233448/disable-wlan-if-wired-cable-network-is-available], replacing {{ic|1=LAN_interface}} with yours.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/wlan_auto_toggle.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$1" = "LAN_interface" ]; then<br />
case "$2" in<br />
up)<br />
nmcli radio wifi off<br />
;;<br />
down)<br />
nmcli radio wifi on<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|You can get a list of interfaces using [[#nmcli examples|nmcli]]. The ethernet (LAN) interfaces start with {{ic|en}}, e.g. {{ic|1=enp0s5}}}}<br />
<br />
==== Use dispatcher to connect to a VPN after a network connection is established ====<br />
<br />
In this example we want to connect automatically to a previously defined VPN connection after connecting to a specific Wi-Fi network. First thing to do is to create the dispatcher script that defines what to do after we are connected to the network.<br />
<br />
{{Note|This script will require {{Pkg|wireless_tools}} in order to use {{ic|iwgetid}}.}}<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME"<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you would like to attempt to automatically connect to VPN for all Wi-Fi networks, you can use the following definition of the ESSID: {{ic|1=ESSID=$(iwgetid -r)}}. Remember to set the script's permissions [[#Network services with NetworkManager dispatcher|accordingly]]. <br />
<br />
Trying to connect with the above script may still fail with {{ic|NetworkManager-dispatcher.service}} complaining about 'no valid VPN secrets', because of [https://developer.gnome.org/NetworkManager/0.9/secrets-flags.html the way VPN secrets are stored]. Fortunately, there are different options to give the above script access to your VPN password.<br />
<br />
1: One of them requires editing the VPN connection configuration file to make NetworkManager store the secrets by itself rather than inside a keyring [https://bugzilla.redhat.com/show_bug.cgi?id=710552 that will be inaccessible for root]: open up {{ic|/etc/NetworkManager/system-connections/''name of your VPN connection''}} and change the {{ic|password-flags}} and {{ic|secret-flags}} from {{ic|1}} to {{ic|0}}.<br />
<br />
If that alone does not work, you may have to create a {{ic|passwd-file}} in a safe location with the same permissions and ownership as the dispatcher script, containing the following:<br />
<br />
{{hc|/path/to/passwd-file|<br />
vpn.secrets.password:YOUR_PASSWORD<br />
}}<br />
<br />
The script must be changed accordingly, so that it gets the password from the file:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME" passwd-file /path/to/passwd-file<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
2: Alternatively, change the {{ic|password-flags}} and put the password directly in the configuration file adding the section {{ic|vpn-secrets}}:<br />
<br />
[vpn]<br />
....<br />
password-flags=0<br />
<br />
[vpn-secrets]<br />
password=''your_password''<br />
<br />
{{Note|It may now be necessary to re-open the NetworkManager connection editor and save the VPN passwords/secrets again.}}<br />
<br />
==== Use dispatcher to disable IPv6 on VPN provider connections ====<br />
<br />
Many [[:Category:VPN providers|commercial VPN providers]] support only IPv4. That means all IPv6 traffic bypasses the VPN and renders it virtually useless. To avoid this, dispatcher can be used to disable all IPv6 traffic for the time a VPN connection is up.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/10-vpn-ipv6|<nowiki><br />
#!/bin/sh<br />
<br />
case "$2" in<br />
vpn-up)<br />
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
vpn-down)<br />
echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
==== OpenNTPD ====<br />
<br />
See [[OpenNTPD#Using NetworkManager dispatcher]].<br />
<br />
== Testing ==<br />
<br />
NetworkManager applets are designed to load upon login so no further configuration should be necessary for most users. If you have already disabled your previous network settings and disconnected from your network, you can now test if NetworkManager will work. The first step is to [[start]] {{ic|NetworkManager.service}}.<br />
<br />
Some applets will provide you with a {{ic|.desktop}} file so that the NetworkManager applet can be loaded through the application menu. If it does not, you are going to either have to discover the command to use or logout and login again to start the applet. Once the applet is started, it will likely begin polling network connections with for auto-configuration with a DHCP server.<br />
<br />
To start the GNOME applet in non-xdg-compliant window managers like [[awesome]]:<br />
<br />
nm-applet --sm-disable &<br />
<br />
For static IP addresses, you will have to configure NetworkManager to understand them. The process usually involves right-clicking the applet and selecting something like 'Edit Connections'.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Encrypted Wi-Fi passwords ===<br />
<br />
By default, NetworkManager stores passwords in clear text in the connection files at {{ic|/etc/NetworkManager/system-connections/}}. To print the stored passwords, use the following command:<br />
<br />
# grep -r '^psk=' /etc/NetworkManager/system-connections/<br />
<br />
The passwords are accessible to the root user in the filesystem and to users with access to settings via the GUI (e.g. {{ic|nm-applet}}). <br />
<br />
It is preferable to save the passwords in encrypted form in a keyring instead of clear text. The downside of using a keyring is that the connections have to be set up for each user.<br />
<br />
==== Using GNOME Keyring ====<br />
<br />
The keyring daemon has to be started and the keyring needs to be unlocked for the following to work.<br />
<br />
Furthermore, NetworkManager needs to be configured not to store the password for all users. Using GNOME {{ic|nm-applet}}, run {{ic|nm-connection-editor}} from a terminal, select a network connection, click {{ic|Edit}}, select the {{ic|Wifi-Security}} tab and click on the right icon of password and check {{ic|Store the password only for this user}}.<br />
<br />
==== Using KDE Wallet ====<br />
<br />
Using KDE's {{Pkg|plasma-nm}}, click the applet, click on the top right {{ic|Settings}} icon, click on a network connection, in the {{ic|General settings}} tab, untick {{ic|all users may connect to this network}}. If the option is ticked, the passwords will still be stored in clear text, even if a keyring daemon is running.<br />
<br />
If the option was selected previously and you un-tick it, you may have to use the {{ic|reset}} option first to make the password disappear from the file. Alternatively, delete the connection first and set it up again.<br />
<br />
=== Sharing internet connection over Wi-Fi ===<br />
<br />
You can share your internet connection (e.g. 3G or wired) with a few clicks. Please note that a [[firewall]] may interfere with internet sharing.<br />
<br />
You will need a Wi-Fi card which supports AP mode, see [[Software access point#Wi-Fi device must support AP mode]] for details.<br />
<br />
[[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
<br />
Create the shared connection:<br />
<br />
* Click on applet and choose ''Create new wireless network''.<br />
* Follow wizard (choose WPA2 or higher, be sure to use at least 8 character long password, lower lengths will fail).<br />
** Choose either [[Fedora:Features/RealHotspot|Hotspot]] or Ad-hoc as Wi-Fi mode.<br />
<br />
The connection will be saved and remain stored for the next time you need it.<br />
<br />
{{Note|Android does not support connecting to Ad-hoc networks. To share a connection with Android use infrastructure mode (i.e. set Wi-Fi mode to "Hotspot").}}<br />
<br />
=== Sharing internet connection over Ethernet ===<br />
<br />
Scenario: your device has internet connection over wi-fi and you want to share the internet connection to other devices over ethernet.<br />
<br />
Requirements:<br />
<br />
* [[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
* Your internet connected device and the other devices are connected over a suitable ethernet cable (this usually means a cross over cable or a switch in between).<br />
* Internet sharing is not blocked by a [[firewall]].<br />
<br />
Steps:<br />
<br />
{{Style|{{Pkg|nm-connection-editor}} is not a dependency of {{Pkg|networkmanager}} and needs to be installed separately.}}<br />
<br />
* Run {{ic|nm-connection-editor}} from terminal.<br />
* Add a new ethernet connection.<br />
* Give it some sensible name. For example "Shared Internet"<br />
* Go to "IPv4 Settings".<br />
* For "Method:" select "Shared to other computers".<br />
* Save<br />
<br />
Now you should have a new option "Shared Internet" under the Wired connections in NetworkManager.<br />
<br />
=== Checking if networking is up inside a cron job or script ===<br />
<br />
{{Out of date|''nm-tool'' was remove from NetworkManager for long time now[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/bb8c75bd536d4f8fb80a4366025a279078f0ec81]. ''nmcli'' should be used instead.}}<br />
<br />
Some ''cron'' jobs require networking to be up to succeed. You may wish to avoid running these jobs when the network is down. To accomplish this, add an '''if''' test for networking that queries NetworkManager's ''nm-tool'' and checks the state of networking. The test shown here succeeds if any interface is up, and fails if they are all down. This is convenient for laptops that might be hardwired, might be on wireless, or might be off the network.<br />
<br />
{{bc|<nowiki><br />
if [ $(nm-tool|grep State|cut -f2 -d' ') == "connected" ]; then<br />
#Whatever you want to do if the network is online<br />
else<br />
#Whatever you want to do if the network is offline - note, this and the else above are optional<br />
fi<br />
</nowiki>}}<br />
<br />
This useful for a {{ic|cron.hourly}} script that runs ''fpupdate'' for the F-Prot virus scanner signature update, as an example. Another way it might be useful, with a little modification, is to differentiate between networks using various parts of the output from ''nm-tool''; for example, since the active wireless network is denoted with an asterisk, you could grep for the network name and then grep for a literal asterisk.<br />
<br />
=== Connect to network with secret on boot ===<br />
<br />
By default, NetworkManager will not connect to networks requiring a secret automatically on boot. This is because it locks such connections to the user who makes it by default, only connecting after they have logged in. To change this, do the following:<br />
<br />
# Right click on the {{ic|nm-applet}} icon in your panel and select Edit Connections and open the Wireless tab<br />
# Select the connection you want to work with and click the Edit button<br />
# Check the boxes “Connect Automatically” and “Available to all users”<br />
# Additionally, ensure that under "Wi-Fi Security", "Store password for all users (not encrypted)" is selected<br />
<br />
Log out and log back in to complete.<br />
<br />
=== OpenConnect with password in KWallet ===<br />
<br />
While you may type both values at connection time, {{Pkg|plasma-nm}} 0.9.3.2-1 and above are capable of retrieving OpenConnect username and password directly from [[KWallet]].<br />
<br />
Open "KDE Wallet Manager" and look up your OpenConnect VPN connection under "Network Management|Maps". Click "Show values" and <br />
enter your credentials in key "VpnSecrets" in this form (replace ''username'' and ''password'' accordingly):<br />
<br />
form:main:username%SEP%''username''%SEP%form:main:password%SEP%''password''<br />
<br />
Next time you connect, username and password should appear in the "VPN secrets" dialog box.<br />
<br />
=== Ignore specific devices ===<br />
<br />
Sometimes it may be desired that NetworkManager ignores specific devices and does not try to configure addresses and routes for them. You can quickly and easily ignore devices by MAC or interface-name by using the following in {{ic|/etc/NetworkManager/conf.d/unmanaged.conf}}:<br />
<br />
[keyfile]<br />
unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth0<br />
<br />
After editing the file, run {{ic|nmcli general reload}} as root. Afterwards you should be able to configure interfaces without NetworkManager altering what you have set.<br />
<br />
=== Configuring MAC address randomization ===<br />
<br />
{{Note|1=Disabling MAC address randomization may be needed to get (stable) link connection [https://bbs.archlinux.org/viewtopic.php?id=220101] and/or networks that restrict devices based on their MAC Address or have a limit network capacity.}}<br />
<br />
MAC randomization can be used for increased privacy by not disclosing your real MAC address to the network.<br />
<br />
NetworkManager supports two types MAC Address Randomization: randomization during scanning, and for network connections. Both modes can be configured by modifying {{ic|/etc/NetworkManager/NetworkManager.conf}} or by creating a separate configuration file in {{ic|/etc/NetworkManager/conf.d/}} which is recommended since the aforementioned config file may be overwritten by NetworkManager.<br />
<br />
Randomization during Wi-Fi scanning is enabled by default, but it may be disabled by adding the following lines to {{ic|/etc/NetworkManager/NetworkManager.conf}} or a dedicated configuration file under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device]<br />
wifi.scan-rand-mac-address=no<br />
}}<br />
<br />
MAC randomization for network connections can be set to different modes for both wireless and ethernet interfaces. See the [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details on the different modes. <br />
<br />
In terms of MAC randomization the most important modes are {{ic|stable}} and {{ic|random}}. {{ic|stable}} generates a random MAC address when you connect to a new network and associates the two permanently. This means that you will use the same MAC address every time you connect to that network. In contrast, {{ic|random}} will generate a new MAC address every time you connect to a network, new or previously known. You can configure the MAC randomization by adding the desired configuration under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device-mac-randomization]<br />
# "yes" is already the default for scanning<br />
wifi.scan-rand-mac-address=yes<br />
<br />
[connection-mac-randomization]<br />
# Randomize MAC for every ethernet connection<br />
ethernet.cloned-mac-address=random<br />
# Generate a random MAC for each WiFi and associate the two permanently.<br />
wifi.cloned-mac-address=stable<br />
}}<br />
<br />
See the following [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details.<br />
<br />
=== Enable IPv6 Privacy Extensions ===<br />
<br />
See [[IPv6#NetworkManager]].<br />
<br />
=== Working with wired connections ===<br />
<br />
By default, NetworkManager generates a connection profile for each wired ethernet connection it finds. At the point when generating the connection, it does not know whether there will be more ethernet adapters available. Hence, it calls the first wired connection "Wired connection 1". You can avoid generating this connection, by configuring {{ic|no-auto-default}} (see {{man|5|NetworkManager.conf}}), or by simply deleting it. Then NetworkManager will remember not to generate a connection for this interface again.<br />
<br />
You can also edit the connection (and persist it to disk) or delete it. NetworkManager will not re-generate a new connection. Then you can change the name to whatever you want. You can use something like nm-connection-editor for this task.<br />
<br />
=== Using iwd as the Wi-Fi backend ===<br />
<br />
Install {{AUR|networkmanager-iwd}} or enable the experimental [[iwd]] backend creating the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_backend.conf|2=<br />
[device]<br />
wifi.backend=iwd<br />
}}<br />
<br />
=== Running in a network namespace ===<br />
<br />
If you would like to run NetworkManager inside a network namespace (e.g., to manage a specific device which should be use by selected applications), bring the device down before moving it to the namespace:<br />
<br />
$ ip link set dev ''MY_DEVICE'' down<br />
$ ip link set dev ''MY_DEVICE'' netns ''MY_NAMESPACE''<br />
$ ip netns exec ''MY_NAMESPACE'' NetworkManager<br />
...<br />
$ ip netns exec ''MY_NAMESPACE'' killall NetworkManager<br />
<br />
otherwise NetworkManager will later fail to establish the connection with a {{ic|device is strictly unmanaged}} error.<br />
<br />
== Troubleshooting ==<br />
<br />
=== No prompt for password of secured Wi-Fi networks ===<br />
<br />
When trying to connect to a secured Wi-Fi network, no prompt for a password is shown and no connection is established. This happens when no keyring package is installed. An easy solution is to install {{Pkg|gnome-keyring}}. If you want the passwords to be stored in encrypted form, follow [[GNOME Keyring]] to set up the ''gnome-keyring-daemon''.<br />
<br />
=== Network management disabled ===<br />
<br />
When NetworkManager shuts down but the pid (state) file is not removed, you will see a {{ic|Network management disabled}} message. If this happens, remove the file manually:<br />
<br />
# rm /var/lib/NetworkManager/NetworkManager.state<br />
<br />
=== Problems with internal DHCP client ===<br />
<br />
If you have problems with getting an IP address using the internal DHCP client, consider using another DHCP client, see [[#DHCP client]] for instructions. This workaround might solve problems in big wireless networks like eduroam.<br />
<br />
=== DHCP problems with dhclient ===<br />
<br />
If you have problems with getting an IP address via DHCP, try to add the following to your {{ic|/etc/dhclient.conf}}:<br />
<br />
interface "eth0" {<br />
send dhcp-client-identifier 01:''aa:bb:cc:dd:ee:ff'';<br />
}<br />
<br />
Where {{ic|''aa:bb:cc:dd:ee:ff''}} is the MAC address of this NIC. The MAC address can be found using the {{ic|ip link show ''interface''}} command from the {{Pkg|iproute2}} package.<br />
<br />
=== 3G modem not detected ===<br />
<br />
See [[USB 3G Modem#NetworkManager]].<br />
<br />
=== Switching off WLAN on laptops ===<br />
<br />
Sometimes NetworkManager will not work when you disable your Wi-Fi adapter with a switch on your laptop and try to enable it again afterwards. This is often a problem with ''rfkill''. To check if the driver notifies ''rfkill'' about the wireless adapter's status, use:<br />
<br />
$ watch -n1 rfkill list all<br />
<br />
If one identifier stays blocked after you switch on the adapter you could try to manually unblock it with (where X is the number of the identifier provided by the above output):<br />
<br />
# rfkill event unblock X<br />
<br />
=== Static IP address settings revert to DHCP ===<br />
<br />
Due to an unresolved bug, when changing default connections to a static IP address, {{ic|nm-applet}} may not properly store the configuration change, and will revert to automatic DHCP.<br />
<br />
To work around this issue you have to edit the default connection (e.g. "Auto eth0") in {{ic|nm-applet}}, change the connection name (e.g. "my eth0"), uncheck the "Available to all users" checkbox, change your static IP address settings as desired, and click '''Apply'''. This will save a new connection with the given name.<br />
<br />
Next, you will want to make the default connection not connect automatically. To do so, run {{ic|nm-connection-editor}} ('''not''' as root). In the connection editor, edit the default connection (e.g. "Auto eth0") and uncheck "Connect automatically". Click '''Apply''' and close the connection editor.<br />
<br />
=== Cannot edit connections as normal user ===<br />
<br />
See [[#Set up PolicyKit permissions]].<br />
<br />
=== Forget hidden wireless network ===<br />
<br />
Since hidden networks are not displayed in the selection list of the Wireless view, they cannot be forgotten (removed) with the GUI. You can delete one with the following command:<br />
<br />
# rm /etc/NetworkManager/system-connections/''SSID''<br />
<br />
This works for any other connection.<br />
<br />
=== VPN not working in GNOME ===<br />
<br />
When setting up OpenConnect or vpnc connections in NetworkManager while using GNOME, you will sometimes never see the dialog box pop up and the following error appears in {{ic|/var/log/errors.log}}:<br />
<br />
localhost NetworkManager[399]: <error> [1361719690.10506] [nm-vpn-connection.c:1405] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.<br />
<br />
This is caused by the GNOME NM Applet expecting dialog scripts to be at {{ic|/usr/lib/gnome-shell}}, when NetworkManager's packages put them in {{ic|/usr/lib/networkmanager}}.<br />
As a "temporary" fix (this bug has been around for a while now), make the following symlink(s):<br />
<br />
* For OpenConnect: {{ic|ln -s /usr/lib/networkmanager/nm-openconnect-auth-dialog /usr/lib/gnome-shell/}}<br />
* For VPNC (i.e. Cisco VPN): {{ic|ln -s /usr/lib/networkmanager/nm-vpnc-auth-dialog /usr/lib/gnome-shell/}}<br />
<br />
This may need to be done for any other NM VPN plugins as well, but these are the two most common.<br />
<br />
=== Unable to connect to visible European wireless networks ===<br />
<br />
WLAN chips are shipped with a default [[Wireless network configuration#Respecting the regulatory domain|regulatory domain]]. If your access point does not operate within these limitations, you will not be able to connect to the network. Fixing this is easy:<br />
<br />
# [[Install]] {{Pkg|crda}}<br />
# Uncomment the correct Country Code in {{ic|/etc/conf.d/wireless-regdom}}<br />
# Reboot the system, because the setting is only read on boot<br />
<br />
=== Automatic connect to VPN on boot is not working ===<br />
<br />
The problem occurs when the system (i.e. NetworkManager running as the root user) tries to establish a VPN connection, but the password is not accessible because it is stored in the GNOME keyring of a particular user. <br />
<br />
A solution is to keep the password to your VPN in plaintext, as described in step (2.) of [[#Use dispatcher to connect to a VPN after a network connection is established]]. <br />
<br />
You do not need to use the dispatcher described in step (1.) to auto-connect anymore, if you use the new "auto-connect VPN" option from the {{ic|nm-applet}} GUI.<br />
<br />
=== Systemd Bottleneck ===<br />
<br />
Over time the log files ({{ic|/var/log/journal}}) can become very large. This can have a big impact on boot performance when using NetworkManager, see: [[Systemd#Boot time increasing over time]].<br />
<br />
=== Regular network disconnects, latency and lost packets (WiFi) ===<br />
<br />
NetworkManager does a scan every 2 minutes.<br />
<br />
Some WiFi drivers have issues when scanning for base stations whilst connected/associated. Symptoms include VPN disconnects/reconnects and lost packets, web pages failing to load and then refresh fine.<br />
<br />
Running {{ic|journalctl -f}} will indicate that this is taking place, messages like the following will be contained in the logs at regular intervals.<br />
<br />
NetworkManager[410]: <info> (wlp3s0): roamed from BSSID 00:14:48:11:20:CF (my-wifi-name) to (none) ((none))<br />
<br />
There is a patched version of NetworkManager which should prevent this type of scanning: {{AUR|networkmanager-noscan}}.<br />
<br />
Alternatively, if roaming is not important, the periodic scanning behavior can be disabled by locking the BSSID of the access point in the WiFi connection profile.<br />
<br />
=== Unable to turn on wi-fi with Lenovo laptop (IdeaPad, Legion, etc.) ===<br />
<br />
There is an issue with the {{ic|ideapad_laptop}} module on some Lenovo models due to the wi-fi driver incorrectly reporting a soft block. The card can still be manipulated with {{ic|netctl}}, but managers like NetworkManager break. You can verify that this is the problem by checking the output of {{ic|rfkill list}} after toggling your hardware switch and seeing that the soft block persists.<br />
<br />
{{Accuracy|Try to use {{ic|rfkill.default_state}} and {{ic|rfkill.master_switch_mode}} (see [https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt kernel-parameters.txt]) to fix the rfkill problem.}}<br />
<br />
[[modprobe|Unloading]] the {{ic|ideapad_laptop}} module should fix this. ('''warning''': this may disable the laptop keyboard and touchpad also!).<br />
<br />
=== Turn off hostname sending ===<br />
<br />
NetworkManager by default sends the hostname to the DHCP server. Hostname sending can only be disabled per connection not globally ([https://bugzilla.gnome.org/show_bug.cgi?id=768076 GNOME Bug 768076]).<br />
<br />
To disable sending your hostname to the DHCP server for a specific connection, add the following to your network connection file:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''your_connection_file''|2=<br />
...<br />
[ipv4]<br />
dhcp-send-hostname=false<br />
...<br />
[ipv6]<br />
dhcp-send-hostname=false<br />
...<br />
}}<br />
<br />
=== nm-applet disappears in i3wm ===<br />
<br />
If you use the {{ic|xfce4-notifyd.service}} for notifications you must [[edit]] the unit and add the following:<br />
<br />
{{hc|/etc/systemd/user/xfce4-notifyd.service.d/display_env.conf|2=<br />
[Service]<br />
Environment="DISPLAY=:0.0"<br />
}}<br />
<br />
After reloading the daemons [[restart]] {{ic|xfce4-notifyd.service}}. Exit i3 and start it back up again and the applet should show on the tray.<br />
<br />
=== nm-applet tray icons display wrongly ===<br />
<br />
Currently the tray icons of nm-applet are drawn on top of one another, i.e. the icon displaying wireless strength might show on top of the icon indicating no wired connection.<br />
This is apparently a GTK3 bug/problem: https://gitlab.gnome.org/GNOME/gtk/issues/1280 .<br />
<br />
A patched version of GTK3 exists in AUR, which apparently fixes the tray icon bug: {{AUR|gtk3-mushrooms}} .<br />
<br />
=== Unit dbus-org.freedesktop.resolve1.service not found ===<br />
<br />
If {{ic|systemd-resolved.service}} is not started, NetworkManager will try to start it using D-Bus and fail:<br />
<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
dbus-daemon[991]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
<br />
This is because NetworkManager will try to send DNS information to [[systemd-resolved]] regardless of the {{ic|1=main.dns=}} setting in {{man|5|NetworkManager.conf}}.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383]<br />
<br />
This can be disabled with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/no-systemd-resolved.conf|2=<br />
[main]<br />
systemd-resolved=false<br />
}}<br />
<br />
See {{Bug|62138}}.<br />
<br />
=== Secrets were required, but not provided ===<br />
<br />
If you attempt to connect to a network using {{ic|nmcli device wifi connect ''SSID'' password ''password''}} and received the following error:<br />
<br />
Error: Connection activation failed: (7) Secrets were required, but not provided<br />
<br />
The error can be resolved by deleting the connection profile and creating a new one:<br />
<br />
$ nmcli connection delete ''SSID''<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
=== WPA Enterprise connection with NetworkManager ===<br />
<br />
If you try to connect to an WPA Enterprise network like 'eduroam' with NetworkManager with the [[iwd]] backend then you will get the following error from NetworkManager:<br />
<br />
Connection 'eduroam' is not avialable on device wlan0 because profile is not compatible with device (802.1x connections must have IWD provisioning files)<br />
<br />
This is because NetworkManager can not configure a WPA Enterprise network. Therefore you have to configure it using an iwd config file {{ic|/var/lib/iwd/''essid''.8021x}} like described in [[iwd#WPA Enterprise]].<br />
<br />
== See also ==<br />
<br />
* [https://blogs.gnome.org/dcbw/2015/02/16/networkmanager-for-administrators-part-1/ NetworkManager for Administrators Part 1]<br />
* [[Wikipedia:NetworkManager]]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=NetworkManager&diff=627195NetworkManager2020-07-30T13:06:04Z<p>Tobbebobbe: Added section "Automatically connect to VPN" since it is a relevant topic and could not find it on this page or any of the VPN-pages</p>
<hr />
<div>[[Category:Network managers]]<br />
[[Category:Red Hat]]<br />
[[cs:NetworkManager]]<br />
[[de:Networkmanager]]<br />
[[es:NetworkManager]]<br />
[[fr:NetworkManager]]<br />
[[it:NetworkManager]]<br />
[[ja:NetworkManager]]<br />
[[pt:NetworkManager]]<br />
[[zh-hans:NetworkManager]]<br />
{{Related articles start}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related articles end}}<br />
[https://wiki.gnome.org/Projects/NetworkManager/ NetworkManager] is a program for providing detection and configuration for systems to automatically connect to networks. NetworkManager's functionality can be useful for both wireless and wired networks. For wireless networks, NetworkManager prefers known wireless networks and has the ability to switch to the most reliable network. NetworkManager-aware applications can switch from online and offline mode. NetworkManager also prefers wired connections over wireless ones, has support for modem connections and certain types of VPN. NetworkManager was originally developed by Red Hat and now is hosted by the [[GNOME]] project.<br />
<br />
{{Expansion|Clear text storage of secrets is not limited to just Wi-Fi passwords. The secrets are stored in files (and folder) only accesible to root.}}<br />
<br />
{{Warning|By default, Wi-Fi passwords are stored in clear text, see [[#Encrypted Wi-Fi passwords]].}}<br />
<br />
== Installation ==<br />
<br />
NetworkManager can be [[install]]ed with the package {{Pkg|networkmanager}}, which contains a daemon, a command line interface ({{ic|nmcli}}) and a curses‐based interface ({{ic|nmtui}}). <br />
<br />
=== Enable NetworkManager ===<br />
<br />
After installation, you should [[start/enable]] {{ic|NetworkManager.service}}. Once the NetworkManager daemon is started, it will automatically connect to any available "system connections" that have already been configured. Any "user connections" or unconfigured connections will need ''nmcli'' or an applet to configure and connect.<br />
<br />
=== Additional interfaces ===<br />
<br />
* {{Pkg|nm-connection-editor}} for a graphical user interface,<br />
* {{Pkg|network-manager-applet}} for a system tray applet ({{ic|nm-applet}}).<br />
<br />
{{Note|You must ensure that no other service that wants to configure the network is running; in fact, multiple networking services will conflict. You can find a list of the currently running services with {{ic|1=systemctl --type=service}} and then [[stop]] them. See [[#Configuration]] to enable the NetworkManager service.}}<br />
<br />
=== Mobile broadband support ===<br />
<br />
[[Install]] {{Pkg|modemmanager}}, {{Pkg|mobile-broadband-provider-info}} and {{Pkg|usb_modeswitch}} packages for mobile broadband connection support. See [[USB 3G Modem#NetworkManager]] for details.<br />
<br />
=== PPPoE / DSL support ===<br />
<br />
[[Install]] {{Pkg|rp-pppoe}} package for PPPoE / DSL connection support. To actually add PPPoE connection, use {{ic|1=nm-connection-editor}} and add new DSL/PPPoE connection.<br />
<br />
=== VPN support ===<br />
<br />
NetworkManager since version 1.16 has native support for [[WireGuard]], all it needs is the {{ic|wireguard}} kernel module. Read the [https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-networkmanager/ WireGuard in NetworkManager blog post] for details.<br />
<br />
Support for other VPN types is based on a plug-in system. They are provided in the following packages:<br />
<br />
* {{Pkg|networkmanager-openconnect}} for [[OpenConnect]]<br />
* [[networkmanager-openvpn]] for [[OpenVPN]]<br />
* {{Pkg|networkmanager-pptp}} for [[PPTP Client]]<br />
* {{Pkg|networkmanager-vpnc}} for [[Vpnc]]<br />
* {{Pkg|networkmanager-strongswan}} for [[strongSwan]]<br />
* {{AUR|networkmanager-fortisslvpn-git}}<br />
* {{AUR|networkmanager-iodine-git}}<br />
* {{AUR|networkmanager-libreswan}}<br />
* {{AUR|networkmanager-l2tp}}<br />
* {{AUR|networkmanager-ssh-git}}<br />
* {{Pkg|network-manager-sstp}}<br />
<br />
{{Warning|1=There are a lot of [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues?search=VPN&state=opened bugs] (and [https://bugzilla.gnome.org/buglist.cgi?bug_status=__open__&content=VPN&product=NetworkManager old bugs]) related to VPN support. Check the daemon processes options set via the GUI correctly and double-check with each package release.}}<br />
<br />
{{Note|To have fully functioning DNS resolution when using VPN, you should set up [[#DNS caching and conditional forwarding|conditional forwarding]].}}<br />
<br />
== Usage ==<br />
<br />
NetworkManager comes with {{man|1|nmcli}} and {{man|1|nmtui}}.<br />
<br />
=== nmcli examples ===<br />
<br />
List nearby wifi networks:<br />
<br />
$ nmcli device wifi list<br />
<br />
Connect to a wifi network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
Connect to a hidden network:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' hidden yes<br />
<br />
Connect to a wifi on the {{ic|wlan1}} wifi interface:<br />
<br />
$ nmcli device wifi connect ''SSID'' password ''password'' ifname wlan1 ''profile_name''<br />
<br />
Disconnect an interface:<br />
<br />
$ nmcli device disconnect ifname eth0<br />
<br />
Reconnect an interface marked as disconnected:<br />
<br />
$ nmcli connection up uuid ''UUID''<br />
<br />
Get a list of UUIDs:<br />
<br />
$ nmcli connection show<br />
<br />
See a list of network devices and their state:<br />
<br />
$ nmcli device<br />
<br />
Turn off wifi:<br />
<br />
$ nmcli radio wifi off<br />
<br />
=== Edit a connection ===<br />
<br />
For a comprehensive list of settings, see {{man|5|nm-settings}}.<br />
<br />
Firstly you need to get list of connections:<br />
<br />
{{hc|$ nmcli connection|<nowiki><br />
NAME UUID TYPE DEVICE<br />
Wired connection 2 e7054040-a421-3bef-965d-bb7d60b7cecf ethernet enp5s0<br />
Wired connection 1 997f2782-f0fc-301d-bfba-15421a2735d8 ethernet enp0s25<br />
MY-HOME-WIFI-5G 92a0f7b3-2eba-49ab-a899-24d83978f308 wifi --<br />
</nowiki>}}<br />
<br />
Here you can use the first column as connection-id used later. In this example we pick {{ic|Wired connection 2}} as a connection-id.<br />
<br />
You have three methods to configure a connection {{ic|Wired connection 2}} after it has been created:<br />
<br />
; nmcli interactive editor<br />
: {{ic|nmcli connection edit 'Wired connection 2'}}.<br> Usage is well documented from the editor.<br />
<br />
; nmcli command line interface<br />
: {{ic|nmcli connection modify 'Wired connection 2' ''setting''.''property'' ''value''}}. See {{man|1|nmcli}} for usage. For example you can change its IPv4 route metric to 200 using {{ic|nmcli connection modify 'Wired connection 2' ipv4.route-metric 200}} command.<br />
<br />
; Connection file<br />
: In {{ic|/etc/NetworkManager/system-connections/}}, modify the corresponding {{ic|Wired connection 2.nmconnection}} file .<br> Do not forget to reload the configuration file with {{ic|nmcli connection reload}}.<br />
<br />
== Front-ends ==<br />
<br />
To configure and have easy access to NetworkManager, most users will want to install an applet. This GUI front-end usually resides in the system tray (or notification area) and allows network selection and configuration of NetworkManager. Various desktop environments have their own applet. Otherwise you can use [[#nm-applet]].<br />
<br />
=== GNOME ===<br />
<br />
[[GNOME]] has a built-in tool, accessible from the Network settings.<br />
<br />
=== KDE Plasma ===<br />
<br />
[[Install]] the {{Pkg|plasma-nm}} package. After that, add it to the KDE taskbar via the ''Panel options > Add widgets > Networks'' menu.<br />
<br />
=== nm-applet ===<br />
<br />
{{Pkg|network-manager-applet}} is a GTK 3 front-end which works under Xorg environments with a systray.<br />
<br />
To store connection secrets install and configure [[GNOME/Keyring]].<br />
<br />
Be aware that after enabling the tick-box option {{ic|Make available to other users}} for a connection, NetworkManager stores the password in plain-text, though the respective file is accessible only to root (or other users via {{ic|nm-applet}}). See [[#Encrypted Wi-Fi passwords]].<br />
<br />
In order to run {{ic|nm-applet}} without a systray, you can use {{Pkg|trayer}} or {{Pkg|stalonetray}}. For example, you can add a script like this one in your path:<br />
<br />
{{hc|nmgui|<nowiki><br />
#!/bin/sh<br />
nm-applet 2>&1 > /dev/null &<br />
stalonetray 2>&1 > /dev/null<br />
killall nm-applet<br />
</nowiki>}}<br />
<br />
When you close the ''stalonetray'' window, it closes {{ic|nm-applet}} too, so no extra memory is used once you are done with network settings.<br />
<br />
The applet can show notifications for events such as connecting to or disconnecting from a WiFi network. For these notifications to display, ensure that you have a notification server installed - see [[Desktop notifications]]. If you use the applet without a notification server, you might see some messages in stdout/stderr, and the app might hang. See [https://bugzilla.gnome.org/show_bug.cgi?id=788313].<br />
<br />
In order to run {{ic|nm-applet}} with such notifications disabled, start the applet with the following command:<br />
<br />
$ nm-applet --no-agent<br />
<br />
{{Tip|{{ic|nm-applet}} might be started automatically with a [[XDG Autostart|autostart desktop file]], to add the --no-agent option modify the Exec line there, i.e.<br />
<br />
{{bc|1=Exec=nm-applet --no-agent}}<br />
<br />
}}<br />
<br />
{{Warning|On [[i3]], if nm-applet is started with the {{ic|--no-agent}} option, it is not possible to connect to a new encrypted WiFi network by clicking on the item list because no password input dialogue window will pop out. [[journal]] will show {{ic|no secrets: No agents were available for this request}}.}}<br />
<br />
==== Appindicator ====<br />
<br />
As of version 1.18.0 Appindicator support is [https://github.com/archlinux/svntogit-packages/commit/7640a2bd557fe84813207ef4d5e35bb5aece6c54 available] in the official {{Pkg|network-manager-applet}} package. To use nm-applet in an Appindicator environment start the applet with the following command:<br />
<br />
$ nm-applet --indicator<br />
<br />
=== networkmanager-dmenu ===<br />
<br />
Alternatively there is {{AUR|networkmanager-dmenu-git}} which is a small script to manage NetworkManager connections with [[dmenu]] or [[rofi]] instead of {{ic|nm-applet}}. It provides all essential features such as connection to existing NetworkManager wifi or wired connections, connect to new wifi connections, requests passphrase if required, connect to existing VPN connections, enable/disable networking, launch ''nm-connection-editor'' GUI, connect to Bluetooth networks.<br />
<br />
== Configuration ==<br />
<br />
NetworkManager will require some additional steps to be able run properly. Make sure you have configured {{ic|/etc/hosts}} as described in [[Network configuration#Set the hostname]] section.<br />
<br />
NetworkManager has a global configuration file at {{ic|/etc/NetworkManager/NetworkManager.conf}}. Addition configuration files can be placed in {{ic|/etc/NetworkManager/conf.d/}}. Usually no configuration needs to be done to the global defaults.<br />
<br />
After editing a configuration file, the changes can be applied by running:<br />
<br />
# nmcli general reload<br />
<br />
=== Enable NetworkManager Wait Online ===<br />
<br />
{{Out of date|{{ic|NetworkManager.service}} has {{ic|1=Also=NetworkManager-wait-online.service}} in the {{ic|[Install]}} section.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/167e42a87e97ed7fb26a4263c22f1774716ac51b] If {{ic|NetworkManager.service}} was [[enable]]d before the change, it needs to be [[enable|reenabled]].}}<br />
<br />
If you have services which fail if they are started before the network is up, you may use {{ic|NetworkManager-wait-online.service}} in addition to {{ic|NetworkManager.service}}. This is, however, rarely necessary because most networked daemons start up okay, even if the network has not been configured yet.<br />
<br />
In some cases, the service will still fail to start successfully on boot due to the timeout setting in {{ic|/usr/lib/systemd/system/NetworkManager-wait-online.service}} being too short. Change the default timeout from 30 to a higher value.<br />
<br />
=== Set up PolicyKit permissions ===<br />
<br />
See [[General troubleshooting#Session permissions]] for setting up a working session.<br />
<br />
With a working session, you have several options for granting the necessary privileges to NetworkManager:<br />
<br />
* ''Option 1.'' Run a [[Polkit]] authentication agent when you log in, such as {{ic|/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1}} (part of {{Pkg|polkit-gnome}}). You will be prompted for your password whenever you add or remove a network connection.<br />
* ''Option 2.'' [[Users and groups#Group management|Add]] yourself to the {{ic|wheel}} group. You will not have to enter your password, but your user account may be granted other permissions as well, such as the ability to use [[sudo]] without entering the root password.<br />
* ''Option 3.'' [[Users and groups#Group management|Add]] yourself to the {{ic|network}} group and create the following file:<br />
<br />
{{hc|/etc/polkit-1/rules.d/50-org.freedesktop.NetworkManager.rules|<nowiki><br />
polkit.addRule(function(action, subject) {<br />
if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0 && subject.isInGroup("network")) {<br />
return polkit.Result.YES;<br />
}<br />
});<br />
</nowiki>}}<br />
<br />
: All users in the {{ic|network}} group will be able to add and remove networks without a password. This will not work under [[systemd]] if you do not have an active session with ''systemd-logind''.<br />
<br />
=== Proxy settings ===<br />
<br />
NetworkManager does not directly handle proxy settings, but if you are using [[GNOME]] or [[KDE]], you could use [http://marin.jb.free.fr/proxydriver/ proxydriver] which handles proxy settings using NetworkManager's information. proxydriver is found in the package {{AUR|proxydriver}}.<br />
<br />
In order for ''proxydriver'' to be able to change the proxy settings, you would need to execute this command, as part of the GNOME startup process (see [[GNOME#Autostart]]).<br />
<br />
xhost +si:localuser:''username''<br />
<br />
See also [[Proxy settings]].<br />
<br />
=== Checking connectivity ===<br />
<br />
NetworkManager can try to reach a page on Internet when connecting to a network. {{Pkg|networkmanager}} is configured by default in {{ic|/usr/lib/NetworkManager/conf.d/20-connectivity.conf}} to check connectivity to archlinux.org. To use a different webserver or disable connectivity checking create {{ic|/etc/NetworkManager/conf.d/20-connectivity.conf}}, see {{man|5|NetworkManager.conf|CONNECTIVITY SECTION}}. Below is an example of using GNOME servers (it does not require the use of [[GNOME]]):<br />
<br />
{{hc|/etc/NetworkManager/conf.d/20-connectivity.conf|<nowiki><br />
[connectivity]<br />
uri=http://nmcheck.gnome.org/check_network_status.txt<br />
</nowiki>}}<br />
<br />
{{Note|Although automatic connectivity checks are a potential privacy leak, the official archlinux.org default connectivity URL is committed to not logging any access. See [https://gitlab.archlinux.org/archlinux/infrastructure/-/commit/68fbaca2ef9f31f624f117899848f4288d6b39d1].}}<br />
<br />
=== Captive portals ===<br />
<br />
{{Style|Complex scripts should not be maintained on the wiki.}}<br />
<br />
For those behind a [[Wikipedia:Captive portal|captive portal]], the desktop manager may automatically open a window asking for credentials. If your desktop does not, you can use {{Pkg|capnet-assist}} package (however, it currently it has a broken NetworkManager dispatcher script). Alternatively, you can create a NetworkManager dispatcher script with the following content:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/90-open_captive_portal|<nowiki><br />
#!/bin/sh -e<br />
# Script to dispatch NetworkManager events<br />
#<br />
# Runs shows a login webpage on walled garden networks.<br />
# See NetworkManager(8) for further documentation of the dispatcher events.<br />
<br />
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin<br />
<br />
if [ -x "/usr/bin/logger" ]; then<br />
logger="/usr/bin/logger -s -t captive-portal"<br />
else<br />
logger=":"<br />
fi<br />
<br />
wait_for_process() {<br />
PNAME=$1<br />
while [ -z "$(/usr/bin/pgrep $PNAME)" ]; do<br />
sleep 3;<br />
done<br />
}<br />
<br />
#launch the browser, but on boot we need to wait that nm-applet starts<br />
start_browser() {<br />
local user="$1"<br />
local display="$2"<br />
<br />
export DISPLAY="$display"<br />
wait_for_process nm-applet<br />
<br />
export XAUTHORITY="/home/$user/.Xauthority"<br />
<br />
$logger "Running browser as '$user' with display '$display' to login in captive portal"<br />
sudo -u "$user" --preserve-env=DISPLAY,XAUTHORITY -H xdg-open http://capnet.elementary.io 2>&1 > /dev/null<br />
}<br />
<br />
# Run the right scripts<br />
case "$2" in<br />
connectivity-change)<br />
$logger -p user.debug "dispatcher script triggered on connectivity change: $CONNECTIVITY_STATE"<br />
if [ "$CONNECTIVITY_STATE" = "PORTAL" ]; then<br />
# Match last column of who's output with ' :[at least one digit] '<br />
who | awk '$NF ~ /\(:[0-9]+\)/ { print $1 " " substr($NF, 2, length($NF)-2) };' | \<br />
while read user display; do<br />
start_browser $user $display || $logger -p user.err "Failed for user: '$user' display: '$display'"<br />
done<br />
fi<br />
;;<br />
*)<br />
# In a down phase<br />
exit 0<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
You will need to [[restart]] {{ic|NetworkManager.service}} or reboot for this to start working. Once you do, the dispatcher script should open a login window once it detects you are behind a captive portal.<br />
<br />
Another solution is {{AUR|captive-browser-git}} based on Google Chrome.<br />
<br />
=== DHCP client ===<br />
<br />
By default NetworkManager uses its internal DHCP client. The internal DHCPv4 plugin is based on the [https://nettools.github.io/n-dhcp4/ nettools' n-dhcp4] library, while the internal DHCPv6 plugin is made from code based on systemd-networkd.<br />
<br />
To use ISC’s DHCP client, [[install]] {{Pkg|dhclient}}. To change the DHCP client backend, set the option {{ic|1=main.dhcp=''dhcp_client_name''}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}. E.g.:<br />
<br />
{{hc|1=/etc/NetworkManager/conf.d/dhcp-client.conf|2=<br />
[main]<br />
dhcp=dhclient<br />
}}<br />
<br />
{{Note|<br />
* Do not enable the systemd units shipped with the {{Pkg|dhclient}} and {{Pkg|dhcpcd}} packages. They will conflict with NetworkManager, see the note in [[#Installation]] for details.<br />
* NetworkManger does not support dhcpcd ≥ 9.0.0. See {{Bug|66231}}.<br />
}}<br />
<br />
=== DNS management ===<br />
<br />
NetworkManager's DNS management is described in the GNOME project's wiki page—[https://wiki.gnome.org/Projects/NetworkManager/DNS Projects/NetworkManager/DNS].<br />
<br />
==== DNS caching and conditional forwarding ====<br />
<br />
NetworkManager has a plugin to enable DNS caching and conditional forwarding ([https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/143 previously] called "split DNS" in NetworkManager's documentation) using [[dnsmasq]] or [[systemd-resolved]]. The advantages of this setup is that DNS lookups will be cached, shortening resolve times, and DNS lookups of VPN hosts will be routed to the relevant VPN's DNS servers. This is especially useful if you are connected to more than one VPN.<br />
<br />
===== dnsmasq =====<br />
<br />
Make sure {{Pkg|dnsmasq}} has been installed. Then set {{ic|1=main.dns=dnsmasq}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=dnsmasq<br />
}}<br />
<br />
Now run {{ic|nmcli general reload}} as root. NetworkManager will automatically start dnsmasq and add {{ic|127.0.0.1}} to {{ic|/etc/resolv.conf}}. The original DNS servers can be found in {{ic|/run/NetworkManager/no-stub-resolv.conf}}. You can verify dnsmasq is being used by doing the same DNS lookup twice with {{ic|drill example.com}} and verifying the server and query times.<br />
<br />
{{Note|<br />
* You do not need to start {{ic|dnsmasq.service}} or edit {{ic|/etc/dnsmasq.conf}}. NetworkManager will start dnsmasq without using the systemd service and without reading the dnsmasq's default configuration file(s).<br />
* The dnsmasq instance started by NetworkManager will bind to {{ic|127.0.0.1:53}}, you cannot run any other software (including {{ic|dnsmasq.service}}) on the same address and port.<br />
}}<br />
<br />
====== Custom dnsmasq configuration ======<br />
<br />
Custom configurations can be created for ''dnsmasq'' by creating configuration files in {{ic|/etc/NetworkManager/dnsmasq.d/}}. For example, to change the size of the DNS cache (which is stored in RAM):<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/cache.conf|2=<br />
cache-size=1000<br />
}}<br />
<br />
{{Tip|Check the configuration file syntax with {{ic|1=dnsmasq --test --conf-file=/dev/null --conf-dir=/etc/NetworkManager/dnsmasq.d}}.}}<br />
<br />
See {{man|8|dnsmasq}} for all available options.<br />
<br />
====== IPv6 ======<br />
<br />
{{Accuracy|This does not solve the issue because NetworkManager does not add {{ic|::1}} to {{ic|/etc/resolv.conf}}. Unless {{ic|@::1}} is manually passed to drill, it will still fail with {{ic|Error: error sending query: No (valid) nameservers defined in the resolver}}.}}<br />
<br />
Enabling {{ic|dnsmasq}} in NetworkManager may break IPv6-only DNS lookups (i.e. {{ic|drill -6 [hostname]}}) which would otherwise work. In order to resolve this, creating the following file will configure ''dnsmasq'' to also listen to the IPv6 loopback:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/ipv6-listen.conf|2=<br />
listen-address=::1<br />
}}<br />
<br />
In addition, {{ic|dnsmasq}} also does not prioritize upstream IPv6 DNS. Unfortunately NetworkManager does not do this ([https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/936712 Ubuntu Bug]). A workaround would be to disable IPv4 DNS in the NetworkManager config, assuming one exists<br />
<br />
====== DNSSEC ======<br />
<br />
The dnsmasq instance started by NetworkManager by default will not validate [[DNSSEC]] since it is started with the {{ic|--proxy-dnssec}} option. It will trust whatever DNSSEC information it gets from the upstream DNS server.<br />
<br />
For dnsmasq to properly validate DNSSEC, thus breaking DNS resolution with name servers that do not support it, create the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/dnsmasq.d/dnssec.conf|2=<br />
conf-file=/usr/share/dnsmasq/trust-anchors.conf<br />
dnssec<br />
}}<br />
<br />
===== systemd-resolved =====<br />
<br />
{{Expansion|NetworkManager 1.16 adds a new setting {{ic|main.systemd-resolved}}[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383] (enabled by default). It unconditionally sends DNS configuration to systemd-resolved. Related to "Preserving resolv.conf" from [[systemd-resolved#DNS]]?}}<br />
<br />
NetworkManager can use [[systemd-resolved]] as a DNS resolver and cache. Make sure that ''systemd-resolved'' is properly configured and that {{ic|systemd-resolved.service}} is [[started]] before using it.<br />
<br />
systemd-resolved will be used automatically if {{ic|/etc/resolv.conf}} is a [[Systemd-resolved#DNS|symlink]] to {{ic|/run/systemd/resolve/stub-resolv.conf}}, {{ic|/run/systemd/resolve/resolv.conf}} or {{ic|/usr/lib/systemd/resolv.conf}}.<br />
<br />
You can enable it explicitly by setting {{ic|1=main.dns=systemd-resolved}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=systemd-resolved<br />
}}<br />
<br />
===== DNS resolver with an openresolv subscriber =====<br />
<br />
If [[openresolv]] has a subscriber for your local [[DNS resolver]], set up the subscriber and [[#Use openresolv|configure NetworkManager to use openresolv]].<br />
<br />
Because NetworkManager advertises a single "interface" to ''resolvconf'', it is not possible to implement conditional forwarding between two NetworkManager connections. See [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 NetworkManager issue 153].<br />
<br />
This can be partially mitigated if you set {{ic|1=private="*"}} in {{ic|/etc/resolvconf.conf}}[https://roy.marples.name/projects/openresolv/configuration.html]. Any queries for domains that are not in search domain list will not get forwarded. They will be handled according to the local resolver's configuration, for example, forwarded to another DNS server or resolved recursively from the DNS root.<br />
<br />
==== Custom DNS servers ====<br />
<br />
===== Setting custom global DNS servers =====<br />
<br />
To set DNS servers for all connections, specify them in {{man|5|NetworkManager.conf}} using the syntax {{ic|1=servers=''serveripaddress1'',''serveripaddress2'',''serveripaddress3''}} in a section named {{ic|[global-dns-domain-*]}}. For example:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns-servers.conf|2=<br />
[global-dns-domain-*]<br />
servers=::1,127.0.0.1<br />
}}<br />
<br />
{{Note|<br />
* If you use [[#DNS caching and conditional forwarding|NetworkManager's dnsmasq or systemd-resolved plugin]] or [[#DNS resolver with an openresolv subscriber|openresolv subscribers]], then do not specify loopback addresses with the {{ic|1=servers=}} option, it can break DNS resolution.<br />
* The specified servers do not get sent to [[systemd-resolved]], the connection's DNS servers are used instead.<br />
}}<br />
<br />
===== Setting custom DNS servers in a connection =====<br />
<br />
====== Setting custom DNS servers in a connection (GUI) ======<br />
<br />
Setup will depend on the type of front-end used; the process usually involves right-clicking on the applet, editing (or creating) a profile, and then choosing DHCP type as ''Automatic (specify addresses)''. The DNS addresses will need to be entered and are usually in this form: {{ic|127.0.0.1, ''DNS-server-one'', ...}}.<br />
<br />
====== Setting custom DNS servers in a connection (nmcli / connection file) ======<br />
<br />
To setup DNS Servers per connection, you can use the {{ic|dns}} field (and the associated {{ic|dns-search}} and {{ic|dns-options}}) in the [[#Edit a connection|connection settings]]. <br />
<br />
If {{ic|method}} is set to {{ic|auto}} (when you use DHCP), you need to set {{ic|ignore-auto-dns}} to {{ic|yes}}.<br />
<br />
==== /etc/resolv.conf ====<br />
<br />
By default {{ic|/etc/resolv.conf}} is managed by ''NetworkManager'' unless it is a symlink.<br />
<br />
It can be configured to write it through [[#Use openresolv|openresolv]] or to [[#Unmanaged /etc/resolv.conf|not touch it at all]].<br />
<br />
Using openresolv allows NetworkManager to coexists with other ''resolvconf'' supporting software or, for example, to run a local DNS caching and split-DNS resolver for which openresolv has a [[openresolv#Subscribers|subscriber]].<br />
<br />
{{Note|Conditional forwarding is [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 not yet fully supported] when using NetworkManager with openresolv.}}<br />
<br />
''NetworkManager'' also offers hooks via so called dispatcher scripts that can be used to alter the {{ic|/etc/resolv.conf}} after network changes. See [[#Network services with NetworkManager dispatcher]] and {{man|8|NetworkManager}} for more information.<br />
<br />
{{Note|<br />
* If NetworkManager is configured to use either [[#dnsmasq|dnsmasq]] or [[#systemd-resolved|systemd-resolved]], then the appropriate loopback addresses will be written to {{ic|/etc/resolv.conf}}.<br />
* The {{ic|resolv.conf}} file NetworkManager writes or would write to {{ic|/etc/resolv.conf}} can be found at {{ic|/run/NetworkManager/resolv.conf}}.<br />
* A {{ic|resolv.conf}} file with the acquired name servers and search domains can be found at {{ic|/run/NetworkManager/no-stub-resolv.conf}}.<br />
}}<br />
<br />
===== Unmanaged /etc/resolv.conf =====<br />
<br />
To stop NetworkManager from touching {{ic|/etc/resolv.conf}}, set {{ic|1=main.dns=none}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/dns.conf|2=<br />
[main]<br />
dns=none<br />
}}<br />
<br />
{{Tip|You might also want to set {{ic|1=main.systemd-resolved=false}}, so that NetworkManager does not send the DNS configuration to [[systemd-resolved]].}}<br />
<br />
{{Note|See [[#DNS caching and conditional forwarding]], to configure NetworkManager using other DNS backends like [[dnsmasq]] and [[systemd-resolved]], instead of using {{ic|1=main.dns=none}}.}}<br />
<br />
After that {{ic|/etc/resolv.conf}} might be a broken symlink that you will need to remove. Then, just create a new {{ic|/etc/resolv.conf}} file.<br />
<br />
===== Use openresolv =====<br />
<br />
{{Note|Do not set {{ic|1=rc-manager=resolvconf}} when {{Pkg|systemd-resolvconf}} is installed. ''systemd-resolved'' provides limited support for the ''resolvconf'' interface and NetworkManager supports communicating with systemd-resolved through D-Bus without using ''resolvconf''.}}<br />
<br />
To configure NetworkManager to use [[openresolv]], set {{ic|1=main.rc-manager=resolvconf}} with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/rc-manager.conf|2=<br />
[main]<br />
rc-manager=resolvconf<br />
}}<br />
<br />
=== Firewall ===<br />
<br />
You can assign a [[firewalld]] zone based on your current connection. For example a restrictive firewall when at work, and a less restrictive one when at home.<br />
<br />
This can also be done with [[#Network services with NetworkManager dispatcher|NetworkManager dispatcher]].<br />
<br />
=== 802.1x / PEAP configuration ===<br />
<br />
A PEAP and 802.1x network can be added by adding a config file to {{ic|/etc/NetworkManager/system-connections/''name''}}.<br />
<br />
Here is an example configuration file for IPv4 with IPv6 disabled:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''name''|2=<br />
[ipv6]<br />
method=ignore<br />
<br />
[ipv4]<br />
method=auto<br />
<br />
[connection]<br />
#id=XXXXXXXXX<br />
#uuid=XXXXXXXXX<br />
type=802-11-wireless<br />
#timestamp=XXXX<br />
<br />
[802-11-wireless-security]<br />
key-mgmt=wpa-eap<br />
<br />
[802-11-wireless]<br />
ssid=ssid<br />
mode=infrastructure<br />
#seen-bssids=XXXXXXXXX<br />
security=802-11-wireless-security<br />
<br />
[802-1x]<br />
eap=peap;<br />
identity=user<br />
password=password<br />
phase2-auth=mschapv2<br />
}}<br />
<br />
The number sign (#) defines comments.<br />
<br />
=== Automatically connect to VNP ===<br />
<br />
NetworkManager can be set to automatically connect to a VPN when connecting to the internet, on a per network basis. While the VPN connection itself can be added in the Gnome gui, but to make it automatically use the VPN {{ic|nmcli}} must be used.<br />
<br />
First, make sure to make the VPN connection available to all users. I the Gnome gui this is a matter of checking a box under the {{details}} tab. Then under the {{Identity}} tab, in the password field, click the icon on the right side in the field, and set it to {{Store the password for all users}}.<br />
<br />
Then use the {{ic|nmcli}} tool via command line:<br />
<br />
# nmcli connection<br />
<br />
To list your connections. Then enter configuration mode for the internet connection you want to automatically connect to a VPN<br />
<br />
# nmcli connection edit <NAME of Internet Connection><br />
<br />
Please note that it is the Internet connection and not the VPN you should edit. Here you do not need to use the UUID of the Internet connection, the NAME is fine. Then make the setting with the command:<br />
<br />
# set connection.secondaries <UUID of VPN><br />
<br />
Here the UUID of the VPN must be used, but {{tab}} works for autocompletion.<br />
<br />
<br />
<br />
== Network services with NetworkManager dispatcher ==<br />
<br />
There are quite a few network services that you will not want running until NetworkManager brings up an interface. NetworkManager has the ability to start services when you connect to a network and stop them when you disconnect (e.g. when using [[NFS]], [[SMB]] and [[NTPd]]).<br />
<br />
To activate the feature you need to [[enable]] and [[start]] the {{ic|NetworkManager-dispatcher.service}}.<br />
<br />
Once the service is active, scripts can be added to the {{ic|/etc/NetworkManager/dispatcher.d}} directory.<br />
<br />
Scripts must be owned by '''root''', otherwise the dispatcher will not execute them. For added security, set group [[ownership]] to root as well:<br />
<br />
# chown root:root /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
Make sure the file has correct permissions:<br />
<br />
# chmod 755 /etc/NetworkManager/dispatcher.d/''10-script.sh''<br />
<br />
The scripts will be run in alphabetical order at connection time, and in reverse alphabetical order at disconnect time. To ensure what order they come up in, it is common to use numerical characters prior to the name of the script (e.g. {{ic|10-portmap}} or {{ic|30-netfs}} (which ensures that the ''portmapper'' is up before NFS mounts are attempted).<br />
<br />
Scripts will receive the following arguments:<br />
<br />
* '''Interface name:''' e.g. {{ic|eth0}}<br />
* '''Interface status:''' ''up'' or ''down''<br />
* '''VPN status:''' ''vpn-up'' or ''vpn-down''<br />
<br />
{{Warning|If you connect to foreign or public networks, be aware of what services you are starting and what servers you expect to be available for them to connect to. You could make a security hole by starting the wrong services while connected to a public network.}}<br />
<br />
=== Avoiding the dispatcher timeout ===<br />
<br />
If the above is working, then this section is not relevant. However, there is a general problem related to running dispatcher scripts which take longer to be executed. Initially an internal timeout of three seconds only was used. If the called script did not complete in time, it was killed. Later the timeout was extended to about 20 seconds (see the [https://bugzilla.redhat.com/show_bug.cgi?id=982734 Bugtracker] for more information). If the timeout still creates the problem, a work around may be to modify the dispatcher service file {{ic|/usr/lib/systemd/system/NetworkManager-dispatcher.service}} to remain active after exit: <br />
<br />
{{hc|/etc/systemd/system/NetworkManager-dispatcher.service.d/remain_after_exit.conf|2=<br />
[Service]<br />
RemainAfterExit=yes<br />
}}<br />
<br />
Now start and enable the modified {{ic|NetworkManager-dispatcher}} service.<br />
<br />
{{Warning|Adding the {{ic|RemainAfterExit}} line to it will prevent the dispatcher from closing. Unfortunately, the dispatcher '''has''' to close before it can run your scripts again. With it the dispatcher will not time out but it also will not close, which means that the scripts will only run once per boot. Therefore, do not add the line unless the timeout is definitely causing a problem.}}<br />
<br />
=== Dispatcher examples ===<br />
<br />
==== Mount remote folder with sshfs ====<br />
<br />
As the script is run in a very restrictive environment, you have to export {{ic|SSH_AUTH_SOCK}} in order to connect to your SSH agent. There are different ways to accomplish this, see [https://bbs.archlinux.org/viewtopic.php?pid=1042030#p1042030 this message] for more information. The example below works with [[GNOME Keyring]], and will ask you for the password if not unlocked already. In case NetworkManager connects automatically on login, it is likely ''gnome-keyring'' has not yet started and the export will fail (hence the sleep). The {{ic|UUID}} to match can be found with the command {{ic|nmcli connection status}} or {{ic|nmcli connection list}}. <br />
<br />
{{bc|<nowiki><br />
#!/bin/sh<br />
USER='username'<br />
REMOTE='user@host:/remote/path'<br />
LOCAL='/local/path'<br />
<br />
interface=$1 status=$2<br />
if [ "$CONNECTION_UUID" = "</nowiki>''uuid''<nowiki>" ]; then<br />
case $status in<br />
up)<br />
SSH_AUTH_SOCK=$(find /tmp -maxdepth 1 -type s -user "$USER" -name 'ssh')<br />
export SSH_AUTH_SOCK<br />
su "$USER" -c "sshfs $REMOTE $LOCAL"<br />
;;<br />
down)<br />
fusermount -u "$LOCAL"<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
==== Mounting of SMB shares ====<br />
<br />
Some [[SMB]] shares are only available on certain networks or locations (e.g. at home). You can use the dispatcher to only mount SMB shares that are present at your current location.<br />
<br />
The following script will check if we connected to a specific network and mount shares accordingly:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-mount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
# Find the connection UUID with "nmcli connection show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
if [ "$2" = "up" ]; then<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
mount /your/mount/point & <br />
# add more shares as needed<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The following script will unmount all SMB shares before a software initiated disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/pre-down.d/30-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|Make sure this script is located in the {{ic|pre-down.d}} sub-directory as shown above, otherwise it will unmount all shares on any connection state change.}}<br />
<br />
The following script will attempt to unmount all SMB shares following an unexpected disconnect from a specific network:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/40-umount-smb.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$CONNECTION_UUID" = "uuid" ]; then<br />
if [ "$2" = "down" ]; then<br />
umount -a -l -t cifs<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|<br />
* Since NetworkManager 0.9.8, the ''pre-down'' and ''down'' events are not executed on shutdown or restart, see [https://bugzilla.gnome.org/show_bug.cgi?id&#61;701242 this bug report] for more info.<br />
* The previous ''umount'' scripts are still prone to leaving applications actually accessing the mount to 'hang'.<br />
}}<br />
<br />
An alternative is to use the script as seen in [[NFS#Using a NetworkManager dispatcher]]:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-smb.sh|<nowiki><br />
#!/bin/bash<br />
<br />
# Find the connection UUID with "nmcli con show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
WANTED_CON_UUID="CHANGE-ME-NOW-9c7eff15-010a-4b1c-a786-9b4efa218ba9"<br />
<br />
if [[ "$CONNECTION_UUID" == "$WANTED_CON_UUID" ]]; then<br />
<br />
# Script parameter $1: NetworkManager connection name, not used<br />
# Script parameter $2: dispatched event<br />
<br />
case "$2" in<br />
"up")<br />
mount -a -t cifs<br />
;;<br />
"pre-down");&<br />
"vpn-pre-down")<br />
umount -l -a -t cifs >/dev/null<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|This script ignores mounts with the {{ic|noauto}} option, remove this mount option or use {{ic|auto}} to allow the dispatcher to manage these mounts.}}<br />
<br />
Create a symlink inside {{ic|/etc/NetworkManager/dispatcher.d/pre-down/}} to catch the {{ic|pre-down}} events:<br />
<br />
# ln -s ../30-smb.sh /etc/NetworkManager/dispatcher.d/pre-down.d/30-smb.sh<br />
<br />
==== Mounting of NFS shares ====<br />
<br />
See [[NFS#Using a NetworkManager dispatcher]].<br />
<br />
==== Use dispatcher to automatically toggle wireless depending on LAN cable being plugged in ====<br />
<br />
The idea is to only turn Wi-Fi on when the LAN cable is unplugged (for example when detaching from a laptop dock), and for Wi-Fi to be automatically disabled, once a LAN cable is plugged in again. <br />
<br />
Create the following dispatcher script[https://superuser.com/questions/233448/disable-wlan-if-wired-cable-network-is-available], replacing {{ic|1=LAN_interface}} with yours.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/wlan_auto_toggle.sh|<nowiki><br />
#!/bin/sh<br />
<br />
if [ "$1" = "LAN_interface" ]; then<br />
case "$2" in<br />
up)<br />
nmcli radio wifi off<br />
;;<br />
down)<br />
nmcli radio wifi on<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
{{Note|You can get a list of interfaces using [[#nmcli examples|nmcli]]. The ethernet (LAN) interfaces start with {{ic|en}}, e.g. {{ic|1=enp0s5}}}}<br />
<br />
==== Use dispatcher to connect to a VPN after a network connection is established ====<br />
<br />
In this example we want to connect automatically to a previously defined VPN connection after connecting to a specific Wi-Fi network. First thing to do is to create the dispatcher script that defines what to do after we are connected to the network.<br />
<br />
{{Note|This script will require {{Pkg|wireless_tools}} in order to use {{ic|iwgetid}}.}}<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME"<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you would like to attempt to automatically connect to VPN for all Wi-Fi networks, you can use the following definition of the ESSID: {{ic|1=ESSID=$(iwgetid -r)}}. Remember to set the script's permissions [[#Network services with NetworkManager dispatcher|accordingly]]. <br />
<br />
Trying to connect with the above script may still fail with {{ic|NetworkManager-dispatcher.service}} complaining about 'no valid VPN secrets', because of [https://developer.gnome.org/NetworkManager/0.9/secrets-flags.html the way VPN secrets are stored]. Fortunately, there are different options to give the above script access to your VPN password.<br />
<br />
1: One of them requires editing the VPN connection configuration file to make NetworkManager store the secrets by itself rather than inside a keyring [https://bugzilla.redhat.com/show_bug.cgi?id=710552 that will be inaccessible for root]: open up {{ic|/etc/NetworkManager/system-connections/''name of your VPN connection''}} and change the {{ic|password-flags}} and {{ic|secret-flags}} from {{ic|1}} to {{ic|0}}.<br />
<br />
If that alone does not work, you may have to create a {{ic|passwd-file}} in a safe location with the same permissions and ownership as the dispatcher script, containing the following:<br />
<br />
{{hc|/path/to/passwd-file|<br />
vpn.secrets.password:YOUR_PASSWORD<br />
}}<br />
<br />
The script must be changed accordingly, so that it gets the password from the file:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli connection up id "$VPN_NAME" passwd-file /path/to/passwd-file<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli connection show --active | grep "$VPN_NAME"; then<br />
nmcli connection down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
2: Alternatively, change the {{ic|password-flags}} and put the password directly in the configuration file adding the section {{ic|vpn-secrets}}:<br />
<br />
[vpn]<br />
....<br />
password-flags=0<br />
<br />
[vpn-secrets]<br />
password=''your_password''<br />
<br />
{{Note|It may now be necessary to re-open the NetworkManager connection editor and save the VPN passwords/secrets again.}}<br />
<br />
==== Use dispatcher to disable IPv6 on VPN provider connections ====<br />
<br />
Many [[:Category:VPN providers|commercial VPN providers]] support only IPv4. That means all IPv6 traffic bypasses the VPN and renders it virtually useless. To avoid this, dispatcher can be used to disable all IPv6 traffic for the time a VPN connection is up.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/10-vpn-ipv6|<nowiki><br />
#!/bin/sh<br />
<br />
case "$2" in<br />
vpn-up)<br />
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
vpn-down)<br />
echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
==== OpenNTPD ====<br />
<br />
See [[OpenNTPD#Using NetworkManager dispatcher]].<br />
<br />
== Testing ==<br />
<br />
NetworkManager applets are designed to load upon login so no further configuration should be necessary for most users. If you have already disabled your previous network settings and disconnected from your network, you can now test if NetworkManager will work. The first step is to [[start]] {{ic|NetworkManager.service}}.<br />
<br />
Some applets will provide you with a {{ic|.desktop}} file so that the NetworkManager applet can be loaded through the application menu. If it does not, you are going to either have to discover the command to use or logout and login again to start the applet. Once the applet is started, it will likely begin polling network connections with for auto-configuration with a DHCP server.<br />
<br />
To start the GNOME applet in non-xdg-compliant window managers like [[awesome]]:<br />
<br />
nm-applet --sm-disable &<br />
<br />
For static IP addresses, you will have to configure NetworkManager to understand them. The process usually involves right-clicking the applet and selecting something like 'Edit Connections'.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Encrypted Wi-Fi passwords ===<br />
<br />
By default, NetworkManager stores passwords in clear text in the connection files at {{ic|/etc/NetworkManager/system-connections/}}. To print the stored passwords, use the following command:<br />
<br />
# grep -r '^psk=' /etc/NetworkManager/system-connections/<br />
<br />
The passwords are accessible to the root user in the filesystem and to users with access to settings via the GUI (e.g. {{ic|nm-applet}}). <br />
<br />
It is preferable to save the passwords in encrypted form in a keyring instead of clear text. The downside of using a keyring is that the connections have to be set up for each user.<br />
<br />
==== Using GNOME Keyring ====<br />
<br />
The keyring daemon has to be started and the keyring needs to be unlocked for the following to work.<br />
<br />
Furthermore, NetworkManager needs to be configured not to store the password for all users. Using GNOME {{ic|nm-applet}}, run {{ic|nm-connection-editor}} from a terminal, select a network connection, click {{ic|Edit}}, select the {{ic|Wifi-Security}} tab and click on the right icon of password and check {{ic|Store the password only for this user}}.<br />
<br />
==== Using KDE Wallet ====<br />
<br />
Using KDE's {{Pkg|plasma-nm}}, click the applet, click on the top right {{ic|Settings}} icon, click on a network connection, in the {{ic|General settings}} tab, untick {{ic|all users may connect to this network}}. If the option is ticked, the passwords will still be stored in clear text, even if a keyring daemon is running.<br />
<br />
If the option was selected previously and you un-tick it, you may have to use the {{ic|reset}} option first to make the password disappear from the file. Alternatively, delete the connection first and set it up again.<br />
<br />
=== Sharing internet connection over Wi-Fi ===<br />
<br />
You can share your internet connection (e.g. 3G or wired) with a few clicks. Please note that a [[firewall]] may interfere with internet sharing.<br />
<br />
You will need a Wi-Fi card which supports AP mode, see [[Software access point#Wi-Fi device must support AP mode]] for details.<br />
<br />
[[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
<br />
Create the shared connection:<br />
<br />
* Click on applet and choose ''Create new wireless network''.<br />
* Follow wizard (choose WPA2 or higher, be sure to use at least 8 character long password, lower lengths will fail).<br />
** Choose either [[Fedora:Features/RealHotspot|Hotspot]] or Ad-hoc as Wi-Fi mode.<br />
<br />
The connection will be saved and remain stored for the next time you need it.<br />
<br />
{{Note|Android does not support connecting to Ad-hoc networks. To share a connection with Android use infrastructure mode (i.e. set Wi-Fi mode to "Hotspot").}}<br />
<br />
=== Sharing internet connection over Ethernet ===<br />
<br />
Scenario: your device has internet connection over wi-fi and you want to share the internet connection to other devices over ethernet.<br />
<br />
Requirements:<br />
<br />
* [[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
* Your internet connected device and the other devices are connected over a suitable ethernet cable (this usually means a cross over cable or a switch in between).<br />
* Internet sharing is not blocked by a [[firewall]].<br />
<br />
Steps:<br />
<br />
{{Style|{{Pkg|nm-connection-editor}} is not a dependency of {{Pkg|networkmanager}} and needs to be installed separately.}}<br />
<br />
* Run {{ic|nm-connection-editor}} from terminal.<br />
* Add a new ethernet connection.<br />
* Give it some sensible name. For example "Shared Internet"<br />
* Go to "IPv4 Settings".<br />
* For "Method:" select "Shared to other computers".<br />
* Save<br />
<br />
Now you should have a new option "Shared Internet" under the Wired connections in NetworkManager.<br />
<br />
=== Checking if networking is up inside a cron job or script ===<br />
<br />
{{Out of date|''nm-tool'' was remove from NetworkManager for long time now[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/bb8c75bd536d4f8fb80a4366025a279078f0ec81]. ''nmcli'' should be used instead.}}<br />
<br />
Some ''cron'' jobs require networking to be up to succeed. You may wish to avoid running these jobs when the network is down. To accomplish this, add an '''if''' test for networking that queries NetworkManager's ''nm-tool'' and checks the state of networking. The test shown here succeeds if any interface is up, and fails if they are all down. This is convenient for laptops that might be hardwired, might be on wireless, or might be off the network.<br />
<br />
{{bc|<nowiki><br />
if [ $(nm-tool|grep State|cut -f2 -d' ') == "connected" ]; then<br />
#Whatever you want to do if the network is online<br />
else<br />
#Whatever you want to do if the network is offline - note, this and the else above are optional<br />
fi<br />
</nowiki>}}<br />
<br />
This useful for a {{ic|cron.hourly}} script that runs ''fpupdate'' for the F-Prot virus scanner signature update, as an example. Another way it might be useful, with a little modification, is to differentiate between networks using various parts of the output from ''nm-tool''; for example, since the active wireless network is denoted with an asterisk, you could grep for the network name and then grep for a literal asterisk.<br />
<br />
=== Connect to network with secret on boot ===<br />
<br />
By default, NetworkManager will not connect to networks requiring a secret automatically on boot. This is because it locks such connections to the user who makes it by default, only connecting after they have logged in. To change this, do the following:<br />
<br />
# Right click on the {{ic|nm-applet}} icon in your panel and select Edit Connections and open the Wireless tab<br />
# Select the connection you want to work with and click the Edit button<br />
# Check the boxes “Connect Automatically” and “Available to all users”<br />
# Additionally, ensure that under "Wi-Fi Security", "Store password for all users (not encrypted)" is selected<br />
<br />
Log out and log back in to complete.<br />
<br />
=== OpenConnect with password in KWallet ===<br />
<br />
While you may type both values at connection time, {{Pkg|plasma-nm}} 0.9.3.2-1 and above are capable of retrieving OpenConnect username and password directly from [[KWallet]].<br />
<br />
Open "KDE Wallet Manager" and look up your OpenConnect VPN connection under "Network Management|Maps". Click "Show values" and <br />
enter your credentials in key "VpnSecrets" in this form (replace ''username'' and ''password'' accordingly):<br />
<br />
form:main:username%SEP%''username''%SEP%form:main:password%SEP%''password''<br />
<br />
Next time you connect, username and password should appear in the "VPN secrets" dialog box.<br />
<br />
=== Ignore specific devices ===<br />
<br />
Sometimes it may be desired that NetworkManager ignores specific devices and does not try to configure addresses and routes for them. You can quickly and easily ignore devices by MAC or interface-name by using the following in {{ic|/etc/NetworkManager/conf.d/unmanaged.conf}}:<br />
<br />
[keyfile]<br />
unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth0<br />
<br />
After editing the file, run {{ic|nmcli general reload}} as root. Afterwards you should be able to configure interfaces without NetworkManager altering what you have set.<br />
<br />
=== Configuring MAC address randomization ===<br />
<br />
{{Note|1=Disabling MAC address randomization may be needed to get (stable) link connection [https://bbs.archlinux.org/viewtopic.php?id=220101] and/or networks that restrict devices based on their MAC Address or have a limit network capacity.}}<br />
<br />
MAC randomization can be used for increased privacy by not disclosing your real MAC address to the network.<br />
<br />
NetworkManager supports two types MAC Address Randomization: randomization during scanning, and for network connections. Both modes can be configured by modifying {{ic|/etc/NetworkManager/NetworkManager.conf}} or by creating a separate configuration file in {{ic|/etc/NetworkManager/conf.d/}} which is recommended since the aforementioned config file may be overwritten by NetworkManager.<br />
<br />
Randomization during Wi-Fi scanning is enabled by default, but it may be disabled by adding the following lines to {{ic|/etc/NetworkManager/NetworkManager.conf}} or a dedicated configuration file under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device]<br />
wifi.scan-rand-mac-address=no<br />
}}<br />
<br />
MAC randomization for network connections can be set to different modes for both wireless and ethernet interfaces. See the [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details on the different modes. <br />
<br />
In terms of MAC randomization the most important modes are {{ic|stable}} and {{ic|random}}. {{ic|stable}} generates a random MAC address when you connect to a new network and associates the two permanently. This means that you will use the same MAC address every time you connect to that network. In contrast, {{ic|random}} will generate a new MAC address every time you connect to a network, new or previously known. You can configure the MAC randomization by adding the desired configuration under {{ic|/etc/NetworkManager/conf.d}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=<br />
[device-mac-randomization]<br />
# "yes" is already the default for scanning<br />
wifi.scan-rand-mac-address=yes<br />
<br />
[connection-mac-randomization]<br />
# Randomize MAC for every ethernet connection<br />
ethernet.cloned-mac-address=random<br />
# Generate a random MAC for each WiFi and associate the two permanently.<br />
wifi.cloned-mac-address=stable<br />
}}<br />
<br />
See the following [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME blog post] for more details.<br />
<br />
=== Enable IPv6 Privacy Extensions ===<br />
<br />
See [[IPv6#NetworkManager]].<br />
<br />
=== Working with wired connections ===<br />
<br />
By default, NetworkManager generates a connection profile for each wired ethernet connection it finds. At the point when generating the connection, it does not know whether there will be more ethernet adapters available. Hence, it calls the first wired connection "Wired connection 1". You can avoid generating this connection, by configuring {{ic|no-auto-default}} (see {{man|5|NetworkManager.conf}}), or by simply deleting it. Then NetworkManager will remember not to generate a connection for this interface again.<br />
<br />
You can also edit the connection (and persist it to disk) or delete it. NetworkManager will not re-generate a new connection. Then you can change the name to whatever you want. You can use something like nm-connection-editor for this task.<br />
<br />
=== Using iwd as the Wi-Fi backend ===<br />
<br />
Install {{AUR|networkmanager-iwd}} or enable the experimental [[iwd]] backend creating the following configuration file:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/wifi_backend.conf|2=<br />
[device]<br />
wifi.backend=iwd<br />
}}<br />
<br />
=== Running in a network namespace ===<br />
<br />
If you would like to run NetworkManager inside a network namespace (e.g., to manage a specific device which should be use by selected applications), bring the device down before moving it to the namespace:<br />
<br />
$ ip link set dev ''MY_DEVICE'' down<br />
$ ip link set dev ''MY_DEVICE'' netns ''MY_NAMESPACE''<br />
$ ip netns exec ''MY_NAMESPACE'' NetworkManager<br />
...<br />
$ ip netns exec ''MY_NAMESPACE'' killall NetworkManager<br />
<br />
otherwise NetworkManager will later fail to establish the connection with a {{ic|device is strictly unmanaged}} error.<br />
<br />
== Troubleshooting ==<br />
<br />
=== No prompt for password of secured Wi-Fi networks ===<br />
<br />
When trying to connect to a secured Wi-Fi network, no prompt for a password is shown and no connection is established. This happens when no keyring package is installed. An easy solution is to install {{Pkg|gnome-keyring}}. If you want the passwords to be stored in encrypted form, follow [[GNOME Keyring]] to set up the ''gnome-keyring-daemon''.<br />
<br />
=== Network management disabled ===<br />
<br />
When NetworkManager shuts down but the pid (state) file is not removed, you will see a {{ic|Network management disabled}} message. If this happens, remove the file manually:<br />
<br />
# rm /var/lib/NetworkManager/NetworkManager.state<br />
<br />
=== Problems with internal DHCP client ===<br />
<br />
If you have problems with getting an IP address using the internal DHCP client, consider using another DHCP client, see [[#DHCP client]] for instructions. This workaround might solve problems in big wireless networks like eduroam.<br />
<br />
=== DHCP problems with dhclient ===<br />
<br />
If you have problems with getting an IP address via DHCP, try to add the following to your {{ic|/etc/dhclient.conf}}:<br />
<br />
interface "eth0" {<br />
send dhcp-client-identifier 01:''aa:bb:cc:dd:ee:ff'';<br />
}<br />
<br />
Where {{ic|''aa:bb:cc:dd:ee:ff''}} is the MAC address of this NIC. The MAC address can be found using the {{ic|ip link show ''interface''}} command from the {{Pkg|iproute2}} package.<br />
<br />
=== 3G modem not detected ===<br />
<br />
See [[USB 3G Modem#NetworkManager]].<br />
<br />
=== Switching off WLAN on laptops ===<br />
<br />
Sometimes NetworkManager will not work when you disable your Wi-Fi adapter with a switch on your laptop and try to enable it again afterwards. This is often a problem with ''rfkill''. To check if the driver notifies ''rfkill'' about the wireless adapter's status, use:<br />
<br />
$ watch -n1 rfkill list all<br />
<br />
If one identifier stays blocked after you switch on the adapter you could try to manually unblock it with (where X is the number of the identifier provided by the above output):<br />
<br />
# rfkill event unblock X<br />
<br />
=== Static IP address settings revert to DHCP ===<br />
<br />
Due to an unresolved bug, when changing default connections to a static IP address, {{ic|nm-applet}} may not properly store the configuration change, and will revert to automatic DHCP.<br />
<br />
To work around this issue you have to edit the default connection (e.g. "Auto eth0") in {{ic|nm-applet}}, change the connection name (e.g. "my eth0"), uncheck the "Available to all users" checkbox, change your static IP address settings as desired, and click '''Apply'''. This will save a new connection with the given name.<br />
<br />
Next, you will want to make the default connection not connect automatically. To do so, run {{ic|nm-connection-editor}} ('''not''' as root). In the connection editor, edit the default connection (e.g. "Auto eth0") and uncheck "Connect automatically". Click '''Apply''' and close the connection editor.<br />
<br />
=== Cannot edit connections as normal user ===<br />
<br />
See [[#Set up PolicyKit permissions]].<br />
<br />
=== Forget hidden wireless network ===<br />
<br />
Since hidden networks are not displayed in the selection list of the Wireless view, they cannot be forgotten (removed) with the GUI. You can delete one with the following command:<br />
<br />
# rm /etc/NetworkManager/system-connections/''SSID''<br />
<br />
This works for any other connection.<br />
<br />
=== VPN not working in GNOME ===<br />
<br />
When setting up OpenConnect or vpnc connections in NetworkManager while using GNOME, you will sometimes never see the dialog box pop up and the following error appears in {{ic|/var/log/errors.log}}:<br />
<br />
localhost NetworkManager[399]: <error> [1361719690.10506] [nm-vpn-connection.c:1405] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.<br />
<br />
This is caused by the GNOME NM Applet expecting dialog scripts to be at {{ic|/usr/lib/gnome-shell}}, when NetworkManager's packages put them in {{ic|/usr/lib/networkmanager}}.<br />
As a "temporary" fix (this bug has been around for a while now), make the following symlink(s):<br />
<br />
* For OpenConnect: {{ic|ln -s /usr/lib/networkmanager/nm-openconnect-auth-dialog /usr/lib/gnome-shell/}}<br />
* For VPNC (i.e. Cisco VPN): {{ic|ln -s /usr/lib/networkmanager/nm-vpnc-auth-dialog /usr/lib/gnome-shell/}}<br />
<br />
This may need to be done for any other NM VPN plugins as well, but these are the two most common.<br />
<br />
=== Unable to connect to visible European wireless networks ===<br />
<br />
WLAN chips are shipped with a default [[Wireless network configuration#Respecting the regulatory domain|regulatory domain]]. If your access point does not operate within these limitations, you will not be able to connect to the network. Fixing this is easy:<br />
<br />
# [[Install]] {{Pkg|crda}}<br />
# Uncomment the correct Country Code in {{ic|/etc/conf.d/wireless-regdom}}<br />
# Reboot the system, because the setting is only read on boot<br />
<br />
=== Automatic connect to VPN on boot is not working ===<br />
<br />
The problem occurs when the system (i.e. NetworkManager running as the root user) tries to establish a VPN connection, but the password is not accessible because it is stored in the GNOME keyring of a particular user. <br />
<br />
A solution is to keep the password to your VPN in plaintext, as described in step (2.) of [[#Use dispatcher to connect to a VPN after a network connection is established]]. <br />
<br />
You do not need to use the dispatcher described in step (1.) to auto-connect anymore, if you use the new "auto-connect VPN" option from the {{ic|nm-applet}} GUI.<br />
<br />
=== Systemd Bottleneck ===<br />
<br />
Over time the log files ({{ic|/var/log/journal}}) can become very large. This can have a big impact on boot performance when using NetworkManager, see: [[Systemd#Boot time increasing over time]].<br />
<br />
=== Regular network disconnects, latency and lost packets (WiFi) ===<br />
<br />
NetworkManager does a scan every 2 minutes.<br />
<br />
Some WiFi drivers have issues when scanning for base stations whilst connected/associated. Symptoms include VPN disconnects/reconnects and lost packets, web pages failing to load and then refresh fine.<br />
<br />
Running {{ic|journalctl -f}} will indicate that this is taking place, messages like the following will be contained in the logs at regular intervals.<br />
<br />
NetworkManager[410]: <info> (wlp3s0): roamed from BSSID 00:14:48:11:20:CF (my-wifi-name) to (none) ((none))<br />
<br />
There is a patched version of NetworkManager which should prevent this type of scanning: {{AUR|networkmanager-noscan}}.<br />
<br />
Alternatively, if roaming is not important, the periodic scanning behavior can be disabled by locking the BSSID of the access point in the WiFi connection profile.<br />
<br />
=== Unable to turn on wi-fi with Lenovo laptop (IdeaPad, Legion, etc.) ===<br />
<br />
There is an issue with the {{ic|ideapad_laptop}} module on some Lenovo models due to the wi-fi driver incorrectly reporting a soft block. The card can still be manipulated with {{ic|netctl}}, but managers like NetworkManager break. You can verify that this is the problem by checking the output of {{ic|rfkill list}} after toggling your hardware switch and seeing that the soft block persists.<br />
<br />
{{Accuracy|Try to use {{ic|rfkill.default_state}} and {{ic|rfkill.master_switch_mode}} (see [https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt kernel-parameters.txt]) to fix the rfkill problem.}}<br />
<br />
[[modprobe|Unloading]] the {{ic|ideapad_laptop}} module should fix this. ('''warning''': this may disable the laptop keyboard and touchpad also!).<br />
<br />
=== Turn off hostname sending ===<br />
<br />
NetworkManager by default sends the hostname to the DHCP server. Hostname sending can only be disabled per connection not globally ([https://bugzilla.gnome.org/show_bug.cgi?id=768076 GNOME Bug 768076]).<br />
<br />
To disable sending your hostname to the DHCP server for a specific connection, add the following to your network connection file:<br />
<br />
{{hc|/etc/NetworkManager/system-connections/''your_connection_file''|2=<br />
...<br />
[ipv4]<br />
dhcp-send-hostname=false<br />
...<br />
[ipv6]<br />
dhcp-send-hostname=false<br />
...<br />
}}<br />
<br />
=== nm-applet disappears in i3wm ===<br />
<br />
If you use the {{ic|xfce4-notifyd.service}} for notifications you must [[edit]] the unit and add the following:<br />
<br />
{{hc|/etc/systemd/user/xfce4-notifyd.service.d/display_env.conf|2=<br />
[Service]<br />
Environment="DISPLAY=:0.0"<br />
}}<br />
<br />
After reloading the daemons [[restart]] {{ic|xfce4-notifyd.service}}. Exit i3 and start it back up again and the applet should show on the tray.<br />
<br />
=== nm-applet tray icons display wrongly ===<br />
<br />
Currently the tray icons of nm-applet are drawn on top of one another, i.e. the icon displaying wireless strength might show on top of the icon indicating no wired connection.<br />
This is apparently a GTK3 bug/problem: https://gitlab.gnome.org/GNOME/gtk/issues/1280 .<br />
<br />
A patched version of GTK3 exists in AUR, which apparently fixes the tray icon bug: {{AUR|gtk3-mushrooms}} .<br />
<br />
=== Unit dbus-org.freedesktop.resolve1.service not found ===<br />
<br />
If {{ic|systemd-resolved.service}} is not started, NetworkManager will try to start it using D-Bus and fail:<br />
<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
dbus-daemon[991]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.<br />
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")<br />
<br />
This is because NetworkManager will try to send DNS information to [[systemd-resolved]] regardless of the {{ic|1=main.dns=}} setting in {{man|5|NetworkManager.conf}}.[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383]<br />
<br />
This can be disabled with a configuration file in {{ic|/etc/NetworkManager/conf.d/}}:<br />
<br />
{{hc|/etc/NetworkManager/conf.d/no-systemd-resolved.conf|2=<br />
[main]<br />
systemd-resolved=false<br />
}}<br />
<br />
See {{Bug|62138}}.<br />
<br />
=== Secrets were required, but not provided ===<br />
<br />
If you attempt to connect to a network using {{ic|nmcli device wifi connect ''SSID'' password ''password''}} and received the following error:<br />
<br />
Error: Connection activation failed: (7) Secrets were required, but not provided<br />
<br />
The error can be resolved by deleting the connection profile and creating a new one:<br />
<br />
$ nmcli connection delete ''SSID''<br />
$ nmcli device wifi connect ''SSID'' password ''password''<br />
<br />
=== WPA Enterprise connection with NetworkManager ===<br />
<br />
If you try to connect to an WPA Enterprise network like 'eduroam' with NetworkManager with the [[iwd]] backend then you will get the following error from NetworkManager:<br />
<br />
Connection 'eduroam' is not avialable on device wlan0 because profile is not compatible with device (802.1x connections must have IWD provisioning files)<br />
<br />
This is because NetworkManager can not configure a WPA Enterprise network. Therefore you have to configure it using an iwd config file {{ic|/var/lib/iwd/''essid''.8021x}} like described in [[iwd#WPA Enterprise]].<br />
<br />
== See also ==<br />
<br />
* [https://blogs.gnome.org/dcbw/2015/02/16/networkmanager-for-administrators-part-1/ NetworkManager for Administrators Part 1]<br />
* [[Wikipedia:NetworkManager]]</div>Tobbebobbehttps://wiki.archlinux.org/index.php?title=Dnsmasq&diff=622111Dnsmasq2020-06-26T08:13:50Z<p>Tobbebobbe: Specified which config file should be changed for "no-resolv" and fallback DNS in section "DNS Server"-->"Manual forwarding". This was not done and caused unclarity</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Domain Name System]]<br />
[[Category:DHCP]]<br />
[[es:Dnsmasq]]<br />
[[it:Dnsmasq]]<br />
[[ja:Dnsmasq]]<br />
[[pt:Dnsmasq]]<br />
[[ru:Dnsmasq]]<br />
[[zh-hans:Dnsmasq]]<br />
{{Related articles start}}<br />
{{Related|Domain name resolution}}<br />
{{Related articles end}}<br />
[http://www.thekelleys.org.uk/dnsmasq/doc.html dnsmasq] provides a [[Wikipedia:Name server|DNS server]], a [[Wikipedia:Dynamic Host Configuration Protocol|DHCP server]] with support for [[Wikipedia:DHCPv6|DHCPv6]] and [[Wikipedia:Preboot Execution Environment|PXE]], and a [[Wikipedia:Trivial File Transfer Protocol|TFTP server]]. It is designed to be lightweight and have a small footprint, suitable for resource constrained routers and firewalls. dnsmasq can also be configured to cache DNS queries for improved DNS lookup speeds to previously visited sites.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|dnsmasq}} package.<br />
<br />
== Start the daemon ==<br />
<br />
[[Start/enable]] {{ic|dnsmasq.service}}.<br />
<br />
To see if dnsmasq started properly, check the system's journal:<br />
<br />
$ journalctl -u dnsmasq.service<br />
<br />
The network will also need to be restarted so the DHCP client can create a new {{ic|/etc/resolv.conf}}.<br />
<br />
== Configuration ==<br />
<br />
To configure dnsmasq, edit {{ic|/etc/dnsmasq.conf}}. The file contains comments explaining the options. For all available options see {{man|8|dnsmasq}}.<br />
<br />
{{Warning|dnsmasq's default configuration enables its DNS server. If you do not require it, you need to explicitly disable it by setting the DNS port to {{ic|0}}:<br />
<br />
{{bc|1=port=0}}<br />
<br />
}}<br />
<br />
{{Tip|To check configuration file(s) syntax, execute:<br />
<br />
$ dnsmasq --test<br />
<br />
}}<br />
<br />
=== DNS server ===<br />
<br />
To set up dnsmasq as a DNS caching daemon on a single computer specify a {{ic|listen-address}} directive, adding in the localhost IP address:<br />
<br />
listen-address=::1,127.0.0.1<br />
<br />
To use this computer to listen on its LAN IP address for other computers on the network. It is recommended that you use a static LAN IP in this case. E.g.:<br />
<br />
listen-address=::1,127.0.0.1,192.168.1.1<br />
<br />
Set the number of cached domain names with {{ic|1=cache-size=''size''}} (the default is {{ic|150}}):<br />
<br />
cache-size=1000<br />
<br />
To validate [[DNSSEC]] load the DNSSEC trust anchors provided by the {{Pkg|dnsmasq}} package and set the option {{ic|dnssec}}:<br />
<br />
conf-file=/usr/share/dnsmasq/trust-anchors.conf<br />
dnssec<br />
<br />
See {{man|8|dnsmasq}} for more options you might want to use.<br />
<br />
==== DNS addresses file and forwarding ====<br />
<br />
After configuring dnsmasq, you need to add the localhost addresses as the only nameservers in {{ic|/etc/resolv.conf}}. This causes all queries to be sent to dnsmasq.<br />
<br />
Since dnsmasq is a stub resolver not a recursive resolver you must set up forwarding to an external DNS server. This can be done automatically by using [[openresolv]] or by manually specifying the DNS server address in dnsmasq's configuration.<br />
<br />
===== openresolv =====<br />
<br />
If your network manager supports ''resolvconf'', instead of directly altering {{ic|/etc/resolv.conf}}, you can use [[openresolv]] to generate configuration files for dnsmasq. [https://roy.marples.name/projects/openresolv/configuration.html]<br />
<br />
Edit {{ic|/etc/resolvconf.conf}} and add the loopback addresses as name servers, and configure openresolv to write out dnsmasq configuration:<br />
<br />
{{hc|/etc/resolvconf.conf|2=<br />
# Use the local name server<br />
name_servers="::1 127.0.0.1"<br />
<br />
# Write out dnsmasq extended configuration and resolv files<br />
dnsmasq_conf=/etc/dnsmasq-conf.conf<br />
dnsmasq_resolv=/etc/dnsmasq-resolv.conf<br />
}}<br />
<br />
Run {{ic|resolvconf -u}} so that the configuration files get created. If the files do not exist {{ic|dnsmasq.service}} will fail to start.<br />
<br />
Edit dnsmasq's configuration file to use openresolv's generated configuration:<br />
<br />
# Read configuration generated by openresolv<br />
conf-file=/etc/dnsmasq-conf.conf<br />
resolv-file=/etc/dnsmasq-resolv.conf<br />
<br />
===== Manual forwarding =====<br />
<br />
First you must set localhost addresses as the only nameservers in {{ic|/etc/resolv.conf}}:<br />
<br />
{{hc|/etc/resolv.conf|<br />
nameserver ::1<br />
nameserver 127.0.0.1<br />
}}<br />
<br />
Make sure to protect {{ic|/etc/resolv.conf}} from modification as described in [[Domain name resolution#Overwriting of /etc/resolv.conf]].<br />
<br />
The upstream DNS server addresses must then be specified in dnsmasq's configuration file as {{ic|1=server=''server_address''}}. Also add {{ic|no-resolv}} so dnsmasq does not needlessly read {{ic|/etc/resolv.conf}} which only contains the localhost addresses of itself. <br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
[...]<br />
no-resolv<br />
<br />
# Google's nameservers, for example<br />
server=8.8.8.8<br />
server=8.8.4.4<br />
}}<br />
<br />
Now DNS queries will be resolved with dnsmasq, only checking external servers if it cannot answer the query from its cache.<br />
<br />
==== Adding a custom domain ====<br />
<br />
It is possible to add a custom domain to hosts in your (local) network:<br />
<br />
local=/lan/<br />
domain=lan<br />
<br />
In this example it is possible to ping a host/device (e.g. defined in your {{ic|/etc/hosts}} file) as {{ic|''hostname''.lan}}.<br />
<br />
Uncomment {{ic|expand-hosts}} to add the custom domain to hosts entries:<br />
<br />
expand-hosts<br />
<br />
Without this setting, you will have to add the domain to entries of {{ic|/etc/hosts}}.<br />
<br />
==== Test ====<br />
<br />
To do a lookup speed test choose a website that has not been visited since dnsmasq has been started (''drill'' is part of the {{Pkg|ldns}} package):<br />
<br />
$ drill archlinux.org | grep "Query time"<br />
<br />
Running the command again will use the cached DNS IP and result in a faster lookup time if dnsmasq is setup correctly:<br />
<br />
{{hc|$ drill archlinux.org {{!}} grep "Query time"|<br />
;; Query time: 18 msec<br />
}}<br />
<br />
{{hc|$ drill archlinux.org {{!}} grep "Query time"|<br />
;; Query time: 2 msec<br />
}}<br />
<br />
To test if DNSSEC validation is working see [[DNSSEC#Testing]].<br />
<br />
=== DHCP server ===<br />
<br />
{{Expansion|Add instructions for IPv6}}<br />
<br />
By default dnsmasq has the DHCP functionality turned off, if you want to use it you must turn it on. Here are the important settings:<br />
<br />
{{bc|<nowiki><br />
# Only listen to routers' LAN NIC. Doing so opens up tcp/udp port 53 to<br />
# localhost and udp port 67 to world:<br />
interface=<LAN-NIC><br />
<br />
# dnsmasq will open tcp/udp port 53 and udp port 67 to world to help with<br />
# dynamic interfaces (assigning dynamic ips). Dnsmasq will discard world<br />
# requests to them, but the paranoid might like to close them and let the <br />
# kernel handle them:<br />
bind-interfaces<br />
<br />
# Optionally set a domain name<br />
domain=example.com<br />
<br />
# Set default gateway<br />
dhcp-option=3,0.0.0.0<br />
<br />
# Set DNS servers to announce<br />
dhcp-option=6,0.0.0.0<br />
<br />
# If your dnsmasq server is also doing the routing for your network,<br />
# you can use option 121 to push a static route out.<br />
# x.x.x.x is the destination LAN, yy is the CIDR notation (usually /24), <br />
# and z.z.z.z is the host which will do the routing.<br />
dhcp-option=121,x.x.x.x/yy,z.z.z.z<br />
<br />
# Dynamic range of IPs to make available to LAN PC and the lease time. <br />
# Ideally set the lease time to 5m only at first to test everything works okay before you set long-lasting records.<br />
dhcp-range=192.168.111.50,192.168.111.100,12h<br />
<br />
# Provide IPv6 DHCP leases through Router Advertisements (RAs) for aaaa:bbbb:cccc:dddd::/64 subnet<br />
dhcp-range=aaaa:bbbb:cccc:dddd::,ra-only,infinite<br />
<br />
# If you’d like to have dnsmasq assign static IPs to some clients, bind the LAN computers<br />
# NIC MAC addresses:<br />
dhcp-host=aa:bb:cc:dd:ee:ff,192.168.111.50<br />
dhcp-host=aa:bb:cc:ff:dd:ee,192.168.111.51<br />
</nowiki>}}<br />
<br />
See {{man|8|dnsmasq}} for more options.<br />
<br />
==== Test ====<br />
<br />
From a computer that is connected to the one with dnsmasq on it, configure it to use DHCP for automatic IP address assignment, then attempt to log into the network normally.<br />
<br />
If you inspect the {{ic|/var/lib/misc/dnsmasq.leases}} file on the server, you should be able to see the lease.<br />
<br />
=== TFTP server ===<br />
<br />
dnsmasq has built-in [[TFTP]] server.<br />
<br />
To use it, create a directory for TFTP root (e.g. {{ic|/srv/tftp}}) to put transferable files in.<br />
<br />
For increased security it is advised to use dnsmasq's TFTP secure mode. In secure mode only files owned by the {{ic|dnsmasq}} user will be served over TFTP. You will need to [[chown]] TFTP root and all files in it to {{ic|dnsmasq}} user to use this feature.<br />
<br />
Enable TFTP:<br />
<br />
enable-tftp<br />
tftp-root=/srv/tftp<br />
tftp-secure<br />
<br />
See {{man|8|dnsmasq}} for more options.<br />
<br />
=== PXE server ===<br />
<br />
PXE requires DHCP and TFTP servers, both functions can be provided by dnsmasq.<br />
<br />
{{Tip|dnsmasq can run in "proxy-DHCP" mode and add PXE booting options to a network with an already running DHCP server:<br />
<br />
{{bc|1=<br />
interface=''enp0s0''<br />
bind-dynamic<br />
dhcp-range=''192.168.0.1'',proxy<br />
}}<br />
<br />
}}<br />
<br />
# set up [[#TFTP server]] and [[#DHCP server]]<br />
# copy and configure a PXE compatible bootloader (e.g. [[PXELINUX]]) on TFTP root<br />
# enable PXE in {{ic|/etc/dnsmasq.conf}}:<br />
<br />
{{Note|<br />
*file paths are relative to TFTP root<br />
*if the file has a {{ic|.0}} suffix, you must exclude the suffix in {{ic|pxe-service}} options<br />
}}<br />
<br />
To simply send one file:<br />
<br />
dhcp-boot=lpxelinux.0<br />
<br />
To send a file depending on client architecture:<br />
<br />
pxe-service=x86PC, "PXELINUX (BIOS)", "bios/lpxelinux"<br />
pxe-service=X86-64_EFI, "PXELINUX (EFI)", "efi64/syslinux.efi"<br />
<br />
{{Note|In case {{ic|pxe-service}} does not work (especially for UEFI-based clients), combination of {{ic|dhcp-match}} and {{ic|dhcp-boot}} can be used. See [https://tools.ietf.org/html/rfc4578#section-2.1 RFC4578] for more {{ic|client-arch}} numbers for use with dhcp boot protocol.}}<br />
<br />
dhcp-match=set:efi-x86_64,option:client-arch,7<br />
dhcp-match=set:efi-x86_64,option:client-arch,9<br />
dhcp-match=set:efi-x86,option:client-arch,6<br />
dhcp-match=set:bios,option:client-arch,0<br />
dhcp-boot=tag:efi-x86_64,"efi64/syslinux.efi"<br />
dhcp-boot=tag:efi-x86,"efi32/syslinux.efi"<br />
dhcp-boot=tag:bios,"bios/lpxelinux.0"<br />
<br />
See {{man|8|dnsmasq}} for more options.<br />
<br />
The rest is up to the [[bootloader]].<br />
<br />
== Tips and tricks ==<br />
<br />
=== Prevent OpenDNS redirecting Google queries ===<br />
<br />
To prevent OpenDNS from redirecting all Google queries to their own search server, add to {{ic|/etc/dnsmasq.conf}}:<br />
{{bc|1=server=/www.google.com/<ISP DNS IP>}}<br />
<br />
=== Override addresses ===<br />
<br />
In some cases, such as when operating a captive portal, it can be useful to resolve specific domains names to a hard-coded set of addresses. This is done with the {{ic|address}} config:<br />
<br />
address=/example.com/1.2.3.4<br />
<br />
Furthermore, it's possible to return a specific address for all domain names that are not answered from {{ic|/etc/hosts}} or DHCP by using a special wildcard:<br />
<br />
address=/#/1.2.3.4<br />
<br />
=== More than one instance ===<br />
<br />
If we want two or more dnsmasq servers works per interface(s).<br />
<br />
==== Static ====<br />
<br />
To do this staticly, server per interface, use {{ic|interface}} and {{ic|bind-interface}} options. This enforce start second dnsmasq.<br />
<br />
==== Dynamic ====<br />
<br />
In this case we can exclude per interface and bind any others:<br />
<br />
except-interface=lo<br />
bind-dynamic<br />
<br />
{{Note|This is the default in [[libvirt]].}}<br />
<br />
=== Domain blacklisting ===<br />
<br />
To blacklist domains, i.e. answer queries for them with NXDOMAIN, use the {{ic|address}} option without specifying the IP address:<br />
<br />
address=/blacklisted.example/<br />
address=/another.blacklisted.example/<br />
<br />
For ease of use place the blacklist in a separate file, e.g. {{ic|/etc/dnsmasq.d/blacklist.conf}} and load it from {{ic|/etc/dnsmasq.conf}} with {{ic|1=conf-file=/etc/dnsmasq.d/blacklist.conf}} or {{ic|1=conf-dir=/etc/dnsmasq.d/,*.conf}}.<br />
<br />
{{Tip|A list of potential sources for the blacklist can be found in [https://github.com/openwrt/packages/blob/master/net/adblock/files/README.md OpenWrt's adblock package's README].}}<br />
<br />
== See also ==<br />
<br />
* [http://www.g-loaded.eu/2010/09/18/caching-nameserver-using-dnsmasq/ Caching Nameserver using dnsmasq, and a few other tips and tricks.]</div>Tobbebobbe