FAQ

Frequently Asked Questions

Q: Why is DHCLIENT6_MODE=managed insufficient when IPv6 router advertisement is missed.

Since wicked 0.6.55, we have updated wicked to follow the behavior described in RFC5942. This means we no longer assume that the directly connected IPv6 network prefix-length is /64, and we instead now apply the DHCPv6 IPv6 address with a /128 prefix-length while we don't trigger a direct route creation anymore in the kernel for the local network.

Problem: DHCPv6 does not provide a prefix-length for the IPv6 address, which are created by the kernel when a RA contains a prefix XXX/YY { AdvOnLink on; }

Workaround: set also DHCLIENT6_ADDRESS_LENGTH=YY (e.g. 64) together with the DHCLIENT6_MODE=managed to assume that the IP address prefix is on-link and has the specified prefix-length (e.g. /64).

Solution: configure a router sending IPv6 router advertisement with AdvManagedFlag on and a prefix ${your_network}/${cidr} {} (slaac + dhcp6) or prefix ${your_network}/${cidr} {} { AdvAutonomous off; } (dhcp6 only). To avoid a default route on the client / hosts, set also AdvDefaultLifetime 0 in the RA.

Q: Why is wicked unable to provide a DHCPv4 lease on newer versions?

DHCP is using a "client identifier" (client-id) option (DHCPv4/DHCPv6) to identify a DHCP client to the DHCP server, which is using the identifier to index their database of address bindings. The client-id is expected to be unique for all clients in the same administrative domain. The RFC4361 updates DHCPv4 clients to use a DHCPv6 compatible client-identifier, which is required to perform dynamic DNS updates for IPv4 (A) and IPv6 (AAAA) address records in the same DNS zone/domain and is mandatory to use for InfiniBand / IPoIB interfaces where the hardware address is too long to fit into the DHCPv4 header. It also permits to use other, non-hardware address based client-identifiers like Enterprise specific DUID-EN and UUID based DUID-UUID identifiers for both, DHCPv4 and DHCPv6.

Wicked changed its defaults to use this DHCPv6 compatible RFC4361 client-id in favour of the older RFC2132 client-id. However, this has caused some issues with older DHCPv4 servers and existing setups where the client-id stored by the server is used to assign a (static) address. It is recommended to fix this server-side, but still, wicked provides several ways of addressing this issue:

The sysconfig ifcfg-<ifname> file can contain a DHCLIENT_CLIENT_ID variable (see man 5 ifcfg-dhcp), allowing to manually set the desired client-id, e.g.
```
DHCLIENT_CLIENT_ID='01:00:01:02:03:04:05'
```
which is an "old" (rfc2132) client-id where the 1st byte 01 is the number of ethernet hardware-type, followed by 6 bytes with the ethernet hardware/MAC address '00:01:02:03:04:05`.
The DHCLIENT_CLIENT_ID can be passed as kernel/boot parameter to the linuxrc installer as:
```
ifcfg=00:01:02:03:04:05=dhcp4,DHCLIENT_CLIENT_ID=01:00:01:02:03:04:05
```
In wicked xml config files (/etc/wicked/ifconfig) the client-id can be defined inside the <ipv4:dhcp> node, e.g.
```
<ipv4:dhcp><client-id>01:00:01:02:03:04:05</client-id></ipv4:dhcp>
```
The format is the same as visible in the wicked show-config command output.
When the configuration does not provide any client-id for a device, wicked is using the settings defined in the wicked-config (see man 5 wicked-config) to generate a client id, which also permits to change the behavior to use a rfc4321 client-id again by creating an /etc/wicked/local.xml with the following content:
```
<config><addrconf><dhcp4><create-cid>rfc2132</create-cid></dhcp4></addrconf></config>
```
See man 5 wicked-config man page for more details.
When there is no advise in wicked-config(5) which one to generate, a compile time default is used, which can be specified using the --enable-dhcp4-rfc4361-cid/--disable-dhcp4-rfc4361-cid via configure options.

