WICKED-CONFIG(5)

📦

version 0.6.80 · 2 versions

0.6.80 · opensuse-leap 16.0 (latest)
0.6.77 · fedora 43, fedora 44

💖 NAME 💖

wicked-config.xml — the wicked configuration file, aka wicked-config(5) from the File Formats Manual. Bestie, this is the main character config doc. 💅

✨ SYNOPSIS ✨

/usr/etc/wicked/common.xml
/usr/etc/wicked/server.xml
/usr/etc/wicked/client.xml
/usr/etc/wicked/nanny.xml

🎀 DESCRIPTION 🎀

Okay so these files contain the global configuration options for the wicked network management service components. All files follow the same XML schema. No cap.

⚠️ Note: Make sure to restart the wickedd service to apply changes. Like, actually restart it. Don’t just vibe and hope. 😭

common.xml — This configuration file contains definitions common to all wicked network management service components.

local.xml — This configuration file, if present, is included by the common.xml and intended for common custom definitions that will not be overwritten by a wicked update. It’s your little safe space, bestie. 🫶

Wicked components will load different component specific config files at start. For instance, the wickedd server process will try to load server.xml, which includes common.xml and the specific custom server-local.xml if present. If the server.xml file does not exist, it will fall back to load the common.xml file directly. Lowkey flexible.

Wicked searches these configuration files and their includes first in the system configuration directory /etc/wicked, intended for locally provided files, and then in the distribution configuration directory /usr/etc/wicked. A file found in the system directory takes precedence over a file with the same name in the distribution directory. System dir wins. Periodt.

The following table shows which wicked components use which configuration file — same facts, now in cute list form:

wicked — load-config: client.xml, custom-config: client-local.xml
wickedd — load-config: server.xml, custom-config: server-local.xml
wickedd-nanny — load-config: nanny.xml, custom-config: nanny-local.xml
(common) — load-config: common.xml, custom-config: local.xml

We do not ship specific configurations for the dhcp6, dhcp4 and auto4 supplicants. Custom settings for these supplicants should be placed in local.xml file. That’s the move. 💫

🌸 GENERAL OPTIONS 🌸

The configuration file is an XML document; its root node must be called <config>. Respect the root node, bestie.

🎀 `include`

This element can be used to refer to an additional XML configuration file. When parsing a configuration file, wicked will traverse the XML hierarchy once, in the order in which elements occur in the file. The file referenced by an <include> element is loaded and parsed at the time the <include> element is encountered.

Note that the contents of the file will not be “included” in the way you would expect this from e.g. a macro preprocessor. Instead, the referenced file must be a proper XML document, and its top node must also be a config element.

The file or directory to include is selected with one of the following attributes:

name — Includes a single file. The file name is looked up in the configuration search path, that is the system directory /etc/wicked first and then the distribution directory /usr/etc/wicked.
dir — Includes all *.xml files found in the given directory, in alphabetical order. The directory name is resolved in the configuration search path and the contents of all matching directories are merged; a file name found in the system directory masks the same file name in the distribution directory.

The boolean optional attribute permits to silently ignore a missing file or directory if set to true (default false). Ghosting a missing file, but politely. 🙈

Custom config include example, /etc/wicked/local.xml:

<config>
  <addrconf>
    <dhcp4>
      <create-cid>rfc2132</create-cid>
    </dhcp4>
    <dhcp6>
      <default-duid per-device="true"/>
    </dhcp6>
  </addrconf>
  <include name="custom-dhcp-options.xml" optional="true"/>
  <include dir="local" optional="true"/>
</config>

🛣️ Common pathnames

💫 `piddir`

This element specifies the directory used to write pid files.

The path attribute of this element contains the path to this directory. The optional mode attribute can be used to specify the permissions of this directory.

The default is to use /run/wicked, mode 0755.

<statedir path="/run/wicked" mode="0755" />

💫 `statedir`

This element specifies the location of the directory containing various files relating to the state of the server. For instance, temporary files are stored here when starting external programs like pppd(8).

The path attribute of this element contains the path to this directory. The optional mode attribute can be used to specify the permissions of this directory.

The default is to use /run/wicked, mode 0755.

<statedir path="/run/wicked" mode="0755" />

💫 `storedir`

