I can confirm that the issue is also occuring without NetworkManager being installed (no output from "rpm -qa | grep -i networkmanager").

(In reply to Christoph Feck from comment #1)
> I can confirm that the issue is also occuring without NetworkManager being
> installed (no output from "rpm -qa | grep -i networkmanager").

We still have not received proper logs with disabled NetworkManager.
Please provide them.

Here is how to do it:
‒ set DEBUG=all in /etc/sysconfig/network/config
‒ systemctl restart wickedd
‒ wicked --debug all ifup all # systemctl restart wicked
‒ wicked ifstatus all > status.log
‒ wicked show-config > configs.log
‒ journalctl -b -o short-iso > wicked.log

- edit /usr/lib/systemd/system/wpa_supplicant.service file:

-ExecStart=/usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f /var/log/wpa_supplicant.log
+ExecStart=/usr/sbin/wpa_supplicant -dddt -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f /var/log/wpa_supplicant.log

- systemctl daemon-reload
- systemctl restart wpa_supplicant

reproduce the issue and attach: status.log, configs.log, wicked.log and /var/log/wpa_supplicant.log

Thanks.

> enp9s0 is set to 'Connect automatically on cable connection'. If I unplug
> the cable and reboot, I have to restart the network 3-4 times after
> conncecting the cable before I get a connection

This can be fixed by enabling nanny. Which is supposed to deal with hotplug scenarios like the one above.

In order to do so edit /etc/wicked/common.xml

-  <use-nanny>false</use-nanny>
+  <use-nanny>true</use-nanny>

and call:
systemctl restart wickedd
wicked ifup enp9s0

you should be able to plug in and unplug the cable and the network should be configured automatically for you.

(In reply to Christoph Feck from comment #1)
> I can confirm that the issue is also occuring without NetworkManager being
> installed (no output from "rpm -qa | grep -i networkmanager").

Please provide logs as requested in the comment #2.
Thanks.

(In reply to Pawel Wieczorkiewicz from comment #3)
> > enp9s0 is set to 'Connect automatically on cable connection'. If I unplug
> > the cable and reboot, I have to restart the network 3-4 times after
> > conncecting the cable before I get a connection
> 
> This can be fixed by enabling nanny. Which is supposed to deal with hotplug
> scenarios like the one above.
> 
> In order to do so edit /etc/wicked/common.xml
> 
> -  <use-nanny>false</use-nanny>
> +  <use-nanny>true</use-nanny>
> 
> and call:
> systemctl restart wickedd
> wicked ifup enp9s0
> 
> you should be able to plug in and unplug the cable and the network should be
> configured automatically for you.

The only text in my /etc/wicked/common.xml is 'false'. 

I also have /etc/wicked/nanny.xml but it is blank. 

Should I change false to true in the common.xml file?

(In reply to kevin vandeventer from comment #5)
> > systemctl restart wickedd
> > wicked ifup enp9s0
                ^^^^^^
                all

All config has to be reapplied.

> The only text in my /etc/wicked/common.xml is 'false'. 

Then the file is broken, please reinstall wicked.

> I also have /etc/wicked/nanny.xml but it is blank. 

No, do not touch nanny.xml. It is for nanny only. The use-nanny
flag is also used in nanny but basically most important in the
_client_ which has to feed the config into nanny and not into the
wickedd directly.
 
> Should I change false to true in the common.xml file?

It needs this content:

<!-- Common configuration file sourced by all application-specific files -->
<config>
  <piddir   path="/run/wicked" mode="0755"/>
  <statedir path="/run/wicked" mode="0755"/>
  <storedir path="/var/lib/wicked" mode="0755"/>

  <!--
    Config options specific to DBus service
   -->
  <dbus>
    <service name="org.opensuse.Network" />
    <schema name="/usr/share/wicked/schema/wicked.xml"/>
  </dbus>

  <!--
    Use nanny or not:

    'false': causes ifup (and ifreload) to apply the config
	     directly into wickedd without nanny involved
	     (one shot setup).

    'true':  causes ifup (and ifreload) to apply a policy
	     with the effective config to nanny and nanny
	     configures wickedd then; with hotplug support.

    After a change, restart wickedd.service and execute
    "wicked ifup all" to (re)apply the config / policies.
  -->
  <use-nanny>true</use-nanny>

  <!--
    If you want to make changes to this file, consider putting
    your changes into /etc/wicked/local.xml instead.
    Otherwise, you may lose your changes when applying
    future maintenance updates.
    -->
  <include name="local.xml" optional="true" />
</config>

I used YaST to uninstall wicked and libwicked-0-6. After reinstallation, /etc/wicked/common.xml still only contains one word: false.

# echo true > /etc/wicked/common.xml 
# cat /etc/wicked/common.xml 
true
# zypper in -f wicked wicked-service libwicked-0-6
Loading repository data...
Reading installed packages...
Forcing installation of 'wicked-0.6.12-1.1.x86_64' from repository 'Main Repository (OSS)'.
Forcing installation of 'wicked-service-0.6.12-1.1.x86_64' from repository 'Main Repository (OSS)'.
Forcing installation of 'libwicked-0-6-0.6.12-1.1.x86_64' from repository 'Main Repository (OSS)'.
Resolving package dependencies...

The following 3 packages are going to be reinstalled:
  libwicked-0-6 wicked wicked-service 

3 packages to reinstall.
Overall download size: 847.0 KiB. Already cached: 0 B  No additional space will be used 
or freed after the operation.
Continue? [y/n/? shows all options] (y): 
Retrieving package libwicked-0-6-0.6.12-1.1.x86_64  (1/3), 343.9 KiB (1020.7 KiB unpacked)
Retrieving: libwicked-0-6-0.6.12-1.1.x86_64.rpm ....................................[done]
Retrieving package wicked-0.6.12-1.1.x86_64          (2/3), 463.2 KiB (  1.5 MiB unpacked)
Retrieving: wicked-0.6.12-1.1.x86_64.rpm ..............................[done (97.1 KiB/s)]
Retrieving package wicked-service-0.6.12-1.1.x86_64  (3/3),  39.9 KiB (  9.2 KiB unpacked)
Retrieving: wicked-service-0.6.12-1.1.x86_64.rpm ...................................[done]
Checking for file conflicts: .......................................................[done]
(1/3) Installing: libwicked-0-6-0.6.12-1.1 .........................................[done]
(2/3) Installing: wicked-0.6.12-1.1 ................................................[done]
Additional rpm output:
Updating /etc/sysconfig/network/config...


(3/3) Installing: wicked-service-0.6.12-1.1 ........................................[done]
# cat /etc/wicked/common.xml 
true
# ls -l /etc/wicked/common.xml*
-rw-r--r-- 1 root root 5 Nov 17 15:24 /etc/wicked/common.xml


Hmm... A "%config(noreplace) %_sysconfdir/wicked/common.xml" should
at least create a "/etc/wicked/common.xml.rpmnew"... why it doesn't?

# zypper -v in -f -d wicked
# find /var/cache/zypp/ -name wicked-0.6.12-1.1.x86_64.rpm
/var/cache/zypp/packages/download.opensuse.org-oss_1/suse/x86_64/wicked-0.6.12-1.1.x86_64.rpm
# cat /etc/wicked/common.xml 
true
# rpm -Uvvvh /var/cache/zypp/packages/download.opensuse.org-oss_1/suse/x86_64/wicked-0.6.12-1.1.x86_64.rpm --force 2>out
Preparing...                          ################################# [100%]
Updating / installing...
   1:wicked-0.6.12-1.1                ################################# [100%]
Updating /etc/sysconfig/network/config...
# grep common.xml out 
D: skip       100644  1 (   0,   0)  1161 /etc/wicked/common.xml;546a0744

Hmm... it still skips it. Please use this as workaround:

# rm /etc/wicked/common.xml 
# zypper in -f wicked wicked-service libwicked-0-6

Please verify the installation using:
  rpm -V wicked wicked-service libwicked-0-6
the output should be empty. When not, remove all modified files and repeat.

Michael,

any idea why rpm does not install at least a ".rpmnew" file, but just silently
skips install? This is a new behavior to me...

I followed the instructions from comment 8 to reinstall wicked. After, the result of 'ls -l /etc/wicked/common.xml*' is:

-rw-r--r-- 1 root root 1161 Oct 14 01:02 /etc/wicked/common.xml

The date is still from last month and the file still says 'false'.

(In reply to kevin vandeventer from comment #10)
> I followed the instructions from comment 8 to reinstall wicked. After, the
> result of 'ls -l /etc/wicked/common.xml*' is:
> 
> -rw-r--r-- 1 root root 1161 Oct 14 01:02 /etc/wicked/common.xml
> 
> The date is still from last month and the file still says 'false'.

1161 is the correct size of the original file, though.
How did you see the "false" ? did you try vim?

You can get the correct one with
old /etc/wicked/common.xml ; zypper in -f wicked

It doesn't create a rpmnew file if the file didn't change in the update, i.e. the old rpm and the new rpm contained the same config file. That's because in that case rpm knows that the user changed the file, and it makes sense to keep the change.

(In reply to Bernhard Wiedemann from comment #11)
> (In reply to kevin vandeventer from comment #10)
> > I followed the instructions from comment 8 to reinstall wicked. After, the
> > result of 'ls -l /etc/wicked/common.xml*' is:
> > 
> > -rw-r--r-- 1 root root 1161 Oct 14 01:02 /etc/wicked/common.xml
> > 
> > The date is still from last month and the file still says 'false'.
> 
> 1161 is the correct size of the original file, though.
> How did you see the "false" ? did you try vim?
> 
> You can get the correct one with
> old /etc/wicked/common.xml ; zypper in -f wicked

I see now that the default app to open the common.xml file is Konqueror, while I was assuming it was KWrite. Konqueror is the one that just shows 'false'. If I use KWrite to open the file, it has content similar to the example in comment 6 from Mr. Tomaschewski except instead of-- <use-nanny>true</use-nanny>

I have <use-nanny>false</use-nanny>

Also, I have no /etc/wicked/local.xml

I tried using the 'old /etc/wicked/common.xml ;' command, but the new common.xml file still says it was created Oct 14.

(In reply to kevin vandeventer from comment #13)
> If I use KWrite to open the file, it has content similar to the
> example in comment 6 from Mr. Tomaschewski except instead of--
> <use-nanny>true</use-nanny>
> 
> I have <use-nanny>false</use-nanny>

OK, then please either _change_ it to <use-nanny>true</use-nanny>,
e.g. using:

  old /etc/wicked/common.xml
  sed -e 's|<use-nanny>false</use-nanny>|<use-nanny>true</use-nanny>|g' -i /etc/wicked/common.xml

or create a local.xml containing it:

  printf "<config>\n\t<use-nanny>true</use-nanny>\n</config>\n" > /etc/wicked/local.xml

both commands have to be executed as root of course.

Then verify that the file is changed:

  grep use-nanny /etc/wicked/*.xml

and contains a <use-nanny>false</use-nanny> now,
then restart wickedd and reapply the configs:

 rcwickedd restart # note: wickedd with 2 * d here
 wicked ifup all

or reboot.

Changing 'false' to 'true' partially fixed it for me.

This 'false' line is in the core package, given that SO many people have broken systems because of this, as far as I am concerned, you should release an update with the correct setting as soon as possible. Not everyone is going to go hunting in bugzilla.

The other problem people are having so many problems with is the amount of time it takes wicked to do anything.

It appears that it gets started after the network comes up, but does not iterate through the interfaces at run time and therefore waits... and waits... and waits... until... it... decides... to... do... something... This... should... also... be... fixed...

I noticed an update to wicked today so I thought I would try to reconnect with wicked.service. Still no luck. It's still showing 'setup-in-progress' for both ethernet and wireless. Here is some output after shutting down NetworkManager and starting wicked.

linux:/home/kevin #  systemctl  status network.service wickedd.service wpa_supplicant.service NetworkManager.service -l 
wicked.service - wicked managed network interfaces
   Loaded: loaded (/usr/lib/systemd/system/wicked.service; enabled)
   Active: active (exited) since Fri 2015-01-02 08:59:19 CST; 7min ago
  Process: 4512 ExecStart=/usr/sbin/wicked --systemd ifup all (code=exited, status=0/SUCCESS)
 Main PID: 4512 (code=exited, status=0/SUCCESS)

Jan 02 08:59:19 linux.site wicked[4512]: lo              up
Jan 02 08:59:19 linux.site wicked[4512]: enp9s0          setup-in-progress
Jan 02 08:59:19 linux.site wicked[4512]: wlp5s5          setup-in-progress

wickedd.service - wicked network management service daemon
   Loaded: loaded (/usr/lib/systemd/system/wickedd.service; enabled)
   Active: active (running) since Fri 2015-01-02 08:58:33 CST; 7min ago
 Main PID: 4502 (wickedd)
   CGroup: /system.slice/wickedd.service
           └─4502 /usr/sbin/wickedd --systemd --foreground

Jan 02 08:58:49 linux.site wickedd[4502]: unable to translate eap protocol AKA
Jan 02 08:58:49 linux.site wickedd[4502]: unable to translate eap protocol AKA'
Jan 02 08:58:49 linux.site wickedd[4502]: unable to translate eap protocol FAST
Jan 02 08:58:49 linux.site wickedd[4502]: lo: address 127.0.0.1 covered by a static lease
Jan 02 08:58:49 linux.site wickedd[4502]: lo: address ::1 covered by a static lease

wpa_supplicant.service - WPA Supplicant daemon
   Loaded: loaded (/usr/lib/systemd/system/wpa_supplicant.service; enabled)
   Active: active (running) since Fri 2015-01-02 08:58:11 CST; 8min ago
 Main PID: 4493 (wpa_supplicant)
   CGroup: /system.slice/wpa_supplicant.service
           └─4493 /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f /var/log/wpa_supplicant.log

Jan 02 08:58:49 linux.site wpa_supplicant[4493]: ioctl[SIOCSIWENCODEEXT]: Invalid argument
Jan 02 08:58:49 linux.site wpa_supplicant[4493]: ioctl[SIOCSIWENCODEEXT]: Invalid argument

NetworkManager.service - Network Manager
   Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; disabled)
   Active: inactive (dead) since Fri 2015-01-02 08:55:52 CST; 10min ago
 Main PID: 781 (code=exited, status=0/SUCCESS)

Jan 02 08:55:52 linux.site NetworkManager[781]: Received signal 15, initiating shutdown.
Jan 02 08:55:52 linux.site NetworkManager[781]: DHCPRELEASE on wlp5s5 to 192.168.1.254 port 67 (xid=0x4a8c3e69)
Jan 02 08:55:52 linux.site NetworkManager[781]: <info> (wlp5s5): device state change: activated -> deactivating (reason 'removed') [100 110 36]
Jan 02 08:55:52 linux.site NetworkManager[781]: <info> NetworkManager state is now DISCONNECTING
Jan 02 08:55:52 linux.site NetworkManager[781]: <info> (wlp5s5): device state change: deactivating -> unmanaged (reason 'removed') [110 10 36]
Jan 02 08:55:52 linux.site NetworkManager[781]: <info> (wlp5s5): deactivating device (reason 'removed') [36]
Jan 02 08:55:52 linux.site NetworkManager[781]: <warn> (wlp5s5): DHCP client pid 1474 didn't exit, will kill it.
Jan 02 08:55:52 linux.site NetworkManager[781]: <info> (wlp5s5): canceled DHCP transaction, DHCP client pid 1474
Jan 02 08:55:52 linux.site NetworkManager[781]: <info> NetworkManager state is now DISCONNECTED
Jan 02 08:55:52 linux.site NetworkManager[781]: (NetworkManager:781): GLib-CRITICAL **: Source ID 20 was not found when attempting to remove it

I have experienced similar issues.  I discovered that I could get the network to come up by the following procedure (tested only once, so I'm not sure how reliable it is):

ifdown wlan0
rmmod iwldvm iwlwifi mac80211 cfg80211
modprobe iwlwifi
sleep 2
iwconfig wlan0 essid <ap-name>
rm -f /var/lib/dhcpcd/*wlan0* /var/lib/dhcpv6/*wlan0*
ip link set wlan0 up
iwconfig wlan0 essid <ap-name> # Yes, again
ifup wlan0
iwlist wlan0 scan >&/dev/null
dhcpcd -n -N wlan0
pkill wpa_supplicant
wpa_supplicant -iwlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf -B

This complex sequence is in a script I developed over a period of years, and I suspect that some of the actions aren't necessary on the current release.  However, I know (because I tried without them) that it is usually necessary to remove and reinstall the wireless modules before they will recognize a new access point, and it's necessary to kill and restart wpa_supplicant before it will associate with an encrypted AP.  (Open APs work just fine without that step.)

Here are some relevant wpa_supplicant log lines from working with an encrypted AP (why doesn't it timestamp logs?):

wlan0: CTRL-EVENT-REGDOM-CHANGE init=DRIVER type=WORLD
wlan0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=US
wlan0: CTRL-EVENT-SCAN-STARTED 
wlan0: SME: Trying to authenticate with 00:22:90:39:46:cd (SSID='Claremont-WPA' freq=5805 MHz)
wlan0: Trying to associate with 00:22:90:39:46:cd (SSID='Claremont-WPA' freq=5805 MHz)
wlan0: Associated with 00:22:90:39:46:cd
wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlan0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=US
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=US/ST=California/L=Claremont/O=Claremont University Consortium/CN=*.claremont.edu'
EAP-MSCHAPV2: Authentication succeeded
wlan0: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
wlan0: WPA: Key negotiation completed with 00:22:90:39:46:cd [PTK=CCMP GTK=CCMP]
wlan0: CTRL-EVENT-CONNECTED - Connection to 00:22:90:39:46:cd completed [id=3 id_str=]
wlan0: CTRL-EVENT-DISCONNECTED bssid=00:22:90:39:46:cd reason=3 locally_generated=1

(In reply to Geoff Kuenning from comment #17)
> I have experienced similar issues.  I discovered that I could get the
> network to come up by the following procedure (tested only once, so
> I'm not sure how reliable it is):
[...]

This would mean, iwlwifi (or wpa-supplicant) has a bug -- I didn't seen
any such problems with iwlwifi, ath5k and rtl8192cu which I'm using here.

Unfortunately Kevin didn't provided config/logs until now as requested
in comment 2 [or https://en.opensuse.org/openSUSE:Bugreport_wicked]...

> remove and reinstall the wireless modules before they will recognize
> a new access point

This only happens when you set the AP [mac address of the access point]
using the WIRELESS_AP variable / bind it to this AP and forbid roaming.

-> "iwconfig wlan0 ap any" should do the trick and cause to reassociate.

Apropos explicit AP: there is a bug in it: bug#911315, fixed in RPMs at
http://download.opensuse.org/repositories/network:/wicked:/master/

Geoff, could you try out if it works for you without any workarounds and
provide logs? Of course, X-out any credentials from the files, ...

Wicked has started working for me with my wireless card but so far I have been unable to figure out exactly how it started working. I'm using Plasma5/Frameworks5 with 13.2 and on 1-13-15 there were some updates for plasma to version 5.1.95. Only some packages were updated and when I rebooted, plasmashell crashed and on subsequent logouts/reboots it continued to crash. These crashes also caused NetworkManager to stop working, or at least there was not network connection.

I switched to IceWM to work around the plasma crashes and I switched to wicked via command line and connected an ethernet cable to get a network connection. 

Twenty four hours later, there were updates for more plasma packages in 5.1.95 series and this fixed the crashes in plasma. I clicked on the network icon in the panel and it said I was connected with enp9s0 and wlp5s5 was available. I switched to wlp5s5 and it has been working ever since. There was also an update to NetworkManager during this time, but I don't know if that helped or not. 

A recent email about bug #895447 said an update to sysconfig may help with this wicked problem, but mine starting working long before that. It's been working for about nine days. Now when I execute the status command, everything is 'up' and the only 'setup-in-progress' is because the ethernet isn't plugged in. 

sudo systemctl  status network.service wickedd.service wpa_supplicant.service NetworkManager.service -l 
sudo: ignoring time stamp from the future
root's password:
wicked.service - wicked managed network interfaces
   Loaded: loaded (/usr/lib/systemd/system/wicked.service; enabled)
   Active: active (exited) since Fri 2015-01-23 11:33:12 CST; 20min ago
 Main PID: 813 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/wicked.service

Jan 23 11:33:12 linux.site wicked[813]: lo              up
Jan 23 11:33:12 linux.site wicked[813]: enp9s0          setup-in-progress
Jan 23 11:33:12 linux.site wicked[813]: wlp5s5          up

wickedd.service - wicked network management service daemon
   Loaded: loaded (/usr/lib/systemd/system/wickedd.service; enabled)
   Active: active (running) since Fri 2015-01-23 11:32:42 CST; 20min ago
 Main PID: 805 (wickedd)
   CGroup: /system.slice/wickedd.service
           └─805 /usr/sbin/wickedd --systemd --foreground

Jan 23 11:32:42 linux.site wickedd[805]: unable to translate eap protocol AKA
Jan 23 11:32:42 linux.site wickedd[805]: unable to translate eap protocol AKA'
Jan 23 11:32:42 linux.site wickedd[805]: unable to translate eap protocol FAST
Jan 23 11:32:42 linux.site wickedd[805]: lo: address 127.0.0.1 covered by a static lease
Jan 23 11:32:42 linux.site wickedd[805]: lo: address ::1 covered by a static lease
Jan 23 11:32:50 linux.site wickedd[805]: wlp5s5: Notified neighbours about IP address 192.168.1.69

wpa_supplicant.service - WPA Supplicant daemon
   Loaded: loaded (/usr/lib/systemd/system/wpa_supplicant.service; enabled)
   Active: active (running) since Fri 2015-01-23 11:32:42 CST; 20min ago
 Main PID: 777 (wpa_supplicant)
   CGroup: /system.slice/wpa_supplicant.service
           └─777 /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f /var/log/wpa_supplicant.log

Jan 23 11:32:42 linux.site wpa_supplicant[777]: ioctl[SIOCSIWENCODEEXT]: Invalid argument
Jan 23 11:32:42 linux.site wpa_supplicant[777]: ioctl[SIOCSIWENCODEEXT]: Invalid argument
Jan 23 11:32:49 linux.site wpa_supplicant[777]: ioctl[SIOCSIWFREQ]: Device or resource busy

NetworkManager.service - Network Manager                                                                 
   Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled)                              
   Active: active (running) since Fri 2015-01-23 11:32:42 CST; 20min ago                                 
 Main PID: 803 (NetworkManager)                                                                          
   CGroup: /system.slice/NetworkManager.service                                                          
           ├─ 803 /usr/sbin/NetworkManager --no-daemon                                                   
           └─1608 /sbin/dhclient -d -sf /usr/lib/nm-dhcp-helper -pf /var/run/dhclient-wlp5s5.pid -lf /var/lib/NetworkManager/dhclient-89d89176-938b-4c00-b02c-0deb032a90ae-wlp5s5.lease -cf /var/lib/NetworkManager/dhclient-wlp5s5.conf wlp5s5                                                                            

Jan 23 11:32:54 linux.site NetworkManager[803]: <info>   plen 24 (255.255.255.0)
Jan 23 11:32:54 linux.site NetworkManager[803]: <info>   gateway 192.168.1.xxx
Jan 23 11:32:54 linux.site NetworkManager[803]: <info>   server identifier 192.168.1.xxx
Jan 23 11:32:54 linux.site NetworkManager[803]: <info>   lease time 86400
Jan 23 11:32:54 linux.site NetworkManager[803]: <info>   nameserver '192.168.1.254'
Jan 23 11:32:54 linux.site NetworkManager[803]: <info>   domain name 'xxxlocal.net'
Jan 23 11:32:54 linux.site NetworkManager[803]: <info> Activation (wlp5s5) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
Jan 23 11:32:54 linux.site NetworkManager[803]: <info> Activation (wlp5s5) Stage 5 of 5 (IPv4 Commit) started...
Jan 23 11:32:54 linux.site NetworkManager[803]: <info> Activation (wlp5s5) Stage 5 of 5 (IPv4 Commit) complete.
Jan 23 11:32:54 linux.site NetworkManager[803]: bound to 192.168.1.xx -- renewal in 36557 seconds.

(In reply to kevin vandeventer from comment #19)
> Wicked has started working for me with my wireless card but so far I have
> been unable to figure out exactly how it started working.
[...]
> I switched to IceWM to work around the plasma crashes and I switched to
                                                            ^^^^^^^^^^^^^
> wicked via command line and connected an ethernet cable to get a network
  ^^^^^^^^^^^^^^^^^^^^^^^
> connection.
[...]
> A recent email about bug #895447 said an update to sysconfig may help with
> this wicked problem, but mine starting working long before that.

The sysconfig update contains an update migration fix. It is required to stop
all processes of the NM service, because a "systemctl stop NetworkManager" is
not doing it (stops only the NetworkManager process, but not e.g. dhclient):

/usr/bin/systemctl --kill-who=all kill NetworkManager.service || :
/usr/bin/systemctl stop NetworkManager.service || :
/usr/bin/systemctl --force disable NetworkManager.service || :

The rest of this issue is about a correction of the wicked <-> NetworkManager
switch in yast2. Once fixed, using yast2 should be able to make it correctly.

> It's been working for about nine days. Now when I execute the status command,
> everything is 'up' and the only 'setup-in-progress' is because the ethernet
> isn't plugged in. 

When use-nanny is enabled, nanny will setup ethernet when there is a link.

We do not setup IP addresses on interfaces without a link, because a link
is required for:
  - bridge STP
  - authentication
  - lldp
  - duplicate address detection

There are some corner cases where it makes sense to ignore the link status
and just set up it (e.g. on a router) -- that is, we will add a config
switch allowing it. But this is an another issue:

> sudo systemctl  status network.service wickedd.service
> wpa_supplicant.service NetworkManager.service -l 
[...]
> wicked.service - wicked managed network interfaces
>   Loaded: loaded (/usr/lib/systemd/system/wicked.service; enabled)
>   Active: active (exited) since Fri 2015-01-23 11:33:12 CST; 20min ago
[...]
> wickedd.service - wicked network management service daemon
>   Loaded: loaded (/usr/lib/systemd/system/wickedd.service; enabled)
>   Active: active (running) since Fri 2015-01-23 11:32:42 CST; 20min ago
> Main PID: 805 (wickedd)
>   CGroup: /system.slice/wickedd.service
>           └─805 /usr/sbin/wickedd --systemd --foreground
[...]

> NetworkManager.service - Network Manager                                    
>    Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled) 
>    Active: active (running) since Fri 2015-01-23 11:32:42 CST; 20min ago    
>  Main PID: 803 (NetworkManager)          
>    CGroup: /system.slice/NetworkManager.service 
>            ├─ 803 /usr/sbin/NetworkManager --no-daemon
>            └─1608 /sbin/dhclient -d -sf /usr/lib/nm-dhcp-helper -pf /var/run/dhclient-wlp5s5.pid -lf /var/lib/NetworkManager/dhclient-89d89176-938b-4c00-b02c-0deb032a90ae-wlp5s5.lease -cf /var/lib/NetworkManager/dhclient-wlp5s5.conf wlp5s5

But as this output shows, your bug is a duplicate of bug #895447 -- you
still have both network services running ... again -> you stopped NM
(manually, see above) for a while and it started working but you did not
disabled the NetworkManager.service...
-> Please execute the 3 systemctl commands I've provided above as root.

Resolving as duplicate of bug#895447

*** This bug has been marked as a duplicate of bug 895447 ***

I executed the three commands above as root and NetworkManager is now showing 'inactive' (dead). I think the only difference from the commands I used before is the --force option. Now I have no network connection with wicked. Wicked, wickedd, wpa-supplicant are all shown as active but both my wired and wireless connections are showing 'setup-in-progress'. 

So I'm back to using NetworkManager. I will continue to monitor bug #895447 for progress on this issue.

(In reply to kevin vandeventer from comment #21)
> Now I have no network connection with wicked.

We really need the logs to see what happens in your case. Don't continue
here, but please open a new bug report and attach config you're using
and logs (see also https://en.opensuse.org/openSUSE:Bugreport_wicked):


#
# Execute following commands as root:
#

# enable debug
sed -e 's/^WICKED_DEBUG=.*/WICKED_DEBUG=all/g' -i /etc/sysconfig/network/config

# enable nanny use
sed -e 's|<use-nanny.*use-nanny>|<use-nanny>true</use-nanny>|g' -i /etc/wicked/common.xml 

# enable wpa supplicant debug
sed -e "s|sbin/wpa_supplicant -c|sbin/wpa_supplicant -dddt -c|g " < /usr/lib/systemd/system/wpa_supplicant.service > /etc/systemd/system/wpa_supplicant.service


# enable wicked as the network.service
systemctl --force disable NetworkManager.service
systemctl enable --force wicked.service

# force reset of wpa-supplicant log file
cp --backup=numbered /dev/null /var/log/wpa_supplicant.log

reboot

#
# wait until the system started + 1 minute, login as root / "su -" and execute:
#

mkdir bug-report-data-1 ; cd bug-report-data-1
wicked show-config >  wicked-config.xml
wicked show-xml >  wicked-status.xml
journalctl -b -o short-precise > wicked.log
cp /var/log/wpa_supplicant.log wpa_supplicant.log

#
# Edit the wicked.config file and replace your WPA pre-shared key
# with XXXXXXXXXXX. You may use "vi", "joe" or F4 in "mc".
# Do not use any full blown office/konqieror/... which may try to
# interpret the files like in the comment above.
#
# Finally, create a tgz or zip archive of the files:
#

tar cvzf wicked-bug-report-data-1.tgz wicked*.* wpa*.log

# and attach the wicked-bug-report-data-1.tgz file as private one to
# the new bug report.
# To be safe, change the WPA key on the access point after doing it.

(In reply to Bob Goddard from comment #15)
> Changing 'false' to 'true' partially fixed it for me.
> 
> This 'false' line is in the core package, given that SO many people have
> broken systems because of this, as far as I am concerned, you should release
> an update with the correct setting as soon as possible. Not everyone is
> going to go hunting in bugzilla.

Yes. The default was "true" -- but there was a management decision to
disable it by default, because there was some bug while instalation,
where it accidentially worked without nanny but not with nanny :-/
And yes, we have to address this somehow and change to "true" again...