|
Bugzilla – Full Text Bug Listing |
| Summary: | No network with wireless card and wicked service | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | kevin vandeventer <pilotgi> |
| Component: | Network | Assignee: | wicked maintainers <wicked-maintainers> |
| Status: | RESOLVED DUPLICATE | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | bwiedemann, cfeck, geoff, mls, mt, opensuse, pilotgi, pwieczorkiewicz |
| Version: | 13.2 Beta 1 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
kevin vandeventer
2014-10-27 18:50:08 UTC
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... |