This element specifies the location of the directory containing various (reboot) persistent data. For instance, the DHCP DUID and lease files are stored in this directory.

The path attribute of this element contains the path to this directory. The optional mode attribute can be used to specify the permissions of this directory.

The default is to use /var/lib/wicked, mode 0755.

<statedir path="/var/lib/wicked" mode="0755" />

🌈 Miscellaneous

💫 `debug`

This element specifies the default debug facilities to be enabled. Allowed is a comma separated list of supported facility names, including set names such as all and most and names with a - prepended for negated facilities, e.g. "all,-xpath".

The wicked --debug help command shows valid facility names. If a debug level is specified on the command line or via the WICKED_DEBUG environment variable, the setting from the XML configuration file will be ignored. CLI and env var said “not today,” bestie. 💀

🫶 DBus service parameters

All configuration options related to the DBus service are grouped below the <dbus> element. Currently, the following child elements are recognized:

💫 `service`

This element specifies the DBus service name used, and must be a valid DBus API name. The default is "org.opensuse.Network".

💫 `schema`

This element specifies the location of the schema files. The schema defines the various DBus APIs offered by the server, and how portions of an interface XML description map to their arguments. The schema files do not contain user-serviceable parts, so it’s best to leave this option untouched. Hands off, icon. ✋

Here’s what the default configuration looks like:

<dbus>
  <service name="org.opensuse.Network" />
  <schema name="/usr/share/wicked/schema/wicked.xml" />
</dbus>

👑 CLIENT ONLY OPTIONS 👑

🦋 `sources`

This specifies a list of sources that the wicked client will pick up interface configurations from, and their load order. Child elements of <sources> must be called ifconfig, and are expected to specify a location attribute.

The location attribute takes the form type:string, where string may be empty.

firmware — Get configuration from firmware, usually iBFT
compat — Load interface description using legacy ifcfg files
wicked — Load interface description using native wicked XML

The firmware type takes no additional string parameter. When specifying either wicked, you can optionally specify a directory where to look for XML interface configurations. If no directory is given, the path defaults to /etc/wicked/ifconfig. When specifying either compat, you can optionally specify the ifcfg flavor, which can be either suse or redhat. If no flavor is specified, the result is implementation dependent — but usually, it will pick the platform default it was compiled on. It’s giving “trust the build,” bestie. 🧚

The default configuration is this:

<sources>
  <ifconfig location="firmware:" />
  <ifconfig location="compat:" />
  <ifconfig location="wicked:" />
</sources>

🦋 ADDRESS CONFIGURATION OPTIONS 🦋

Okay so the <addrconf> element is evaluated by server applications only — yes bestie, server side, not your lil client era — and it controls the behavior of dynamic address configuration protocols such as DHCP. This is where you blacklist stuff (e.g. certain DHCP servers) and choose which information provided by address configuration actually gets applied. 💅

`default-allow-update`

Most dynamic address configuration protocols, including DHCP, do not just provide a list of addresses and routes to install for the managed network interface. They can also be used to provide information such as a list of DNS servers, directory information (for e.g. NIS), etc. A system receiving that information is free to reconfigure some of its services based on this information. For instance, it makes a lot of sense to configure the resolver library to use the DNS servers specified by a DHCP server. On the other hand, you may want to ignore any NIS information received via DHCP.

The <default-allow-update> is applied to static and intrinsic leases, which do not have their own, type and address family specific <allow-update> element as available under the <dhcp6>, <dhcp4>, <auto6> and <auto4> sub-elements, which support a subset of the possible facilities listed here. The <default-allow-update> and the type specific <allow-update> elements enable you to control which system services wicked will (request and) consider to update in the system.

It contains a list of either empty XML elements e.g. (<dns/><ntp/>) naming the system facilities or alternatively, a space separated string list (dns ntp) with the facility names. The special elements default, none and all enable and disable the default, none and all updates, respectively. A no- or a - in front of a facility name permits to remove/disable a facility from the currently applied set and enable further supported facilities, e.g. default,-nis,slp is applying a modified default set with disabled nis and the optional slp facility enabled additionally.

The following updater facilities are currently defined:

