NM-SETTINGS-DBUS(5)

🫢 nm-settings-dbus(5) β€” the Configuration page 🫢

okay bestie, this is the manual page for nm-settings-dbus: it’s literally the description of settings and properties of NetworkManager connection profiles on the D-Bus API. No cap, it’s giving backend lore, but make it make sense πŸ’…


🌸 NAME 🌸

nm-settings-dbus β€” Description of settings and properties of NetworkManager connection profiles on the D-Bus API


✨ DESCRIPTION ✨

NetworkManager is built around a concept of connection profiles, sometimes just called connections because we’re casual like that. These connection profiles contain a network configuration. When NetworkManager activates a connection profile on a network device, the configuration gets applied and an active network connection is established. Users are free to create as many connection profiles as they see fit, so they’re flexible in having various network configurations for different networking needs. It’s very β€œwardrobe full of outfits, but for network configs” energy πŸ‘‘

The connection profiles are handled by NetworkManager via the settings service and are exported on D-Bus as /org/freedesktop/NetworkManager/Settings/<num> objects. The conceptual objects can be described as follows:

  • Connection (profile) β€” A specific, encapsulated, independent group of settings describing all the configuration required to connect to a specific network. It is referred to by a unique identifier called the UUID. A connection is tied to one specific device type, but not necessarily a specific hardware device. It is composed of one or more Settings objects. main character energy, honestly πŸ¦‹
  • Setting β€” A group of related key/value pairs describing a specific piece of a Connection (profile). Settings keys and allowed values are described in the tables below. Keys are also referred to as properties. Developers can find the setting objects and their properties in the libnm-core sources. Look for the *_class_init functions near the bottom of each setting source file. iykyk 🧚

The settings and properties shown in the tables below list all available connection configuration options. However, bestie, note that not all settings are applicable to all connection types β€” that’s the vibe check you gotta keep in mind ⚠️

NetworkManager provides a command-line tool called nmcli that allows direct configuration of the settings and properties according to a connection profile type. And nmcli connection editor has also a built-in describe command that can display the description of particular settings and properties of this page. So yeah, the tool is out here being helpful and iconic 🌈


no worries, the rest of the settings-and-properties lore is coming in the next parts πŸ’–

πŸŽ€ connection setting πŸŽ€

General Connection Profile Settings β€” the baseline vibe of every profile, bestie. Let's get into it πŸ’…

  • auth-retries β€” value type int32, default -1. This is literally the number of retries for the authentication. Zero means "try forever, we're not quitting, periodt" (try indefinitely); -1 means "use a global default". And if that global default isn't set? Then the authentication retries for 3 times before failing the connection. Also, heads up: connections that use a pre-shared key to authenticate will only prompt for a new key during the last authentication attempt πŸ™ˆ
  • autoconnect β€” value type boolean, default TRUE. Whether or not the connection should be automatically connected by NetworkManager when the resources for the connection are available. Set TRUE to automatically activate the connection, FALSE to require manual intervention to activate it. Autoconnect happens when the circumstances are suitable, iykyk β€” which means, for example, that the device is currently managed and not active. So autoconnect never replaces or competes with an already active profile, no cap. πŸ’– Note that autoconnect is not implemented for VPN profiles 🫢 β€” see "secondaries" as an alternative to automatically connect VPN profiles.
⭐ lowkey important: those two little notes about the last-attempt prompt and VPN profiles are real behaviour, not fluff β€” don't skip 'em.

So, back to autoconnect for a sec: if multiple profiles are ready to autoconnect on the same device, the one with the better connection.autoconnect-priority is chosen. If the priorities are equal, then the most recently connected profile is activated. If the profiles were not connected earlier or their connection.timestamp is identical, the choice is undefined. 😬 Depending on connection.multi-connect, a profile can (auto)connect only once at a time or multiple times.


  • autoconnect-ports (int32, default -1) β€” whether or not ports of this connection should be automatically brought up when NetworkManager activates this connection. This only has a real effect for controller connections. The properties autoconnect, autoconnect-priority and autoconnect-retries are unrelated to this setting. The permitted values are: 0: leave port connections untouched, 1: activate all the port connections with this connection, -1: default. If -1 (the default) is set, the global connection.autoconnect-ports is read to determine the real value. If that's also default, it falls back to 0. πŸ’…
  • autoconnect-priority (int32, default 0) β€” the autoconnect priority, in range -999 to 999. If the connection is set to autoconnect, connections with higher priority will be preferred. Higher number = higher priority. Defaults to 0. Note that this property only matters if there are more than one candidate profile to select for autoconnect. In case of equal priority, the profile used most recently is chosen. πŸ”₯
  • autoconnect-retries (int32, default -1) β€” the number of times a connection should be tried when autoactivating before giving up. 0 means forever, -1 means the global default (4 times if not overridden). Setting this to 1 means to try activation only once

…before it goes and blocks autoconnect for you. And bestie, listen β€” after that timeout expires, NetworkManager will try to autoconnect again 😭 she does not give up, she's giving main character persistence fr fr.

  • autoconnect-slaves (NMSettingConnectionAutoconnectSlaves, int32) β€” okay so this one's asking: should the ports of this connection get brought up automatically when NetworkManager activates this connection? 🫢 Real talk: this only actually does anything for controller connections. And ngl, the properties "autoconnect", "autoconnect-priority" and "autoconnect-retries" are unrelated to this setting β€” don't mix them up, iykyk. The permitted values are:
    • 0 β€” leave port connections untouched
    • 1 β€” activate all the port connections with this connection
    • -1 β€” default If -1 (default) is set, the global connection.autoconnect-slaves gets read to figure out the real value. And if that's default too, it fallbacks to 0. Layers on layers, lowkey iconic. πŸ’…
Deprecated 1.46. Use "autoconnect-ports" instead β€” this is just an alias. She's retired but still showing up to the group chat πŸ™ˆ
  • controller (string) β€” the interface name of the controller device, or the UUID of the controller connection. That's it, that's the whole vibe ✨
  • dns-over-tls (int32, default -1) β€” is DNSOverTls (dns-over-tls) enabled for this connection or not? So DNSOverTls is a technology that uses TLS to encrypt dns traffic β€” yes, encrypted DNS, we love a privacy moment πŸ¦‹. The permitted values are:
    • "yes" (2) β€” use DNSOverTls and disabled fallback, no compromises
    • "opportunistic" (1) β€” use DNSOverTls but allow fallback to unencrypted resolution
    • "no" (0) β€” don't ever use DNSOverTls, periodt If it's unspecified, "default" depends on the plugin used. Systemd-resolved uses the global setting.
Heads up: this feature requires a plugin which supports DNSOverTls. Otherwise the setting has no effect β€” literally nothing, zero, nada πŸ’€. One such plugin is dns-systemd-resolved.
  • dnssec (int32, default -1) β€” is DNSSEC (dnssec) enabled for this connection? 🌸 The permitted values are:
    • "yes" (2) β€” use DNSSEC and disable fallback
    • "allow-downgrade" (1) β€” use DNSSEC but allow fallback if the server does not support it (be flexible bestie 🫢)
    • "no" (0) β€” don't ever use DNSSEC The effect of "default" (-1) depends on the dns plugin used. Systemd-resolved uses its global setting in this case.
Same deal as above: this feature requires a plugin which supports DNSSEC. Otherwise the setting has no effect. One such plugin is systemd-resolved. ✨
  • down-on-poweroff (int32, default -1) β€” whether this connection gets brought down before the system powers off. The default value is -1 (default). And when you leave it at that default? NetworkManager looks up the global value from its configuration, and if that's not set either, it's considered as 0 (no).
  • gateway-ping-timeout (uint32, default 0) β€” if this is greater than zero, it delays the success of IP addressing until either the timeout is reached, or an IP gateway actually replies to a ping. no vibes-based "it's probably fine" here, we wait for an actual answer πŸ’…
  • id (string) β€” a human readable unique identifier for the connection, like "Work Wi-Fi" or "T-Mobile 3G". name it something your future self will recognize, bestie πŸŽ€
  • interface-name (string) β€” the name of the network interface this connection is bound to. If you don't set it, the connection can be attached to any interface of the appropriate type (subject to the restrictions imposed by other settings).

For software devices this specifies the name of the created device.

For connection types where interface names can't easily be made persistent (e.g. mobile broadband or USB Ethernet), this property should not be used. because setting it restricts which interfaces a connection can be used with, and if interface names change or get reordered the connection may end up applied to the wrong interface. 😭

  • ip-ping-addresses (array of string) β€” a list of target IP addresses for pinging. When multiple targets are set, NetworkManager starts multiple ping processes in parallel. parallel pinging, she's multitasking πŸ’… This property can only be set if connection.ip-ping-timeout is set. The ip-ping-timeout is used to delay the success of IP addressing until either the specified timeout (in seconds) is reached, or a target IP address replies to a ping. Heads up though: configuring "ip-ping-addresses" may delay reaching systemd's network-online.target due to waiting for the ping operations to complete or timeout. ⏳
  • ip-ping-addresses-require-all (int32, default -1) β€” this property determines whether it's sufficient for any ping check to succeed among "ip-ping-addresses", or if all ping checks must succeed for "ip-ping-addresses". any vs. all, choose your fighter 🫢
  • ip-ping-timeout β€” uint32, default 0. If this is greater than zero, success of IP addressing gets delayed until either the timeout you set (in seconds) is reached, or a target IP address replies to a ping. This property specifies the timeout for "ip-ping-addresses". It is incompatible with "gateway-ping-timeout" β€” you literally cannot set these two properties at the same time. πŸ’…
  • lldp β€” int32, default -1. Whether LLDP is enabled for the connection. That’s the whole vibe. ✨
  • llmnr β€” int32, default -1. Whether Link-Local Multicast Name Resolution (LLMNR) is enabled for the connection. LLMNR is a protocol based on the Domain Name System (DNS) packet format that allows both IPv4 and IPv6 hosts to perform name resolution for hosts on the same local link. The permitted values are: "yes" (2) register hostname and resolving for the connection, "no" (0) disable LLMNR for the interface, "resolve" (1) do not register hostname but allow resolving of LLMNR host names. If unspecified, "default" ultimately depends on the DNS plugin (which for systemd-resolved currently means "yes"). This feature requires a plugin which supports LLMNR. Otherwise, the setting has no effect. One such plugin is dns-systemd-resolved. πŸ¦‹
  • master β€” string, default empty. Interface name of the controller device or UUID of the controller connection. Deprecated 1.46. Use "controller" instead, this is just an alias. 🫢
  • mdns β€” int32, default -1. Whether mDNS is enabled for the connection. The permitted values are: "yes" (2) register hostname and resolving for the connection, "no" (0) disable mDNS for the interface, "resolve" (1) do not register hostname but allow resolving of mDNS host names and "default" (-1) to allow lookup of a global default in NetworkManager.conf. If unspecified, "default" ultimately depends on the DNS plugin. This feature requires a plugin which supports mDNS. Otherwise, the setting has no effect. Currently the only supported DNS plugin is systemd-resolved. For systemd-resolved, the default is configurable via MulticastDNS=

metered

  • D-Bus type: NMMetered (int32)
  • Default: (none)

Is this connection metered or not, bestie? That's the whole vibe check here. πŸ’œ

And here's the slay detail: if you update this property on a connection that's currently activated, the change takes effect immediately β€” no reconnect, no drama, it just happens ✨


mptcp-flags

  • D-Bus type: uint32
  • Default: 0

Okay so this one is a whole thing and honestly it's kind of iconic 🫢 This is where you decide whether to configure MPTCP endpoints and the address flags. If MPTCP is enabled in NetworkManager, it will configure the addresses of the interface as MPTCP endpoints.

Heads up, the following are excluded from being configured as endpoints β€” no cap, they're just not invited to the party πŸ™ˆ: - IPv4 loopback addresses (127.0.0.0/8) - IPv4 link local addresses (169.254.0.0/16) - the IPv6 loopback address (::1) - IPv6 link local addresses (fe80::/10) - IPv6 unique local addresses (ULA, fc00::/7) - IPv6 privacy extension addresses (rfc3041, ipv6.ip6-privacy)

So, the flags themselves β€” let me lay them out for you πŸ’…

  • "disabled" (0x1) β€” MPTCP handling for the interface is disabled and no endpoints are registered. Full stop, nothing happens, we're done here.
  • "enabled" (0x2) β€” MPTCP handling is enabled. Cute bonus: this flag can also be implied from the presence of other flags, so you don't always have to spell it out 😌

Now, even when it's enabled, MPTCP handling will by default still be disabled unless the /proc/sys/net/mptcp/enabled sysctl is on πŸ‘€ And listen β€” NetworkManager does not change the sysctl. That's on the administrator or the distribution, not us. So if you wanna configure endpoints even when the sysctl is disabled, that's what the "also-without-sysctl" (0x4) flag is for. In that case, NetworkManager doesn't look at the sysctl at all and configures endpoints regardless. Main character energy, honestly πŸ”₯

And there's more (sorry, it's giving thorough πŸŽ€): even when enabled, NetworkManager will only configure MPTCP endpoints for a certain address family if there's a unicast default route (0.0.0.0/0 or ::/0) in the main routing table. Wanna override that? The "also-without-default-route" (0x8) flag says "nope, we're doing it anyway" ⭐

So when MPTCP handling is enabled, endpoints get configured with the specified address flags:

  • "signal" (0x10)
  • "subflow" (0x20)
  • "backup" (0x40)
  • "fullmesh" (0x80)
  • "laminar" (0x100)

Check out ip-mptcp(8) for the extra tea on what those flags actually mean πŸ’–

And if the flags are zero (0x0), the global connection default from NetworkManager.conf is honored. If still unspecified, the fallback is "enabled,subflow". Note that this means that MPTCP

...is by default done depending on the /proc/sys/net/mptcp/enabled sysctl. πŸ’…

Bestie, listen β€” NetworkManager does not change the MPTCP limits, and it does not enable MPTCP via /proc/sys/net/mptcp/enabled. That's a host configuration thing, and the admin can change it via sysctl and ip-mptcp. No cap. 🫢

Also, strict reverse path filtering (rp_filter) breaks so many MPTCP use cases 😭, so when MPTCP handling for IPv4 addresses on the interface is enabled, NetworkManager would loosen the strict reverse path filtering (1) to the loose setting (2). It's giving "we fixed it for you, you're welcome." ✨

  • mud-url (string) β€” If it's configured, this gets set to a Manufacturer Usage Description (MUD) URL that points to manufacturer-recommended network policies for IoT devices. It's transmitted as a DHCPv4 or DHCPv6 option, lowkey just doing its thing. The value must be a valid URL starting with https:// β€” no shortcuts, bestie. πŸŽ€

The special value none is allowed, and it means exactly what it sounds like: no MUD URL is used, periodt. πŸ’…