Q: Why does wicked not request DHCPv6 IP address on my card?

Wicked follows the network administrator configuration provided by the router in its advertisements (IPv6 RA) by default and starts DHCPv6 request if the Managed or OtherConfig flags in the RA forwarded to it by the kernel is enabled. When there is no IPv6 router on the network, the router sends an IPv6 RA with DHCPv6 disabled, the firewall blocks icmpv6 traffic or the network card is incorrectly reporting carrier detection, wicked-dhcp6 may stay silent waiting for RA events.

Set FW_BOOT_FULL_INIT="yes" in /etc/sysconfig/SuSEfirewall2, so the SuSEfirewall2_init.service does not block icmpv6 packets. To provide/override the RA flags, set the DHCLIENT6_MODE=managed either in the ifcfg(5) file or in /etc/sysconfig/network/dhcp.

Q: My network is not IPv6 enabled, how to use DHCPv4 only?

Change the ifcfg(5) config file to use BOOTPROTO=dhcp4 instead of BOOTPROTO=dhcp. To disable IPv6 completely, you can use either sysctl.conf(5) config file:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

or the ipv6.disable=1 kernel boot parameter, e.g. in the GRUB_CMDLINE_LINUX variables of /etc/default/grub.

Q: Why is wicked not setting IP address on my network card?

The network card probably does not have carrier.

Wicked monitors events and states and preforms the setup steps according to state and layering of network device. Once the carrier is detected (and e.g. wireless link authentication was successful), it will start verifying the IP addresses for duplicates and applying them.

To break the rules and apply the IP address before the carrier is detected and layer 2 setup finished, you can disable it per interface using LINK_REQUIRED=no in the ifcfg- config file.

Q: Why wicked does not set my (default) static route?

Each route using a gateway needs a direct route covering the gateway. When there is a static IP address (IPADDR) defined and it is in the same network as the gateway, the IP address causes to prepend the direct route matching also the gateway.

Otherwise declare such route explicitely, for example, when there is an IPADDR="192.168.1.2/24" (192.168.1 net), but the router has the IP 192.168.0.1 (in 192.168.0 net), define an explicit direct route for the gateway before routes using the directly connected gateway:

# declare that the gateway is reachable directly:
192.168.0.1    -           - eth0

# then use it for other routes via the gateway, e.g.:
192.168.1.0/24 192.168.0.1 - eth0
# or also:
default        192.168.0.1 - eth0

Q: Howto use USB LTE modem with wicked

Wicked currently do not configure the LTE modem it self. How to use the modem with wicked depends on the driver of the modem. To determine the modem and used driver with lsusb -vt.

The output for cdc_ether looks like

    |__ Port 3: Dev 12, If 0, Class=Communications, Driver=cdc_ether, 480M
        ID 12d1:14db Huawei Technologies Co., Ltd. E353/E3131

The output for qmi_wwan looks like:

        |__ Port 1: Dev 6, If 2, Class=Vendor Specific Class, Driver=qmi_wwan, 480M
            ID 1bc7:1201 Telit Wireless Solutions LE910 / LE920

If it uses cdc_ether driver, only a DHCP configuration for the interface is needed (@see Q: Howto setup LTE modem using cdc_ether). For qmi_wwan driver, a pre-up script can be used to configure the modem before requesting an IP via DHCP (@see Q: Howto setup LTE modem using qmi_wwan)

Q: Howto setup LTE modem using cdc_ether

If your modem is running with cdc_ether driver, you can simply use DHCP to get an connection to it. Find your modem with hwinfo --netcard --short. The output should looks like:

network
  eth1                 Huawei E353/E3131

Then create the ifcfg file and start the interface.

cat > /etc/sysconfig/network/ifcfg-eth1 << EOT
STARTMODE=manual
BOOTPROTO=dhcp
EOT

To test DHCP4 without configuring the interface use

wicked test dhcp4 eth1

Finally start the interface

wicked ifup eth1

Afterwards use your web-browser to configure to the modem. The IP is the given gateway wicked ifstatus eth1 | grep route.