default-route — system default route (IPv4 or IPv6)
hostname — system hostname
dns — update resolv.conf or dns server (via netconfig)
nis — NIS client (via netconfig)
ntp — NTP servers (via netconfig)
smb — SMB settings (no netconfig module implemented)
nds — NDS servers (no netconfig module implemented)
slp — SLP client (no netconfig module implemented)
sip — SIP client (no netconfig module implemented)
log — syslog servers (no netconfig module implemented)
lpr — print servers (no netconfig module implemented)
tz — posix time zone (no netconfig module implemented)
mtu — adjust interface mtu (dhcp4)
boot — root-path (dhcp4)/boot-url (dhcp6) used in the initrd

Note: administrators wishing to support currently unimplemented updaters can do so by configuring external updaters using the <system-updater> extensions described below. 🫶

`dhcp4`

This element can be used to control the behavior of the DHCP4 supplicant. See below for a list of options.

`dhcp6`

This element can be used to control the behavior of the DHCP6 supplicant. See below for a list of options.

`auto6`

This element can be used to control the behavior of AUTO6 processing.

`arp`

This element can be used to control ARP verify and ARP notify settings. See ARP CONFIGURATION OPTIONS for more info.

🎀 ARP CONFIGURATION OPTIONS 🎀

The ARP configuration specifies the verify and notify settings used by wicked for duplicate address detection. If specified as child of <config><addrconf> the settings apply to STATIC only. To change the ARP settings for AUTO4 or DHCP4, add the <arp> node as child of the corresponding <config><addrconf><auto4> or <config><addrconf><dhcp4> node.

         <arp>
           <verify>
             <count></count>
             <retries></retries>
             <interval>
               <min></min>
               <max></max>
             </interval>
           </verify>
           <notify>
             <count></count>
             <interval></interval>
             <retries></retries>
           </notify>
         </arp>

count — This element can specify the number of ARP packets send.
retries — This element specify the number of retries while sending ARP packages.
interval — This element specify the delay between each ARP package in milliseconds. For <verify> it can be a range specified via <min> and <max>.

💖 DHCP4 SUPPLICANT OPTIONS 💖

Okay bestie, so the DHCP4 client has its own lil' set of knobs, and every single one of them has to live nested inside the config node, like this:

<addrconf>
  <dhcp4>
    ...
  </dhcp4>
</addrconf>

…or, if you're feeling per-device about it, inside a device name context like:

<addrconf>
  <dhcp4>
    <device name="eth0" >
      ...
    </device>
  </dhcp4>
</addrconf>

That's the whole vibe check. Now let's meet the options 💅

`create-cid`

Specifies the standard client-id type to use. Here's the lineup 👑

rfc4361 / alias dhcp6 — use 0xff as type, followed by DHCPv6 IAID and DUID
rfc2132 / alias hwaddr — use hardware/link layer type, followed by the address
disable / alias none — disables creation (custom client-id is send if given)

When the interface configuration does not provide an explicit client-id (DHCLIENT_CLIENT_ID in ifcfg files or <client-id> xml config/policy node), wicked will generate a DHCPv4 client-id as specified in this option. Slay, it just handles it for you 🫶

When set to rfc4361, wicked will create a DHCPv4 client-id using the DHCPv6 IAID and DUID (see <dhcp6><default-duid> option). This new rfc4361 client-id is required to perform DDNS updates for ipv4 (A) and ipv6 (AAAA) address records in the same DNS zone (domain) and mandatory to use on infiniband interfaces. So like, no cap, you need this one for those cases 🔥

When set to rfc2132, wicked will create a DHCPv4 client-id using the network interface hardware-type and address. This may be needed to maintain compatibility to e.g. DHCPv4 servers with static leases explicitly bound to a rfc2132 client-id or having trouble to provide a lease to a dhcp4 client using the new and longer rfc4361 client-id. Old-server core, honestly 🎀

When set to disable, no client-id is created and send by default (except when the interface config request to acquire a lease contains a custom/explicit one).

When unspecified, the default behavior depends on the --enable-dhcp4-rfc4361-cid (default) and --disable-dhcp4-rfc4361-cid configure options, allowing to revert to use the old rfc2132 client-id at compile time, i.e. to prereserve behavior like in older releases, but permit to change to enable the new rfc4361 client-id default at runtime.

