NAME¶

NetworkManager - network management daemon

SYNOPSIS¶

NetworkManager [OPTIONS...]

DESCRIPTION¶

The NetworkManager daemon attempts to make networking configuration and operation as painless and automatic as possible by managing the primary network connection and other network interfaces, like Ethernet, Wi-Fi, and Mobile Broadband devices. NetworkManager will connect any network device when a connection for that device becomes available, unless that behavior is disabled. Information about networking is exported via a D-Bus interface to any interested application, providing a rich API with which to inspect and control network settings and operation.

DISPATCHER SCRIPTS¶

NetworkManager-dispatcher service can execute scripts for the user in response to network events. See NetworkManager-dispatcher(8) manual.

OPTIONS¶

The following options are understood:

--version | -V

--help | -h

--no-daemon | -n

--debug | -d

--pid-file | -p

--state-file

--config

--configure-and-quit [initrd]

--plugins

--log-level

--log-domains

--print-config

UDEV PROPERTIES¶

udev(7) device manager is used for the network device discovery. The following property influences how NetworkManager manages the devices:

NM_UNMANAGED

ID_NET_MANAGED_BY

NM_AUTO_DEFAULT_LINK_LOCAL_ONLY

ID_NET_AUTO_LINK_LOCAL_ONLY

ID_NET_DHCP_BROADCAST

SIGNALS¶

NetworkManager process handles the following signals:

SIGHUP

SIGUSR1

SIGUSR2

An alternative to a signal to reload configuration is the Reload D-Bus call. It allows for more fine-grained selection of what to reload, it only returns after the reload is complete, and it is guarded by PolicyKit.

DEBUGGING¶

NetworkManager only configures your system. So when your networking setup doesn't work as expected, the first step is to look at your system to understand what is actually configured, and whether that is correct. The second step is to find out how to tell NetworkManager to do the right thing.

You can for example try to ping hosts (by IP address or DNS name), look at ip link show, ip address show and ip route show, and look at /etc/resolv.conf for name resolution issues. Also look at the connection profiles that you have configured in NetworkManager (nmcli connection and nmcli connection show "$PROFILE") and the configured interfaces (nmcli device).

If that does not suffice, look at the logfiles of NetworkManager. NetworkManager logs to syslog, so depending on your system configuration you can call journalctl to get the logs. By default, NetworkManager logs are not verbose and thus not very helpful for investigating a problem in detail. You can change the logging level at runtime with nmcli general logging level TRACE domains ALL. But usually a better way is to collect full logs from the start, by configuring level=TRACE in NetworkManager.conf. See NetworkManager.conf(5) manual. Note that trace logs of NetworkManager are verbose and systemd-journald might rate limit some lines. Possibly disable rate limiting first with the RateLimitIntervalSec and RateLimitBurst options of journald (see journald.conf(5) manual).

NetworkManager does not log any secrets. However, you are advised to check whether anything private sensitive gets logged before posting. When reporting an issue, provide complete logs and avoid modifications (for privacy) that distort the meaning.

/VAR/LIB/NETWORKMANAGER/SECRET_KEY AND /ETC/MACHINE-ID¶

The identity of a machine is important as various settings depend on it. For example, ipv6.addr-gen-mode=stable and ethernet.cloned-mac-address=stable generate identifiers by hashing the machine's identity. See also the connection.stable-id connection property which is a per-profile seed that gets hashed with the machine identity for generating such addresses and identifiers.

If you backup and restore a machine, the identity of the machine probably should be preserved. In that case, preserve the files /var/lib/NetworkManager/secret_key and /etc/machine-id. On the other hand, if you clone a virtual machine, you probably want that the clone has a different identity. There is already existing tooling on Linux for handling /etc/machine-id (see machine-id(5)).

The identity of the machine is determined by the /var/lib/NetworkManager/secret_key. If such a file does not exist, NetworkManager will create a file with random content. To generate a new identity just delete the file and after restart a new file will be created. The file should be read-only to root and contain at least 16 bytes that will be used to seed the various places where a stable identifier is used.

Since 1.16.0, NetworkManager supports a version 2 of secret-keys. For such keys /var/lib/NetworkManager/secret_key starts with ASCII "nm-v2:" followed by at least 32 bytes of random data. Also, recent versions of NetworkManager always create such kinds of secret-keys, when the file does not yet exist. With version 2 of the secret-key, /etc/machine-id is also hashed as part of the generation for addresses and identifiers. The advantage is that you can keep /var/lib/NetworkManager/secret_key stable, and only regenerate /etc/machine-id when cloning a VM.

BUGS¶

Please report any bugs you find in NetworkManager at the NetworkManager issue tracker[1].

SEE ALSO¶

NetworkManager home page[2], NetworkManager.conf(5), NetworkManager-dispatcher(8), NetworkManager-wait-online.service(8), nmcli(1), nmcli-examples(7), nm-online(1), nm-settings-nmcli(5), nm-applet(1), nm-connection-editor(1), udev(7)

NOTES¶

1.

NetworkManager issue tracker

2.

NetworkManager home page