Q: Howto setup LTE modem using qmi_wwan

Since https://github.com/openSUSE/wicked/pull/940 wicked has support for raw-ip. To configure the modem you need to install the libqmi-tools. On SUSE Linux Enterprise you find this package in the sle-module-desktop-applications module.

SUSEConnect --product sle-module-desktop-applications/xx.x/x86_64

Install it on SLE and openSUSE with:

zypper in libqmi-tools

Find the corresponding cdc-wdm device via dmesg | grep qmi. It should look like:

[   25.117483] qmi_wwan 1-1.1:1.2: cdc-wdm0: USB WDM device
[   25.139657] qmi_wwan 1-1.1:1.2 wwan0: register 'qmi_wwan' at usb-0000:01:00.0-1.1, WWAN/QMI device, 1e:bd:92:aa:c7:bb
[   25.139987] usbcore: registered new interface driver qmi_wwan

With this, the device is /dev/cdc-wdm0 and has the corresponding netif wwan0.

Create the ifcfg file

cat > /etc/sysconfig/network/ifcfg-wwan0 << 'EOT'
STARTMODE=manual
BOOTPROTO=dhcp4
PRE_UP_SCRIPT="wicked:wwan/qmicli-raw-ip"
DHCLIENT_RELEASE_BEFORE_QUIT=yes
DHCLIENT_ROUTE_PRIORITY=100
EOT

and the pre-up script

cat > /etc/wicked/scripts/wwan/qmicli-raw-ip << 'EOT'
#!/bin/bash
#
# Test hook script to init wwan-qmi in raw-ip(v4) mode on ifup.
#
script=${0##*/}
action="$1"
ifname="$2"

APN_NAME="super"

#verbose="-v"

## write "bash -x" trace + outputs to this file:
#exec &>"/tmp/wicked-${script}.$$.trace"
#set -x

# fail/exit on error and use null-glob match:
set -e
shopt -s nullglob

get_cdc_wdm_dev()
{
    # find /dev/cdc-wdmX for wwanX
    local dev iface
    for dev in /dev/cdc-wdm* ; do
        test -c "$dev" || continue
        iface=$(qmicli -d "$dev" --get-wwan-iface 2>/dev/null)
        if test "X$ifname" = "X$iface" ; then
            echo "$dev" ; return 0
        fi
     done
     return 1
}

case $action in
pre-up)
    # pre-up action is executed before `ip link set up`
    device=$(get_cdc_wdm_dev)

    # enable 'raw-ip' mode if needed:
    format=$(qmicli -d "$device" --get-expected-data-format 2>/dev/null)
    test "X$format" = "Xraw-ip" || \
    qmicli -d "$device" --set-expected-data-format='raw-ip'

    # make sure we're 'online'
    qmicli -d "$device" --dms-get-operating-mode | grep -qs online || \
    qmicli -d "$device" --dms-set-operating-mode='online'

    # do we also have to set the ip family to ipv4? :
    #qmicli -d "$device" --wds-set-ip-family=4

    # open and start network in raw-ip mode (we don't use a pin,user,pass):
    qmicli -d "$device" $verbose \
           --device-open-net='net-raw-ip|net-no-qos-header' \
           --wds-start-network="apn='${APN_NAME}',ip-type=4" \
	   --client-no-release-cid
;;
post-down)
    # post-up action is executed after `ip link set down`
    device=$(get_cdc_wdm_dev)
 
    # We should stop the wds network again, it's visible on start:
    #    [/dev/cdc-wdm0] Network started
    #        Packet data handle: '2266033312'
    # but I currently don't know how to query the handle ...
    #qmicli -d "$device" --wds-stop-network='2266033312'
;;
esac
EOT

chmod +x /etc/wicked/scripts/wwan/qmicli-raw-ip

For debugging run the script directly

bash -x /etc/wicked/scripts/wwan/qmicli-raw-ip pre-up wwan0
wicked test dhcp4 wwan0

Or start the interface as usual