⚠️ Note, that a change of the client-id usually causes to disassociate the lease and/or DNS records, because it is used in the DHCID DNS record (see rfc4701). Bestie, don't just flip this one for fun 😭

`vendor-class`

Specifies the string to be used as the vendor-class option in the DHCP request. By default, no vendor-class option is sent. Literally nothing, silence, iconic quiet-luxury energy ✨

`lease-time`

Specifies the lease time to request in the DHCP request, in seconds. This also caps the lease time that can be requested in an interface configuration — any lease-time specified there will be silently limited to what was specified in the global configuration file. So the global config is the main character here 👑

The following will set the default lease time to one hour:

<lease-time>3600</lease-time>

`ignore-rfc3927-1-6`

The 169.254.0.0/16 prefix is reserved for dynamic configuration of IPv4 link-local addresses, prohibited for other purposes by RFC3927 Section 1.6 and wickedd-dhcp4 supplicant rejects to request them in offers provided by DHCP servers. Administrators should use the RFC1918 prefixes (192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8) in their DHCP servers instead. Like, those are the correct ones, okay? 🌸

Enabling this option causes to ignore the RFC3927 Section 1.6 Alternate Use Prohibition:

<ignore-rfc3927-1-6>true</ignore-rfc3927-1-6>

`ignore-server`

Using the ip attribute of this element, you can specify the IP or HW address (currently ethernet devices only) of a faulty DHCP server that should be ignored. Blocked. Blocked. Blocked. 🙈

<ignore-server ip="192.168.8.1" />
<ignore-server mac="52:54:00:02:c2:67" />

`prefer-server`

Specify a preferred DHCP server, together with a numeric value indicating its preference. Again, the address of the server is specified using the ip or mac attribute.

The numeric preference value is given by the weight, and should range from -1 to 100. Higher numbers indicate a higher preference. A negative value will cause the server to be ignored. If a response from a server with a weight of 100 is received, it will be selected immediately. Otherwise, the supplicant will wait for about one second, and select the server with the highest preference afterwards. Casual one-second deliberation, very demure 💅

The special keywords never and always correspond to -1 and 100, respectively. If no weight attribute is given, it defaults to always (100).

The following example will ignore 192.168.8.1, always use the information from 192.168.8.10 if available, and fall back to 192.168.8.7 if not:

<prefer-server ip="192.168.8.1"  weight="never" />
<prefer-server mac="02:03:04:05:06:07" weight="always" />
<prefer-server ip="192.168.8.7"  weight="50" />

`allow-update`

Specify the list of system services that wicked will configure based on the DHCP lease received. For the syntax of this element, please refer to the description of default-allow-update above. dhcp4 supports all update facilities. All of them. Overachiever behavior, we love to see it ⭐

`route-options`

Specify a space separated list of routing options to request from dhcp4 server. The options on the menu are:

classless / alias csr — RFC 3442 classless static route option 121
ms-classless / alias mscsr — MS classless static route option code 249 (pre RFC 3442)
static-routes / alias class — Obsolete option 33 requesting static class routes

The RFC 3442 classless static route option provides all routes with a netmask, includes the default routers and has priority over other routing options. By default, wicked requests classless (121) as well as class static routes (33) and the default routers option (3) (when enabled in allow-update) to be compatible to old servers or servers not configured to provide classless, but only a default router option. Generous queen, looking out for the legacy servers 🧚

`define`

Permits to define list of custom dhcp options not covered by wicked yet. The dhcp4 option codes are 8-bit (1..254) bytes.

For non-standard options, it is recommended is to use the DHCPv4 private option code range 224 to 254, see RFC3942 (section 4), RFC 2939 and www.iana.org/assignments/bootp-dhcp-parameters to avoid conflicts with options that are or may be defined and implemented later. Don't be out here squatting on codes, bestie 😤

See CUSTOM DHCP OPTIONS section for more details.

`arp`

This element can be used to control ARP verify and ARP notify settings. See ARP CONFIGURATION OPTIONS for more info. 🦋

✨ DHCP6 SUPPLICANT OPTIONS ✨

Okay bestie, this is where the DHCP6 client gets its whole personality configured. Every single one of these options has to be nested in the config node, like this:

<addrconf>
  <dhcp6>
    ...
  </dhcp6>
</addrconf>

or, if you're being extra and want it per-device, inside a device name context like:

