Bug 981887

(In reply to Jiri Slaby from comment #0)
> Why does wicked need advanced routing? RTM_GETRULE is only available if
> advanced routing is compiled in kernel,

Then fix this in your kernel to be available again. It is a requested
feature and rules are available in all our kernels since ages (I were
using them already ~20 years ago).

> There is no reason why networking should not start without
> RTM_GETRULE/FIB_RULES.

That's true.

> The failure is as follows:
> # /usr/sbin/wickedd  --foreground 
> wickedd: ni_nl_dump_store: failed to receive response: Operation not
> supported
> wickedd: failed to refresh interface list
> wickedd: failed to discover interface state

Which broken kernel is this? OK, makes sense to catch this and report
more nicely that the kernel is missing functionality and rules are not
supported.

> This is a regression from previous networking setups with dhcp clients like
> dhclient or dhcpcd.

Yes, it is definitively a regression, but mostly in the _kernel_.

It also has _nothing_ with dhcp in common.

Routing rule support is a requested feature (already for SLES-11; but
was deferred [first implementation exists] due to time constrains).

Just tested with Tumbleweed and the kernel contains the rule support
as it should and it is only your kernel build which lacks it.

Setting to enhancement to make a separate query to not fail the main
query when the kernel lacks it -- unlike all our kernels since ages.

Depending on FIB_RULES as such doesn't make much sense, IMHO. If you have
FIB_RULES but not any of IP{,V6}{,_MROUTE}_MULTIPLE_TABLES, you may have
RTM_GETRULE netlink message registered but there are still no routing rules
to dump (and there can't possibly be), you can't possibly add any etc.

But perhaps wickedd would just fail a bit later and with a different error
on such kernel (with FIB_RULES but none of *_MULTIPLE_TABLES).

(In reply to Michal Kubeček from comment #3)
> Depending on FIB_RULES as such doesn't make much sense, IMHO. If you have
> FIB_RULES but not any of IP{,V6}{,_MROUTE}_MULTIPLE_TABLES, you may have
> RTM_GETRULE netlink message registered but there are still no routing rules
> to dump (and there can't possibly be), you can't possibly add any etc.
> 
> But perhaps wickedd would just fail a bit later and with a different error
> on such kernel (with FIB_RULES but none of *_MULTIPLE_TABLES).

It is not a problem to fix it in wicked and we will do it of course.
Most time costs probably to compile a kernel without rules and to test it.

Why it fails: I've added rule query to the common (link+addr+route) query
in "refresh all" used at bootstrap/start -- when it fails to query here,
we fail -- something is broken then. It is not a problem to remove the
rule query there again and query them separately (ignoring query error
in the separate call while bootstrap). No rules to dump (empty results)
is (are) not a problem.

When there are rules defined in the config, the setup will fail then,
but this is not a surprise.

Seems it needs these changes until CONFIG_FIB_RULES gets disabled,
otherwise the deps turn it on again...:

@@ -851,11 +851,7 @@
 CONFIG_NET_KEY_MIGRATE=y
 CONFIG_INET=y
 CONFIG_IP_MULTICAST=y
-CONFIG_IP_ADVANCED_ROUTER=y
-# CONFIG_IP_FIB_TRIE_STATS is not set
-CONFIG_IP_MULTIPLE_TABLES=y
-CONFIG_IP_ROUTE_MULTIPATH=y
-CONFIG_IP_ROUTE_VERBOSE=y
+# CONFIG_IP_ADVANCED_ROUTER is not set
 CONFIG_IP_ROUTE_CLASSID=y
 CONFIG_IP_PNP=y
 CONFIG_IP_PNP_DHCP=y
@@ -866,10 +862,7 @@
 CONFIG_NET_IP_TUNNEL=m
 CONFIG_NET_IPGRE=m
 CONFIG_NET_IPGRE_BROADCAST=y
-CONFIG_IP_MROUTE=y
-CONFIG_IP_MROUTE_MULTIPLE_TABLES=y
-CONFIG_IP_PIMSM_V1=y
-CONFIG_IP_PIMSM_V2=y
+# CONFIG_IP_MROUTE is not set
 CONFIG_SYN_COOKIES=y
 CONFIG_NET_IPVTI=m
 CONFIG_NET_UDP_TUNNEL=m
@@ -927,8 +920,7 @@
 CONFIG_IPV6_NDISC_NODETYPE=y
 CONFIG_IPV6_TUNNEL=m
 CONFIG_IPV6_GRE=m
-CONFIG_IPV6_MULTIPLE_TABLES=y
-CONFIG_IPV6_SUBTREES=y
+# CONFIG_IPV6_MULTIPLE_TABLES is not set
 # CONFIG_IPV6_MROUTE is not set
 CONFIG_NETLABEL=y
 CONFIG_NETWORK_SECMARK=y
@@ -1647,7 +1639,6 @@
 # CONFIG_AF_RXRPC_DEBUG is not set
 CONFIG_RXKAD=m
 CONFIG_AF_KCM=m
-CONFIG_FIB_RULES=y
 CONFIG_WIRELESS=y
 CONFIG_WIRELESS_EXT=y
 CONFIG_WEXT_CORE=y
@@ -2474,7 +2465,6 @@
 CONFIG_VETH=m
 CONFIG_VIRTIO_NET=m
 CONFIG_NLMON=m
-CONFIG_NET_VRF=m
 CONFIG_SUNGEM_PHY=m
 # CONFIG_ARCNET is not set
 CONFIG_ATM_DRIVERS=y

Jiri, you seem to have such a kernel already. Where?

CONFIG_FIB_RULES is selected by

  IP_MULTIPLE_TABLES
  IP_MROUTE_MULTIPLE_TABLES
  IPV6_MULTIPLE_TABLES
  IPV6_MROUTE_MULTIPLE_TABLES

This is an autogenerated message for OBS integration:
This bug (981887) was mentioned in
https://build.opensuse.org/request/show/401114 Factory / wicked

(In reply to Michal Kubeček from comment #9)
> CONFIG_FIB_RULES is selected by
> 
>   IP_MULTIPLE_TABLES
>   IP_MROUTE_MULTIPLE_TABLES
>   IPV6_MULTIPLE_TABLES
>   IPV6_MROUTE_MULTIPLE_TABLES

Yes, a second attempt to disable it in the kernel worked and we've submitted
the cleanups already to factory + sle12.

Works great, thanks.

openSUSE-RU-2016:2978-1: An update that has 19 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 865573,902897,913861,916613,916948,972471,973355,974231,975466,981887,982231,982952,984088,985894,988794,988954,989741,997027,998413
CVE References: 
Sources used:
openSUSE Leap 42.1 (src):    wicked-0.6.39-12.1
openSUSE 13.2 (src):    wicked-0.6.39-36.1

SUSE-RU-2016:3192-1: An update that has 19 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 865573,902897,913861,916613,916948,972471,973355,974231,975466,981887,982231,982952,984088,985894,988794,988954,989741,997027,998413
CVE References: 
Sources used:
SUSE Linux Enterprise Server 12-SP1 (src):    wicked-0.6.39-28.3.1
SUSE Linux Enterprise Desktop 12-SP1 (src):    wicked-0.6.39-28.3.1