Comment # 21 on bug 972471 from Marius Tomaschewski

(In reply to Per Jessen from comment #13)
> Created attachment 671428 [details]
> journalctl -b -o short-precise

Either there is still something blocking router icmpv6 responses or the
kernel didn't forwarded it to userspace (patches mentioned in comment 6).

It is not visible in the logs, but please disable the firewall using:
  systemctl disable SuSEfirewall2.service SuSEfirewall2_init.service 

Maybe this helps to see what's wrong: Write a
  /etc/wicked/scripts/pre-up/ip6tables-dump
script with following content:

  #!/bin/bash
  set -e
  action="$1"
  ifname="$2"
  test "X$ifname" != "X" -a -d "/sys/class/net/$ifname"
  test -x /usr/sbin/ip6tables-save
  echo "*** $(date -u):"     &>> "/tmp/ip6tables.${ifname}.${action}.dump"
  /usr/sbin/ip6tables-save   &>> "/tmp/ip6tables.${ifname}.${action}.dump"
  echo ""                    &>> "/tmp/ip6tables.${ifname}.${action}.dump"
  ip addr show dev "$ifname" &>> "/tmp/ip6tables.${ifname}.${action}.dump"
  echo ""                    &>> "/tmp/ip6tables.${ifname}.${action}.dump"

make it executable:
  chmod +x /etc/wicked/scripts/pre-up/ip6tables-dump

And add either:
  PRE_UP_SCRIPT="wicked:pre-up"
or
  PRE_UP_SCRIPT="wicked:pre-up/ip6tables-dump"

to ifcfg-eth0 file. After reboot, attach /tmp/ip6tables.eth0.pre-up.
Further, installing "radvd" and running "radvdump" for a while (10min)
and/or calling "ip link set down eth0 ; ip link set up eth0" would
show what is in the RA.

Workaround: You can provide the IPv6 RA managed/other-config flags
explicitly in the ifcfg-eth0 by adding DHCLIENT6_MODE='managed' to it.

(In reply to George Anchev from comment #14)
> Here is my wicked debug info:
> 
> https://goo.gl/Di6TXG
> 
> After disabling debug (restoring to original as explained) I also tested
> with IPv6 disabled (with and without SuSE_firewall2). In all cases -
> absolutely no change. Still waiting for 33 seconds.

You have configuration for ifcfg-{eno1,eth0,enp2s0,eth1} ethernet interfaces
and even when the eth1 setup basically finished after 4 seconds:

Apr 04 12:24:39.018645 i7 wicked[1351]: Executing: /usr/sbin/wicked --systemd
ifup all
...
Apr 04 12:24:43.303684 i7 wickedd-nanny[1350]: eth1: successfully transitioned
from addrconf-up to network-up
Apr 04 12:24:43.303904 i7 wicked[1351]: received signal progressInfo;
object_path=/org/opensuse/Network/Nanny/Interface/3; target_state=network-up,
state_name=network-up

it still waits for the other requested interfaces:

Apr 04 12:24:43.304117 i7 wickedd-nanny[1350]: eth0: state=device-up
want=network-up, wait-for=link-up
Apr 04 12:24:43.304330 i7 wickedd-nanny[1350]: waiting for 1 devices to become
ready (1 explicitly requested)
Apr 04 12:24:43.304571 i7 wickedd-nanny[1350]: ni_nanny_recheck(eno1)
Apr 04 12:24:43.304771 i7 wickedd-nanny[1350]: eno1: no applicable policies
Apr 04 12:24:43.304983 i7 wickedd-nanny[1350]: ni_nanny_recheck(enp2s0)
Apr 04 12:24:43.305200 i7 wickedd-nanny[1350]: enp2s0: no applicable policies

until the timeout is reached:

Apr 04 12:25:09.087723 i7 wicked[1351]: Interface wait time reached

This has not much in common with ipv6. Not ignoring missed STARTMODE=hotplug
configs is bug #945601. But in your case, it are even STARTMODE=boot devices,
so it works as expected here.

An
  rm -v /etc/sysconfig/network/ifcfg-{eno1,eth0,enp2s0}
will stop waiting for eno1 enp2s0 (which are eth0 + eth1 probably) + eth0.
When eth0 is used, but currently not connected, you mv ifcfg-eth0 .ifcfg-eth0
as workaround to avoid the timeout until STARTMODE=hotplug & co is fixed.
It would be possible to set LINK_REQUIRED=no for eth0, but this is generally
IMO not a good idea (except in special cases) and configures IPs + routes on
unconnected interfaces (-> black hole) and ignoring network layer order.

I'd tend to resolve this report as dup of #945601 (even the config is not
using STARTMODE=hotplug).
Does it make sense to split the report into multiple? We have already two
different scenarios here.