<addrconf>
  <dhcp6>
    <device name="eth0" >
      ...
    </device>
  </dhcp6>
</addrconf>

🎀 `default-duid`

So DHCPv6 identifies a client with a thing called a DUID, plus an IAID that points at an interface. And get this — DHCPv4 now also defaults to building its client-id out of the DHCPv6 IAID and DUID too (peep the <dhcp4><create-cid> option, iykyk). By default, wickedd-dhcp6 tries to generate a DUID based on the device's link layer address (MAC) and the time — that's DUID-LLT, bestie.

The default-duid element lets you override all that. Two ways to do it:

Specify an explicit DUID as a string of colon-separated hex octets, like:

<default-duid>00:03:00:01:02:00:00:00:00:02</default-duid>

Or give an advise on which duid type to construct or import, expressed in a child element:

<default-duid><duid type element/></default-duid>

...using one of these duid type elements 💅

`llt` — DUID type 1, Link-layer address plus time 🕰️

This one lets you specify the link/hardware type and address in its hardware and address elements, e.g.:

<llt>
  <hardware>ethernet</hardware><address>02:00:00:00:00:02</address>
</llt>

With no arguments, wicked creates the duid-llt using the hardware type and address of the actual device that requests a duid first. And the time inside the DUID? Set automatically to the duid creation time. Iconic behavior tbh.

`en` — DUID type 2, Vendor Based on IANA Enterprise Number 🏢

Lets you specify a vendor type DUID-EN based on the IANA assigned enterprise number and a machine identifier, given in the enterprise-number and identifier elements. Example using IANA number 7057, which is assigned to SUSE:

<en>
  <enterprise-number>7057</enterprise-number>
  <identifier>02:00:00:00:00:02</identifier>
</en>

`ll` — DUID type 3, Link-layer address (without time) ⚡

Usage is exactly like the type 1 duid llt, except the duid does not contain a time. No clock, just vibes.

`uuid` — DUID type 4, UUID-Based Unique Identifier 🦋

Lets you specify the effective UUID to use, e.g.:

<uuid>80d732e7-b8dc-45ef-bdae-f9f5e6925cef</uuid>

or import it from the /etc/machine-id file:

<uuid><machine-id/></uuid>

or use an explicit path to the machine-id file:

<uuid><machine-id>/etc/machine-id</machine-id></uuid>

or go for the DMI product id — which is problematic, it may not be available or may not be unique, so like... be aware:

<uuid><dmi-product-id/></uuid>

With no arguments, wicked tries to import the machine-id, falling back to the DMI product id when no machine-id file exists. Slay, but with a backup plan.

🫶 the `per-device` attribute

Also! The default-duid element supports a per-device attribute. When you enable it via <default-duid per-device="true"/>, wicked switches to a non-standard behavior and keeps a separate duid for each device, instead of one same ("default") DUID for all interfaces plus a per device/interface IAID.

Why would you want that? It works around some special cases where the host should appear to the server as multiple identities — basically behaving as multiple machines instead of as one machine with multiple interfaces. Main character energy, honestly.

The wickedd daemons store the generated DUIDs in /run/wicked/duid.xml. And the wicked duid utility command lets you review and modify the duid as needed. 💖

⏳ `lease-time`

Specifies the lease time to request in the DHCP request, in seconds. It also caps the lease time that can be requested in an interface configuration — any lease-time you set there gets silently limited to whatever you set in the global config file. No fighting, no warning, just vibes and caps.

The following sets the default lease time to one hour:

<lease-time>3600</lease-time>

📤 `release-retransmits`

Specifies the number of lease release retransmissions, in the range 1..5. Default is to send up to 5 (REL_MAX_RC) retransmissions. That's it, that's the option 🌸

🔄 `info-refresh-time`

Specifies a different default for the RFC4242 info refresh time, used when the dhcp6 server doesn't provide any. It also lets you adjust the acceptable time range via the min and max attributes, e.g.:

<info-refresh-time min= 600" max="604800">86400</info-refresh-time>

Yes, that's exactly how it's written in the original page. Not me, bestie. Copy it character for character and you'll be fine 🙈

👑 `prefer-server`

Specify a preferred DHCP server, along with a numeric value indicating its preference. The server is identified by its DUID, which has to be specified via the id attribute.