If the per-profile value is unspecified (that's the default), a global connection default gets consulted. And if that's still unspecified, the ultimate default is none. Chain of command, iykyk. πŸ‘‘

  • multi-connect (int32, default 0) β€” Specifies whether the profile can be active multiple times at a particular moment. The value is of type NMConnectionMultiConnect. That's the whole vibe check. ✨
  • permissions (array of string) β€” An array of strings defining what access a given user has to this connection. Okay so:
    • If this is NULL or empty, all users are allowed to access this connection 🫢
    • Otherwise, users are allowed if and only if they are in this list. Strict guest list energy. πŸŽ€
    • When this is not empty, the connection can be active only when one of the specified users is logged into an active session. πŸ‘‘

Each entry is of the form "[type]:[id]:[reserved]" β€” for example, "user:dcbw:blah". Cute, right? 🌸

At this time only the "user" [type] is allowed. Any other values are ignored and reserved for future use β€” so don't come at it with random types, it's not gonna slay. πŸ’€

[id] is the username that this permission refers to, which may not contain the ":" character. That's the one rule, bestie, respect it. πŸ™ˆ

Any [reserved] information present must be ignored and is reserved for future use. Not me telling you to straight-up ignore it, it's literally the spec. 😭

All of [type], [id], and [reserved] must be valid UTF-8. Non-negotiable, icon behavior. ⭐

  • port-type (string) β€” Setting name of the device type

...of this port's controller connection (eg, "bond"), or NULL if this connection is not a port. 🫢

  • read-only β€” this one's a boolean, defaulting to FALSE, and honestly? It's giving ghost town πŸ‘» β€” this property is deprecated and has no meaning. Like, it literally does nothing. It's been deprecated since version 1.44. And yes bestie, they said it twice, so imma say it twice: this property is deprecated and has no meaning. πŸ’€
  • secondaries β€” an array of string, no default. It's the list of connection UUIDs that should be activated when the base connection itself is activated. Currently, only VPN connections are supported. So it's the squad that shows up when the main character arrives. πŸ‘‘
  • slave-type β€” a string, no default. This is the setting name of the device type of this port's controller connection (eg, "bond"), or NULL if this connection is not a port. ⚠️ Heads up though: deprecated in 1.46 β€” use "port-type" instead, because this is just an alias. It's the understudy, not the lead. 🎭
  • stable-id β€” a string, no default, and this one's the ✨ main character ✨ ngl. It represents the identity of the connection used for various purposes, and it lets you configure multiple profiles to share the identity. Also β€” and this is the cool part β€” the stable-id can contain placeholders that are substituted dynamically and deterministically depending on the context. πŸ¦‹

The stable-id is used for generating IPv6 stable private addresses with ipv6.addr-gen-mode=stable-privacy. It's also used to seed the generated cloned MAC address for ethernet.cloned-mac-address=stable and wifi.cloned-mac-address=stable. It's also used to derive the DHCP client identifier with ipv4.dhcp-client-id=stable, the DHCPv6 DUID with ipv6.dhcp-duid=stable-[llt,ll,uuid] and the DHCP IAID with ipv4.iaid=stable and ipv6.iaid=stable. Like, one string doing ALL that? obsessed. πŸ’…

Note that depending on the context where it's used, other parameters are also seeded into the generation algorithm. For example, a per-host key is commonly also included, so that different systems end up generating different IDs. Or with ipv6.addr-gen-mode=stable-privacy, also the device's name is included, so that different interfaces yield different addresses. The per-host key is the identity of your machine and stored in /var/lib/NetworkManager/secret_key β€” see NetworkManager(8) manual about the secret-key and the host identity. πŸ—οΈβœ¨

The '$' character is treated… (to be continued, bestie, don't you dare close the tab 😭*)*

…special to perform dynamic substitutions at activation time. Currently, supported are ${CONNECTION}, ${DEVICE}, ${MAC}, ${NETWORK_SSID}, ${BOOT}, ${RANDOM}. These effectively create unique IDs per-connection, per-device, per-SSID, per-boot, or every time. πŸ’«

The way each one resolves, bestie:

  • ${CONNECTION} uses the profile's connection.uuid
  • ${DEVICE} uses the interface name of the device
  • ${MAC} uses the permanent MAC address of the device
  • ${NETWORK_SSID} uses the SSID for Wi-Fi networks, and falls back to ${CONNECTION} on other networks

Any unrecognized patterns following $ are treated verbatim, however they are reserved for future use. You are thus advised to avoid $ or escape it as $$. πŸ™ˆ

fr fr do not raw-dog a $ in there unless you mean it, okay? future-you (and future NetworkManager) will not be cute about it.

For example, set it to ${CONNECTION}-${BOOT}-${DEVICE} to create a unique id for this connection that changes with every reboot and differs depending on the interface where the profile activates. iconic behaviour honestly πŸŽ€

If the value is unset, a global connection default is consulted. If the value is still unset, the default is default${CONNECTION} go generate an ID unique per connection profile. (yes it literally says "go generate" in the man page, i'm not fixing it, that's not my job πŸ’€)


  • timestamp β€” uint64, default 0. The time, in seconds since the Unix Epoch, that the connection was last successfully fully activated. NetworkManager updates the connection timestamp periodically when the connection is active to ensure that an active connection has the latest timestamp. The property is only meant for reading β€” and heads up, changes to this property will not be preserved. it's read-only in spirit, so don't get any ideas πŸ‘‘
  • type β€” string, no default. Base type of the connection. For hardware-dependent connections, it should contain the setting name of the hardware-type specific setting (ie, "802-3-ethernet" or "802-11-wireless" or "bluetooth", etc), and for non-hardware dependent connections like VPN or otherwise, it should contain the setting name of that setting type (ie, "vpn" or "bridge", etc). it's giving "my whole personality is one string" and honestly? valid 🌈
  • uuid β€” string, no default. A universally unique identifier for the connection, for example generated with libuuid. It should be assigned when the connection is created, and never changed as long as the connection still applies to the same network. For example, it should not be changed when the "id" property or NMSettingIP4Config changes β€” but it might need to be re-created when the Wi-Fi SSID, mobile broadband network provider,
  • uuid β€” string, default blank. Okay so picking up right where we left off on this one: the rule also kicks in when the "type" property changes. And the UUID must be in the format "2815492f-7e56-435e-b2e9-246bd7cdc664" β€” like, only hexadecimal characters and "-", that's the whole vibe. No cap. πŸ’…
  • wait-activation-delay β€” int32, default -1. Time in milliseconds to wait for the connection to be considered activated. The waiting starts after the pre-up dispatcher event, bestie, so don't get it twisted. ✨ 0 means no wait time at all. And the default -1? rn it currently has the same meaning as no wait time β€” iconic but lowkey redundant.
  • wait-device-timeout β€” int32, default -1. Timeout in milliseconds to wait for the device at startup. Real talk: during boot, devices can take a hot minute to be detected by the driver. This property will cause a delay of NetworkManager-wait-online.service and nm-online so the device gets a chance to actually show up 🫢. It works by waiting for the given timeout until a compatible device for the profile is available and managed. 0 = no wait time. Default -1 = currently the same meaning as no wait time. Same energy as the last one, fr fr.
  • zone β€” string, default blank. The trust level of the connection. It's a free-form, case-insensitive string (think "Home", "Work", "Public" β€” you know the drill). NULL or unspecified zone means the connection gets placed in the default zone as defined by the firewall. πŸ”₯ And the slay part: when you update this property on a currently activated connection, the change takes effect immediately. No restart era. Periodt.

πŸ¦‹ 6lowpan setting πŸ¦‹

6LoWPAN settings. Tiny table, tiny vibes, full details πŸ‘‘

  • parent β€” string, default blank. If given, this specifies the parent interface name or parent connection UUID from which this 6LowPAN interface should be created. That's it, that's the whole setting. She's minimal, she's mysterious, she ate πŸ’œ
Key Name:  parent
Value Type: string
Default Value: (empty)

πŸ¦‹ 802-1x setting πŸ¦‹

IEEE 802.1x Authentication Settings. β€” bestie, this is the whole auth buffet, so grab a snack πŸ’…


  • altsubject-matches β€” array of string β€” no default listed. A list of strings that get matched against the altSubjectName of the certificate the authentication server hands over. And here's the tea: if the list is empty, no verification of the server certificate's altSubjectName happens at all. None. Zero. 🫣 So like… fill it in if you care.
  • anonymous-identity β€” string β€” no default listed. The anonymous identity string for EAP authentication methods. It gets used as the unencrypted identity with EAP types that support a different tunneled identity β€” EAP-TTLS is the classic example ✨ So your real identity stays cozy inside the tunnel and this one takes the outside shift.
  • auth-timeout β€” int32 β€” default is 0. A timeout for the authentication, periodt. 0 means "use the global default", and if the global default isn't set either? The authentication timeout is 25 seconds. πŸ•°οΈ That's your fallback, no cap.
  • ca-cert β€” byte array β€” no default listed. This holds the CA certificate, if the EAP method specified in the eap property uses one. πŸ“œ

Certificate data is specified using a "scheme", and there are three currently supported: blob, path and pkcs#11 URL. Okay so:

  • When you're using the blob scheme, this property should be set to the certificate's DER encoded data. 🧬
  • When you're using the path scheme, this property should be set to the full UTF-8 encoded path of the certificate, prefixed with the string file:// and ending with a terminating NUL byte. πŸ›£οΈ Yeah, the NUL byte is not optional, she's part of the outfit.

This property can be unset even if the EAP method supports CA

  • ca-cert (byte array) β€” okay so finishing up this one's tea from before: you can stash certificates right here, but bestie, doing that allows man-in-the-middle attacks and is NOT recommended. fr fr, do not πŸ™ˆ And heads up: turning on NMSetting8021x:system-ca-certs will override this setting to use the built-in path β€” but only if the built-in path is not a directory. iykyk πŸ’…
  • ca-cert-password (string) β€” the password used to access the CA certificate stored in the "ca-cert" property. Only makes sense if the cert lives on a PKCS#11 token that requires a login. πŸ”‘
  • ca-cert-password-flags (NMSettingSecretFlags (uint32)) β€” flags indicating how to handle the "ca-cert-password" property. ✨
  • ca-path (string) β€” a UTF-8 encoded path to a directory holding PEM- or DER-formatted certificates, which get added to the verification chain in addition to whatever cert you set in the "ca-cert" property. πŸ“

And like β€” if NMSetting8021x:system-ca-certs is enabled and the built-in CA path is an existing directory, then this whole setting is just ignored. not it being ghosted πŸ‘»

  • client-cert (byte array) β€” contains the client certificate if the EAP method specified in the "eap" property uses one. πŸŽ€

Certificate data gets specified using a "scheme", and there are currently two supported: blob and path. Bestie, listen:

  • blob scheme (which is backwards compatible with NM 0.7.x) β€” set this property to the certificate's DER encoded data.
  • path scheme β€” set this property to the full UTF-8 encoded path of the certificate, prefixed with the string "file://" and ending with a terminating NUL byte. 🫢
  • client-cert-password (string) β€” the password used to access the client certificate stored in the "client-cert" property. Only makes sense if the certificate is stored on a PKCS#11 token that requires a login. πŸ”
  • client-cert-password-flags (NMSettingSecretFlags (uint32)) β€” flags indicating how to handle the "client-cert-password" property. ⭐
  • domain-match (string) β€” constraint for the server domain name. If set, this list of FQDNs is used as a match requirement for the dNSName element(s) of the certificate presented by the authentication server. If a matching dNSName is found, this constraint is met. If no

…and if no dNSName values are present, this constraint is matched against SubjectName CN using the same comparison. Multiple valid FQDNs can be passed as a ";" delimited list. πŸ’…


  • domain-suffix-match β€” string, no default 🌸 β€” this one's the constraint for the server's domain name. If you set it, that FQDN gets used as a suffix match requirement for the dNSName element(s) of the certificate the authentication server hands over. Find a matching dNSName? Constraint met, slay. If there are no dNSName values at all, this constraint gets matched against SubjectName CN using the same suffix match comparison. And since version 1.24, you can pass multiple valid FQDNs as a ";" delimited list. iconic.
  • eap β€” array of string, no default πŸ¦‹ β€” the allowed EAP method to be used when authenticating to the network with 802.1x. Valid methods are: "leap", "md5", "tls", "peap", "ttls", "pwd", and "fast". Heads up bestie: each method needs different configuration using the properties of this setting β€” so go refer to the wpa_supplicant documentation for the allowed combinations, iykyk πŸ“š
  • identity β€” string, no default πŸŽ€ β€” the identity string for EAP authentication methods. Often it's the user's user or login name. literally that simple.
  • openssl-ciphers β€” string, no default ✨ β€” defines openssl_ciphers for wpa_supplicant. Here's the tea: Openssl sometimes moves ciphers among SECLEVELs, so the compiled-in default value in wpa_supplicant (as modified by some linux distributions) sometimes prevents you from connecting to old servers that don't support the new protocols. not me getting blocked by legacy infra 😭
  • optional β€” boolean, default FALSE πŸ’œ β€” whether the 802.1X authentication is optional. If TRUE, the activation will keep going even after a timeout or an authentication failure. ⚠️ Setting the property to TRUE is currently allowed only for Ethernet connections. If set to FALSE, the activation can continue only after a successful authentication. no shortcuts, periodt.
  • pac-file β€” string, no default πŸ“ β€” a UTF-8 encoded file path containing the PAC for EAP-FAST.
  • password β€” string, no default πŸ”₯ β€” the UTF-8 encoded password used for EAP authentication methods. And if both the "password" property and the "password-raw" property are specified, "password" is preferred. she wins the tiebreak, as she should πŸ‘‘
  • password-flags β€” NMSettingSecretFlags (uint32), no default 🧚 β€” flags indicating how to handle the "password" property.
  • password-raw β€” byte array, no default πŸ’€ β€” password used for EAP

…authentication methods, given as a byte array to allow passwords in other encodings than UTF-8 to be used. If both the "password" property and the "password-raw" property are specified, "password" is preferred. πŸ’–

  • password-raw-flags β€” type: NMSettingSecretFlags (uint32); default: (blank). These are the flags that say how to handle the "password-raw" property. πŸ’…
  • phase1-auth-flags β€” type: uint32; default: 0. Specifies the authentication flags to use in "phase 1" outer authentication using NMSetting8021xAuthFlags options. The individual TLS versions can be explicitly disabled, and TLS time checks can be also disabled. If a certain TLS disable flag is not set, it is up to the supplicant to allow or forbid it. The TLS options map to tls_disable_tlsv1_x and tls_disable_time_checks settings. See the wpa_supplicant documentation for more details. ✨
  • phase1-fast-provisioning β€” type: string; default: (blank). Enables or disables in-line provisioning of EAP-FAST credentials when FAST is specified as the EAP method in the "eap" property. Recognized values are "0" (disabled), "1" (allow unauthenticated provisioning), "2" (allow authenticated provisioning), and "3" (allow both authenticated and unauthenticated provisioning). See the wpa_supplicant documentation for more details. πŸ¦‹
  • phase1-peaplabel β€” type: string; default: (blank). Forces use of the new PEAP label during key derivation. Some RADIUS servers may require forcing the new PEAP label to interoperate with PEAPv1. Set to "1" to force use of the new PEAP label. See the wpa_supplicant documentation for more details. πŸŽ€
  • phase1-peapver β€” type: string; default: (blank). Forces which PEAP version is used when PEAP is set as the EAP method in the "eap" property. When unset, the version reported by the server will be used. Sometimes when using older RADIUS servers, it is necessary to force the client to use a particular PEAP version. To do so, this property may be set to "0" or "1" to force that specific PEAP version. 🌸
  • phase2-altsubject-matches β€” type: array of string; default: (blank). List of strings to be matched against the altSubjectName of the certificate presented by the authentication server during the inner "phase 2" authentication. If the list is empty, no verification of the server certificate's altSubjectName is performed. 🫢
  • phase2-auth β€” type: string; default: (blank). Specifies the allowed "phase 2" inner authentication method

…okay picking right back up on phase2-auth, because this one has layers, bestie πŸ’… β€” it's the property that does the work when an EAP method that uses an inner TLS tunnel is specified in the "eap" property. Here's the tea:

  • For TTLS, this property selects one of the supported non-EAP inner methods: "pap", "chap", "mschap", "mschapv2"
  • "phase2-autheap" (the next one, don't worry) selects an EAP inner method instead.
  • For PEAP, this selects an inner EAP method, one of: "gtc", "otp", "md5" and "tls".
  • Each "phase 2" inner method requires specific parameters for successful authentication; see the wpa_supplicant documentation for more details.
  • 🚨 Both "phase2-auth" and "phase2-autheap" cannot be specified. Pick a lane, babe.

  • phase2-autheap (string) β€” specifies the allowed "phase 2" inner EAP-based authentication method when TTLS is specified in the "eap" property. The recognized EAP-based "phase 2" methods are "md5", "mschapv2", "otp", "gtc", and "tls". Each "phase 2" inner method requires specific parameters for successful authentication; see the wpa_supplicant documentation for more details. (Yes, same warning energy as above β€” and again, you can't have both "phase2-auth" and this one. πŸ’€)
  • phase2-ca-cert (byte array) β€” contains the "phase 2" CA certificate if used by the EAP method specified in the "phase2-auth" or "phase2-autheap" properties.

So how do you actually hand over certificate data? With a "scheme" β€” and three are currently supported: blob, path and pkcs#11 URL.

  • With the blob scheme, this property should be set to the certificate's DER encoded data.
  • With the path scheme, this property should be set to the full UTF-8 encoded path of the certificate, prefixed with the string "file://" and ending with a terminating NUL byte. (Yes, the NUL byte is part of the vibe. 🫢)

This property can be unset even if the EAP method supports CA certificates β€” but that allows man-in-the-middle attacks and is NOT recommended. Like, genuinely not recommended, bestie, this is the one where you don't skip the safety rails. 😭

Also, heads up: enabling NMSetting8021x:system-ca-certs will override this setting to use the built-in path, if the built-in path is not a directory. Sneaky override, but it's documented, so we respect it. ✨
  • phase2-ca-cert-password (string) β€” the password used to access the "phase2" CA certificate stored in the "phase2-ca-cert" property. Only makes sense if the certificate is stored on a PKCS#11 token that requires a login. Otherwise you're just out here typing a password into the void πŸ™ˆ
  • phase2-ca-cert-password-flags (NMSettingSecretFlags (uint32)) β€” flags indicating how to handle the "phase2-ca-cert-password" property. Secret-handling bookkeeping, lowkey iconic for keeping your password from being a public spectacle. πŸ”₯
  • phase2-ca-path (string) β€” UTF-8 encoded path to a directory containing PEM or DER formatted certificates to…

…and it gets tacked onto the verification chain on top of whatever cert you already dropped into the "phase2-ca-cert" property. Two CAs, one handshake, we love a duo. πŸ’«

Oh, and a lil gotcha: if NMSetting8021x:system-ca-certs is enabled and the built-in CA path is an existing directory, then this setting just gets ignored. Bye bestie, the system's taking the wheel. πŸŽ€

  • phase2-client-cert β€” byte array, default empty. Holds the "phase 2" client certificate if the EAP method specified in "phase2-auth" or "phase2-autheap" actually uses one. You specify cert data using a "scheme", and there are exactly two rn:
    • blob β€” backwards compatible with NM 0.7.x, and you set this property to the certificate's DER-encoded data.
    • path β€” you set this property to the full UTF-8 encoded path of the certificate, prefixed with the string "file://" and ending with a terminating NUL byte. Yeah, the NUL byte is part of the assignment, no cap. 😭

This property can be unset even if the EAP method supports CA certificates β€” but doing that lowkey opens you up to man-in-the-middle attacks and is NOT recommended. Like, fr fr, don't. πŸ’€

  • phase2-client-cert-password β€” string, default empty. The password used to access the "phase2" client certificate stored in the "phase2-client-cert" property. Only makes sense if that certificate lives on a PKCS#11 token that requires a login. Iconic when it applies, meaningless otherwise. πŸ”‘
  • phase2-client-cert-password-flags β€” NMSettingSecretFlags (uint32), default empty. Flags that say how to handle the "phase2-client-cert-password" property. Just vibes and bitfields. ✨
  • phase2-domain-match β€” string, default empty. Constraint for the server domain name. If you set it, this list of FQDNs becomes a match requirement for the dNSName element(s) of the certificate that the authentication server presents during the inner "phase 2" authentication. Find a matching dNSName β†’ constraint met, slay. βœ… If there are no dNSName values present, this constraint gets matched against SubjectName CN using the same comparison. You can pass multiple valid FQDNs as a ";" delimited list β€” semicolons, not commas, iykyk.
  • phase2-domain-suffix-match β€” string, default empty. Also a constraint for the server domain name, but make it suffix energy. πŸ¦‹ If set, this FQDN is used as a suffix match requirement for the dNSName element(s) of the certificate presented by the authentication server during the inner "phase 2" authentication. Matching dNSName found β†’ constraint met. 🌸 If no dNSName values are present, this constraint is matched against SubjectName CN using the same suffix match comparison. One FQDN here, not a list β€” that's just how she is.
  • ✨ and just finishing off the row above bestie: since version 1.24, multiple valid FQDNs can be passed as a ";" delimited list. πŸŽ€
  • phase2-private-key β€” byte array β€” this one's holding the "phase 2" inner private key whenever the "phase2-auth" or "phase2-autheap" property is set to "tls". πŸ”

So the key data gets specified using a "scheme", and there are exactly two in the game rn: blob and path. Ngl this next bit is a whole paragraph but it matters, so:

  • when you're using the blob scheme and private keys, set this property to the key's encrypted PEM encoded data πŸ’–
  • when you're using private keys with the path scheme, set this property to the full UTF-8 encoded path of the key, prefixed with the string "file://" and ending with a terminating NUL byte πŸ¦‹
  • when you're using PKCS#12 format private keys and the blob scheme, set this property to the PKCS#12 data, and the "phase2-private-key-password" property must be set to the password used to decrypt the PKCS#12 certificate and key πŸ”₯
  • when you're using PKCS#12 files and the path scheme, set this property to the full UTF-8 encoded path of the key, prefixed with the string "file://" and ending with a terminating NUL byte β€” and, same as the blob scheme, the "phase2-private-key-password" property must be set to the password used to decode the PKCS#12 private key and certificate πŸ’…
  • phase2-private-key-password β€” string β€” the password used to decrypt the "phase 2" private key that lives in the "phase2-private-key" property, when that private key either uses the path scheme or is a PKCS#12 format key. πŸ—οΈ
  • phase2-private-key-password-flags β€” NMSettingSecretFlags (uint32) β€” flags indicating how to handle the "phase2-private-key-password" property. 🚩
  • phase2-subject-match β€” string β€” a substring to be matched against the subject of the certificate presented by the authentication server during the inner "phase 2" authentication.
🚨 when this is unset, no verification of the authentication server certificate's subject is performed. And honestly? This property provides little security, if any, and should not be used. Periodt.

Also, heads up: this property is deprecated since version 1.2. Use "phase2-domain-suffix-match" instead, bestie. πŸ™ˆ

  • pin β€” string β€” the PIN used for EAP authentication methods. πŸ”’
  • pin-flags β€” NMSettingSecretFlags (uint32) β€” flags indicating how to handle the "pin" property. πŸŽ€
  • private-key (byte array) β€” okay so this one holds your actual private key, but only when the "eap" property is set to "tls". πŸ’…

Key data gets specified using a "scheme", and there are exactly two supported rn: blob and path. Let's break it down because it's a lot, bestie:

  • blob scheme + private keys β†’ set this property to the key's encrypted PEM encoded data.
  • path scheme + private keys β†’ set this property to the full UTF-8 encoded path of the key, prefixed with the string "file://" and ending with a terminating NUL byte.
  • PKCS#12 format private keys + blob scheme β†’ set this property to the PKCS#12 data, and the "private-key-password" property must be set to the password used to decrypt the PKCS#12 certificate and key.
  • PKCS#12 files + path scheme β†’ set this property to the full UTF-8 encoded path of the key, prefixed with "file://" and ending with a terminating NUL byte β€” and just like the blob scheme, "private-key-password" must be set to the password used to decode the PKCS#12 private key and certificate.
WARNING: "private-key" is not a "secret" property, which means unencrypted private key data using the BLOB scheme may be totally readable by unprivileged users. 😭 Like, no cap. Private keys should always be encrypted with a private key password so nobody unauthorized can peek at your unencrypted private key data. Protect urself fr fr. πŸ”₯
  • private-key-password (string) β€” the password used to decrypt the private key you specified in the "private-key" property, when that private key either uses the path scheme, or when it's a PKCS#12 format key. πŸŽ€
  • private-key-password-flags (NMSettingSecretFlags / uint32) β€” flags that tell you how to handle the "private-key-password" property. 🫢
  • subject-match (string) β€” a substring that gets matched against the subject of the certificate the authentication server presents. When it's unset, no verification of the authentication server certificate's subject happens at all. πŸ™ˆ
Heads up: this property provides little security, if any, and should not be used. It's giving deprecated β€” deprecated since version 1.2, actually. Use "phase2-domain-suffix-match" instead. πŸ’€
  • system-ca-certs (boolean) β€” default is FALSE. When it's TRUE, it overrides the "ca-path" and "phase2-ca-path" properties using the system CA directory specified at configure time with the --system-ca-path switch. The certificates in this directory are added to the verification
  • ...continued: it gets added to the certificate chain in addition to any certificates specified by the "ca-cert" and "phase2-ca-cert" properties. But bestie, plot twist 🫒 β€” if the path you hand to --system-ca-path is actually a file name (like, a bundle of trusted CA certificates), then it overrides the "ca-cert" and "phase2-ca-cert" properties instead (it sets the ca_cert/ca_cert2 options for wpa_supplicant). iykyk ✨

πŸŽ€ adsl setting πŸŽ€

ADSL Settings. Very retro of you, honestly. πŸ’…

  • encapsulation β€” string, no default. Encapsulation of the ADSL connection. Can be "vcmux" or "llc".
  • password β€” string, no default. The password used to authenticate with the ADSL service. πŸ”
  • password-flags β€” NMSettingSecretFlags (uint32), no default. Flags indicating how to handle the "password" property.
  • protocol β€” string, no default. ADSL connection protocol. Can be "pppoa", "pppoe" or "ipoatm".
  • username β€” string, no default. The username used to authenticate with the ADSL service.
  • vci β€” uint32, default 0. VCI of the ADSL connection.
  • vpi β€” uint32, default 0. VPI of the ADSL connection.

πŸ¦‹ bluetooth setting πŸ¦‹

Bluetooth Settings. pairing szn fr fr 🫢

  • bdaddr β€” byte array, no default. The Bluetooth address of the device.
  • type β€” string, no default. Either "dun" for Dial-Up Networking connections, or "panu" for Personal Area Networking connections to devices supporting the NAP profile.

πŸ‘‘ bond setting πŸ‘‘

Bonding Settings. two interfaces holding hands, it's giving main character energy πŸ’–

  • interface-name β€” string, no default. ⚠️ Deprecated in favor of connection.interface-name, but it can still be used for backward-compatibility with older daemons, to set the bond's interface name.
  • options β€” dict of string to string, default {'mode': 'balance-rr'}. A dictionary of key/value pairs of bonding options. Both keys and values must be strings. Option names must contain only alphanumeric characters (ie, [a-zA-Z0-9]). No cap, that's the whole rule. πŸŽ€

πŸŒ‰ bridge setting πŸŒ‰

Okay bestie, this is the bridging settings block β€” yes, like actual network bridges, not the emotional kind πŸ’…. Here's every single key, its type, its default, and what it's giving:

  • ageing-time β€” uint32 β€” default 300 β€” the Ethernet MAC address aging time, in seconds. Lowkey how long a MAC address sticks around before it ghosts πŸ‘».
  • forward-delay β€” uint32 β€” default 15 β€” the Spanning Tree Protocol (STP) forwarding delay, in seconds. It's the "hold up, let me think" era before traffic actually flows 🌸.
  • group-address β€” byte array β€” no default listed β€” if you specify it, this is the MAC address of the multicast group this bridge uses for STP ✨.

The address must be a link-local address in standard Ethernet MAC address format, ie an address of the form 01:80:C2:00:00:0X, with X in [0, 4..F] πŸŽ€. If you don't specify it, the default value is 01:80:C2:00:00:00. Periodt.

  • group-forward-mask β€” uint32 β€” default 0 β€” a mask of group addresses to forward πŸ¦‹.

So here's the lore: usually, group addresses in the range from 01:80:C2:00:00:00 to 01:80:C2:00:00:0F are not forwarded, according to standards 😀. This property is a mask of 16 bits, each one corresponding to a group address in that range that must be forwarded.

Heads up bestie πŸ’€ β€” the mask can't have bits 0, 1 or 2 set, because those are already taken by STP, MAC pause frames and LACP. No cap, they're booked and busy.
  • hello-time β€” uint32 β€” default 2 β€” the Spanning Tree Protocol (STP) hello time, in seconds. Just your bridge saying "hey bestie, still here?" every couple seconds 🫢.
  • interface-name β€” string β€” no default listed β€” deprecated in favor of connection.interface-name ⚠️, but it can still be used for backward-compatibility with older daemons, to set the bridge's interface name. It's giving legacy icon, but like, retired πŸ‘‘.
  • mac-address β€” byte array β€” no default listed β€” if specified, the MAC address of bridge πŸ’–. When creating a new bridge, this MAC address will be set.

If this field is left unspecified, the

...so real talk, instead "ethernet.cloned-mac-address" is referred to, to generate the initial MAC address. Lowkey important though: setting "ethernet.cloned-mac-address" anyway overwrites the MAC address of the bridge later while activating the bridge, so like... it doesn't win, okay? πŸ‘€

🚨 bestie heads up: this property is deprecated since version 1.12. Use the "cloned-mac-address" property instead. Periodt, no cap.
  • max-age β€” uint32, default 20 β€” the Spanning Tree Protocol (STP) maximum message age, in seconds. that's it, that's the vibe ⏱️
  • multicast-hash-max β€” uint32, default 4096 β€” sets the maximum size of the multicast hash table. and ngl the value must be a power of 2, so don't try to be cute with it πŸŽ€
  • multicast-last-member-count β€” uint32, default 2 β€” sets the number of queries the bridge will send before it stops forwarding a multicast group, after a "leave" message has been received. it's giving "are you sure you're leaving" energy πŸ‘‹
  • multicast-last-member-interval β€” uint64, default 100 β€” sets the interval (in deciseconds) between queries to find the remaining members of a group, after a "leave" message is received. deciseconds, bestie, not seconds β€” read the units πŸ’…
  • multicast-membership-interval β€” uint64, default 26000 β€” sets the delay (in deciseconds) after which the bridge will leave a group, if no membership reports for this group are received. silence = exit 🌸
  • multicast-querier β€” boolean, default FALSE β€” enable or disable the sending of multicast queries by the bridge. if not specified the option is disabled. so like, off unless you say otherwise πŸ™ˆ
  • multicast-querier-interval β€” uint64, default 25500 β€” if no queries are seen after this delay (in deciseconds) has passed, the bridge will start to send its own queries. it literally waits, then takes over πŸ’€
  • multicast-query-interval β€” uint64, default 12500 β€” interval (in deciseconds) between queries sent by the bridge after the end of the startup phase. steady beat, main character energy πŸ₯
  • multicast-query-response-interval β€” uint64, default 1000 β€” sets the Max Response Time/Max Response Delay (in deciseconds) for IGMP/MLD queries sent by the bridge. both names, same thing, she contains multitudes ✨
  • multicast-query-use-ifaddr β€” boolean, default FALSE β€” if enabled, the bridge's own IP address is used as the source address for IGMP queries; otherwise the default of 0.0.0.0 is used. glow-up from anonymous to "it me" 🌈
  • multicast-router β€” string, default (empty) β€” sets the bridge's multicast router. multicast-snooping must be enabled for this option to work, so don't come crying if it does nothing 🫢 Supported values are: 'auto', 'disabled', 'enabled', to which the kernel assigns the numbers 1, 0, and 2, respectively. If not
okay so before we dive in β€” the last entry in the table cut off mid-sentence, and its ending is: if nothing was specified the default value is 'auto' (1). πŸ’…
  • multicast-snooping β€” boolean, default TRUE β€” controls whether IGMP snooping is enabled for this bridge. heads up bestie: if snooping was automatically disabled due to hash collisions, the system may refuse to enable the feature until the collisions are resolved. so like… not you fighting the kernel and losing 😭
  • multicast-startup-query-count β€” uint32, default 2 β€” sets the number of IGMP queries to send during the startup phase. two lil hellos, that's it 🫢
  • multicast-startup-query-interval β€” uint64, default 3125 β€” sets the time (in deciseconds) between queries sent out at startup to determine membership information. yes, deciseconds β€” that's the unit, don't come for me ⭐
  • priority β€” uint32, default 32768 β€” sets the Spanning Tree Protocol (STP) priority for this bridge. lower values are "better"; the lowest priority bridge will be elected the root bridge. it's giving main character energy but for switches πŸ‘‘
  • stp β€” boolean, default TRUE β€” controls whether Spanning Tree Protocol (STP) is enabled for this bridge. iconic loop-prevention behaviour, slay 🌈
  • vlan-default-pvid β€” uint32, default 1 β€” the default PVID for the ports of the bridge, that is the VLAN id assigned to incoming untagged frames. untagged frames walking in like they own the place and getting handed a name tag πŸŽ€
  • vlan-filtering β€” boolean, default FALSE β€” control whether VLAN filtering is enabled on the bridge. literally just a yes/no, no cap πŸ¦‹
  • vlan-protocol β€” string, default is empty β€” if specified, the protocol used for VLAN filtering. supported values are: '802.1Q', '802.1ad'. if not specified the default value is '802.1Q'. so like, you can leave it blank and it'll still eat πŸ’…
  • vlan-stats-enabled β€” boolean, default FALSE β€” controls whether per-VLAN stats accounting is enabled. turn it on if you're nosy (affectionate) πŸ“Š
  • vlans β€” array of vardict, no default listed β€” array of bridge VLAN objects. in addition to the VLANs specified here, the bridge will also have the default-pvid VLAN configured by the bridge.vlan-default-pvid property. so bestie, you're never getting just your list, there's always that one extra πŸ’€

in nmcli the VLAN list can be specified with the following syntax:

$vid [pvid] [untagged] [, $vid [pvid] [untagged]]...

where $vid is either a single id between 1 and 4094 or a range, represented as a couple of ids separated by a dash. so like 10-20 is a whole vibe, and pvid/untagged are the lil optional flags you sprinkle on πŸ“


πŸŽ€ bridge-port setting πŸŽ€

okay bestie, this one is literally all about Bridge Port Settings β€” the little settings that live on each port of a bridge. here's your cheat sheet, no cap:

  • hairpin-mode β€” boolean, default FALSE. turns "hairpin mode" on or off for the port πŸ’… and what that means is frames are allowed to get sent right back out through the very same port they were received on. iconic circular-energy behavior, honestly.
  • path-cost β€” uint32, default 100. this is the Spanning Tree Protocol (STP) port cost for destinations that go via this port πŸŒ‰ think of it as the toll price for routing through here.
  • priority β€” uint32, default 32. the Spanning Tree Protocol (STP) priority of this bridge port. yes it's a whole separate thing from path-cost, don't mix them up bestie πŸ™ˆ
  • vlans β€” array of vardict, and the default is just... nothing (blank). this is the array of bridge VLAN objects 🌸 and here's the tea: on top of the VLANs you specify right here, the port will also have the default-pvid VLAN configured on the bridge by the bridge.vlan-default-pvid property. so surprise! there's a bonus VLAN you didn't even ask for ✨

and in nmcli you can specify that VLAN list with this exact syntax:

$vid [pvid] [untagged] [, $vid [pvid] [untagged]]...

where $vid is either a single id between 1 and 4094, or a range β€” which is represented as a couple of ids separated by a dash. ranges are so slay, we love efficiency πŸ’–


πŸ“‘ cdma setting

CDMA-based Mobile Broadband Settings. Yes bestie, this is the whole little world of CDMA config, and here's every key in it β€” types, defaults, the works. πŸ‘‘

  • mtu β€” value type uint32, default value 0. If it's non-zero, only transmit packets of the specified size or smaller, breaking larger packets up into multiple frames. (big-packet energy: denied πŸ’…)
  • number β€” value type string, default is empty. The number to dial to establish the connection to the CDMA-based mobile broadband network, if any. If not specified, the default number (#777) is used when required. iconic default honestly ✨
  • password β€” value type string, default is empty. The password used to authenticate with the network, if required. Many providers do not require a password, or accept any password. But if a password is required, it is specified here. πŸ”‘
  • password-flags β€” value type NMSettingSecretFlags (uint32), default is empty. Flags indicating how to handle the "password" property. 🚩
  • username β€” value type string, default is empty. The username used to authenticate with the network, if required. Many providers do not require a username, or accept any username. But if a username is required, it is specified here. 🫢
lowkey the vibe here is "maybe auth, maybe not" β€” so set username and password if your provider is being picky, and leave them alone if it isn't. no cap 😌

πŸ–₯️ dcb setting

Data Center Bridging settings β€” yes bestie, this is the whole DCB vibe: traffic classes, priorities, the works. πŸ’… Every key below pairs a value type with (usually) a default, so here's the full roster:

  • app-fcoe-flags β€” value type NMSettingDcbFlags (uint32), no default listed. Tells you the NMSettingDcbFlags for the DCB FCoE application. The flags can be any combo of 0x1 (enable), 0x2 (advertise), and 0x4 (willing). Mix and match, it's giving build-your-own-bitmask ✨
  • app-fcoe-mode β€” value type string, no default listed. This is the FCoE controller mode, and it's either "fabric" or "vn2vn". πŸ¦‹ Since 1.34, NULL is the default value and it means "fabric". Before 1.34, NULL was straight-up rejected as invalid, and the default back then was "fabric". So like… same answer, different paperwork, iykyk.
  • app-fcoe-priority β€” value type int32, default -1. The highest User Priority (0 - 7) that FCoE frames should use, or -1 for the default priority. πŸ‘‘ Heads up: it's only used when the "app-fcoe-flags" property includes the 0x1 (enable) flag. No enable flag, no opinion.
  • app-fip-flags β€” value type NMSettingDcbFlags (uint32), no default listed. Specifies the NMSettingDcbFlags for the DCB FIP application. Flags may be any combination of 0x1 (enable), 0x2 (advertise), and 0x4 (willing). πŸŽ€
  • app-fip-priority β€” value type int32, default -1. The highest User Priority (0 - 7) which FIP frames should use, or -1 for default priority. Only used when the "app-fip-flags" property includes the 0x1 (enable) flag. 🌸 Same energy as its FCoE sibling, fr fr.
  • app-iscsi-flags β€” value type NMSettingDcbFlags (uint32), no default listed. Specifies the NMSettingDcbFlags for the DCB iSCSI application. Flags may be any combination of 0x1 (enable), 0x2 (advertise), and 0x4 (willing). πŸ’œ Third app, same three bits β€” iconic consistency.
  • app-iscsi-priority β€” value type int32, default -1. The highest User Priority (0 - 7) which iSCSI frames should use, or -1 for default priority. Only used when the "app-iscsi-flags" property includes the 0x1 (enable) flag. πŸ”₯
  • priority-bandwidth β€” value type array of uint32, no default listed. This one's an array of 8 uint values, where the array index corresponds to the User Priority (0 - 7) and the value indicates the percentage of bandwidth of the priority's assigned group 🌈
  • and like, that's the slice of the pie the priority is allowed to eat. πŸ“ Heads up though: the sum of all the percentages for priorities that live in the same group has to total 100 percents β€” no cap, the math has to math.
  • priority-flow-control β€” array of uint32 β€” this one's an array of 8 boolean values, where the array index corresponds to the User Priority (0 - 7) and the value tells you whether or not that priority should transmit priority pause. Flow control vibes, one slot per priority. πŸ’…
  • priority-flow-control-flags β€” NMSettingDcbFlags (uint32) β€” sets the NMSettingDcbFlags for DCB Priority Flow Control (PFC). The flags can be any combination of 0x1 (enable), 0x2 (advertise), and 0x4 (willing). Mix and match, bestie, it's a combination not a choice. ✨
  • priority-group-bandwidth β€” array of uint32 β€” an array of 8 uint values where the array index corresponds to the Priority Group ID (0 - 7) and the value is the percentage of link bandwidth allocated to that group. Allowed values are 0 - 100, and β€” say it with me β€” the sum of all values must total 100 percents. πŸ”₯
  • priority-group-flags β€” NMSettingDcbFlags (uint32) β€” the NMSettingDcbFlags for DCB Priority Groups. Flags may be any combination of 0x1 (enable), 0x2 (advertise), and 0x4 (willing). Same flag trio, different group energy. 🫢
  • priority-group-id β€” array of uint32 β€” an array of 8 uint values, where the array index corresponds to the User Priority (0 - 7) and the value indicates the Priority Group ID. Allowed Priority Group ID values are 0 - 7, or 15 for the unrestricted group β€” yes 15 is special, she's the main character. πŸ‘‘
  • priority-strict-bandwidth β€” array of uint32 β€” an array of 8 boolean values, where the array index corresponds to the User Priority (0 - 7) and the value indicates whether or not the priority may use all of the bandwidth allocated to its assigned group. Greedy? Maybe. Allowed? Depends on this flag. πŸ’€
  • priority-traffic-class β€” array of uint32 β€” an array of 8 uint values, where the array index corresponds to the User Priority (0 - 7) and the value indicates the traffic class (0

…- 7) β€” to which the priority is mapped. πŸ’…


πŸŽ€ dummy setting πŸŽ€

Dummy Link Settings. That’s it. That’s the setting. No extra lore, no secret sauce β€” just dummy link settings, bestie. πŸŽ€

⚑ ethtool setting ⚑

Ethtool Ethernet Settings. Ethernet vibes, ethtool edition. πŸ¦‹

🌈 generic setting 🌈

Generic Link Settings. Okay so this is the generic link setting, and the table has four columns: Key Name, Value Type, Default Value, and Value Description. We’re gonna bullet it out because we’re cute like that. πŸ’…

  • Key Name: device-handler
    • Value Type: string
    • Default Value: (blank)
    • Value Description: Name of the device-handler that will be invoked to add and delete the device for this connection. The name can only contain ASCII alphanumeric characters and '-', '_', '.'. It cannot start with '.'. See the NetworkManager-dispatcher(8) man page for more details about how to write the device handler. By setting this property the generic connection becomes "virtual", meaning that it can be activated without an existing device; the device will be created at the time the connection is started by invoking the device-handler. ✨

πŸ’… gsm setting πŸ’…

GSM-based Mobile Broadband Settings, bestie β€” this is the little cluster of keys that handles your cellular data vibes. πŸ“Άβœ¨

  • apn β€” string, default: (blank/unset). This is the GPRS Access Point Name, aka the thing that specifies the APN used when establishing a data session with the GSM-based network. The APN often determines how the user will be billed for their network usage and whether the user has access to the Internet or just a provider-specific walled-garden, so it is important to use the correct APN for the user's mobile broadband plan. The APN may only be composed of the characters a-z, 0-9, ., and - per GSM 03.60 Section 14.9.

If the APN is unset (the default) then it may be detected based on "auto-config" setting. The property can be explicitly set to the empty string to prevent that and use no APN. 🫢

  • auto-config β€” boolean, default: FALSE. When TRUE, the settings such as APN, username, or password will default to values that match the network the modem will register to in the Mobile Broadband Provider database. ✨
  • device-id β€” string, default: (blank). The device unique identifier (as given by the WWAN management service) which this connection applies to. If given, the connection will only apply to the specified device. πŸŽ€
  • device-uid β€” string, default: (blank). The device UID (as given by the WWAN management service) which this connection applies to. In contrast to device-id, which is an

...it's a property of the connected device itself β€” one that gets set by a UDEV-rule. So like, go read the "Common udev tags" -> "ID_MM_PHYSDEV_UID" documentation over in ModemManager, that's where the lore lives πŸ“–βœ¨. And the important bit: if you actually give this a value, the connection will only apply to the device you named. That's it. That one device. No sharing, no spilling over into anything else, periodt πŸ’….

  • home-only β€” boolean, default FALSE. When TRUE, the only connections allowed are to the home network. Connections to roaming networks? Not happening. Not even a little πŸš«πŸ“΅.
  • initial-eps-bearer-apn β€” string, no default. For LTE modems, this sets the APN for the initial EPS bearer that gets set up when you attach to the network. Heads up tho: setting this parameter implies initial-eps-bearer-configure is TRUE. It's giving package deal πŸŽ€.
  • initial-eps-bearer-configure β€” boolean, default FALSE. For LTE modems, this one decides whether the initial EPS bearer actually gets configured when the connection is brought up. And it gets inferred as TRUE if initial-eps-bearer-apn is set β€” so like, it'll flip itself on if you gave it the APN, iykyk ✨.
  • initial-eps-bearer-noauth β€” boolean, default TRUE. For LTE modems, this sets the NOAUTH authentication method for the initial EPS bearer that's set up when attaching to the network. If TRUE, don't require the other side to authenticate itself to the client. If FALSE, require authentication from the remote side. In almost all cases, this should be TRUE β€” like, genuinely, leave it alone bestie 🫢.
  • initial-eps-bearer-password β€” string, no default. For LTE modems, this sets the password for the initial EPS bearer that gets set up when attaching to the network. And same deal as the APN: setting this parameter implies initial-eps-bearer-configure is TRUE πŸ”.
  • initial-eps-bearer-password-flags β€” NMSettingSecretFlags (uint32), no default. Flags indicating how to handle the "initial-eps-bearer-password" property. It's the little handler for the password above πŸŽ€.
  • initial-eps-bearer-refuse-chap β€” boolean, default FALSE. For LTE modems, this disables the CHAP authentication method for the initial EPS bearer that gets set up when attaching to the network πŸ™…β€β™€οΈ.
  • initial-eps-bearer-refuse-eap β€” boolean, default FALSE. For LTE modems, this disables the EAP authentication method for the initial EPS bearer that...
  • initial-eps-bearer-refuse-mschap β€” boolean, defaults to FALSE. So for LTE modems πŸ‘‘ this one turns off the MSCHAP authentication method for the initial EPS bearer that gets set up when you attach to the network. Bye bye MSCHAP, bestie.
  • initial-eps-bearer-refuse-mschapv2 β€” boolean, defaults to FALSE. Same energy as above but for MSCHAPV2 β€” for LTE modems, this disables the MSCHAPV2 authentication method for the initial EPS bearer that is set up when attaching to the network. ✨
  • initial-eps-bearer-refuse-pap β€” boolean, defaults to FALSE. And the third sibling 🫢 β€” for LTE modems this disables the PAP authentication method for the initial EPS bearer that is set up when attaching to the network.
  • initial-eps-bearer-username β€” string, no default (empty). For LTE modems, this sets the username for the initial EPS bearer that is set up when attaching to the network. Big brain detail πŸ’…: setting this parameter implies initial-eps-bearer-configure is TRUE. Like, it just does that, no extra work from you.
  • mtu β€” uint32, defaults to 0. If it's non-zero, only transmit packets of the specified size or smaller β€” bigger packets get broken up into multiple frames. If it's 0, it's not doing that. Periodt. πŸŽ€
  • network-id β€” string, no default (empty). This is the Network ID (GSM LAI format, ie MCC-MNC) that forces a specific network registration. If the Network ID is specified, NetworkManager will attempt to force the device to register only on the specified network. Iconic use case 🌸: making sure the device doesn't roam when direct roaming control of the device isn't otherwise possible. Lowkey genius.
  • number β€” string, no default. Legacy setting that used to help establishing PPP data sessions for GSM-based modems. πŸ¦‹
This property is deprecated since version 1.16. User-provided values for this setting are no longer used. So like… it's giving historical artifact, ngl. πŸ’€
  • password β€” string, no default (empty). The password used to authenticate with the network, if required. Many providers don't require a password, or will accept any password (king behavior πŸ’œ) β€” but if a password is required, you specify it right here.
  • password-flags β€” NMSettingSecretFlags (uint32), no default. Flags that indicate how to handle the "password" property. Iykyk. πŸ”₯
  • pin β€” string, no default. If the SIM is locked with a PIN it must be unlocked before any other operations
  • pin β€” okay so this is just straight-up where the PIN goes 🫢 when the device is asking for one, you drop it here: "Specify the PIN here to allow operation of the device." That's it, that's the whole vibe.
  • pin-flags β€” NMSettingSecretFlags (uint32), no default listed β€” these are the little flags that tell everyone how to handle the pin property πŸ‘‘ (yes, the one right above, keep up bestie).
  • sim-id β€” string, no default β€” the SIM card's unique identifier, the way the WWAN management service hands it to you. And the way it works is so clean: if you set it, the connection applies to any device that's also allowed by device-id which contains a SIM card matching that identifier ✨
  • sim-operator-id β€” string, no default β€” this one's a MCC/MNC string, like "310260" or "21601", and it identifies the specific mobile network operator this connection applies to. Set it and the connection applies to any device also allowed by device-id and sim-id that's holding a SIM card provisioned by that operator πŸŽ€ (three-way match, fr fr, it's giving thorough)
  • username β€” string, no default β€” the username used to authenticate with the network, if it's required. And ngl, many providers don't require a username at all, or they'll just accept literally any username you throw at them 😭 but if one is required, this is where it goes πŸ’–

🌈 hsr setting 🌈

HSR/PRP Settings. Very specific, very niche, very iconic πŸ’…

  • interlink β€” string, no default β€” the optional interlink port name of the HSR interface πŸ¦‹
  • multicast-spec β€” uint32, default 0 β€” the last byte of the supervision address ✨
  • port1 β€” string, no default β€” the port1 interface name of the HSR. This property is mandatory. 🚨 like, you cannot skip it, bestie, it's not optional and it's not a vibe
  • port2 β€” string, no default β€” the port2 interface name of the HSR. Also mandatory. 🚨 both ports, no exceptions, periodt
  • protocol-version β€” int32, default -1 β€” configures the protocol version used for the HSR/PRP interface. Let me break this all the way down:
    • -1 (the default) sets the protocol version to the default version for the protocol πŸ’«
    • 0 (hsr-2010) sets it to HSRv0 (IEC 62439-3:2010) πŸ“Ό
    • 1 (hsr-2012) sets it to HSRv1 (IEC 62439-3:2012) πŸ”₯
  • prp β€” boolean, default FALSE β€” the protocol used by the interface, aka whether it's PRP or HSR. Choose your fighter πŸ₯Š

🌈 infiniband setting πŸ¦‹

okay so this is the InfiniBand corner of the settings universe and it has, like, five knobs total β€” but every single one of them matters, so buckle up bestie πŸ’…

  • mac-address β€” byte array, no default. If you actually set this, then the connection will only apply to the IPoIB device whose permanent MAC address matches. And listen β€” this property does not change the MAC address of the device. That means it is not MAC spoofing, it's just a very picky little matcher, mkay? πŸ™ˆ
  • mtu β€” uint32, default 0. If it's non-zero, then only transmit packets of the specified size or smaller β€” and larger packets get broken up into multiple frames. Zero means don't bother, we're not policing packet sizes today ✨
  • p-key β€” int32, default -1. The InfiniBand p-key to use for this device, periodt. A value of -1 means use the default p-key (aka "the p-key at index 0"). Otherwise it's a 16-bit unsigned integer, whose high bit 0x8000 is set if it's a "full membership" p-key. The values 0 and 0x8000 are not allowed β€” like, don't even try it πŸ’€

With the p-key set, the interface name is always "$parent.$p_key". Setting "connection.interface-name" to another name is not supported β€” no cap, it just won't work, so don't fight it 🫢

Note that the kernel will internally always set the full membership bit, even though the interface name does not reflect that. Lowkey sneaky of it, tbh. Usually the user would want to configure a full membership p-key with the 0x8000 flag set πŸ‘‘

  • parent β€” string, no default. The interface name of the parent device of this device. Normally NULL, but if the "p_key" property is set, then you must specify the base device by setting either this property or "mac-address" β€” pick one, bestie, you don't get to skip it 🌸
  • transport-mode β€” string, no default. The IP-over-InfiniBand transport mode. Either "datagram" or "connected" β€” those are your two choices and honestly both are iconic in their own way πŸ’–

πŸ¦‹ ipv4 setting

IPv4 Settings. Yes bestie, this is the whole IPv4 glow-up section β€” every key, every type, every default, presented in the order the daemon expects. Slay responsibly πŸ’…


  • address-data β€” array of vardict, no default listed πŸŽ€ Array of IPv4 addresses. Each address dictionary contains at least 'address' and 'prefix' entries, containing the IP address as a string, and the prefix length as a uint32. Additional attributes may also exist on some addresses.
  • addresses β€” array of array of uint32, no default listed. This one is deprecated in favor of the 'address-data' and 'gateway' properties, but it can still be used for backward-compatibility with older daemons. Heads up though:
    • Note that if you send this property the daemon will ignore 'address-data' and 'gateway'. Like, fully ignore them. It's giving "pick a lane" 😭
    • The value itself is an array of IPv4 address structures. Each IPv4 address structure is composed of 3 32-bit values; the first being the IPv4 address (network byte order), the second the prefix (1 - 32), and last the IPv4 gateway (network byte order).
    • The gateway may be left as 0 if no gateway exists for that subnet. 🫢
  • auto-route-ext-gw β€” NMTernary (int32), no default listed. VPN connections will default to add the route automatically unless this setting is set to FALSE.
    • For other connection types, adding such an automatic route is currently not supported, and setting this to TRUE has no effect. So don't come crying to me when nothing happens, it literally says so 😌
  • clat β€” int32, default -1. Controls the CLAT (Customer-side translator) functionality. CLAT is used to implement the client part of 464XLAT (RFC 6877), an architecture that provides IPv4 connectivity to hosts on IPv6-only networks. πŸ”₯
    • When CLAT is enabled, NetworkManager discovers the NAT64 prefix from IPv6 Router Advertisements; …

...if a NAT64 prefix is announced, NetworkManager installs a BPF program to do the stateless translation of packets between IPv4 and IPv6. like, it's out here translating for free, no state kept, no drama πŸ’…

So the values, bestie, listen up:

  • 0 (no) β€” completely disables CLAT. that's it, that's the whole vibe. gone. πŸ™ˆ
  • 1 (auto) β€” enables CLAT only when the IPv4 method is 'auto' and the device doesn't have a native IPv4 gateway. conditional queen πŸ‘‘
  • 2 (force) β€” enables CLAT even if the IPv4 method is not 'auto' and even if the device does have a native IPv4 gateway. no thoughts, just CLAT πŸ”₯

When it's set to -1 (default), the actual value gets looked up in the global configuration; if it's not specified there, it defaults to 0 (no). Heads up though: in the future, that default fall-back value is gonna change to 1 (auto). so like, don't get too attached to the current default, it's literally evolving ✨


πŸŽ€ dad-timeout πŸŽ€

  • Type: int32
  • Default: -1

This is the maximum timeout in milliseconds used to check whether duplicate IP addresses are chillin' on the network. If an address conflict gets detected β€” boom β€” the activation will fail. 😭 Also important: this property is currently implemented only for IPv4. IPv6 girlies, not your era yet.

The values, gorge:

  • 0 β€” no duplicate address detection at all. we simply don't check. living dangerously 🫢
  • -1 β€” the default value, which is either the value configured globally in NetworkManager.conf or 200ms.
  • anything greater than zero β€” that's your timeout, in milliseconds. ⏱️
ngl the time intervals are subject to randomization as per RFC 5227, so the actual duration can land anywhere between half and the full time you specified in this property. so if you set it and it feels shorter than you asked for... that's not a bug, that's the RFC being quirky πŸ’€

πŸ¦‹ dhcp-client-id πŸ¦‹

  • Type: string
  • Default: (empty)

A string that gets sent to the DHCP server to identify the local machine, which the DHCP server may then use to customize the DHCP lease and options. it's basically your little name tag at the DHCP party πŸŽ€

Here's the tea on how it gets interpreted:

  • When the property is a hex string ('aa:bb:cc'), it's interpreted as a binary client ID. In that case, the first byte is assumed to be the 'type' field as per RFC 2132 section 9.14, and the remaining bytes may be a hardware address β€” e.g. '01:xx:xx:xx:xx:xx:xx', where 1 is the Ethernet ARP type and the rest is a MAC address. cute, structured, iykyk ✨
  • If the property is not a hex string, it's considered as a non-hardware-address…

…client ID and the type field is set to 0. πŸŽ€

The special values "mac" and "perm-mac" are supported, and what they do is use the current or permanent MAC address of the device to generate a client identifier with type ethernet (01). Little heads-up though: currently these options only work for ethernet type of links. πŸ’…

The special value "ipv6-duid" uses the DUID from the ipv6.dhcp-duid property as an RFC4361-compliant client identifier. For the IAID it uses ipv4.dhcp-iaid and falls back to ipv6.dhcp-iaid if that's unset. πŸ¦‹

The special value "duid" generates an RFC4361-compliant client identifier based on ipv4.dhcp-iaid, and uses a DUID generated by hashing /etc/machine-id. ⭐

The special value "stable" is supported to generate a type 0 client identifier based on the stable-id (see connection.stable-id) and a per-host key. If you set the stable-id, you may want to include the ${DEVICE} or ${MAC} specifier so you get a per-device key. 🌸

The special value "none" prevents any client identifier from being sent. Note that this is normally not recommended. πŸ™ˆ (like, seriously, don't)

If unset, a globally configured default from NetworkManager.conf is used. And if it's still unset, the internal dhcp client will default to "mac". periodt.


  • dhcp-dscp (string) β€” specifies the value for the DSCP field (traffic class) of the IP header. When it's empty, the global default value is used; and if no global default is specified, it's assumed to be "CS0". Allowed values are: "CS0", "CS4" and "CS6". ✨
Heads up bestie: this property is currently valid only for IPv4, and it's supported only by the "internal" DHCP plugin. πŸ’€
  • dhcp-fqdn (string) β€” if the dhcp-send-hostname property is TRUE, then the specified FQDN will be sent to the DHCP server when

...acquiring a lease. This property and dhcp-fqdn are mutually exclusive and cannot be set at the same time β€” so like, pick one, bestie, you literally cannot have both πŸ’…


  • dhcp-hostname β€” string β€” (no default) β€” okay so if the dhcp-send-hostname property is TRUE, then the name you put here gets sent to the DHCP server when you're acquiring a lease ✨ This property and dhcp-fqdn are mutually exclusive and cannot be set at the same time β€” they're giving sworn enemies, it's one or the other fr fr πŸ™ˆ
  • dhcp-hostname-flags β€” uint32 β€” default 0 β€” the flags for the DHCP hostname and FQDN πŸŽ€

Currently this property only includes flags to control the FQDN flags set in the DHCP FQDN option. The supported FQDN flags are:

  • 0x1 (fqdn-serv-update)
  • 0x2 (fqdn-encoded)
  • 0x4 (fqdn-no-update)

When no FQDN flag is set and 0x8 (fqdn-clear-flags) is set, the DHCP FQDN option will contain no flag. Otherwise, if no FQDN flag is set and 0x8 (fqdn-clear-flags) is not set, the standard FQDN flags are set in the request: 0x1 (fqdn-serv-update), 0x2 (fqdn-encoded) for IPv4 and 0x1 (fqdn-serv-update) for IPv6 πŸ‘‘

And when this property is set to the default value 0x0 (none), a global default is looked up in NetworkManager configuration. If that value is unset or also 0x0 (none), then the standard FQDN flags described above are sent in the DHCP requests. It's giving "fallback queen" energy, she always has a backup plan πŸ’œ

  • dhcp-iaid β€” string β€” (no default) β€” a string containing the "Identity Association Identifier" (IAID) used by the DHCP client πŸ¦‹

The string can be a 32-bit number β€” either decimal, hexadecimal, or as colon separated hexadecimal numbers. Alternatively it can be set to the special values "mac", "perm-mac", "ifname" or "stable":

  • when set to "mac" (or "perm-mac"), the last 4 bytes of the current (or permanent) MAC address are used as the IAID 🌸
  • when set to "ifname", the IAID is computed by hashing the interface name ✨
  • the special value "stable" can be used to generate an IAID based on the stable-id (see connection.stable-id), …

The dhcp-iaid thing is basically a per-host key plus the interface name, that's the whole vibe. When the property is unset, the value from global configuration is used; and if literally no global default is set, then the IAID is assumed to be "ifname". 🫢

For DHCPv4, just so you know, the IAID is only used with ipv4.dhcp-client-id values duid and ipv6-duid to generate the client-id.

For DHCPv6 β€” heads up bestie β€” at the moment this property is only supported by the internal DHCPv6 plugin.

And the actually used DHCPv6 IAID for a currently activated interface is exposed in the lease information of the device. Slay, transparency. ✨

  • dhcp-ipv6-only-preferred β€” int32, default -1. Controls the IPv6-Only Preferred DHCPv4 option (option 108 - RFC 8925). Ngl this one's a whole saga, so buckle up:
    • When set to 1 (yes), the host adds the option to the parameter request list; if the DHCP server sends the option back, the host stops the DHCP client for the time interval specified in the option. Kinda iconic, it just dips. πŸ’…
    • Enable this feature if the host supports an IPv6-only mode, i.e. either all applications are IPv6-only capable or there is a form of CLAT (464XLAT) deployed. Both are valid entries to the club. πŸŽ€
    • If set to 2 (auto), the option is automatically turned on when the IPv6 method is auto and the connection profile has ipv4.clat set to yes or auto. If these two conditions are met, the host can operate in IPv6-only mode and therefore it is safe to disable DHCPv4 when the network also supports it. Auto-magic, we love to see it. 🌈
    • When set to -1 (default), the actual value is looked up in the global configuration; if not specified, it defaults to 2 (auto). Lowkey the most reasonable default ever.
    • If the connection has IPv6 method set to disabled, this property does not have effect and the IPv6-Only Preferred option is always disabled. Periodt, it's off, don't fight it. πŸ™ˆ
  • dhcp-reject-servers β€” array of string, default empty. Array of servers from which DHCP offers must be rejected. This…

like, the tail end of that one property β€” the whole point of it is that it's useful for avoiding a lease from misconfigured or rogue servers πŸ›‘οΈ no sketchy servers pulling up on you, periodt.

For DHCPv4, every single element has to be an IPv4 address, optionally followed by a slash and a prefix length (e.g. "192.168.122.0/24"). Slash-prefix optional, address not πŸ’….

heads up bestie β€” this property is currently not implemented for DHCPv6 😭 so don't come for it, it's just not there yet.
  • dhcp-send-hostname β€” boolean, default TRUE. Since 1.52 this property is deprecated and is only used as a fallback value for "dhcp-send-hostname-v2" if it's set to 'default'. And that fallback is literally only a thing to avoid breaking existing configurations β€” the new property is what you should be using from now on, fr fr. In other words: deprecated since version 1.52, use the new version of dhcp-send-hostname instead πŸ™ˆ.
  • dhcp-send-hostname-v2 β€” int32, default -1. If TRUE, a hostname is sent to the DHCP server when acquiring a lease. Some DHCP servers use this hostname to update DNS databases, essentially providing a static hostname for the computer ✨. If the "dhcp-hostname" property is NULL and this property is TRUE, the current persistent hostname of the computer is sent 🫢.

The default value is -1 (default). In this case the global value from NetworkManager configuration is looked up. If it's not set, the value from "dhcp-send-hostname", which defaults to TRUE, is used for backwards compatibility. In the future this will change and, in absence of a global default, it will always fallback to TRUE πŸ‘€ β€” so like, mark your calendars.

  • dhcp-send-release β€” NMTernary (int32), default cell is just blank/default-y. Whether the DHCP client will send RELEASE message when bringing the connection down πŸ“΄. The default value is -1 (default). When the default value is specified, then the global value from NetworkManager configuration is looked up, and if not set, it is considered as FALSE.
  • dhcp-timeout β€” int32, default 0. A timeout for a DHCP transaction in seconds ⏱️. If zero (the default), a globally configured default is used. If still unspecified, a device specific timeout is used (usually 45 seconds). So like, don't stress, something will time out eventually πŸ’€.
(finishing the property above real quick πŸ’…) β€” Set to 2147483647 (MAXINT32) for infinity.

✨ dhcp-vendor-class-identifier β€” string, default empty

This one's the Vendor Class Identifier DHCP option, aka option (60). If you ever need to sneak special characters into the data string you can escape them with C-style escapes β€” cute! β€” but bestie, listen: this property cannot contain nul bytes. Not a vibe, not allowed, no cap.

And the fallback chain is very main-character: if the per-profile value is unspecified (which is the default), a global connection default gets consulted. If it's still unspecified, the DHCP option just… doesn't get sent to the server. Ghosted. πŸ’€

🌸 dns β€” array of uint32, default empty

Array of IP addresses of DNS servers β€” but as network-byte-order integers, iykyk. Yes, as integers. That's the whole bit.

πŸ¦‹ dns-data β€” array of strings, default empty

Array of DNS name servers, and this is the glow-up that replaces the deprecated "dns" property. Obsessed. Each name server can also contain a DoT server name β€” so you get the encrypted-DNS realness for free. Periodt.

πŸŽ€ dns-options β€” array of string, default empty

Array of DNS options to be added to resolv.conf. Let's get into it πŸ‘‘

NULL means the options are unset and left at the default β€” in which case NetworkManager uses its own default options. And this is distinct from an empty list of properties, so don't conflate them, bestie, that's a different girl entirely.

The following options are directly added to resolv.conf:

  • "attempts"
  • "debug"
  • "edns0"
  • "inet6"
  • "ip6-bytestring"
  • "ip6-dotint"
  • "ndots"
  • "no-aaaa"
  • "no-check-names"
  • "no-ip6-dotint"
  • "no-reload"
  • "no-tld-query"
  • "rotate"
  • "single-request"
  • "single-request-reopen"
  • "timeout"
  • "trust-ad"
  • "use-vc"

See the resolv.conf(5) man page for a detailed description of these options β€” she's the source of truth, go read her. πŸ“–

In addition, NetworkManager supports the special options "_no-add-edns0" and "_no-add-trust-ad". These do not get added to resolv.conf β€” instead they're the little sabotage switches πŸ₯° that prevent the automatic addition of the options "edns0" and "trust-ad" when you're using caching DNS plugins (see below).

And one big caveat, please don't skip this: the "trust-ad" setting is only honored if the profile actually contributes name servers to resolv.conf, and if all contributing profiles have "trust-ad" enabled. All of them. Unanimous or nothing, diva rules. πŸ’…

  • ✨ and heads up, bestie: when you're using a caching DNS plugin (dnsmasq or systemd-resolved in NetworkManager.conf), then "edns0" and "trust-ad" get added for you automatically β€” no cap, they just show up β€” unless "_no-add-edns0" and "_no-add-trust-ad" are present. So those two little guys are your opt-out tickets 🎟️

  • dns-priority (int32) β€” default 0 β€” this one's the DNS servers priority setting, and it's giving main character energy in the resolution department πŸ‘‘

So here's the vibe: it's the relative priority for DNS servers specified by this setting. And the twist? A lower numerical value is better (higher priority). Yes, bestie, smaller number = bigger deal, it's giving golf scores β›³

Negative values have the special effect of excluding other configurations with a greater numerical priority value β€” so if there's at least one negative priority in the mix, only DNS servers from connections with the lowest priority value will be used. Periodt. And if you want to avoid all DNS leaks, set the priority of the profile that should be used to the most negative value of all active connections profiles πŸ”’ (yes, dramatic, but that's literally what it says)

0 selects a globally configured default value. And if the latter is missing or zero too? It defaults to 50 for VPNs (including WireGuard) and 100 for other connections πŸ’…

ngl, super important to know: the priority is to order DNS settings for multiple active connections. It does not disambiguate multiple DNS servers within the same connection profile. Don't come for it for something it doesn't do πŸ™ˆ

When multiple devices have configurations with the same priority, VPNs will be considered first, then devices with the best (lowest metric) default route and then all other devices. Ranking goes hard πŸ†

When using dns=default, servers with higher priority will be on top of resolv.conf. And to prioritize a given server over another one within the same connection, just specify them in the desired order β€” that's it, that's the whole trick ✨ Note that commonly the resolver tries name servers in /etc/resolv.conf in the order listed, proceeding with the next server in the list on failure. See for example the "rotate" option of the dns-options setting πŸŒ€ And if there are any negative DNS priorities, then only name servers from the devices with that lowest priority will be considered.

When using a DNS resolver that supports Conditional Forwarding or Split DNS (with dns=dnsmasq or dns=systemd-resolved

...and like, before we get into it, bestie, the TL;DR of what that last bit was saying: each connection is used to query domains in its search list. The search domains decide which name servers to ask, and the DNS priority is what prioritizes name servers based on the domain. Queries for domains that aren't present in any search list get routed through connections that have the '~.' special wildcard domain β€” which is added automatically to connections with the default route (or you can add it manually, no pressure πŸ’…). When multiple connections specify the same domain, the one with the best priority (lowest numerical value) wins. Okay and here's the nuanced part, so pay attention 🫢 if a sub domain is configured on another interface, it will be accepted regardless of priority β€” unless the parent domain on the other interface has a negative priority, which causes the sub domain to be shadowed. With Split DNS you can avoid undesired DNS leaks by properly configuring DNS priorities and the search domains, so that only name servers of the desired interface are configured. Slay, no leaks, periodt. ✨


dns-search</p>

  • Type: array of string
  • Default: (none listed)

List of DNS search domains, bestie. Domains starting with a tilde ('~') are considered 'routing' domains and are used only to decide the interface over which a query must be forwarded β€” they are not used to complete unqualified host names. iykyk. 🌸

When you're using a DNS plugin that supports Conditional Forwarding or Split DNS, the search domains specify which name servers to query. This makes the behavior different from running with plain /etc/resolv.conf. For more info, also peep the dns-priority setting. πŸ‘€

When set on a profile that also enabled DHCP, the DNS search list received automatically (option 119 for DHCPv4 and option 24 for DHCPv6) gets merged with the manual list. You can prevent that by setting "ignore-auto-dns". And note β€” if no DNS searches are configured, the fallback will be derived from the domain from DHCP (option 15). literally so much happening, stay with me πŸŽ€


forwarding

  • Type: int32
  • Default: -1

Whether to configure the sysctl interface-specific forwarding. When enabled, the interface will act as a router to forward the packet from one interface to another. When set to -1 (default), the value

  • forwarding (int32) β€” so this one defaults to whatever your global config says; if there's no global default defined, 2 (auto) gets used instead. Ngl there's a little catch: the "forwarding" property is ignored when "method" is set to "shared", because forwarding is always enabled in that case. Periodt.

The accepted values, bestie, are literally:

  • -1 (default): use the global default.
  • 0 (no): disabled.
  • 1 (yes): enabled.
  • 2 (auto): enable if any shared connection is active, use the kernel default otherwise.
  • gateway (string, no default) β€” the gateway associated with this configuration. Heads up though: this is only meaningful if addresses are also set on the device. 🫢

Setting the gateway causes NetworkManager to configure a standard default route with the gateway as next hop. It gets ignored if "never-default" is set. An alternative (iykyk) is to configure the default route explicitly with a manual route and /0 as prefix length.

Note that the gateway usually conflicts with routing that NetworkManager configures for WireGuard interfaces, so usually it should not be set in that case. See "ip4-auto-default-route". πŸ’€
  • ignore-auto-dns (boolean, default: FALSE) β€” when "method" is set to "auto" and this property is TRUE, all those automatically configured name servers and search domains get ignored πŸ™ˆ, and only the name servers and search domains you specified in the "dns" and "dns-search" properties (if any) are used.
  • ignore-auto-routes (boolean, default: FALSE) β€” same vibe, but for routes: when "method" is set to "auto" and this is TRUE, the automatically configured routes are ignored and only the routes specified in the "routes" property (if any) get used. ✨
  • link-local (int32, default: 0) β€” enable/disable the IPv4 link-local configuration independently of the ipv4.method configuration. Lowkey iconic: this lets a link-local address (169.254.x.y/16) be obtained in addition to other addresses, like the ones you manually configured or got from a DHCP server. πŸŽ€

When set to "auto", the value is dependent on "ipv4.method". When set to "default", it honors the global connection default, before falling back to "auto". Note that if "ipv4.method" is "disabled", then link

(picking up right where we left off on the previous property β€” she's still talking, bestie πŸ’–)

…and local addressing is always disabled too. The default is "default". Since 1.52, when set to "fallback", a link-local address is obtained if no other IPv4 address is set. slay for the fallback girlies πŸ™ˆ


  • may-fail β€” boolean, default TRUE. Okay so if this is TRUE, the whole overall network configuration is allowed to keep going even if the config that this property is on straight-up times out 😭. But β€” and this is the important part β€” at least one IP configuration has to succeed, otherwise the overall network configuration still fails. Like, sis, the vibes can be forgiving but not that forgiving πŸ’…. Example time: in IPv6-only networks, setting this property to TRUE on the NMSettingIP4Config lets the overall network configuration succeed if IPv4 config fails but IPv6 config completes successfully. teamwork, no cap ✨
  • method β€” string, no default listed. This is the IP configuration method, the main character of the whole thing πŸ‘‘. NMSettingIP4Config and NMSettingIP6Config both support "disabled", "auto", "manual", and "link-local". For other values, go check the subclass-specific documentation, iykyk πŸ“–. In general, for the "auto" method, properties such as "dns" and "routes" specify information that is added on to the information returned from automatic configuration. The "ignore-auto-routes" and "ignore-auto-dns" properties modify this behavior β€” they're the little gremlins that tweak the vibe check 🧚. For methods that imply no upstream network, such as "shared" or "link-local", these properties must be empty. Empty. Not optional. fr fr, don't test it πŸ’€ For IPv4 method "shared", the IP subnet can be configured by adding one manual IPv4 address, or otherwise 10.42.x.0/24 is chosen. And note this (it trips people up constantly): the shared method must be configured on the interface which shares the internet to a subnet, not on the uplink which is shared. wrong interface = no internet for anybody 😭
  • never-default β€” boolean, default FALSE. If TRUE, this connection will never be the default connection for this IP type, which means it will never be assigned the default route by NetworkManager. she's a supporting character, not the lead 🌸
  • replace-local-rule β€” NMTernary (int32), no default listed. Connections will default to keep the autogenerated priority 0 local rule unless this setting is set to TRUE. the autogenerated rule stays put unless you explicitly say otherwise 🫢
  • required-timeout β€” int32, default -1. The minimum time interval in milliseconds for which dynamic IP configuration should be tried before the connection succeeds. give it a little patience window, babe ⏳

...and lowkey that's the whole point of it: this property is useful, for example, if both IPv4 and IPv6 are enabled and are allowed to fail. Normally the connection succeeds as soon as one of the two address families completes β€” but by setting a required timeout for e.g. IPv4, you can ensure that even if IPv6 succeeds earlier than IPv4, NetworkManager waits some time for IPv4 before the connection becomes active. πŸ’…

Heads up bestie: note that if "may-fail" is FALSE for the same address family, this property has no effect, because NetworkManager needs to wait for the full DHCP timeout. No skipping that line, it's the whole vibe check. 🫢

And the numbers: a zero value means that no required timeout is present, and -1 means the default value (either the configuration ipvx.required-timeout override or zero).


🌈 route-data 🌈

Type: array of vardict

It's an array of IPv4 routes, and literally each route dictionary contains at least 'dest' and 'prefix' entries β€” 'dest' holding the destination IP address as a string, and 'prefix' holding the prefix length as a uint32. ✨

Most routes will also have a 'next-hop' entry, containing the next hop IP address as a string. If the route has a 'metric' entry (containing a uint32), that will be used as the metric for the route β€” otherwise NM will pick a default value appropriate to the device. Additional attributes may also exist on some routes. πŸ‘‘


πŸ¦‹ route-metric πŸ¦‹

Type: int64 Β· Default: -1

This is the default metric for routes that don't explicitly specify a metric. The default value -1 means that the metric is chosen automatically based on the device type. πŸŽ€

The metric applies to dynamic routes, manual (static) routes that don't have an explicit metric setting, address prefix routes, and the default route.

And now the iconic little caveat, iykyk: note that for IPv6, the kernel accepts zero (0) but coerces it to 1024 (user default). Hence, setting this property to zero effectively mean setting it to 1024. For IPv4, zero is a regular value for the metric. πŸ’€


🧚 route-table 🧚

Type: uint32 Β· Default: 0

Enable policy routing (source routing) and set the routing table used when adding routes. Slay. ✨

This affects all routes, including device-routes, IPv4LL, DHCP, SLAAC, default-routes and static routes. But note that static routes can individually overwrite the setting by explicitly specifying a non-zero

Okay so picking right back up on the <pink>table</pink> situation πŸ’… β€” if the table setting is left at zero, it's eligible to be overwritten via global configuration. And if the property is still zero even after applying the global configuration value? Then policy routing is disabled for the address family of this connection, periodt.

And what does "policy routing disabled" even mean, bestie? It means NetworkManager will add all routes to the main table β€” except static routes that explicitly configure a different table. Also (and this is the important bit) NetworkManager will not delete any extraneous routes from tables other than the main table. Why? Backward compatibility, babes β€” for users who manage routing tables outside of NetworkManager. Protecting the legacy vibes 🫢


  • routed-dns β€” type int32, default -1. Whether to add routes for DNS servers. When it's enabled, NetworkManager adds a route for each DNS server that's associated with this connection, whether it's defined statically (i.e. in the connection profile) or dynamically (like, retrieved via DHCP, yk). That route guarantees the DNS server is reached via this interface πŸ™Œ When it's set to -1 (the default), the value from global configuration is used; and if there's no global default defined, this feature is just disabled. No route, no drama.
  • routes β€” type array of array of uint32. ⚠️ Deprecated in favor of the route-data property, but it can still be used for backward-compatibility with older daemons. Note β€” and this is the tea 🍡 β€” if you send this property, the daemon will ignore route-data. It's an array of IPv4 route structures, and each IPv4 route structure is composed of 4 32-bit values:
    1. the destination IPv4 network or address (network byte order)
    2. the destination network or address prefix (1 - 32)
    3. the next-hop (network byte order) if any
    4. the route metric

If the metric is 0, NM will choose an appropriate default metric for the device. (And ngl, there is no way to explicitly specify an actual metric of 0 with this property. Zero means "you pick, king" πŸ‘‘)

  • routing-rules β€” type array of 'a{sv}'. Array of dictionaries for routing rules. Each routing rule supports the following options: action (y), dport-end (q), dport-start (q), family (i), from (s), from-len (y), fwmark (u), fwmask (u), iifname (s), invert (b), ipproto (s), oifname

...and that wraps up the property list, ending on range-end (u), range-start (u). β€” like, that's the whole roster, bestie, no more hiding in the table πŸŽ€


  • shared-dhcp-lease-time (int32, default 0) β€” okay so this one lets you set a custom DHCP lease time for the shared connection method, measured in seconds ⏱️. The value should be a number between 120 and 31536000 (that's one year, iykyk). If you don't specify this option at all, 3600 (one hour) is used β€” the humble default, living its life.

Now the special values, because there are literally two and they're important:

  • 0 β†’ gives you the default value of 1 hour
  • 2147483647 (MAXINT32) β†’ infinite lease time, no cap, main character energy πŸ‘‘
  • shared-dhcp-range (string, default empty) β€” this one lets you specify a custom DHCP range for the shared connection method πŸ’…. The value is expected to be in <START_ADDRESS>,<END_ADDRESS> format β€” yes, with the comma, exactly like that, keep it in backticks and don't get creative.

The range should be part of the network set by the ipv4.address option, and it should not contain the network address or the broadcast address 🚫 β€” those two are not invited to the party.

If you don't specify this option, the DHCP range gets automatically determined based on the interface address, and honestly the algorithm is kind of iconic:

  • the range is selected to be adjacent to the interface address β€” either before it or after it
  • the larger possible range is preferred (obvi, bigger is better)
  • the range gets adjusted to fill the available address space
  • except for networks with a prefix length greater than 24, which will be treated as if they have a prefix length of 24 πŸ™ˆ

So yeah, tiny subnets get the prefix-24 treatment whether they like it or not. No cap.

🌸 ipv6 setting 🌸

okay so this is the whole IPv6 corner of the settings, and it's genuinely giving main character energy πŸ’… everything about how your IPv6 addresses get built lives right here.

  • addr-gen-mode β€” int32, default 3. This one configures the method for creating the IPv6 interface identifier of addresses β€” and it covers both RFC4862 IPv6 Stateless Address Autoconfiguration and IPv6 Link Local. so like, both of the big ones, no cap.

The permitted values are:

  • 0 (eui64)
  • 1 (stable-privacy)
  • 2 (default-or-eui64)
  • 3 (default)

✨ If the property is set to "eui64", the addresses will be generated using the interface token derived from the hardware address. The way this works: the host part of the address stays constant, which makes it possible to track the host's presence when it changes networks πŸ‘€ (iykyk). But β€” the address changes when the interface hardware is replaced. And if a duplicate address is detected, there is no fallback to generate another address. πŸ’€ rough. When configured, the "ipv6.token" is used instead of the MAC address to generate addresses for stateless autoconfiguration. slay.

πŸ¦‹ If the property is set to "stable-privacy", the interface identifier is generated as specified by RFC7217. This works by hashing a host specific key (see NetworkManager(8) manual), the interface name,

okay so this is still the tail end of that addr-gen-mode description and it's actually kind of a big deal, so let's get into it 🫢

  • the whole point: this ties the generated address to the connection's connection.stable-id property plus the address prefix. and like β€” that's genuinely a slay for privacy πŸ”₯ because it makes it way harder for anyone to use the address to track whether the host is around, since every prefix and every network gets a different identifier. also the address stays stable when the network interface hardware gets replaced, which is lowkey the best part πŸ’…

the special values, bestie ✨

  • "default" and "default-or-eui64" β€” these two don't do anything spicy on their own, they fall back to the global connection default, exactly as documented over in the NetworkManager.conf(5) manual πŸ“–
  • if that global default is not specified? then the fallback value is "stable-privacy" or "eui64", respectively. yep, in that order, matching those two special values πŸŽ€

defaults per backend (this part is a whole mood) 🌈

  • libnm β€” the property defaults to "default" since 1.40. before that it used to default to "stable-privacy". character development fr πŸ’€
  • D-Bus β€” if the addr-gen-mode setting is just... absent? that equals "default". no cap πŸ¦‹
  • keyfile plugin β€” when the setting isn't there on disk, that means "default-or-eui64", and the reason is genuinely thoughtful: so the property doesn't change on upgrade from older versions 😭🫢
okay important note, don't skip this one πŸ‘‘ β€” this setting is distinct from the Privacy Extensions as configured by the "ip6-privacy" property, and it does not affect the temporary addresses configured with this option. two totally different things, don't mix them up πŸ™ˆ

  • address-data β€” type: array of vardict Β· no default πŸ’…

Array of IPv6 addresses. Each address dictionary contains at least 'address' and 'prefix' entries, containing the IP address as a string, and the prefix length as a uint32. Additional attributes may also exist on some addresses. iykyk, the extra attrs are just ✨bonus lore✨.

  • addresses β€” type: array of legacy IPv6 address struct (a(ayuay)) Β· no default
🚨 Deprecated in favor of the 'address-data' and 'gateway' properties, but this can be used for backward-compatibility with older daemons.

Note that if you send this property the daemon will ignore 'address-data' and 'gateway'. Array of IPv6 address structures. Each IPv6 address structure is composed of an IPv6 address, a prefix length (0 - 128), and an IPv6 gateway address. The gateway may be zeroed out if no gateway exists for that subnet. fr fr, this one is the grandma option β€” still works, but she's been around a while 🫢

  • auto-route-ext-gw β€” type: NMTernary (int32) Β· no default

VPN connections will default to add the route automatically unless this setting is set to FALSE.

For other connection types, adding such an automatic route is currently not supported and setting this to TRUE has no effect. πŸ’€ not you trying to make it work for every connection type.

  • dad-timeout β€” type: int32 Β· default: -1

Maximum timeout in milliseconds used to check for the presence of duplicate IP addresses on the network. If an address conflict is detected, the activation will fail. The property is currently implemented only for IPv4. 😭 IPv6 girlies, sit this one out.

A zero value means that no duplicate address detection is performed, -1 means the default value (either the value configured globally in NetworkManager.conf or 200ms). A value greater than zero is a timeout in

...in milliseconds. Lowkey important tho β€” the time intervals are subject to randomization as per RFC 5227, so the actual duration can literally land anywhere between half and the full time you specified in this property. So don't come for me if it's not exact, bestie 🫢

  • dhcp-dscp (string) β€” sets the value for the DSCP field (traffic class) of the IP header ✨ When it's empty, the global default value is used; and if there's no global default specified either, it's assumed to be "CS0". Allowed values are: "CS0", "CS4" and "CS6".
Heads up: this property is currently valid only for IPv4, and it's only supported by the "internal" DHCP plugin. Iykyk πŸ’…
  • dhcp-duid (string) β€” a string holding the DHCPv6 Unique Identifier (DUID) that the dhcp client uses to identify itself to DHCPv6 servers (RFC 3315). The DUID gets carried in the Client Identifier option 🌸 If the property is a hex string ('aa:bb:cc'), it's interpreted as a binary DUID and filled in as an opaque value in the Client Identifier option. Periodt.

The special value "lease" will retrieve the DUID previously used, from the lease file belonging to the connection. And if no DUID is found? A global and permanent DUID-UUID (RFC 6355) will be generated based on the machine-id. Slay, automatic πŸ’–

The special values "llt" and "ll" will generate a DUID of type LLT or LL (see RFC 3315) based on the current MAC address of the device. So that you can try to provide a stable DUID-LLT, the time field will contain a constant timestamp β€” one that's used globally (for all profiles, yes, all of them πŸ‘‘) and persisted to disk.

The special values "stable-llt", "stable-ll" and

So, "stable-uuid" will generate a DUID of the corresponding type, derived from the connection's stable-id and a per-host unique key. You may want to include the ${DEVICE} or ${MAC} specifier in the stable-id, in case this profile gets activated on multiple devices. That means the link-layer address of "stable-ll" and "stable-llt" will be a generated address derived from the stable id. The DUID-LLT time value in the "stable-llt" option will be picked among a static timespan of three years β€” and yes, the upper bound of the interval is the same constant timestamp used in "llt" ✨

When the property is unset, the global value provided for ipv6.dhcp-duid is used. If no global value is provided, the default "lease" value is assumed. Cute, consistent, no chaos πŸ’…


  • dhcp-hostname β€” string β€” default: (blank). If the dhcp-send-hostname property is TRUE, then the specified name will be sent to the DHCP server when acquiring a lease. This property and dhcp-fqdn are mutually exclusive and cannot be set at the same time. 🫢
Bestie, mutual exclusion means pick one. Do not try to set both and act surprised. The manpage said what it said πŸ’€
  • dhcp-hostname-flags β€” uint32 β€” default 0. Flags for the DHCP hostname and FQDN.

Currently, this property only includes flags to control the FQDN flags set in the DHCP FQDN option. Supported FQDN flags are 0x1 (fqdn-serv-update), 0x2 (fqdn-encoded) and 0x4 (fqdn-no-update). When no FQDN flag is set and 0x8 (fqdn-clear-flags) is set, the DHCP FQDN option will contain no flag. Otherwise, if no FQDN flag is set and 0x8 (fqdn-clear-flags) is not set, the standard FQDN flags are set in the request: 0x1 (fqdn-serv-update),

...and honestly bestie, the flag options are specific: 0x2 (fqdn-encoded) is the one for IPv4, and 0x1 (fqdn-serv-update) is the one for IPv6. Slay, but also: pay attention to which is which πŸ”₯

When this property is sitting at the default value 0x0 (none), NetworkManager goes and looks up a global default in its configuration. And if that value is unset, or is also 0x0 (none)? Then the standard FQDN flags described above get sent out in the DHCP requests. Periodt β€” that's the fallback chain, no cap πŸ’…

  • dhcp-iaid β€” string. This one's a string holding the "Identity Association Identifier" (IAID) that the DHCP client uses πŸŽ€ And the string is flexible like that: it can be a 32-bit number (decimal, hexadecimal, or colon separated hexadecimal numbers β€” pick your fighter ✨). Or! It can be one of the special values "mac", "perm-mac", "ifname" or "stable". Here's the tea on each πŸ“:
    • Set it to "mac" (or "perm-mac") and the last 4 bytes of the current (or permanent) MAC address get used as the IAID. The way that just works πŸ’«
    • Set it to "ifname" and the IAID is computed by hashing the interface name.
    • The special value "stable" can be used to generate an IAID based on the stable-id (see connection.stable-id), a per-host key and the interface name β€” iconic combo, tbh πŸ‘‘

When the property is unset, the value from global configuration is used; and if no global default is set, then the IAID is assumed to be "ifname". Defaults on defaults, we love a safety net 🫢

For DHCPv4, the IAID is only used with "ipv4.dhcp-client-id" values "duid" and "ipv6-duid" to generate the client-id. That's the whole vibe β€” no duid, no IAID moment πŸ’€

For DHCPv6, note that at the moment this property is only supported by the "internal" DHCPv6 plugin. Just the internal one, bestie, don't come for me πŸ™ˆ

The actually used DHCPv6 IAID for a currently activated interface is exposed in the lease information of the...

  • dhcp-pd-hint β€” type: string; default: (blank in the table). Okay so this one is an IPv6 address followed by a slash and a prefix length. If you set it, the value gets sent to the DHCPv6 server as a hint for the prefix delegation (IA_PD) we want to receive. To hint only a prefix length without a prefix, set the address part to the zero address, like "::/60". slay ✨
  • dhcp-reject-servers β€” type: array of string; default: (blank in the table). This is an array of servers whose DHCP offers must be rejected. It's useful for avoiding a lease from misconfigured or rogue servers β€” vibe check: denied πŸ’…. For DHCPv4, each element must be an IPv4 address, optionally followed by a slash and a prefix length (e.g. "192.168.122.0/24"). This property is currently not implemented for DHCPv6.
  • dhcp-send-hostname β€” type: boolean; default: TRUE. Since 1.52 this property is deprecated and is only used as a fallback value for "dhcp-send-hostname-v2" if it's set to 'default'. This is only done to avoid breaking existing configurations, so the new property should be used from now on. This property is deprecated since version 1.52.use the new version of dhcp-send-hostname instead. ngl, it's giving legacy behavior πŸŽ€
  • dhcp-send-hostname-v2 β€” type: int32; default: -1. If TRUE, a hostname is sent to the DHCP server when acquiring a lease. Some DHCP servers use this hostname to update DNS databases, essentially providing a static hostname for the computer. If the "dhcp-hostname" property is NULL and this property is TRUE, the current persistent hostname of the computer is sent. The default value is -1 (default). In this case

…so the global value from NetworkManager configuration gets looked up πŸ’–. And if that's not set? Then the value from "dhcp-send-hostname" β€” which defaults to TRUE β€” is used for backwards compatibility. And heads up, bestie: in the future this will change, and in absence of a global default it'll always fallback to TRUE. Mark your calendars, iykyk πŸ—“οΈβœ¨

  • dhcp-send-release β€” type NMTernary (int32), no default listed in the table. This is literally about whether the DHCP client will send a RELEASE message when bringing the connection down 🫢. Its default value is -1 (default). And when that default value is specified, the global value from NetworkManager configuration is looked up; if it's not set, it is considered as FALSE. No vibes, just booleans 😌
  • dhcp-timeout β€” type int32, default 0. A timeout for a DHCP transaction, in seconds ⏱️. If it's zero (the default), a globally configured default is used. And if that's still unspecified, a device specific timeout is used (usually 45 seconds). Set it to 2147483647 (MAXINT32) if you want infinity β€” go big or go home πŸ’…πŸ”₯
  • dns β€” type array of byte array, no default. An array of IP addresses of DNS servers (in network byte order) πŸ“‘. Yes, raw bytes. She's vintage like that πŸ™ˆ
  • dns-data β€” type array of strings, no default. An array of DNS name servers. This one replaces the deprecated "dns" property β€” out with the old, in with the new ✨. Each name server can also contain a DoT server name, which is lowkey kind of iconic πŸ”πŸ‘‘
  • dns-options β€” type array of string, no default. An array of DNS options to be added to resolv.conf πŸ“.

Quick mental note on this one: NULL means the options are unset and left at the default. In that case NetworkManager will use default options. And this is distinct from an empty list of properties β€” so don't come for NULL and empty like they're the same thing, they are NOT πŸ‘πŸ’€

The following options are directly added to resolv.conf: "attempts", "debug", "edns0", "inet6", "ip6-bytestring",

Okay so for the values inside dns-options, the resolv.conf-style menu is: "ip6-dotint", "ndots", "no-aaaa", "no-check-names", "no-ip6-dotint", "no-reload", "no-tld-query", "rotate", "single-request", "single-request-reopen", "timeout", "trust-ad", and "use-vc". The resolv.conf(5) man page has the full detailed description of these options, iykyk ✨.

In addition, NetworkManager supports the special options "_no-add-edns0" and "_no-add-trust-ad". They are not added to resolv.conf, and they can be used to prevent the automatic addition of options "edns0" and "trust-ad" when using caching DNS plugins (see below πŸ‘‡).

The "trust-ad" setting is only honored if the profile contributes name servers to resolv.conf, and if all contributing profiles have "trust-ad" enabled. No halfsies, bestie πŸ’….

When using a caching DNS plugin (dnsmasq or systemd-resolved in NetworkManager.conf) then "edns0" and "trust-ad" are automatically added, unless "_no-add-edns0" and "_no-add-trust-ad" are present.

  • dns-priority β€” type int32, default 0. DNS servers priority.

The relative priority for DNS servers specified by this setting. A lower numerical value is better (higher priority) πŸ”₯.

Negative values have the special effect of excluding other configurations with a greater numerical priority value; so in presence of at least one negative priority, only DNS servers from connections with the lowest priority value will be used. To avoid all DNS leaks, set the priority of the profile that should be used to the most negative value of all active connections profiles. Dramatic but important. 🫢

Zero selects a globally configured default

...value, bestie. And if that one's missing or zero too? It defaults to 50 for VPNs (WireGuard totally counts) and 100 for every other connection. πŸ’…

Quick vibe check though β€” this priority is only there to order your DNS settings across multiple active connections. It does not disambiguate multiple DNS servers sitting inside the same connection profile. That's a different thing entirely, iykyk. 🫢

When multiple devices have configs rocking the same priority, here's the order of who gets picked first:

  1. VPNs β€” they go first, always. πŸ‘‘
  2. Then devices with the best (lowest metric) default route.
  3. Then all the other devices.

So yeah, VPN girlies stay winning.

When you're using dns=default, servers with higher priority get placed on top of resolv.conf. And if you want to prioritize one server over another within the same connection? Just specify them in the order you want them, periodt. ✨

Small note that lowkey matters: commonly, the resolver tries name servers in /etc/resolv.conf in the order they're listed, and it moves on to the next server in the list on failure. See for example the "rotate" option of the dns-options setting. 🌸

Heads up: if there are any negative DNS priorities, then only name servers from the devices with that lowest priority will be considered. Like, that's it. That's the whole list. πŸ’€

Now, when you're using a DNS resolver that supports Conditional Forwarding or Split DNS (that's with the dns=dnsmasq or dns=systemd-resolved settings), each connection is used to query domains in its search list. The search domains are what determine which name servers to ask, and the DNS priority is what prioritizes name servers based on the domain. πŸ¦‹

Queries for domains that aren't present in any search list get routed through connections having the '~.' special wildcard domain β€” that one's added automatically to connections with the default route (or you can add it manually, no biggie). And when multiple connections specify the same domain, the one with the best priority (lowest numerical value) wins. πŸŽ€

If a sub domain is

...configured on another interface, it still gets accepted regardless of priority β€” unless the parent domain on that other interface has a negative priority, which causes the sub domain to be shadowed πŸ’€. With Split DNS you can dodge those undesired DNS leaks by properly configuring DNS priorities and the search domains, so that only the name servers of the interface you actually want are configured. No sneaky leaks, bestie πŸ•΅οΈβ€β™€οΈ

  • dns-search β€” array of string, no default. It's the list of DNS search domains ✨ Domains that start with a tilde (~) are considered 'routing' domains β€” they're used only to decide which interface a query must be forwarded over, and they are not used to complete unqualified host names. iykyk πŸŽ€

When you're using a DNS plugin that supports Conditional Forwarding or Split DNS, the search domains specify which name servers to query. That makes the behavior different from running with plain /etc/resolv.conf β€” not me making the rules, that's just how it is πŸ™ˆ For more info, see also the dns-priority setting.

When it's set on a profile that also enabled DHCP, the DNS search list received automatically (option 119 for DHCPv4 and option 24 for DHCPv6) gets merged with the manual list. You can prevent that by setting "ignore-auto-dns". Also note: if no DNS searches are configured, the fallback will be derived from the domain from DHCP (option 15). Free real estate, lowkey 🌸

  • forwarding β€” int32, default -1. This one's about whether to configure the sysctl interface-specific forwarding πŸ› οΈ When enabled, the interface will act as a router and forward the packet from one interface to another. Main character router energy, fr fr πŸ‘‘

When set to -1 (the default), the value from the global configuration is used; if no global default is defined, 2 (auto) will be used. And heads up 🚨 the "forwarding" property is ignored when "method" is set to "shared", because

...and honestly? forwarding is always on in this case, no take-backs. The accepted values are:

  • -1 (default): use global default.
  • 0 (no): disabled.
  • 1 (yes): enabled.
  • 2 (auto): enable if any shared connection is active, use kernel default otherwise.

  • gateway (string, default: nothing set) β€” the gateway that goes with this configuration, bestie. Heads up though: it's only meaningful if addresses are also set on the device. When you set the gateway, NetworkManager goes ahead and configures a standard default route with that gateway as the next hop. Lowkey important: this whole thing is ignored if "never-default" is set. If you want the other route (pun fully intended πŸ›£οΈ), you can configure the default route explicitly with a manual route and /0 as the prefix length instead.
Ngl, the gateway usually conflicts with the routing that NetworkManager configures for WireGuard interfaces, so in that case you should usually not set it. Go look at "ip4-auto-default-route" instead. πŸ’…
  • ignore-auto-dns (boolean, default FALSE) β€” okay so when "method" is set to "auto" and you flip this to TRUE, all those automatically configured name servers and search domains get ignored, and only the name servers and search domains you specified in the "dns" and "dns-search" properties (if you set any) get used. Very "I don't want your suggestions, I have my own" energy πŸ™ˆ.
  • ignore-auto-routes (boolean, default FALSE) β€” same vibe, but for routes: when "method" is set to "auto" and this is TRUE, the automatically configured routes are ignored and only the routes you specified in the "routes" property (if any) get used. Slay, manual control 😌.
  • ip6-privacy (NMSettingIP6ConfigPrivacy, i.e. int32, default: nothing set) β€” this one configures IPv6 Privacy Extensions for SLAAC, as described in RFC4941. If it's enabled, it makes the kernel generate a temporary IPv6 address in addition to the public one that gets generated from the MAC address via modified EUI-64. It enhances privacy ✨ but could cause problems in some applications, on the other hand. The…

...so yeah, those are the permitted values, bestie, and like β€” memorize them:

  • -1 β€” unknown πŸ™ˆ
  • 0 β€” disabled
  • 1 β€” enabled (prefer public address)
  • 2 β€” enabled (prefer temporary addresses)

Having a per-connection setting set to "-1" (that's the default, btw) means fallback to global configuration "ipv6.ip6-privacy". And if that's also unspecified or set to "-1", it falls back to reading /proc/sys/net/ipv6/conf/default/use_tempaddr. It's fallbacks all the way down, iykyk πŸ’…

Note that this setting is distinct from the Stable Privacy addresses that can be enabled with the "addr-gen-mode" property's "stable-privacy" setting β€” that's another way of avoiding host tracking with IPv6 addresses. Two different lil' tricks, same goal, don't mix 'em up πŸŽ€

  • may-fail β€” boolean, default TRUE. If TRUE, allow overall network configuration to proceed even if the configuration specified by this property times out. But listen β€” at least one IP configuration must succeed or the overall network configuration will still fail. Like, one of them has to show up to the party 🫢 For example, in IPv6-only networks, setting this property to TRUE on the NMSettingIP4Config allows the overall network configuration to succeed if IPv4 configuration fails but IPv6 configuration completes successfully. So the v4 side can be a total flop and the whole thing still eats πŸ”₯
  • method β€” string, no default. This is the IP configuration method, the main character of the whole vibe check.

NMSettingIP4Config and NMSettingIP6Config both support "disabled", "auto", "manual", and "link-local". See the subclass-specific documentation for other values (they're out there, go look πŸ‘€).

In general, for the "auto" method, properties such as "dns" and "routes" specify information that is added on to the information returned from automatic configuration. The "ignore-auto-routes" and "ignore-auto-dns" properties modify this behavior. So like, autoconfig gives you the base fit and then you're accessorizing ✨

For methods that imply no upstream network, such as "shared" or "link-local", these properties must be empty. No upstream, no extra props, periodt.

For IPv4 method "shared", the IP subnet can be configured by adding one manual IPv4 address β€” otherwise 10.42.x.0/24 is chosen. And a big note here, don't get this twisted: the shared method must be configured on the interface which shares the internet to a subnet, not on the uplink which is shared. Wrong interface = not the serve you think it is πŸ’€

  • mtu β€” uint32, default 0. Maximum transmission unit size, in bytes. If zero (the default), the MTU is set automatically from router advertisements or is left equal to the link-layer MTU. If greater than the link-layer MTU, or greater than zero but less than the minimum IPv6 MTU of 1280, this value has no effect. Basically if you shoot too high or too low, it just quietly does nothing. Respect the range or get ignored πŸ™ˆ
  • never-default β€” boolean, default FALSE. If TRUE, this connection will never be the default connection for this IP type, meaning it will never be assigned the default route by NetworkManager. It's giving side quest energy, not main character route πŸ¦‹

πŸŽ€ ra-timeout

int32 Β· default 0

A timeout for waiting Router Advertisements, in seconds. If it's zero (which, fun fact, is the default πŸ’…), a globally configured default gets used instead. And if that's still unspecified? The timeout depends on the sysctl settings of the device. iykyk.

Set it to 2147483647 (MAXINT32) for infinity. like, literally forever bestie ✨


πŸ¦‹ replace-local-rule

NMTernary (int32) Β· no default listed

Connections will default to keeping the autogenerated priority 0 local rule β€” unless this setting is set to TRUE. That's the whole vibe check. πŸ‘‘


πŸ’œ required-timeout

int32 Β· default -1

The minimum time interval, in milliseconds, for which dynamic IP configuration should be tried before the connection succeeds. ngl this one's lowkey iconic:

This property is useful, for example, if both IPv4 and IPv6 are enabled and are allowed to fail. Normally the connection succeeds as soon as one of the two address families completes; by setting a required timeout for e.g. IPv4, you can ensure that even if IPv6 succeeds earlier than IPv4, NetworkManager waits some time for IPv4 before the connection becomes active. 🫢

⚠️ Heads up: if may-fail is FALSE for the same address family, this property has no effect, because NetworkManager needs to wait for the full DHCP timeout. no cap.

A zero value means no required timeout is present, and -1 means the default value (either the configuration ipvx.required-timeout override, or zero).


🌸 route-data

array of vardict Β· no default listed

An array of IPv6 routes. Each route dictionary contains at least dest and prefix entries β€” dest holds the destination IP address as a string, and prefix holds the prefix length as a uint32. Most routes will also have a next-hop entry, containing the next hop IP address as a string. ✨

If the route has a metric entry (containing a uint32), that gets used as the metric for the route β€” otherwise NM will pick a default value appropriate to the device. Additional attributes may also exist on some routes. it's giving "there's more under the hood" πŸ’…


πŸ“ route-metric

int64 Β· default -1

The default metric for routes that don't explicitly specify a metric. The default value -1 means the metric is chosen automatically based on the device type. The metric applies to dynamic routes, manual (static) routes that don't have an explicit metric setting, address prefix routes, and the default route. πŸ‘‘

πŸ’€ Careful, this is a spicy one: for IPv6, the kernel accepts zero (0) but coerces it to 1024 (user default). So setting this property to zero effectively means setting it to 1024. For IPv4, zero is a regular value for the metric. periodt.

🧚 route-table

uint32 Β· default 0

Enable policy routing (source routing) and set the routing table used when adding routes. πŸ”₯

This affects all routes β€” including device-routes, IPv4LL, DHCP, SLAAC, default-routes and static routes. But note that static routes can individually overwrite the setting by explicitly specifying a non-zero routing table. iykyk.

If the table setting is left at zero, it is

...eligible to be overwritten via global configuration. If the property is zero even after applying the global configuration value, policy routing is disabled for the address family of this connection.

And what does "policy routing disabled" actually mean, bestie? It means NetworkManager will add all routes to the main table (except static routes that explicitly configure a different table β€” those keep doing their own thing, respect). On top of that, NetworkManager will not delete any extraneous routes from tables other than the main table. Why? To preserve backward compatibility for users who manage routing tables outside of NetworkManager. No cap, it's just being polite. 🫢


πŸ¦‹ routed-dns

Type: int32 Β· Default: -1

So this one's all about whether to add routes for DNS servers. When it's enabled, NetworkManager adds a route for each DNS server associated with this connection β€” either statically (defined in the connection profile) or dynamically (for example, retrieved via DHCP, classic). That route literally guarantees the DNS server is reached via this interface. ✨

When it's set to -1 (the default), the value from global configuration is used; and if no global default is defined, this feature is disabled. That's it, that's the whole vibe.


πŸŽ€ routes

Type: array of legacy IPv6 route struct (a(ayuayu)) Β· Default: (none)

πŸ’€ Deprecated in favor of the 'route-data' property, but this can be used for backward-compatibility with older daemons.

Important detail, don't miss it: if you send this property, the daemon will ignore 'route-data'. Like, it just straight-up pretends it didn't see it. πŸ™ˆ

It's an array of IPv6 route structures. Each IPv6 route structure is composed of:

  • an IPv6 address
  • a prefix length (0 - 128)
  • an IPv6 next hop address (which may be zeroed out if there is no next hop)
  • a metric

And if the metric is 0, NM will choose an appropriate default metric for the device. Iconic behavior, honestly. πŸ‘‘


🌈 routing-rules

Type: array of 'a{sv}' Β· Default: (none)

Array of dictionaries for routing rules. Each routing rule supports the following options, and yes, I'm listing every single one of them because we don't skip over things in this house:

  • action (y)
  • dport-end (q)
  • dport-start (q)
  • family (i)
  • from (s)
  • from-len (y)
  • fwmark (u)
  • fwmask (u)
  • iifname (s)
  • invert (b)
  • ipproto (s)
  • oifname (s)
  • priority (u)
  • sport-end (q)
  • sport-start (q)
  • supress-prefixlength (i)
  • table (u)
  • to (s)
  • tos (y)
  • to-len (y)
  • range-end (u)
  • range-start (u)
πŸ™ˆ Fair warning bestie: yes, supress-prefixlength is spelled with that extra-extra energy in the original β€” I'm not touching it, that's canon. Also dport-end and dport-start come before from in the list, and range-end / range-start show up at the very end after to-len. Keep the order, it's giving very specific.

πŸ“ shared-dhcp-lease-time

Type: int32 Β· Default: 0

This option lets you specify a custom DHCP lease time for the shared connection method, in seconds. The value should be either a number between 120 and 31536000 (one year). If this option is not specified, 3600 (one hour) is used.

Special values, because of course there are special values:

  • 0 β€” for the default value of 1 hour
  • 2147483647 (MAXINT32) β€” for infinite lease time πŸ”₯

🧚 shared-dhcp-range

Type: string Β· Default: (none)

This option lets you specify a custom DHCP range for the shared connection method. The value is expected to be in <START_ADDRESS>,<END_ADDRESS> format. Like, literally that format, with the comma. πŸ“

The range should be part of the network set by ipv4.address option, and it should not contain the network address or the broadcast address β€” those are off-limits, bestie.

If this option is not specified, the DHCP range will be automatically determined based on the interface address. The range will be selected to be adjacent to the interface address, either before or after it, with the larger possible range being preferred. The range will be...

…aaand we're still finishing that previous one's description, so real quick, bestie:

adjusted to fill the available address space, except for networks with a prefix length greater than 24, which will be treated as if they have a prefix length of 24.

Like, it literally just stretches the thing to fit the space, but anything more specific than a /24 gets rounded down and treated as a /24 anyway. Respect the prefix, but only up to a point, iykyk. πŸ’…


  • temp-preferred-lifetime β€” int32, defaults to 0. This is the preferred lifetime of the autogenerated temporary addresses, counted in seconds. ✨

And here's the fallback chain, because of course there's a fallback chain: having a per-connection setting set to "0" (which is the default, bestie) means fall back to the global configuration "ipv6.temp-preferred-lifetime" setting". If that's also unspecified or set to "0", then it falls back to reading /proc/sys/net/ipv6/conf/default/temp_prefered_lft. It's giving inheritance hierarchy. 🫢

  • temp-valid-lifetime β€” int32, defaults to 0. The valid lifetime of autogenerated temporary addresses, in seconds. πŸ•

Same deal as above, fr fr: having a per-connection setting set to "0" (default) means fallback to global configuration "ipv6.temp-valid-lifetime" setting". If it's also unspecified or set to "0", fallback to read /proc/sys/net/ipv6/conf/default/temp_valid_lft. Three layers deep, no cap. 😭

  • token β€” string, no default listed (so, empty). Configure the token for draft-chown-6man-tokenised-ipv6-identifiers-02 IPv6 tokenized interface identifiers. Super useful with eui64 addr-gen-mode. πŸ”₯

When it's set, the token gets used as the IPv6 interface identifier instead of the hardware address. And the important caveat, don't skip it: this only applies to addresses from stateless autoconfiguration β€” not to IPv6 link local addresses. Read that twice, bestie. πŸ‘‘


πŸŽ€ ip-tunnel setting πŸŽ€

IP Tunneling Settings. Okay bestie, this is the full key-by-key rundown β€” value type and default are right up front, and every original detail is staying exactly where it belongs. πŸ’…

  • encapsulation-limit β€” value type: uint32; default value: 0; How many additional levels of encapsulation are permitted to be prepended to packets. This property applies only to IPv6 tunnels. To disable this option, add 0x1 (ip6-ign-encap-limit) to ip-tunnel flags.
  • flags β€” value type: uint32; default value: 0; Tunnel flags. Currently, the following values are supported: 0x1 (ip6-ign-encap-limit), 0x2 (ip6-use-orig-tclass), 0x4 (ip6-use-orig-flowlabel), 0x8 (ip6-mip6-dev), 0x10 (ip6-rcv-dscp-copy), 0x20 (ip6-use-orig-fwmark). They are valid only for IPv6 tunnels.
  • flow-label β€” value type: uint32; default value: 0; The flow label to assign to tunnel packets. This property applies only to IPv6 tunnels.
  • fwmark β€” value type: uint32; default value: 0; The fwmark value to assign to tunnel packets. This property can be set to a non zero value only on VTI and VTI6 tunnels.
  • input-key β€” value type: string; default value: (empty); The key used for tunnel input packets; the property is valid only for certain tunnel modes (GRE, IP6GRE). If empty, no key is used.
  • local β€” value type: string; default value: (empty); The local endpoint of the tunnel; the value can be empty, otherwise it must contain an IPv4 or IPv6 address.
  • mode β€” value type: uint32; default value: 0; The tunneling mode. Valid values: 1 (ipip), 2 (gre), 3 (sit), 4 (isatap), 5 (vti), 6 (ip6ip6), 7 (ipip6), 8 (ip6gre), 9 (vti6), 10 (gretap) and 11 (ip6gretap).
  • mtu β€” value type: uint32; default value: 0; If non-zero, only transmit packets of the specified size or smaller, breaking larger packets up into multiple fragments.
  • output-key β€” value type: string; default value: (empty); The key used for tunnel output packets; the property is valid only for certain tunnel modes (GRE, IP6GRE). If empty, no key is used.
  • parent β€” value type: string; default value: (empty); If given, specifies the parent interface name or parent connection UUID the new device will be bound to so that tunneled packets will only be routed via that interface.
  • path-mtu-discovery β€” value type: boolean; default value: TRUE; Whether to enable Path MTU Discovery on this tunnel.
  • remote β€” value type: string; default value: (empty); The remote endpoint of the tunnel; the value must contain an IPv4 or IPv6 address.
  • tos β€” uint32, default 0. This is the type-of-service (IPv4) or traffic-class (IPv6) field that gets set on your tunneled packets. cute little byte, big job πŸ’…
  • ttl β€” uint32, default 0. The TTL you're assigning to tunneled packets. And listen β€” 0 is a special value here, it literally means the packets just inherit the TTL value instead. no cap, zero isn't "zero TTL", it's "you decide, bestie" ✨

πŸ¦‹ ipvlan setting πŸ¦‹

So this is the IPVLAN setting block β€” your whole config for that interface type lives right here, and it's giving very small-but-mighty energy 🫢

  • mode β€” uint32, default 0. The IPVLAN mode, aka the whole personality of the interface. Valid values are 1 (l2), 2 (l3), and 3 (l3s). those are your only three options, periodt πŸ”₯
  • parent β€” string, default is empty. If you actually give it a value, it specifies the parent interface name or the parent connection UUID that this IPVLAN interface should be created from. Big caveat though: if you skip this property entirely, then the connection must contain an "802-3-ethernet" setting with a "mac-address" property. so like, one or the other, you can't just leave both blank and hope for the best 😭
  • private β€” boolean, default FALSE. Whether the interface should be put in private mode. simple as that πŸ’–
  • vepa β€” boolean, default FALSE. Whether the interface should be put in VEPA mode. also simple as that πŸŽ€

πŸ¦‹ macsec setting πŸ¦‹

Okay bestie, this one's the MACSec settings block β€” yes, the fancy layer-2 encryption situation πŸ’œ Every key name, type, default and value is right here, no cap.

  • encrypt β€” boolean, default TRUE β€” Whether the transmitted traffic must be encrypted. Yeah, your outbound packets get the little lock πŸ”’
  • mka-cak β€” string β€” The pre-shared CAK (Connectivity Association Key) for MACsec Key Agreement. It must be a string of 32 hexadecimal characters, fr fr, count them 🧚
  • mka-cak-flags β€” NMSettingSecretFlags (uint32) β€” Flags indicating how to handle the mka-cak property. It's giving secret-management vibes πŸ’…
  • mka-ckn β€” string β€” The pre-shared CKN (Connectivity-association Key Name) for MACsec Key Agreement. Must be a string of hexadecimal characters with an even length between 2 and 64. Even length. Between 2 and 64. Don't test her πŸ™ˆ
  • mode β€” int32, default 0 β€” Specifies how the CAK (Connectivity Association Key) for MKA (MACsec Key Agreement) is obtained. That's the whole lore πŸŽ€
  • offload β€” int32, default -1 β€” Specifies the MACsec offload mode. Lowkey the most extra one, so listen up:
    • 0 (off) disables MACsec offload.
    • 1 (phy) and 2 (mac) request offload respectively to the PHY or to the MAC; if the selected mode is not available, the connection will fail 😭 like, it's not gonna quietly pick something else for you.
    • -1 (default) uses the global default value specified in NetworkManager configuration; if no global default is defined, the built-in default is 0 (off). Very "we'll check the group chat, then fall back" energy 🫢
  • parent β€” string β€” If given, specifies the parent interface name or parent connection UUID from which this MACSEC interface should be created. If this property is not specified, the connection must contain an "802-3-ethernet" setting with a "mac-address" property. So it's giving ✨found family✨ β€” either you name the parent or you bring the ethernet setting along, periodt.
  • port β€” int32, default 1 β€” The port component of the SCI (Secure Channel Identifier), between 1 and 65534. Stay in range bestie πŸ’€
  • send-sci β€” boolean, default TRUE β€” Specifies whether the SCI (Secure Channel Identifier) is included in every packet. Every. Single. Packet. Iconic.
  • validation β€” int32, default 2 β€” Specifies the validation mode for incoming frames. The vibe check for traffic coming at you 🌸
Heads up bestie: parent has consequences β€” if you leave it out, that "802-3-ethernet" setting with a "mac-address" property isn't optional, it's required. And offload doesn't do graceful fallbacks, so pick a mode your hardware actually supports or the connection's just gonna fail on you πŸ’€

πŸ’… macvlan setting πŸ¦‹

okay bestie, so these are the MAC VLAN Settings β€” the little knobs that control how your macvlan behaves. one table, four keys, all of them important, none of them optional in my heart ✨

  • mode β€” uint32, default 0. this is the macvlan mode, and it's literally the whole personality of the thing: it decides how multiple macvlans on the same lower device talk to each other. communication mechanism vibes, yk? 🫢
  • parent β€” string, no default. if you give it one, it names the parent interface name or the parent connection UUID that this MAC-VLAN interface should be created from. and if you don't set it? then the connection has to contain an "802-3-ethernet" setting with a "mac-address" property. no cap, that's mandatory β€” don't skip it πŸ™ˆ
  • promiscuous β€” boolean, default TRUE. asks the question: should the parent interface get put into promiscuous mode? and the answer is yes by default (true by default β€” the manpage said it, not me πŸ’€). so if you don't want that, you gotta turn it off yourself, bestie.
  • tap β€” boolean, default FALSE. should this interface be a MACVTAP instead? default says no. flip it to true if that's your moment πŸ”₯

like, that's the whole set πŸŽ€ four keys, zero drama, all facts preserved. the defaults are lowkey doing a lot of work here β€” promiscuous starts at TRUE so the parent's out here in promiscuous mode unless you say otherwise, and tap starts at FALSE so you're getting a plain macvlan, not a MACVTAP, unless you change it. iykyk πŸ’œ

πŸŽ€ match setting

This is the whole "do you even go here?" setting, bestie β€” it's a pile of rules that get checked against a device to see if this connection profile is a match. Every key is an array of strings, no defaults anywhere, and it's all pattern-matching energy. Let's go key by key, iykyk. πŸ’…


driver

  • Value type: array of string
  • Default value: (none β€” empty)
  • What it does: A list of driver names to match. Each element is a shell wildcard pattern.
Heads up, gorgeous: see NMSettingMatch:interface-name for how the special characters '|', '&', '!' and '\\' are used for optional and mandatory matches and for inverting the pattern. Same rules apply here, fr fr.

interface-name

  • Value type: array of string
  • Default value: (none β€” empty)
  • What it does: A list of interface names to match. Each element is a shell wildcard pattern.

Okay this one is the ✨ main character ✨ of the special-character rules, so listen up:

An element can be prefixed with a pipe symbol (|) or an ampersand (&). The former means the element is optional, and the latter means it is mandatory. If there are any optional elements, the match evaluates to true if at least one of the optional elements matches (logical OR, slay). If there are any mandatory elements, then they all must match (logical AND, no exceptions 🫢).

By default an element is optional β€” which literally means an element "foo" behaves exactly the same as "|foo". Iconic.

An element can also be inverted with an exclamation mark (!) between the pipe symbol (or the ampersand) and before the pattern. Note that "!foo" is a shortcut for the mandatory match "&!foo". And finally, a backslash can be used at the beginning of the element (after the optional special characters) to escape the start of the pattern. For example, "&\\!a" is a mandatory match for literally "!a". The way that escaping just works πŸ˜­πŸ’–

kernel-command-line

  • Value type: array of string
  • Default value: (none β€” empty)
  • What it does: A list of kernel command line arguments to match. This may be used to check whether a specific kernel command line option is set β€” or unset, if it's prefixed with the exclamation mark.

The argument must either be a single word, or an assignment (i.e. two words, joined by "=").

  • In the former case, the kernel command line is searched for the word appearing as-is, or as the left-hand side of an assignment.
  • In the latter case, the exact assignment is looked for, with right- and left-hand side matching.
Wildcard patterns are not supported here. Like, zero. None. Don't come for me, that's just the rules πŸ’€

See NMSettingMatch:interface-name for how the special characters '|', '&', '!' and '\\' are used for optional and mandatory matches and inverting the match.

path

  • Value type: array of string
  • Default value: (none β€” empty)
  • What it does: A list of paths to match against the ID_PATH udev property of devices. ID_PATH represents the topological persistent path of a device. It typically contains a subsystem string (pci, usb,

...and that path? It's lowkey a whole little address system. It's built from a platform, a subsystem and a subsystem-specific identifier, and honestly once you see it you can't unsee it.

For PCI devices the path has the form "pci-$domain:$bus:$device.$function", where each variable is a hexadecimal value β€” for example "pci-0000:0a:00.0". Cute, right? Very hex, very demure. πŸ’…

You can grab a device's path with:

udevadm info /sys/class/net/$dev | grep ID_PATH=

or by looking at the path property that NetworkManager exports:

nmcli -f general.path device show $dev

Each element of the list is a shell wildcard pattern β€” so yes, globbing is happening, bestie, act accordingly. ✨

And for how the special characters '|', '&', '!' and '\' do their thing (optional matches, mandatory matches, inverting the pattern), go peek at NMSettingMatch:interface-name. It's all there, iykyk. πŸ¦‹


🧚 802-11-olpc-mesh setting 🧚

OLPC Wireless Mesh Settings. Yes, that OLPC. We love a niche icon. πŸŽ€

  • channel β€” uint32, default 0 β€” the channel on which the mesh network to join is located.
  • dhcp-anycast-address β€” byte array, no default β€” anycast DHCP MAC address used when requesting an IP address via DHCP. The specific anycast address used determines which DHCP server class answers the request. Heads up: this is currently only implemented by the dhclient DHCP plugin. That's the whole vibe β€” one plugin, no cap. πŸ™ˆ
  • ssid β€” byte array, no default β€” SSID of the mesh network to join.

🌈 ovs-bridge setting 🌈

OvsBridge Link Settings. Open vSwitch bridge core, main character energy. πŸ‘‘

  • datapath-type β€” string, no default β€” the data path type. One of "system", "netdev" or empty. Pick your fighter. ⭐
  • fail-mode β€” string, no default β€” the bridge failure mode. One of "secure", "standalone" or empty.
  • mcast-snooping-enable β€” boolean, default FALSE β€” enable or disable multicast snooping.
  • rstp-enable β€” boolean, default FALSE β€” enable or disable RSTP.
  • stp-enable β€” boolean, default FALSE β€” enable or disable STP.
All three of those booleans default to FALSE, so if you thought they were on out of the box β€” nope, babe. Turn them on yourself. πŸ’€

🌸 ovs-dpdk setting 🌸

Okay bestie, these are the OvsDpdk Link Settings β€” the little knobs that tell NetworkManager how to talk to Open vSwitch DPDK vibes. There are five keys, and yes, we're going through every single one πŸ’…

  • devargs β€” string, no default value listed.
    • Open vSwitch DPDK device arguments. That's it, that's the whole assignment ✨
  • lsc-interrupt β€” int32, default -1.
    • Configures the Link State Change (LSC) detection mode for the OVS DPDK interface. When it's set to -1 (ignore), NetworkManager literally doesn't change the default value that Open vSwitch configured. Setting it to 1 (enabled) enables interrupts. Setting it to 0 (disabled) disables interrupts, which puts the interface in poll mode 🫢
  • n-rxq β€” uint32, default 0.
    • Open vSwitch DPDK number of rx queues. It defaults to zero, which means the parameter is left unspecified in OVS and effectively configures one queue. One queue, one vibe 🌈
  • n-rxq-desc β€” uint32, default 0.
    • The rx queue size (number of rx descriptors) for DPDK ports. It must be zero or a power of 2 between 1 and 4096, and it has to be supported by the hardware. Defaults to zero, which means the parameter stays unspecified in OVS and effectively configures 2048 descriptors. Math queen behavior, honestly πŸ”₯
  • n-txq-desc β€” uint32, default 0.
    • The tx queue size (number of tx descriptors) for DPDK ports. Same rules, bestie: must be zero or a power of 2 between 1 and 4096, and supported by the hardware. Defaults to zero β€” leaving it unspecified in OVS β€” which effectively configures 2048 descriptors πŸ’œ

πŸ¦‹ ovs-interface setting πŸ¦‹

Now we're on the Open vSwitch Interface Settings β€” only two keys here, but they're lowkey iconic. Let's get into it πŸŽ€

  • ofport-request β€” uint32, default 0.
    • Open vSwitch openflow port number. Defaults to zero, which means the port number won't be specified and it'll be chosen randomly by ovs. OpenFlow ports are the network interfaces for passing packets between OpenFlow processing and the rest of the network. OpenFlow switches connect logically to each other via their OpenFlow ports. So yeah, it's giving "let ovs pick, bestie" ✨
  • type β€” string, no default value listed.
    • The interface type. Either "internal", "system", "patch", "dpdk", or empty. Pick your fighter πŸ‘‘

ovs-patch setting

okay so this is the ✨ OvsPatch Link Settings ✨ block β€” it's tiny, literally one key, but she's important πŸ’…

  • peer β€” string, no default (so like, blank until you set it). This is the name of the interface on the other side of the patch, bestie. And here's the tea πŸ«– β€” the patch sitting on that other side has to set this interface as its peer too. It's giving mutuals-only. Both sides or it doesn't count, periodt. πŸ¦‹

ovs-port setting

now we're in ✨ OvsPort Link Settings ✨ territory, and this one's a whole vibe β€” six keys, all about how a port behaves. buckle up, we're going through them one by one πŸŽ€

  • bond-downdelay β€” uint32, defaults to 0. The amount of time the port has to be inactive before it gets considered down. so like, a grace period before we call it πŸ’€
  • bond-mode β€” string, no default. The bonding mode, friend. It's one of "active-backup", "balance-slb", or "balance-tcp" β€” pick your fighter, those are the only three that exist πŸ”₯
  • bond-updelay β€” uint32, defaults to 0. The amount of time the port has to be active before it actually starts forwarding traffic. she has to prove herself first, ngl, main character energy πŸ‘‘
  • lacp β€” string, no default. The LACP mode β€” one of "active", "off", or "passive". three moods, choose wisely 🌸
  • tag β€” uint32, defaults to 0. The VLAN tag, and it lives in the range 0-4095. don't go outside the range, it's not cute πŸ™ˆ
  • trunks β€” array of vardict, no default. A whole list of VLAN ranges that this port trunks. But β€” and this is the important part β€” this property is only valid for ports whose mode is "trunk", "native-tagged", or "native-untagged" port. And if it's empty? Then the port trunks all the VLANs. everything. the whole buffet. πŸ“
  • vlan-mode β€” string, no default. The VLAN mode itself, one of "access", "native-tagged", "native-untagged", "trunk", "dot1q-tunnel" or unset. yeah, unset is a valid answer, we don't judge πŸ’œ

lowkey that's the whole port vibe check β€” seven keys, no notes. carry on, bestie, more coming πŸ«ΆπŸ’–

πŸ’… ppp setting πŸ’…

Point-to-Point Protocol Settings. Yes bestie, this is the PPP corner of the config β€” every key here gets handed straight to pppd, so let's go through them one by one, no skips, no cap. ✨

  • baud β€” uint32, default 0 β€” if it's non-zero, it tells pppd to set the serial port to that exact baudrate. Normally you leave this at 0 so the speed gets picked automatically. πŸŽ€
  • crtscts β€” boolean, default FALSE β€” if TRUE, pppd sets the serial port to use hardware flow control with the RTS and CTS signals. Normally this should be FALSE, okay? Don't be weird about it.
  • lcp-echo-failure β€” uint32, default 0 β€” if it's non-zero, pppd will assume the connection to the peer is dead once that many LCP echo-requests go unanswered by the peer. Heads up though πŸ‘€ β€” the "lcp-echo-interval" property also has to be set to a non-zero value if you're using this one. They're a package deal, iykyk.
  • lcp-echo-interval β€” uint32, default 0 β€” if it's non-zero, pppd sends an LCP echo-request frame to the peer every n seconds, where n is the value you set. Lowkey important caveat: some PPP peers respond to echo requests and some literally do not, and there is no way to autodetect which kind you're dealing with. πŸ’€
  • mppe-stateful β€” boolean, default FALSE β€” if TRUE, stateful MPPE is used. For the whole lore on stateful MPPE, go read the pppd documentation β€” that's where the details live. πŸ¦‹
  • mru β€” uint32, default 0 β€” if it's non-zero, pppd asks the peer to send packets no bigger than the size you specified. And if it is non-zero, the MRU should be between 128 and 16384. Respect the range bestie. πŸ”₯
  • mtu β€” uint32, default 0 β€” if it's non-zero, pppd sends packets no larger than the size you specified. That's it, that's the vibe.
  • no-vj-comp β€” boolean, default FALSE β€” if TRUE, Van Jacobsen TCP header compression will not be requested. Nope, not today. πŸ™ˆ
  • noauth β€” boolean, default TRUE β€” if TRUE, you don't require the other side (usually the PPP server) to authenticate itself to the client. If FALSE, you do require authentication from the remote side. In almost all cases this should be TRUE β€” like, genuinely, almost all. πŸ‘‘
  • nobsdcomp β€” boolean, default FALSE β€” if TRUE, BSD compression will not be requested. Not requested, not happening, not on the menu.
  • nodeflate β€” boolean, default FALSE β€” if TRUE, "deflate" compression will not be requested. Same energy, different algorithm. πŸ’œ
  • refuse-chap β€” boolean, default FALSE β€” if TRUE, the CHAP authentication method will not be

okay so we’re still in the ppp settings block β€” here’s the rest of the list, bestie, and every single one of these is boolean with default FALSE:

  • refuse-eap β€” type boolean, default FALSE. If TRUE, the EAP authentication method will not be used. no cap.
  • refuse-mschap β€” type boolean, default FALSE. If TRUE, the MSCHAP authentication method will not be used. periodt.
  • refuse-mschapv2 β€” type boolean, default FALSE. If TRUE, the MSCHAPv2 authentication method will not be used. okay?!
  • refuse-pap β€” type boolean, default FALSE. If TRUE, the PAP authentication method will not be used. literally.
  • require-mppe β€” type boolean, default FALSE. If TRUE, MPPE (Microsoft Point-to-Point Encryption) will be required for the PPP session. If either 64-bit or 128-bit MPPE is not available the session will fail. Note that MPPE is not used on mobile broadband connections. πŸ’€ important.
  • require-mppe-128 β€” type boolean, default FALSE. If TRUE, 128-bit MPPE (Microsoft Point-to-Point Encryption) will be required for the PPP session, and the "require-mppe" property must also be set to TRUE. If 128-bit MPPE is not available the session will fail. so yeah, double-check that one 🫢

🌈 pppoe setting 🌈

PPP-over-Ethernet Settings. yes bestie, it’s giving Ethernet but make it PPP ✨

  • parent β€” type string, default is blank. If given, specifies the parent interface name on which this PPPoE connection should be created. If this property is not specified, the connection is activated on the interface specified in "interface-name" of NMSettingConnection. iykyk.
  • password β€” type string, default is blank. Password used to authenticate with the PPPoE service. πŸ”
  • password-flags β€” type NMSettingSecretFlags (uint32), default is blank. Flags indicating how to handle the "password" property. very secret, very flags.
  • service β€” type string, default is blank. If specified, instruct PPPoE to only initiate sessions with access concentrators that provide the specified service. For most providers, this should be left blank. It is only required if there are multiple access concentrators or a specific service is known to be required. πŸŽ€
  • username β€” type string, default is blank. Username used to authenticate with the PPPoE service. periodt. πŸ’…

proxy setting πŸŽ€

WWW Proxy Settings β€” bestie, this is the proxy corner of the settings universe, and every key/type/default is right here. No cap. πŸ’…

  • browser-only β€” type <cyan>boolean</cyan>, default <green>FALSE</green>. Whether the proxy configuration is for browser only. πŸ¦‹
  • method β€” type <cyan>int32</cyan>, default <green>0</green>. Method for proxy configuration, default is 0 (none). πŸ‘‘
  • pac-script β€” type <cyan>string</cyan>, default (empty). PAC script for the connection. This is an UTF-8 encoded javascript code that defines a FindProxyForURL() function. ✨
  • pac-url β€” type <cyan>string</cyan>, default (empty). PAC URL for obtaining PAC file. πŸ’–

serial setting 🌸

Serial Link Settings β€” the serial-port vibe check. All the knobs, defaults, and little warnings are here, periodt.

  • baud β€” type <cyan>uint32</cyan>, default <green>57600</green>. Speed to use for communication over the serial port. Note that this value usually has no effect for mobile broadband modems as they generally ignore speed settings and use the highest available speed. 😭
  • bits β€” type <cyan>uint32</cyan>, default <green>8</green>. Byte-width of the serial communication. The 8 in "8n1" for example. πŸŽ€
  • parity β€” type <cyan>byte</cyan>, default (empty). The connection parity: 69 (ASCII 'E') for even parity, 111 (ASCII 'o') for odd, 110 (ASCII 'n') for none. πŸ’€
  • send-delay β€” type <cyan>uint64</cyan>, default <green>0</green>. Time to delay between each byte sent to the modem, in microseconds. 🫢
  • stopbits β€” type <cyan>uint32</cyan>, default <green>1</green>. Number of stop bits for communication on the serial port. Either 1 or 2. The 1 in "8n1" for example. 🌈

πŸŽ€ sriov setting πŸŽ€

okay bestie, this is the SR-IOV corner of the settings world β€” harness the actual hardware, no cap. every key here lives in the sriov setting, and here's the full rundown πŸ’…

  • autoprobe-drivers β€” NMTernary (int32), no default listed here β€” whether to autoprobe virtual functions by a compatible driver πŸ¦‹
    • if set to 1 (true), the kernel will try to bind VFs to a compatible driver, and if this succeeds a new network interface will be instantiated for each VF ✨
    • if set to 0 (false), VFs will not be claimed and no network interfaces will be created for them πŸ™ˆ
    • when set to -1 (default), the global default is used; in case the global default is unspecified it is assumed to be 1 (true) πŸ’–
  • eswitch-encap-mode β€” int32, default -1 β€” select the eswitch encapsulation support πŸ‘‘
    • currently it's only supported for PCI PF devices, and only if the eswitch device is managed from the same PCI address than the PF πŸ”₯
    • if set to -1 (preserve) (default) the eswitch encap-mode won't be modified by NetworkManager πŸ’…
  • eswitch-inline-mode β€” int32, default -1 β€” select the eswitch inline-mode of the device. some HWs need the VF driver to put part of the packet headers on the TX descriptor so the e-switch can do proper matching and steering 🧚
    • currently it's only supported for PCI PF devices, and only if the eswitch device is managed from the same PCI address than the PF 🌸
    • if set to -1 (preserve) (default) the eswitch inline-mode won't be modified by NetworkManager ⭐
  • eswitch-mode β€” int32, default -1 β€” select the eswitch mode of the device. currently it's only supported for PCI PF devices, and

... and lowkey the whole eswitch situation only kicks in if the eswitch device is managed from the same PCI address as the PF, iykyk 🫢

If you set it to -1 (that's preserve, and yes it's the default), NetworkManager literally won't touch the eswitch mode at all β€” hands off, no notes πŸ’…


  • preserve-on-down β€” int32, default -1 β€” this one's the main character of "do we keep the SR-IOV stuff or nah" πŸŽ€ It controls whether NetworkManager preserves the SR-IOV parameters set on the device when the connection is deactivated, or whether it resets them to their default value. And bestie, "the SR-IOV parameters" means the ones specified in this very setting (the "sriov" setting) β€” like the number of VFs to create, the eswitch configuration, etc. ✨
    • Set it to 0 (no) and NetworkManager resets the SR-IOV parameters when the connection is deactivated πŸ™ˆ
    • Set it to 1 (yes) and NetworkManager preserves those parameters on the device πŸ‘‘
    • If the value is -1 (the default), NetworkManager looks up a global default value in the configuration; and in case no such value is defined, it uses 0 (no) as fallback. no cap πŸ’€
  • total-vfs β€” uint32, default 0 β€” the total number of virtual functions to create 🌸 Heads up though: when the sriov setting is present, NetworkManager enforces the number of virtual functions on the interface (also when it is zero, fr fr) during activation, and resets it upon deactivation 😭 So if you wanna prevent any changes to SR-IOV parameters, just don't add a sriov setting to the connection. periodt 🧚
  • vfs β€” array of vardict β€” array of virtual function descriptors πŸ¦‹ Each VF descriptor is a dictionary mapping attribute names to GVariant values. And the 'index' entry is mandatory for each VF β€” like, non-negotiable, bestie πŸ’…

When a VF gets represented as a string, it’s literally in the form:

"INDEX [ATTR=VALUE[ ATTR=VALUE]...]"

for example:

"2 mac=00:11:22:33:44:55 spoof-check=true"

Multiple VFs can be specified using a comma as separator. Currently, the following attributes are supported: mac, spoof-check, trust, min-tx-rate, max-tx-rate, vlans. ✨

The vlans attribute is represented as a semicolon-separated list of VLAN descriptors, where each descriptor has the form

"ID[.PRIORITY[.PROTO]]"

PROTO can be either 'q' for 802.1Q (the default) or 'ad' for 802.1ad. 🫢

🚦 tc setting

Linux Traffic Control Settings. Okay bestie, here’s the lowdown on these two keys:

  • qdiscs β€” Value Type: array of vardict; Default Value: (empty). Array of TC queueing disciplines.

When the "tc" setting is present, qdiscs from this property are applied upon activation. If the property is empty, all qdiscs are removed and the device will only have the default qdisc assigned by kernel according to the net.core.default_qdisc sysctl.

If the "tc" setting is not present, NetworkManager doesn't touch the qdiscs present on the interface.

  • tfilters β€” Value Type: array of vardict; Default Value: (empty). Array of TC traffic filters.

When the "tc" setting is present, filters from this property are applied upon activation. If the property is empty, NetworkManager removes all the filters.

If the "tc" setting is not present, NetworkManager doesn't touch the filters present on the interface. πŸ’…

team setting 🫢

okay bestie, this is the Teaming Settings block β€” everything you need to make a team network interface behave. each key below lists its value type and default value, so keep an eye on those πŸ’…

  • config β€” string, no default set (empty). this one holds the JSON configuration for the team network interface. lowkey important: the property should contain raw JSON configuration data suitable for teamd, because the value is passed directly to teamd. if you don't specify it, the default configuration is used. see man teamd.conf for the format details πŸ“œ
  • interface-name β€” string, no default set (empty). deprecated in favor of connection.interface-name, but it can still be used for backward-compatibility with older daemons, to set the team's interface name. so like, it works, but it's giving legacy energy πŸ™ˆ
  • link-watchers β€” array of vardict, no default set (empty). this is the link watchers configuration for the connection. each link watcher is defined by a dictionary, and the keys of that dictionary depend upon the selected link watcher.
    • available link watchers are 'ethtool', 'nsna_ping' and 'arp_ping', and it is specified in the dictionary with the key 'name' ✨
    • available keys, by watcher:
      • ethtool: 'delay-up', 'delay-down', 'init-wait'
      • nsna_ping: 'init-wait', 'interval', 'missed-max', 'target-host'
      • arp_ping: all the ones in nsna_ping, plus 'source-host', 'validate-active', 'validate-inactive', 'send-always'
    • see the teamd.conf man page for more details πŸ”
  • mcast-rejoin-count β€” int32, default -1. corresponds to the teamd mcast_rejoin.count.
  • mcast-rejoin-interval β€” int32, default -1. corresponds to the teamd mcast_rejoin.interval.
  • notify-peers-count β€” int32, default -1. corresponds to the teamd notify_peers.count.
  • notify-peers-interval β€” int32, default -1. corresponds to the teamd notify_peers.interval.
  • runner β€” string, no default set (empty). corresponds to the teamd runner.name. permitted values are: "roundrobin", "broadcast", "activebackup", "loadbalance", "lacp", "random" πŸ‘‘
  • runner-active β€” boolean, default TRUE. corresponds to the teamd runner.active. and yes, it's TRUE by default β€” she's active, she's thriving πŸ’…
  • runner-agg-select-policy β€” type: string, default: empty ✨ β€” corresponds to the teamd runner.agg_select_policy. this is the one that picks how the aggregator chooses its ports, iykyk πŸŽ€
  • runner-fast-rate β€” type: boolean, default: FALSE πŸ’… β€” corresponds to the teamd runner.fast_rate. lowkey just flips fast rate on or off, that's the whole vibe.
  • runner-hwaddr-policy β€” type: string, default: empty πŸ¦‹ β€” corresponds to the teamd runner.hwaddr_policy. this is the hardware address policy, no cap.
  • runner-min-ports β€” type: int32, default: -1 🌸 β€” corresponds to the teamd runner.min_ports. the minimum port count, fr fr.
  • runner-sys-prio β€” type: int32, default: -1 ⭐ β€” corresponds to the teamd runner.sys_prio. system priority, periodt.
  • runner-tx-balancer β€” type: string, default: empty πŸ”₯ β€” corresponds to the teamd runner.tx_balancer.name. yup, the name of the tx balancer specifically πŸ‘‘
  • runner-tx-balancer-interval β€” type: int32, default: -1 🌈 β€” corresponds to the teamd runner.tx_balancer.interval. the interval for that balancer, bestie.
  • runner-tx-hash β€” type: array of string, default: empty πŸ’œ β€” corresponds to the teamd runner.tx_hash. it's an array of strings, not a single one β€” literally a whole list, don't forget πŸ™ˆ
ok so that's the runner- block done and dusted πŸ’– every single one of these maps straight onto a teamd runner.* key, so if you know teamd you already know what's tea here πŸ“

🌸 team-port setting 🌸

Okay bestie, this is the Team Port settings block β€” all the little knobs that get glued onto a single port inside a team device. Let's go key by key, no skips, no cap. πŸ’…

  • config β€” string Β· default: (none given) β€” This is the raw JSON configuration for the team port. The property is supposed to hold raw JSON configuration data that's suitable for teamd, because the value gets passed directly to teamd. If you don't specify it, the default configuration is used. Wanna know the format? See man teamd.conf. πŸ“„
  • lacp-key β€” int32 Β· default: -1 β€” Corresponds to the teamd ports.PORTIFNAME.lacp_key.
  • lacp-prio β€” int32 Β· default: -1 β€” Corresponds to the teamd ports.PORTIFNAME.lacp_prio.
  • link-watchers β€” array of vardict Β· default: (none given) β€” The link watchers configuration for the connection. Each link watcher is defined by a dictionary, and the keys in that dictionary depend on which link watcher you picked. The available link watchers are 'ethtool', 'nsna_ping' and 'arp_ping', and you specify which one you want inside the dictionary with the key 'name'. The available keys per watcher are:
    • ethtool: 'delay-up', 'delay-down', 'init-wait'
    • nsna_ping: 'init-wait', 'interval', 'missed-max', 'target-host'
    • arp_ping: all the ones in nsna_ping plus 'source-host', 'validate-active', 'validate-inactive', 'send-always'

See the teamd.conf man page for more details. πŸ‘€

  • prio β€” int32 Β· default: 0 β€” Corresponds to the teamd ports.PORTIFNAME.prio.
  • queue-id β€” int32 Β· default: -1 β€” Corresponds to the teamd ports.PORTIFNAME.queue_id. When it's set to -1, that literally means the parameter is skipped from the json config. 🫢
  • sticky β€” boolean Β· default: FALSE β€” Corresponds to the teamd ports.PORTIFNAME.sticky.

🧚 tun setting β€” the tunnel glow-up ✨

Tunnel Settings, bestie. This is where you tell NetworkManager how your virtual tunnel device should look and act. Here's the whole lineup, no skips, no cap:

  • group β€” Value type:</> string. Default:</> (none β€” it's empty). The group ID that's gonna own the device. If you set it to NULL, literally everyone can use the device. πŸ™ˆ
  • mode β€” Value type:</> uint32. Default:</> 1. This is the operating mode of the virtual device. The allowed values are 1 (tun) which creates a layer 3 device, and 2 (tap) which makes an Ethernet-like layer 2 one. Choose your fighter πŸ’…
  • multi-queue β€” Value type:</> boolean. Default:</> FALSE. If this property is set to TRUE, the interface will support multiple file descriptors (queues) so it can parallelize packet sending or receiving. Otherwise it's single queue only β€” one lane, no carpool 😭
  • owner β€” Value type:</> string. Default:</> (none β€” empty). The user ID that will own the device. Set it to NULL and everyone can use the device, which is giving "no rules just vibes" πŸŽ€
  • pi β€” Value type:</> boolean. Default:</> FALSE. If TRUE, the interface will prepend a 4 byte header to the packets describing the physical interface. Four whole bytes of context, iconic πŸ’–
  • vnet-hdr β€” Value type:</> boolean. Default:</> FALSE. If TRUE, the IFF_VNET_HDR means the tunnel packets will include a virtio network header. Yep, that's the whole thing πŸ¦‹

🌸 user setting β€” your personal little scrapbook πŸŽ€

General User Profile Settings. It's the one place NetworkManager is like "not my business, do you."

  • data β€” Value type:</> dict of string to string. Default:</> {}. A dictionary of key/value pairs holding user data. NetworkManager literally ignores this data β€” it exists purely for you to use at your own discretion, iykyk. The keys only support a strict ascii format, but the values can be arbitrary UTF8 strings up to a certain length. So go off, decorate your profile 🌈
Heads up bestie: the keys are ascii-only. The values are where you get to be free πŸ’œ

🌸 vlan setting 🌸

Okay bestie, this is the VLAN settings block β€” yes, it’s giving network-nerd realness, and we’re gonna keep every key exactly as it appears. πŸ’…

  • egress-priority-map β€” Value type: array of string. Default: (blank). For outgoing packets, this is a list of mappings from Linux SKB priorities to 802.1p priorities. The mapping is given in the format "from:to" where both "from" and "to" are unsigned integers, ie "7:3". ✨
  • flags β€” Value type: NMVlanFlags (uint32). Default: (blank). One or more flags which control the behavior and features of the VLAN interface. Flags include:
    • 0x1 (reorder-headers) β€” reordering of output packet headers πŸŽ€
    • 0x2 (gvrp) β€” use of the GVRP protocol πŸ¦‹
    • 0x4 (loose-binding) β€” loose binding of the interface to its controller device's operating state 🌸
    • 0x8 (mvrp) β€” use of the MVRP protocol ⭐
The default value of this property is NM_VLAN_FLAG_REORDER_HEADERS, but it used to be 0. To preserve backward compatibility, the default-value in the D-Bus API continues to be 0 and a missing property on D-Bus is still considered as 0. πŸ‘‘
  • id β€” Value type: uint32. Default: 0. The VLAN identifier that the interface created by this connection should be assigned. The valid range is from 0 to 4094, without the reserved id 4095. No cap, that reserved 4095 is not invited to the party πŸ™ˆ
  • ingress-priority-map β€” Value type: array of string. Default: (blank). For incoming packets, this is a list of mappings from 802.1p priorities to Linux SKB priorities. The mapping is given in the format "from:to" where both "from" and "to" are unsigned integers, ie "7:3". πŸ’–
  • interface-name β€” Value type: string. Default: (blank). Deprecated in favor of connection.interface-name, but can be used for backward-compatibility with older daemons, to set the vlan's interface name. So like… it still works, but it’s lowkey the old way 😭
  • parent β€” Value type: string. Default: (blank). If given, specifies the parent interface name or parent connection UUID from which this VLAN interface should be created. If this property is not specified, the connection must contain an "802-3-ethernet" setting with a "mac-address" property. Fr fr, don’t skip that part 🫢
  • protocol β€” string β€” no default value listed here (but the description says if you leave it out, the default is '802.1Q' πŸ’…) β€” This one specifies the VLAN protocol to use for encapsulation. Supported values are: '802.1Q', '802.1ad'. If not specified the default value is '802.1Q'. That's it, that's the whole vibe πŸŽ€

✨ vpn setting ✨

VPN Settings. Like, the whole tunnel situation πŸš‡ β€” here's every key you can set, bestie:

  • data β€” dict of string to string β€” default {} β€” A dictionary of key/value pairs of VPN plugin specific data. Both keys and values must be strings. No sneaky non-strings allowed, the type check is literally that girl 🫢
  • persistent β€” boolean β€” default FALSE β€” If the VPN service supports persistence, and this property is TRUE, the VPN will attempt to stay connected across link changes and outages, until explicitly disconnected. Iconic clingy behaviour, honestly πŸ₯Ί
  • secrets β€” dict of string to string β€” default {} β€” A dictionary of key/value pairs of VPN plugin specific secrets like passwords or private keys. Both keys and values must be strings. Keep these safe, they're not for the group chat πŸ”
  • service-type β€” string β€” no default β€” The D-Bus service name of the VPN plugin that this setting uses to connect to its network. i.e. org.freedesktop.NetworkManager.vpnc for the vpnc plugin. Yes, that's a whole hostname-length string, copy it exactly pls 😭
  • timeout β€” uint32 β€” default 0 β€” Timeout for the VPN service to establish the connection. Some services may take quite a long time to connect. Value of 0 means a default timeout, which is 60 seconds (unless overridden by vpn.timeout in configuration file). Values greater than zero mean timeout in seconds. So like, it's giving you a knob, use it wisely ⏱️
  • user-name β€” string β€” no default β€” If the VPN connection requires a user name for authentication, that name should be provided here. If the connection is available to more than one user, and the VPN requires each user to supply a different name, then leave this property empty. If this property is empty, NetworkManager will automatically supply the username of the user which requested the VPN connection. So the empty case is not broken, it's automatic, slay ✨

🌈 vrf setting 🌈

VRF settings. Short and sweet, honestly a little minimalist king πŸ‘‘

  • table β€” uint32 β€” default 0 β€” The routing table for this VRF. Just the one key, bestie, nothing else to memorise πŸŽ€

πŸ¦‹ vxlan setting

okay bestie, this is the vxlan corner of the settings world β€” VXLAN Settings, no cap. every key here lives on a tunnel and they all have ✨opinions✨. here's the whole roster, type and defaults included:

  • ageing β€” type uint32, default 300. this one's the lifetime, in seconds, of the FDB entries that the kernel learns. so like, how long a learned entry sticks around before it ghosts πŸ’€
  • destination-port β€” type uint32, default 8472. the UDP destination port u use to talk to the remote VXLAN tunnel endpoint. old-school default, iconic.
  • id β€” type uint32, default 0. the VXLAN Network Identifier (or, if ur feeling fancy, the VXLAN Segment Identifier) to use. yes it's one field with two names, it's giving versatile πŸ’…
  • l2-miss β€” type boolean, default FALSE. says whether netlink LL ADDR miss notifications get generated. off by default, she's lowkey.
  • l3-miss β€” type boolean, default FALSE. same vibe but for netlink IP ADDR miss notifications. also off unless u say otherwise.
  • learning β€” type boolean, default TRUE. this is the big one: whether unknown source link layer addresses and IP addresses get entered into the VXLAN device forwarding database. on by default β€” she's nosy and she's learning πŸŽ€
  • limit β€” type uint32, default 0. the maximum number of FDB entries. and bestie, a value of zero means the kernel will store unlimited entries β€” so yes, 0 is the "no limits, we die like legends" setting 🫢
  • local β€” type string, no default. if given, it specifies the source IP address to use in outgoing packets. ur tunnel's little return address πŸ’Œ
  • parent β€” type string, no default. if given, it specifies the parent interface name or parent connection UUID. the tunnel's actual home base.
  • proxy β€” type boolean, default FALSE. specifies whether ARP proxy is turned on. off unless u flip her.
  • remote β€” type string, no default. specifies the unicast destination IP address to use in outgoing packets when the destination link layer address isn't known in the VXLAN device forwarding database β€” or the multicast IP address to join. two jobs, one key, main character energy πŸ‘‘
  • rsc β€” type boolean, default FALSE. specifies whether route short circuit is turned on. nope by default.
  • source-port-max β€” type uint32, default 0. the maximum UDP source port to communicate to the remote VXLAN tunnel endpoint. top of the range, literally.
  • source-port-min β€” type uint32, default 0. the minimum UDP source port to communicate to the remote VXLAN tunnel endpoint. bottom of the range, also literally πŸ“
  • tos β€” type uint32, default 0. specifies the TOS value to use in outgoing packets. the vibe tag on ur packets ✨
  • ttl β€” type uint32, default 0. specifies the time-to-live
  • …and the value to use in outgoing packets. That's the last row of that table bestie, we're moving on πŸ’…

🌸 wifi-p2p setting 🌸

Wi-Fi P2P Settings. Peer-to-peer, device-to-device, the whole cute little ad-hoc vibe ✨

  • peer β€” string β€” no default β€” the P2P device that should be connected to. Currently, this is the only way to create or join a group. Like, the literal only door in πŸšͺ
  • wfd-ies β€” byte array β€” no default β€” the Wi-Fi Display (WFD) Information Elements (IEs) to set. Wi-Fi Display requires a protocol specific information element to be set in certain Wi-Fi frames, and you can specify those here for the purpose of establishing a connection.
Heads up: this setting is only useful when implementing a Wi-Fi Display client. Server girlies, this one's not for you 🫢
  • wps-method β€” uint32 β€” default 0 β€” flags indicating which mode of WPS is to be used.
Real talk: there's little point in changing the default setting, because NetworkManager will automatically determine the best method to use. Let her cook πŸ‘‘πŸ”₯

πŸ¦‹ wimax setting πŸ¦‹

WiMax Settings. Sit down for this one, it's giving vintage 😭

  • mac-address β€” byte array β€” no default β€” if specified, this connection will only apply to the WiMAX device whose MAC address matches. This property does not change the MAC address of the device (known as MAC spoofing) β€” read that again, it's a filter, not a glow-up πŸ’€
Deprecated since version 1.2. WiMAX is no longer supported. Gone but not forgotten πŸ•―οΈ
  • network-name β€” string β€” no default β€” Network Service Provider (NSP) name of the WiMAX network this connection should use.
Deprecated since version 1.2. WiMAX is no longer supported. Bestie it's a museum piece now πŸ›οΈ

🌐 802-3-ethernet setting 🌐

Wired Ethernet settings, bestie β€” this is where you go when the cable life calls πŸ’…

  • accept-all-mac-addresses β€” NMTernary (int32), no default listed. When TRUE, it sets up the interface to accept packets for all MAC addresses β€” that's literally enabling the kernel interface flag IFF_PROMISC (yes, promiscuous mode, she's nosy πŸ™ˆ). When FALSE, the interface only accepts packets with the interface destination mac address or broadcast.
  • assigned-mac-address β€” string, no default listed. The new field for the cloned MAC address ✨ It can be either a hardware address in ASCII representation, or one of the special values "preserve", "permanent", "random" or "stable". This field replaces the deprecated "cloned-mac-address" on D-Bus, which can only contain explicit hardware addresses. Heads up though β€” this property only exists in the D-Bus API; libnm and nmcli continue to call this property "cloned-mac-address". Iykyk 😭
  • auto-negotiate β€” boolean, default FALSE. When TRUE, it enforces auto-negotiation of speed and duplex mode. If "speed" and "duplex" properties are both specified, only that single mode will be advertised and accepted during the link auto-negotiation process: this works only for BASE-T 802.3 specifications and is useful for enforcing gigabits modes, as in these cases link negotiation is mandatory. When FALSE, the "speed" and "duplex" properties should be both set or link configuration will be skipped. Don't leave her hanging 🫢
  • cloned-mac-address β€” byte array, no default listed. This D-Bus field is deprecated in favor of "assigned-mac-address", which is more flexible and allows specifying special variants like "random". For libnm and nmcli, this field is called "cloned-mac-address". So yeah, she's iconic but retired πŸ‘‘
  • duplex β€” string, no default listed. When a value is set β€” either "half" or "full" β€” it configures the device to use the specified duplex mode. If "auto-negotiate" is "yes", the specified duplex mode will be the only one advertised during link negotiation: this works only for BASE-T
  • upper bits look like auto-negotiate shenanigans: this thing is straight out of the 802.3 specifications and it's genuinely useful for enforcing gigabit modes, because in those cases link negotiation is mandatory, no cap.
  • if the value is unset (that's the default btw), the link config gets either skipped β€” that happens when "auto-negotiate" is "no", which is also the default β€” or auto-negotiated, which happens when "auto-negotiate" is "yes", and then the local device advertises all the supported duplex modes. ✨
  • must be set together with the "speed" property if it's specified. like, they're a package deal, bestie 🫢
  • before you specify a duplex mode, be sure your device actually supports it. don't just pick one and hope, that's giving chaos energy πŸ’€

  • generate-mac-address-mask β€” type string, no default listed. Okay so picture this: with "cloned-mac-address" set to "random" or "stable", by default every single bit of the MAC address gets scrambled and a locally-administered, unicast MAC address is created. This property is your little cheat code to say "actually, keep these bits exactly as they are." πŸŽ€

Note the fine print, though: the least significant bit of the first MAC address will always be unset, because that's how you get a unicast MAC address. That one you can't opt out of, iykyk 🌸

If the property is NULL, it's eligible to be overwritten by a default connection setting. And if the value is still NULL, or it's an empty string, the default is to create a locally-administered, unicast MAC address. Simple enough πŸ’…

Now the fun part: if the value contains one MAC address, that address is used as a mask. The set bits of the mask get filled with the current MAC address of the device, while the unset bits are the ones that get randomized. So setting "FE:FF:FF:00:00:00" means "preserve the OUI of the current MAC address and only randomize the lower 3 bytes" using the "random" or "stable" algorithm. Obsessed with how clean that is πŸ¦‹

Put one additional MAC address after the mask and that address is used instead of the current MAC address to fill the bits that shall not be randomized. Example time: a value of "FE:FF:FF:00:00:00 68:F7:28:00:00:00" will set the OUI of the MAC address to 68:F7:28, while the lower bits are randomized. And a value of "02:00:00:00:00:00 00:00:00:00:00:00" will create a fully scrambled globally-administered, burned-in MAC address. iconic frankly πŸ‘‘

And if the value contains more than one additional MAC address, one of them is chosen randomly. For example, "02:00:00:00:00:00 00:00:00:00:00:00 02:00:00:00:00:00" will create a fully … 🌈 (and yeah, the sentence is literally still going β€” hold that thought, we pick it right back up πŸ’–)

  • mac-address β€” byte array, no default β€” if you set this, the connection will only apply to the Ethernet device whose permanent MAC address matches. And no, bestie, this does not change the MAC address of the device β€” it is not MAC spoofing, it's just a matching filter. iykyk πŸ’…
  • mac-address-blacklist β€” array of string, no default β€” if you set this, the connection will never apply to the Ethernet device whose permanent MAC address matches an address in the list. Each MAC address goes in the standard hex-digits-and-colons notation, like 00:11:22:33:44:55. πŸŽ€
  • mac-address-denylist β€” array of string, no default β€” same energy as the one above, honestly: if specified, this connection will never apply to the Ethernet device whose permanent MAC address matches an address in the list. Each MAC address is in the standard hex-digits-and-colons notation, 00:11:22:33:44:55. ✨
  • mtu β€” uint32, default 0 β€” if it's non-zero, only transmit packets of the specified size or smaller, breaking larger packets up into multiple Ethernet frames. lowkey the classic packet-shredder 🌸
  • port β€” string, no default β€” the specific port type to use if the device supports multiple attachment methods. One of:
    • "tp" β€” Twisted Pair
    • "aui" β€” Attachment Unit Interface
    • "bnc" β€” Thin Ethernet
    • "mii" β€” Media Independent Interface

If the device supports only one port type, this setting is just ignored. no thoughts, ignored πŸ’€

  • s390-nettype β€” string, no default β€” the s390 network device type; one of "qeth", "lcs", or "ctc", representing the different types of virtual network devices available on s390 systems. mainframe girlies rise 🫢
  • s390-options β€” dict of string to string, default {} β€” a dictionary of key/value pairs of s390-specific device options. Both keys and values must be strings. Allowed keys include "portno", "layer2", "portname", "protocol", among others. Key names must contain only alphanumeric characters (ie, [a-zA-Z0-9]). πŸ”₯

Real talk though: currently, NetworkManager itself does nothing with this information. However, s390utils ships a udev rule which parses this information and applies it to the interface. so it's giving middleman, but make it functional ✨

  • s390-subchannels β€” array of string, no default β€” identifies specific subchannels that this network device uses

…for communication with z/VM or s390 host. Like the mac-address property for non-z/VM devices, this property can be used to ensure this connection only applies to the network device that uses these subchannels. The list should contain exactly 3 strings, and each string may only be composed of hexadecimal characters and the period (.) character.

That row is wrapped πŸ’… β€” now the wired-property rows keep rolling:

  • speed β€” type uint32, default 0. When a value greater than 0 is set, configures the device to use the specified speed. If auto-negotiate is yes the specified speed will be the only one advertised during link negotiation: this works only for BASE-T 802.3 specifications and is useful for enforcing gigabit speeds, as in this case link negotiation is mandatory. If the value is unset (0, the default), the link configuration will be either skipped (if auto-negotiate is no, the default) or will be auto-negotiated (if auto-negotiate is yes) and the local device will advertise all the supported speeds. In Mbit/s, ie 100 == 100Mbit/s. Must be set together with the duplex property when non-zero.
Before specifying a speed value be sure your device supports it. fr fr β€” don't just yolo a number in there 🫢
  • wake-on-lan β€” type uint32, default 1. The NMSettingWiredWakeOnLan options to enable. Not all devices support all options. May be any combination of 0x2 (phy), 0x4 (unicast), 0x8 (multicast), 0x10 (broadcast), 0x20 (arp), 0x40 (magic) or the special values 0x1 (default) (to use global settings) and 0x8000 (ignore) (to disable management of Wake-on-LAN in NetworkManager).
  • wake-on-lan-password β€” type string, default (blank). If specified, the password used with magic-packet-based Wake-on-LAN, represented as an Ethernet MAC address. If NULL, no password will be required. ✨

πŸ‰ wireguard setting πŸ‰

okay bestie, welcome to the WireGuard corner of the config kingdom ✨ this is where the tunnel vibes live, and here's every single key, type, default and deet β€” no skips, no cap πŸ’…

  • fwmark (uint32, default 0) β€” using a fwmark is totally optional and off by default. setting it to 0 disables it, periodt. otherwise it's a 32-bit fwmark for outgoing packets 🫢
    • ⚠️ real talk: if "ip4-auto-default-route" or "ip6-auto-default-route" is enabled, that implies it'll automatically choose a fwmark for you. iykyk.
  • ip4-auto-default-route (NMTernary (int32), default: unset) β€” do you want the ✨special handling✨ of the IPv4 default route? here's the tea: if enabled, the IPv4 default route from wireguard.peer-routes gets placed into a dedicated routing-table, and two policy routing rules get added πŸ”₯ the fwmark number is also used as the routing-table for the default-route, and if fwmark is zero, an unused fwmark/table is chosen automatically. this is literally what wg-quick does with Table=auto, and what WireGuard calls "Improved Rule-based Routing" πŸ‘‘
    • 🫢 note that for this automatism to work, you usually don't want to set ipv4.gateway, because that'll result in a conflicting default route. not the vibe.
    • 🌸 leaving this at the default will enable this option automatically if ipv4.never-default is not set and there are any peers that use a default-route as allowed-ips. since this automatism only makes sense if you also have a peer with an /0 allowed-ips, it's usually not necessary to enable this explicitly. but you can disable it if you wanna configure your own routing and rules. main character energy.
  • ip6-auto-default-route (NMTernary (int32), default: unset) β€” literally like ip4-auto-default-route, but for the IPv6 default route πŸ¦‹ same energy, different protocol.
  • listen-port (uint32, default 0) β€” the listen-port, bestie. if listen-port is not specified, the port will be chosen randomly 🎲 when the interface comes up.
  • mtu (uint32, default 0) β€” if non-zero, only transmit packets of the specified size or smaller, breaking larger packets up into multiple fragments πŸ’… if it's zero, a default MTU is used.
    • ⚠️ note that β€” contrary to wg-quick's MTU setting β€” this does not take into account the current routes at the time of activation. so like, don't come for it if your routes change, it's doing its best πŸ™ˆ
  • peer-routes β€” boolean, default TRUE πŸ›£οΈ β€” this is the "should I auto-add routes for the peers' AllowedIPs ranges" switch, and bestie, it's giving main character. If it's TRUE (which, again, is the default), NetworkManager will automatically add routes in the routing tables according to ipv4.route-table and ipv6.route-table. Usually you absolutely want this automatism enabled, no cap. If it's FALSE, no such routes get added automatically β€” and in that case the user may want to configure static routes in ipv4.routes and ipv6.routes, respectively. Your call, your vibes πŸ’…
Heads up though πŸ‘€ if the peer's AllowedIPs is "0.0.0.0/0" or "::/0" and the profile's ipv4.never-default or ipv6.never-default setting is enabled, then the peer route for this peer won't be added automatically. That's just how it is, iykyk.
  • peers β€” array of 'a{sv}' β€” literally just an array of dictionaries for the WireGuard peers 🫢
  • private-key β€” string β€” the 256 bit private-key in base64 encoding πŸ” keep it secret, keep it safe, do not be posting this in the group chat.
  • private-key-flags β€” NMSettingSecretFlags (uint32) β€” flags indicating how to handle the "private-key" property πŸŽ€

✨ 802-11-wireless setting ✨

Wi-Fi Settings, bestie β€” this is the whole vibe of your wireless connection πŸ¦‹

  • ap-isolation β€” type NMTernary (int32), no default listed πŸŽ€ β€” configures AP isolation, which stops wireless devices connected to this AP from talking to each other. You can only set this to something other than -1 (the default) when the interface is configured in AP mode.
    • Set it to 1 (true) and devices literally cannot communicate with each other. That's a security glow-up ✨ because it protects devices against attacks from other clients on the network β€” but at the same time it also blocks devices from accessing resources on the same wireless network, like file shares, printers, etc. 😭
    • Set it to 0 (false) and devices can talk to each other, no cap.
    • Left at -1 (default)? The global default gets used, and if the global default is unspecified it's assumed to be 0 (false). Periodt.
  • assigned-mac-address β€” type string, no default listed πŸ’… β€” the new field for the cloned MAC address. It can be either a hardware address in ASCII representation, or one of the special values "preserve", "permanent", "random" or "stable". This field replaces the deprecated "cloned-mac-address" on D-Bus, which can only contain explicit hardware addresses. πŸ‘‘ Heads up though: this property only exists in the D-Bus API β€” libnm and nmcli continue to call this property "cloned-mac-address". iykyk.
  • band β€” type string, no default listed 🌸 β€” the 802.11 frequency band of the network. One of "a" for 5GHz, "bg" for 2.4GHz or "6GHz". Pick your lane, bestie πŸ“Ά
  • (still the tail end of the previous row, bestie β€” the band one) β€” this locks associations to the Wi-Fi network to the specific band, i.e. if "a" is specified, the device will not associate with the same network in the 2.4GHz (bg) or 6GHz bands even if the network's settings are compatible. Lowkey important: this setting depends on specific driver capability and may not work with all drivers. πŸ’…

  • bssid β€” byte array 🌸 β€” if specified, this directs the device to only associate with the given access point. Heads up though: this capability is highly driver dependent and not supported by all devices. Note: this property does not control the BSSID used when creating an Ad-Hoc network and is unlikely to in the future. πŸ™ˆ

Locking a client profile to a certain BSSID will prevent roaming and also disable background scanning. That can be useful, if there is only one access point for the SSID. (iconic "I know exactly where home is" behavior tbh πŸŽ€)

  • channel β€” uint32, default 0 β€” the wireless channel to use for the Wi-Fi connection. The device will only join (or create, for Ad-Hoc networks) a Wi-Fi network on the specified channel. And because channel numbers overlap between bands, this property also requires the "band" property to be set. no cap, set both or it won't slay ✨
  • channel-width β€” int32, default 0 β€” specifies the width of the wireless channel in Access Point (AP) mode. πŸ“Ά

When set to 0 (auto) β€” which is the default β€” the channel width is automatically determined. At the moment, this means that the safest (smallest) width is chosen. 🧚

If the value is not 0 (auto), then the 'channel' property must also be set. When using the 2.4GHz band, the width can be at most 40MHz. ⭐

This property can be set to a value different from 0 (auto) only when the interface is configured in AP mode. That's the vibe check it has to pass, fr fr.

  • cloned-mac-address β€” byte array β€” this D-Bus field is deprecated in favor

So like β€” this is that same-ish vibe but the ✨upgraded✨ version, and honestly? It's the one you actually want, bestie πŸ’… because the plain "assigned-mac-address" is the stiff one, while "cloned-mac-address" is more flexible and lets you do fun stuff like special variants such as "random" 🎲. Oh and heads up, if you're in libnm or nmcli, this field goes by the name "cloned-mac-address" β€” same queen, different name tag iykyk πŸ’–

  • generate-mac-address-mask (string) β€” the picky little detail-gremlin that decides which bits of your MAC get scrambled πŸ™ˆ

So here's the tea β˜•: when "cloned-mac-address" is set to "random" or "stable", by default all the bits of the MAC address get scrambled and you end up with a locally-administered, unicast MAC address. Iconic default behavior, honestly. But this property lets you go "no actually, keep these bits exactly as they are" β€” like, certain bits stay fixed πŸ“Œ. Just know that the least significant bit of the first MAC address will always be unset, because that's literally how you create a unicast MAC address. No negotiating on that one πŸ’€

If the property is NULL, it's eligible to be overwritten by a default connection setting 🫢. And if the value is still NULL or is an empty string, the default is to create a locally-administered, unicast MAC address β€” back to factory vibes ✨

If the value contains one MAC address, that address is used as the mask πŸŽ€. The set bits of the mask get filled with the current MAC address of the device, while the unset bits are subject to randomization. So like, setting "FE:FF:FF:00:00:00" means "preserve the OUI of the current MAC address and only randomize the lower 3 bytes" using the "random" or "stable" algorithm β€” cute, controlled chaos πŸŒ€

If the value contains one additional MAC address after the mask, that address is used instead of the current MAC address to fill in the bits that shall not be randomized πŸ‘‘. For example, a value of "FE:FF:FF:00:00:00 68:F7:28:00:00:00" will set the OUI of the MAC address to 68:F7:28, while the lower bits are randomized 🌈. And a value of "02:00:00:00:00:00 00:00:00:00:00:00" will create a fully scrambled globally-administered, burned-in MAC address β€” very "borrowed identity but make it legal" of it πŸ”₯

If the value contains more than one additional MAC address, one of them is chosen randomly 🎰. For example, "02:00:00:00:00:00 00:00:00:00:00:00 02:00:00:00:00:00" will create a fully scrambled MAC address, randomly locally or

hidden

boolean Β· default FALSE

If TRUE, it means the network is a non-broadcasting one that hides its SSID. Works in both infrastructure and AP mode, bestie. ✨

In infrastructure mode, various workarounds get used for a more reliable discovery of hidden networks, like probe-scanning the SSID. But 😬 those workarounds expose inherent insecurities with hidden SSID networks, and thus hidden SSID networks should be used with caution. fr fr, be careful.

In AP mode, the created network does not broadcast its SSID.

Note that marking the network as hidden may be a privacy issue for you (in infrastructure mode) or for client stations (in AP mode), as the explicit probe-scans are distinctly recognizable on the air. πŸ‘€ lowkey everybody can see you looking.

mac-address

byte array Β· no default

If specified, this connection will only apply to the Wi-Fi device whose permanent MAC address matches. 🎯

This property does not change the MAC address of the device (i.e. no MAC spoofing). It's giving "which device am I for", not "who am I pretending to be". πŸ’…

mac-address-blacklist

array of string Β· no default

A list of permanent MAC addresses of Wi-Fi devices to which this connection should never apply. 🚫 Each MAC address should be given in the standard hex-digits-and-colons notation (eg "00:11:22:33:44:55").


mac-address-denylist

array of string Β· no default

A list of permanent MAC addresses of Wi-Fi devices to which this connection should never apply. 🚫 Each MAC address should be given in the standard hex-digits-and-colons notation (eg "00:11:22:33:44:55").


mac-address-randomization

uint32 Β· default 0

One of 0 (default) (never randomize unless the user has set a global default to randomize and the supplicant supports randomization), 1 (never) (never randomize the MAC address), or 2 (always) (always randomize the MAC address). 🎲

This property is deprecated since

…version 1.4. Use the "cloned-mac-address" property instead. πŸ’…

  • mode (string, default: blank) β€” Wi-Fi network mode, bestie. One of "infrastructure", "mesh", "adhoc" or "ap". If it’s blank, infrastructure is assumed. ✨
  • mtu (uint32, default: 0) β€” if non-zero, only transmit packets of the specified size or smaller, breaking larger packets up into multiple Ethernet frames. πŸ¦‹
  • powersave (uint32, default: 0) β€” one of 2 (disable) (disable Wi-Fi power saving), 3 (enable) (enable Wi-Fi power saving), 1 (ignore) (don't touch currently configure setting) or 0 (default) (use the globally configured value). All other values are reserved. πŸ”₯
  • rate (uint32, default: 0) β€” this property is not implemented and has no effect. It’s deprecated since version 1.44. And yes, because the page really said it twice: this property is not implemented and has no effect. πŸ’€
  • security (type: blank, default: blank) β€” this property is deprecated and has no effect. For backwards compatibility, it can be set to "802-11-wireless-security" if the profile has a wireless security setting. πŸ™ˆ
  • seen-bssids (array of string, default: blank) β€” a list of BSSIDs (each BSSID formatted as a MAC address like "00:11:22:33:44:55") that have been detected as part of the Wi-Fi network. NetworkManager internally tracks previously seen BSSIDs. The property is only meant for reading and reflects the BSSID list of NetworkManager. The changes you make to this property will not be preserved. This is not a regular property that the user would configure. Instead, NetworkManager automatically sets the seen BSSIDs and tracks them internally in /var/lib/NetworkManager/seen-bssids file. 🫢
  • ssid (byte array, default: blank) β€” SSID of the Wi-Fi network. Must be specified. Periodt. πŸ‘‘
  • tx-power (uint32, default: 0) β€” this property is not implemented and has no effect. This property is deprecated since

…and yeah, that note is literally the whole vibe: version 1.44. This property is not implemented and has no effect. πŸ’€ Not a drill, not a typo β€” it genuinely does nothing, so don't come for me when it doesn't do the thing.

  • wake-on-wlan β€” type uint32, default 1. This is the NMSettingWirelessWakeOnWLan situation β€” a.k.a. which wake-on-WLAN options you're asking for. Quick reality check bestie: not all devices support all options, so don't assume your NIC ate the whole menu. 🫢

You can pass any combination of these, and it's a bitmask so yeah, you add them up:

  • 0x2 β€” any
  • 0x4 β€” disconnect
  • 0x8 β€” magic
  • 0x10 β€” gtk-rekey-failure
  • 0x20 β€” eap-identity-request
  • 0x40 β€” 4way-handshake
  • 0x80 β€” rfkill-release
  • 0x100 β€” tcp

Plus the two ✨ special ✨ values that aren't really "flags" so much as whole moods:

  • 0x1 β€” default β€” like, "use the global settings", let the big picture decide πŸ”₯
  • 0x8000 β€” ignore β€” to disable management of Wake-on-LAN in NetworkManager. You're taking the wheel, main character energy, NM stays out of it. πŸ’…
Ngl, mixing 0x1 or 0x8000 in with the other bits is not the serve you think it is β€” they're special values, not extra toppings. πŸ“

✨ 802-11-wireless-security setting ✨

Wi-Fi Security Settings. Bestie, this is the whole vibe check for how your laptop proves it's allowed on the network πŸ¦‹

  • auth-alg β€” string, no default. When WEP is in the building (i.e. key-mgmt = "none" or "ieee8021x"), you use this to tell everyone which 802.11 authentication algorithm the AP is demanding. Pick one of "open" for Open System, "shared" for Shared Key, or "leap" for Cisco LEAP. And heads up 🫢 β€” when you're doing Cisco LEAP (i.e. key-mgmt = "ieee8021x" and auth-alg = "leap"), the "leap-username" and "leap-password" properties must be specified. Like, non-negotiable.
  • fils β€” int32, default 0. Says whether Fast Initial Link Setup (802.11ai) has to be enabled for the connection. One of:
    • 0 (default) β€” use the global default value
    • 1 (disable) β€” disable FILS
    • 2 (optional) β€” enable FILS if the supplicant and the access point both support it
    • 3 (required) β€” enable FILS and fail if it's not supported

And when it's set to 0 (default) and no global default is set, FILS will be optionally enabled. iykyk πŸ’…

  • group β€” array of string, no default. A list of group/broadcast encryption algorithms β€” and the way this works is it prevents connections to Wi-Fi networks that don't use at least one of the algorithms in your list. For maximum compatibility, leave this property empty (fr fr, empty is the move). Each list element can be one of "wep40", "wep104", "tkip", or "ccmp" 🌈
  • key-mgmt β€” string, no default. The key management used for the connection, aka the main character of this whole table πŸ‘‘. One of:
    • "none" β€” WEP or no password protection
    • "ieee8021x" β€” Dynamic WEP
    • "owe" β€” Opportunistic Wireless Encryption
    • "wpa-psk" β€” WPA2 + WPA3 personal
    • "sae" β€” WPA3 personal only
    • "wpa-eap" β€” WPA2 + WPA3 enterprise
    • "wpa-eap-suite-b-192" β€” WPA3 enterprise only
  • leap-password β€” string β€” no default listed. The login password for legacy LEAP connections (ie, key-mgmt = "ieee8021x" and auth-alg = "leap"). Lowkey a relic but she's still out here πŸ’…
  • leap-password-flags β€” NMSettingSecretFlags (uint32) β€” no default listed. Flags indicating how to handle the "leap-password" property. πŸŽ€
  • leap-username β€” string β€” no default listed. The login username for legacy LEAP connections (ie, key-mgmt = "ieee8021x" and auth-alg = "leap"). Matching set with the password above, obvs 🫢
  • pairwise β€” array of string β€” no default listed. A list of pairwise encryption algorithms which prevents connections to Wi-Fi networks that do not utilize one of the algorithms in the list. For maximum compatibility leave this property empty. Each list element may be one of "tkip" or "ccmp". So like, if you fill this in you're basically telling the network "bestie, show me your algorithms or we're not doing this" 😀
  • pmf β€” int32 β€” default 0. Indicates whether Protected Management Frames (802.11w) must be enabled for the connection. One of:
    • 0 (default) β€” use global default value
    • 1 (disable) β€” disable PMF
    • 2 (optional) β€” enable PMF if the supplicant and the access point support it
    • 3 (required) β€” enable PMF and fail if not supported

When set to 0 (default) and no global default is set, PMF will be optionally enabled. The way this little number runs the whole vibe check for your management frames 🌸

  • proto β€” array of string β€” no default listed. List of strings specifying the allowed WPA protocol versions to use. Each element may be one "wpa" (allow WPA) or "rsn" (allow WPA2/RSN). If not specified, both WPA and RSN connections are allowed. Ngl, leaving it blank is the chill option ✨
  • psk β€” string β€” no default listed. Pre-Shared-Key for WPA networks. For WPA-PSK, it's either an ASCII passphrase of 8 to 63 characters that is (as specified in the 802.11i standard) hashed to derive the actual key, or the key in form of 64 hexadecimal character. The WPA3-Personal networks use a passphrase of any length for SAE authentication.
No cap, that 8-to-63 vs. 64-hex split is the classic trap β€” count your characters before you commit, bestie 😭
  • psk-flags β€” NMSettingSecretFlags (uint32) β€” no default listed. Flags indicating how to handle the "psk" property. πŸ¦‹
  • wep-key-flags β€” NMSettingSecretFlags (uint32) β€” no default listed. Flags indicating how to handle the "wep-key0", "wep-key1", "wep-key2", and "wep-key3"
  • wep-key-type β€” NMWepKeyType (uint32) β€” this one controls how your WEP keys get interpreted, and honestly it's giving "choose your own adventure" πŸ’… the allowed values are:
    • 1 (key) β€” in which case the key is either a 10- or 26-character hexadecimal string, or a 5- or 13-character ASCII password πŸŽ€
    • 2 (passphrase) β€” in which case the passphrase is provided as a string and will be hashed using the de-facto MD5 method to derive the actual WEP key πŸ”
  • wep-key0 β€” string β€” Index 0 WEP key, aka the main character πŸ‘‘ this is the WEP key used in most networks, fr fr. See the "wep-key-type" property for a description of how this key is interpreted πŸ’–
  • wep-key1 β€” string β€” Index 1 WEP key. This WEP index is not used by most networks 😴 see the "wep-key-type" property for a description of how this key is interpreted ✨
  • wep-key2 β€” string β€” Index 2 WEP key. This WEP index is not used by most networks πŸ™ˆ see the "wep-key-type" property for a description of how this key is interpreted 🌸
  • wep-key3 β€” string β€” Index 3 WEP key. This WEP index is not used by most networks πŸ’€ see the "wep-key-type" property for a description of how this key is interpreted πŸ¦‹
  • wep-tx-keyidx β€” uint32 β€” default is 0 ✨ when static WEP is used (ie, key-mgmt = "none") and a non-default WEP key index is used by the AP, put that WEP key index here. Valid values are 0 (default key) through 3. note that some consumer access points (like the Linksys WRT54G) number the keys 1 - 4 β€” yeah, they really said "let's count from one, chaos is fun" 😭 so double-check before you hardcode anything bestie
  • wps-method β€” uint32 β€” default is 0 πŸŽ€ flags indicating which mode of WPS is to be used if any. There's little point in changing the default setting as NetworkManager will automatically determine whether it's feasible to start WPS enrollment from the Access Point capabilities β€” it's literally out here doing the vibes check for you πŸ”₯ WPS can be disabled by setting this property to a value of 1 🫢

🌈 wpan setting 🌈

Okay bestie, this one is the IEEE 802.15.4 (WPAN) MAC Settings block β€” yes, all of them. Here's the keys, their types, their defaults, and what they actually mean πŸ‘‡

  • channel β€” type int32, default -1. This is the IEEE 802.15.4 channel. You give it a positive integer, or -1, and -1 means "do not set, use whatever the device is already set to" ✨
  • mac-address β€” type string, default is empty (no default listed, bestie, that's just how it is). If you specify it, this connection will only apply to the IEEE 802.15.4 (WPAN) MAC layer device whose permanent MAC address matches. It's giving ✨ commitment ✨
  • page β€” type int32, default -1. The IEEE 802.15.4 channel page. Positive integer, or -1, and again -1 means "do not set, use whatever the device is already set to" πŸ’…
  • pan-id β€” type uint32, default 65535. The IEEE 802.15.4 Personal Area Network (PAN) identifier. Cute little network name-tag, no cap πŸŽ€
  • short-address β€” type uint32, default 65535. The short IEEE 802.15.4 address to be used within a restricted environment. Tiny address, big main character energy πŸ‘‘

πŸ¦‹ bond-port setting πŸ¦‹

And here's the Bond Port Settings section β€” only two keys, but they're lowkey important if you're doing bond things πŸ”₯

  • prio β€” type int32, default 0. The port priority for bond active port re-selection during failover. Higher number = higher priority in selection, periodt. The primary port has the highest priority. Heads up though: this option is only compatible with active-backup, balance-tlb and balance-alb modes β€” it does not vibe with the others, bestie πŸ™ˆ
  • queue-id β€” type uint32, default 0. The queue ID of this bond port. And the way the maximum value works: it's the number of TX queues currently active in device. That's the ceiling, so don't go over it πŸ’€
  • destination-port β€” uint32, default 6081 ✨ β€” bestie this one picks the UDP destination port you're communicating to on the remote GENEVE tunnel endpoint πŸŽ€
  • df β€” int32, default 0 β€” controls how the Don't Fragment (DF) flag gets handled in the outer IP header of GENEVE tunnel packets, iykyk πŸ’…
    • 0 (unset) (0) β€” don't set the DF flag at all, so packets may be fragmented πŸ¦‹
    • 1 (set) (1) β€” always set the DF flag, packets will not be fragmented, periodt πŸ”₯
    • 2 (inherit) (2) β€” inherit the DF flag straight from the inner IP header, no cap 🧚
  • id β€” uint32, default 0 β€” specifies the GENEVE Network Identifier (or GENEVE Segment Identifier, same vibe, different name 🌸) to use πŸ‘‘
  • remote β€” string, default is empty β€” specifies the unicast destination IP address used in outgoing packets when you're communicating with the remote GENEVE tunnel endpoint πŸ’–
  • tos β€” uint32, default 0 β€” specifies the TOS value to use in outgoing packets. The special value "inherit" (1) means inherit from the outer packet, iconic behavior fr fr ⭐
  • ttl β€” int32, default 0 β€” specifies the time-to-live value to use in outgoing packets 🌈
    • "inherit" (-1) β€” inherit from the outer packet πŸ™ˆ
    • 0 β€” auto, let the kernel do its thing πŸ’€
    • 1–255 β€” fixed values, you picked it, you own it πŸ’œ

🏠 hostname setting

Okay bestie, this little block is all about naming your computer β€” like, who gets to decide what your machine calls itself, and which connection is allowed to have an opinion. It's giving "everyone wants to name the group chat" energy. 😭 Each key below is a property of the setting, with its type, its default, and what it actually does.

  • from-dhcp β€” type NMTernary (int32), default value: (blank β€” see below, the -1 business is the real answer). This one's the "can we learn our name from DHCP on this connection?" switch. When it's set to -1 (that's the default), the value from the global configuration is used instead. And if the property doesn't have a value in the global configuration? NetworkManager just assumes the value is 1 (true). Slay, it names itself. ✨
  • from-dns-lookup β€” type NMTernary (int32), default value: (blank). Same vibe, different source: this asks whether the system hostname can be figured out from a reverse DNS lookup of addresses on this device. When set to -1 (default), the value from the global configuration is used. If the property has no value in the global configuration, NetworkManager assumes the value is 1 (true). DNS said "that's you" and NM believed it. πŸ¦‹
  • only-from-default β€” type NMTernary (int32), default value: (blank). This is the picky one, the "only if you're the main character" flag. πŸ‘‘
    • If it's set to 1 (true), NetworkManager attempts to get the hostname via DHCPv4/DHCPv6 or reverse DNS lookup on this device only when the device has the default route for the given address family (IPv4/IPv6).
    • If it's set to 0 (false), the hostname can be set from this device even if it doesn't have the default route. Chill mode unlocked. πŸ“
    • When it's set to -1 (default), the value from the global configuration is used. And if the property doesn't have a value in the global configuration, NetworkManager assumes the value is 0 (false).
  • priority β€” type int32, default value: 0. The relative priority of this connection when it comes to determining the system hostname. And heads up, the math is backwards from what your gut says: a lower numerical value is better (higher priority) 🫢. A connection with higher priority is considered before connections with lower priority. Think of it like being early to the party β€” small number, big flex. πŸ’…
    • If the value is zero, it can be overridden by a global value from NetworkManager configuration. If the property doesn't have a value in the global configuration, the value is assumed to be 100.
    • Negative values have the special effect of excluding other connections with a greater numerical

…so it's the priority value, fr fr; so in presence of at least one negative priority, only connections with the lowest priority value will be used to determine the hostname. πŸ’…


Link settings, bestie β€” all the NIC-level knobs, and yes every single one of them defaults to -1 because that means "leave whatever's already there alone" 😌

  • gro-max-size β€” int64, default -1. The maximum size of a packet built by the Generic Receive Offload stack for this device. The value must be between 0 and 4294967295. When set to -1, the existing value is preserved.
  • gso-max-segments β€” int64, default -1. The maximum segments of a Generic Segment Offload packet the device should accept. The value must be between 0 and 4294967295. When set to -1, the existing value is preserved.
  • gso-max-size β€” int64, default -1. The maximum size of a Generic Segment Offload packet the device should accept. The value must be between 0 and 4294967295. When set to -1, the existing value is preserved.
  • tx-queue-length β€” int64, default -1. The size of the transmit queue for the device, in number of packets. The value must be between 0 and 4294967295. When set to -1, the existing value is preserved.
ok so literally every one of these is "between 0 and 4294967295, and -1 means don't touch it" β€” the range is the whole vibe, memorize it once and you're golden ✨

πŸ¦‹ loopback setting

Loopback Link Settings β€” just the one key, she's lowkey but she matters 🫢

  • mtu β€” uint32, default 0. If non-zero, only transmit packets of the specified size or smaller, breaking larger packets up into multiple Ethernet frames.

🌸 ovs-external-ids setting

OVS External IDs Settings β€” it's giving "one key, one dict, endless possibilities" πŸ’œ

  • data β€” dict of string to string, default {}. A dictionary of key/value pairs with external-ids for OVS.

🌈 ovs-other-config setting

OVS Other Config Settings β€” same shape as the last one, different destination πŸŽ€

  • data β€” dict of string to string, default {}. A dictionary of key/value pairs with other_config settings for OVS. See also "other_config" in the "ovs-vswitchd.conf.db" manual for the keys that OVS supports.
ngl bestie, that cross-reference is doing the heavy lifting here β€” go read the "ovs-vswitchd.conf.db" manual if you actually wanna know which keys OVS accepts, because this page is not about to list them all for you πŸ’€

πŸ’… prefix-delegation setting

Ok so these are the IPv6 prefix delegation settings β€” the lil' knobs for when your interface is getting its prefixes handed down from upstream. Slay. 🌈

  • subnet-id β€” type int64, default value -1. This is the subnet ID you wanna use on the interface from the prefix delegation received via an upstream interface. Set it to a value between 0 and 0xffffffff (that's 2^32 - 1 bestie, huge range iykyk) to indicate a specific subnet ID. Or set it to -1 and let the system automatically choose an available subnet ID for you β€” very much giving "not me making decisions today." πŸ¦‹

✨ veth setting

Veth Settings, aka the virtual ethernet situation. πŸŽ€

  • peer β€” type string, default value is empty (yep, blank!). This property specifies the peer interface name of the veth. And heads up: this property is mandatory. Like, no peer, no veth. Periodt. πŸ”₯

🫢 Secret flag types

Okay so this is important β€” every password or secret property in a setting has an associated flags property that describes how to handle that secret. The flags property is a bitfield that contains zero or more of the following values logically OR-ed together. (Bitfield math, we love to see it. ⭐)

  • 0x0 (none) β€” the system is responsible for providing and storing this secret. This may be required so that secrets are already available before the user logs in. It also commonly means that the secret will be stored in plain text on disk, accessible to root only. For example via the keyfile settings plugin as described in the "PLUGINS" section in NetworkManager.conf(5). πŸ‘€ (yes, plain text, be aware bestie.)
  • 0x1 (agent-owned) β€” a user-session secret agent is responsible for providing and storing this secret; when it is required, agents will be asked to provide it. πŸ’œ
  • 0x2 (not-saved) β€” this secret should not be saved but should be requested from the user each time it is required. This flag should be used for One-Time-Pad secrets, PIN codes from hardware tokens, or if the user simply does not want to save the secret. honestly relatable. πŸ™ˆ
  • 0x4 (not-required) β€” in some situations it cannot be automatically determined that a secret is required or not. This flag hints that the secret is not required and should not be requested from the user. πŸ“

🌸 FILES

/etc/NetworkManager/system-connections or distro plugin-specific location

(yes, "or distro plugin-specific location" β€” your distro might have its own spot, that's literally what it says ✨)


πŸ‘‘ SEE ALSO

Go read these next, bestie, they're iconic:


and that's a wrap on the whole page!! πŸŽ‰ you read the entire NM-SETTINGS-DBUS(5) manpage, which is honestly main character energy. go touch some grass, then come back and configure ur network. πŸ’–

NetworkManager 1.58.0 Β· NM-SETTINGS-DBUS(5) β€” that's the version and the manpage name right there for you, mwah πŸ«ΆπŸ’…βœ¨

πŸ“¦ where this page comes from