wicked ifup wwan0

Q: Howto connect two interfaces to the same network segment with each interface using DHCPv4

On Linux, an IP address belongs to the host, not to an interface.

The Kernel behaves by default like:

Use the first equivalent/conflicting (same metric and tos) route matching a destination when sending packets. Only the first interface (in the routing table) is used for outgoing packets.
Answer ARP requests for all IP addresses on all interfaces, causing so called ARP-Flux. Thus the IP address is re-associated with the MAC address of the interface where the request arrived. With this the MAC address of an IP address can change even in packets of the same TCP connection.

Problem:

By default the metric of each received route via DHCPv4 will have the same (default) metric (and tos) and the kernel will reject adding further equivalent/conflicting routes via another interfaces (only the kernel itself can add such routes):

# ip link set up eth0
# ip link set up eth1
# ip addr add 192.168.0.11/24 dev eth0 
# ip addr add 192.168.0.12/24 dev eth1 
# ip route add default via 192.168.0.1 dev eth0 
# ip route add default via 192.168.0.1 dev eth1 
RTNETLINK answers: File exists
# ip route show | egrep "eth0|eth1"
default via 192.168.0.1 dev eth0
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.11
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.12

If the interfaces that appears first in the routing table looses carrier, the Linux kernel will mark the corresponding routes as linkdown, but continue to use this route. It has the effect that outgoing packages are dropped.

# ip route show | egrep "eth0|eth1"
default via 192.168.0.1 dev eth0 proto dhcp linkdown
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.11 linkdown
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.12

The host responds to ARP requests from both interfaces, also for the IP on the interface without carrier.

Solutions:

Three solutions are mentioned here, the recommended solutions are Bond or Team:

1) Bond:

Bonding in mode active-backup, balance-alb, balance-tlb do not require any switch configuration:

# cat ifcfg-bond0
STARTMODE='auto'
BOOTPROTO='dhcp4'
BONDING_MASTER='yes'
BONDING_SLAVE_0='eth0'
BONDING_SLAVE_1='eth1'
BONDING_MODULE_OPTS='mode=active-backup miimon=100'

See man 5 ifcfg-bonding and also Kernel Bonding/Switch Configuration

2) Team:

Team using activebackup runner.

# cat ifcfg-team0
STARTMODE='auto'
BOOTPROTO='dhcp4'
TEAM_RUNNER="activebackup"
TEAM_LW_NAME="ethtool"
TEAM_PORT_DEVICE_1="eth0"
TEAM_PORT_DEVICE_2="eth1"

See man 5 ifcfg-team.

3) Metric and ARP/sysctl configuration

Configure different DHCPv4 metrics for each interfaces:

# cat ifcfg-eth0
STARTMODE=auto
BOOTPROTO=dhcp4
DHCLIENT_ROUTE_PRIORITY=100

# cat ifcfg-eth1
STARTMODE=auto
BOOTPROTO=dhcp4
DHCLIENT_ROUTE_PRIORITY=100

Configure the Linux host using sysctl.

See Kernel IP-Sysctl Documentation for complete documentation.

# cat /etc/sysctl.d/50-shared-net.conf

# Ignore routes which have the linkdown flag
net.ipv4.conf.eth0.ignore_routes_with_linkdown=1
net.ipv4.conf.eth1.ignore_routes_with_linkdown=1

# Reply only if the target IP address is local address 
# configured and sender IP address is on the same subnet
net.ipv4.conf.eth0.arp_ignore=2
net.ipv4.conf.eth1.arp_ignore=2

# Always use the best local address for this target
net.ipv4.conf.eth0.arp_announce=2
net.ipv4.conf.eth1.arp_announce=2

# Ensure to disable `rp_filter` to avoid packet dropping by route match
net.ipv4.conf.eth0.rp_filter=0
net.ipv4.conf.eth1.rp_filter=0

Load new configuration

sysctl --load /etc/sysctl.d/50-shared-net.conf
wicked ifup eth0 eth1

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

FAQ