The numeric preference value comes from weight, and should range from -1 to 255. Higher numbers = higher preference. A negative value causes the server to be ignored. And if a response arrives from a server with a weight of 255, it gets selected immediately — no waiting, no deliberation, periodt.

Otherwise, the supplicant waits for about one second, then selects the server providing an offer with the best request match and the highest preference afterwards.

The special keywords never and always correspond to -1 and 255, respectively. If no weight attribute is given, it defaults to always (255).

The following example ignores DHCP offers from the first server, always uses the information from the second (if available), and falls back to the third if not:

<prefer-server id="00:03:00:01:02:03:04:05:06:07" weight="never" />
<prefer-server ip="2001:DB8::1" weight="always" />
<prefer-server ip="2001:DB8::2" weight="50" />

🛠️ `allow-update`

Specify the list of system services that wicked will configure based on the DHCP lease it received. For the syntax of this element, go check out the description of default-allow-update above ☝️

DHCPv6 allows the following update facilities:

hostname — system hostname (fqdn)
dns — update resolv.conf or dns server (via netconfig)
ntp — NTP servers (via netconfig)
sip — SIP client (optional, no netconfig module implemented)
nis — NIS client (optional, no netconfig module, not supported by ypbind)
tz — posix time zone (no netconfig module implemented)
boot — boot-url used in the initrd

Note: the DHCPv6 protocol does not provide any options to request routing settings — those are applied via a router advertisement (IPv6 RA). So don't come looking here for routes, bestie, they're simply not in the protocol 😭

🧚 `define`

Permits you to define a list of custom dhcp options that wicked doesn't cover yet. The dhcp6 option codes are 16-bit (1..65534) integers.

See http://www.iana.org/assignments/dhcpv6-parameters and RFC7227.

See the CUSTOM DHCP OPTIONS section for more details. 💜

Note: the DHCPv6 protocol does not define any routing options — those are applied by IPv6 Router Advertisement (RA) or require static configuration. And the current NIS / ypbind implementation on linux does not support IPv6 at all. F in the chat for NIS 🫡

🧩 CUSTOM DHCP OPTIONS 🧩

Okay so a custom option gives a dhcp option code a name and a format for interpreting that option’s raw data. This option definition is used to parse and format lease-xml files, (format) leaseinfo dump files, and the name can be used to request options (oro alias option-request-option). 💅

The name has to be a valid keyword and is restricted to a word of 1..63 alphanumeric and - characters (same as a hostname without any dots). No cap.

The current implementation supports the following simple types (scalars):

opaque [fixed-length="<length in bytes>" | embedded-length="1|2|uint8|uint16"] — opaque data or a not-printable string formatted as a hex-string (xx:xx:xx) with variable length. The fixed-length attribute lets you adjust it to a \0-padded fixed-length data field, and embedded-length interprets the initial 1 (uint8) or 2 (uint16) bytes as the data length (RFC7227).
string [fixed-length="<length in bytes>" | embedded-length="1|2|uint8|uint16"] — a printable variable-length string (without a \0 null-termination). The fixed-length attribute lets you adjust it to a \0-padded fixed-length string, and embedded-length interprets the initial 1 (uint8) or 2 (uint16) bytes as the string length (RFC7227).
bool — a single byte value interpreted as a boolean (0 is "false", otherwise "true").
int8 | int16 | int32 | int64 uint8 | uint16 | uint32 | uint64 [notation="hex"] — a signed or unsigned integer in decimal, or optionally in a 0x.. hex notation.
ipv4-address | ipv6-address — IPv4 and IPv6 address types.
ipv4-prefix | ipv6-prefix — an RFC3442 / RFC7227 prefix (destination descriptor) with a compact encoded prefix-length byte followed by the significant octets of the network address.

These simple types can be combined together in structs and arrays.

A struct consists of one or more members, each with a name and a member type (simple type, struct, or array). The last member in a struct is allowed to be a variable-length type. An array contains an element name and a fixed-length type or struct.

A simple type can be specified in the node name (<string/>) or in the data of the type node (<type>string</type>).

Examples:

         <!--
              global or device specific definitions of dhcp4/dhcp6 options
              under <config><addrconf><dhcp4> or <config><addrconf><dhcp6>
         -->
         <define>
           <option>
             <code>224</code>
             <name>foo-server</name>
             <type>ipv4-address</type>
           </option>
           <option>
             <code>225</code>
             <name>foo-path</name>
             <string/>
           </option>
           <option>
             <code>250</code>
             <name>test-cls-routes</name> <!-- RFC3442 classless route format -->
             <array>
               <name>route</name>
               <struct>
                 <member>
                   <name>destination</name>
                   <ipv4-prefix/>
                 </member>
                 <member>
                   <name>gateway</name>
                   <ipv4-address/>
                 </member>
               </struct>
             </array>
           </option>
           <option>
             <code>251</code>
             <name>six-addresses</name>
             <array>
               <name>ip</name>
               <ipv6-address/>
             </array>
           </option>
         </define>

To test the option definition, the "wicked test" call can be used:

        wicked test dhcp4 --request - eth1 <<EOF
         <request type= offer">
           <request-options>
             <option>224</option>
             <option>test-cls-routes</option>
           </request-options>
         </request>
        EOF

Do that before adding the option requests to the ifcfg or xml configuration and restarting wickedd (rcwickedd restart) to apply to the supplicant. 🫶

🛰️ SERVER ONLY OPTIONS 🛰️

💅 teamd

The <teamd> element permits you to enable or disable teamd support (inclusive discovery of team device details) in its <enable> sub-element. Disabled by default, server.xml config enables it. Further, it permits you to specify the control interface to communicate with teamd in the <ctl> sub-element, using the following options:

detect-once — detect the control interface to use, once (default)
detect — detect the control interface to use in each call
dbus — communicate directly with teamd via dbus
unix — use unix socket control interface via teamdctl tool

🧲 bonding

The <bonding> element permits you to specify whether to use netlink or sysfs to configure the bonding in its <ctl> sub-element:

netlink — configure bonding via netlink (default)
sysfs — configure bonding via sysfs (the old way)

🌈 EXTENSIONS 🌈

The functionality of wickedd can be extended through external commands and shell scripts. All of these extensions are declared in server.xml, and all of them follow the same pattern.

🧚 Script extensions 🧚

Scripts are specified via the <script> element, which needs to provide a name attribute and a command attribute. Again, the name serves as an identifier, while the command specifies the command to be invoked. wicked comes with a (simple) parser for this, which splits up this command into an argument array which is passed to execve(2) eventually.

An example would look like this:

  <script name="install"
          command="hostname install"/>

The command is looked up in the extensions search path: the system extensions directory /etc/wicked/extensions, and then the distribution extensions directory /usr/libexec/wicked/extensions. An absolute command path that points into this search path is migrated to a plain relative reference while the configuration is parsed.

When defining script extensions, it is possible to define additional environment variables that get passed to the script. This mechanism is explained in more detail below.

Extensions are always grouped under a parent element. The following configuration elements can contain extensions:

🖥️ System updaters 🖥️

These specify extensions for managing files like resolv.conf, or the system hostname, based on information contained through an address configuration protocol like DHCP. The configuration element must have a name attribute that specifies the system service to configure, and include extensions for backing up the current configuration, for installing new settings, and for restoring the backup.

The configuration for the hostname updater might look like this:

  <system-updater name= hostname">
    <script name="backup" command="hostname backup"/>
    <script name="restore" command="hostname restore"/>
    <script name="install" command="hostname install"/>
    <script name="install" command="hostname remove"/>
  </system-updater>

Currently, wicked supports generic and hostname system updaters. The generic updater operates on data which can be set via netconfig (refer to netconfig(7)). The hostname updater sets the system hostname.

This extension class supports shell scripts only.

📡 Firmware discovery 📡

Some platforms support iBFT or similar mechanisms to provide the configuration for a network device through the firmware (so that it’s possible to boot off that device). In order to support these mechanisms, wicked supports extensions to discover such configuration from a firmware.

  <netif-firmware-discovery name= ibft">
    <script name= show-config" command="ibft" />
    <script name= list-ifnames" command="ibft -l" />
  </netif-firmware-discovery>

When looking for firmware interface configuration, wicked will invoke these scripts for all defined/selected firmware extension types in turn and parses their output.

show-config — the script command is expected to return XML output that contain zero or more <interface> nodes with the network interface configuration.
list-ifnames — the script command is expected to return lines with a space separated list of interface names the firmware configures (incl. virtual interfaces like vlans).

This extension class supports shell scripts only. The wicked-firmware(8) command allows you to list available extensions, the interfaces they configure and maintenance actions such as to enable/disable the execution of the firmware-discovery scripts.

wicked FAQ: https://github.com/openSUSE/wicked/wiki/FAQ

🐛 BUGS 🐛

Please report bugs as described at <https://bugs.opensuse.org>

👑 AUTHORS 👑

Olaf Kirch
Karol Mroz
Nirmoy Das
Rubén Torrero Marijnissen
Marius Tomaschewski

And that’s the whole WICKED-CONFIG(5) era — the source/version is this very page, dated 16 July 2012. Love that for us, bye bestie 💖✨

📦 where this page comes from

opensuse-leap 16.0: wicked 0.6.80-bp160.2.1 · GPL-2.0-or-later
opensuse-leap 16.0: wicked 0.6.80-bp160.2.1 · GPL-2.0-or-later
opensuse-leap 16.0: wicked 0.6.80-bp160.2.1 · GPL-2.0-or-later
opensuse-leap 16.0: wicked 0.6.80-bp160.2.1 · GPL-2.0-or-later
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on 2026-11-04: a language model's rewrite of the original, under its terms

WICKED-CONFIG(5)

💖 NAME 💖

✨ SYNOPSIS ✨

🎀 DESCRIPTION 🎀

🌸 GENERAL OPTIONS 🌸

🎀 include

🛣️ Common pathnames

💫 piddir

💫 statedir

💫 storedir

🌈 Miscellaneous

💫 debug

🫶 DBus service parameters

💫 service

💫 schema

👑 CLIENT ONLY OPTIONS 👑

🦋 sources

🦋 ADDRESS CONFIGURATION OPTIONS 🦋

default-allow-update

dhcp4

dhcp6

auto6

arp

🎀 ARP CONFIGURATION OPTIONS 🎀

💖 DHCP4 SUPPLICANT OPTIONS 💖

create-cid

vendor-class

lease-time

ignore-rfc3927-1-6

ignore-server

prefer-server

allow-update

route-options

define

arp

✨ DHCP6 SUPPLICANT OPTIONS ✨

🎀 default-duid

llt — DUID type 1, Link-layer address plus time 🕰️

en — DUID type 2, Vendor Based on IANA Enterprise Number 🏢

ll — DUID type 3, Link-layer address (without time) ⚡

uuid — DUID type 4, UUID-Based Unique Identifier 🦋

🫶 the per-device attribute

⏳ lease-time

📤 release-retransmits

🔄 info-refresh-time

👑 prefer-server

🛠️ allow-update

🧚 define

🧩 CUSTOM DHCP OPTIONS 🧩

🛰️ SERVER ONLY OPTIONS 🛰️

💅 teamd

🧲 bonding

🌈 EXTENSIONS 🌈

🧚 Script extensions 🧚

🖥️ System updaters 🖥️

📡 Firmware discovery 📡

👀 SEE ALSO 👀

©️ COPYRIGHT ©️

🐛 BUGS 🐛

👑 AUTHORS 👑

🎀 `include`

💫 `piddir`

💫 `statedir`

💫 `storedir`

💫 `debug`

💫 `service`

💫 `schema`

🦋 `sources`

`default-allow-update`

`dhcp4`

`dhcp6`

`auto6`

`arp`

`create-cid`

`vendor-class`

`lease-time`

`ignore-rfc3927-1-6`

`ignore-server`

`prefer-server`

`allow-update`

`route-options`

`define`

`arp`

🎀 `default-duid`

`llt` — DUID type 1, Link-layer address plus time 🕰️

`en` — DUID type 2, Vendor Based on IANA Enterprise Number 🏢

`ll` — DUID type 3, Link-layer address (without time) ⚡

`uuid` — DUID type 4, UUID-Based Unique Identifier 🦋

🫶 the `per-device` attribute

⏳ `lease-time`

📤 `release-retransmits`

🔄 `info-refresh-time`

👑 `prefer-server`

🛠️ `allow-update`

🧚 `define`