Bug 1257368 - WiFi doesn't 'turn on' after resume from suspend
WiFi doesn't 'turn on' after resume from suspend
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
24
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
: Reopened
: 1289631 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-26 19:15 EDT by Rodd Clarkson
Modified: 2017-08-08 08:10 EDT (History)
23 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-08 08:10:19 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Before suspending and resuming (34.82 KB, image/png)
2015-08-27 07:58 EDT, Rodd Clarkson
no flags Details
After suspending and resuming (24.10 KB, image/png)
2015-08-27 07:59 EDT, Rodd Clarkson
no flags Details
Output from "journalctl -u NetworkManager" (684.62 KB, text/plain)
2015-10-29 11:25 EDT, Vinicius Reis
no flags Details
journalctl -u NetworkManager (with debug level) (1.03 MB, text/plain)
2015-10-30 11:56 EDT, Vinicius Reis
no flags Details
udevadm monitor output (for a suspend/resume cycle on lid close) (21.05 KB, text/plain)
2015-10-30 11:58 EDT, Vinicius Reis
no flags Details
journalctl -u NetworkManager, for the steps on the comment #16 (1.25 MB, text/plain)
2015-10-30 22:56 EDT, Vinicius Reis
no flags Details
kernel log on Dell P57G (71.21 KB, text/plain)
2016-05-16 01:07 EDT, Pavel Roskin
no flags Details
lspci on Dell P57G (1.20 KB, text/plain)
2016-05-16 01:08 EDT, Pavel Roskin
no flags Details

  None (edit)
Description Rodd Clarkson 2015-08-26 19:15:45 EDT
Description of problem:

Each time I resume my laptop from suspend I have to 'Turn On' WiFi again.


Version-Release number of selected component (if applicable):

NetworkManager-1.0.6-0.2.20150813git7e2caa2.fc23.x86_64


How reproducible:

Every time


Steps to Reproduce:
1. Suspend laptop
2. Resume from suspend
3. WiFi failes to connect to a local (known) network.


Actual results:

The WiFi is still 'Off' and you need to click in the top-right corner of Gnome, select WiFi and then select Turn On.


Expected results:

WiFi should automatically be turned on and just connect to a known network if available.


Additional info:

This is a regression.

$ lspci
00:00.0 Host bridge: Intel Corporation Haswell-ULT DRAM Controller (rev 0b)
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)
00:03.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 0b)
00:14.0 USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04)
00:16.0 Communication controller: Intel Corporation 8 Series HECI #0 (rev 04)
00:1b.0 Audio device: Intel Corporation 8 Series HD Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 1 (rev e4)
00:1c.2 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 3 (rev e4)
00:1d.0 USB controller: Intel Corporation 8 Series USB EHCI #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation 8 Series LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 8 Series SATA Controller 1 [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 8 Series SMBus Controller (rev 04)
02:00.0 Network controller: Intel Corporation Wireless 7260 (rev 6b)
Comment 1 Jirka Klimes 2015-08-27 07:49:37 EDT
Please check that you Wi-Fi connection profile is setup to connect automatically. Either in gnome-control-center or using nmcli.

$ nmcli connection
select you profile
$ nmcli con show <your profile name> | grep autoconnect
Comment 2 Rodd Clarkson 2015-08-27 07:55:38 EDT
$ nmcli con show "Somewhere Else" | grep autoconnect
connection.autoconnect:                 yes
connection.autoconnect-priority:        0
connection.autoconnect-slaves:          -1 (default)
$ nmcli con show "Somewhere There" | grep autoconnect
connection.autoconnect:                 yes
connection.autoconnect-priority:        0
connection.autoconnect-slaves:          -1 (default)
$ nmcli con show "MRSS School" | grep autoconnect
connection.autoconnect:                 yes
connection.autoconnect-priority:        0
connection.autoconnect-slaves:          -1 (default)
Comment 3 Rodd Clarkson 2015-08-27 07:57:59 EDT
The problem isn't autoconnecting. Once WiFi is turned on the connection works properly, but the WiFi is "Off" after resume.  See the attached screenshots of the gnome properties Network dialog before and after a suspend/resume cycle.
Comment 4 Rodd Clarkson 2015-08-27 07:58:33 EDT
Created attachment 1067697 [details]
Before suspending and resuming
Comment 5 Rodd Clarkson 2015-08-27 07:59:41 EDT
Created attachment 1067699 [details]
After suspending and resuming
Comment 6 Jirka Klimes 2015-09-04 05:11:30 EDT
Well, would you then grab NetworkManager logs over suspend/resume cycle?
(journalctl -u NetworkManger)

Also take output of 'nmcli radio' and 'rfkill list' before and after suspend.
Comment 7 Rodd Clarkson 2015-09-13 20:18:03 EDT
Before suspend:

$ nmcli radio
WIFI-HW  WIFI     WWAN-HW  WWAN    
enabled  enabled  enabled  enabled 

$ rfkill list
1: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
4: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no



After resume:

$ nmcli radio
WIFI-HW  WIFI      WWAN-HW  WWAN    
enabled  disabled  enabled  enabled 

$ rfkill list
1: phy0: Wireless LAN
	Soft blocked: yes
	Hard blocked: no
6: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no



Log file for "journalctl -u NetworkManger"

NOTE: It's not as consistent as it was.  These log files contain a suspend/resume cycle where the WIFI started properly, and then one where it didn't.


Sep 14 10:13:53 moose NetworkManager[962]: <info>  sleep requested (sleeping: no  enabled: yes)
Sep 14 10:13:53 moose NetworkManager[962]: <info>  sleeping...
Sep 14 10:13:53 moose NetworkManager[962]: <info>  (wlp2s0): device state change: activated -> unmanaged
Sep 14 10:13:53 moose NetworkManager[962]: <info>  (wlp2s0): canceled DHCP transaction, DHCP client pid 
Sep 14 10:13:53 moose NetworkManager[962]: <info>  (wlp2s0): DHCPv4 state changed bound -> done
Sep 14 10:13:53 moose NetworkManager[962]: <info>  NetworkManager state is now ASLEEP
Sep 14 10:13:53 moose NetworkManager[962]: <warn>  Failed to GDBus.Error:fi.w1.wpa_supplicant1.NotConnec
Sep 14 10:14:02 moose NetworkManager[962]: <info>  wake requested (sleeping: yes  enabled: yes)
Sep 14 10:14:02 moose NetworkManager[962]: <info>  waking up...
Sep 14 10:14:02 moose NetworkManager[962]: <info>  (wlp2s0): device state change: unmanaged -> unavailab
Sep 14 10:14:02 moose NetworkManager[962]: <info>  NetworkManager state is now CONNECTED_LOCAL
Sep 14 10:14:02 moose NetworkManager[962]: <info>  connectivity: check for uri 'http://fedoraproject.org
Sep 14 10:14:02 moose NetworkManager[962]: <info>  (wlp2s0) supports 1 scan SSIDs
Sep 14 10:14:02 moose NetworkManager[962]: <info>  (wlp2s0): supplicant interface state: starting -> rea
Sep 14 10:14:02 moose NetworkManager[962]: <info>  (wlp2s0): device state change: unavailable -> disconn
Sep 14 10:14:05 moose NetworkManager[962]: <info>  (wlp2s0): supplicant interface state: ready -> inacti
Sep 14 10:14:05 moose NetworkManager[962]: <info>  Auto-activating connection 'Somewhere There'.
Sep 14 10:14:05 moose NetworkManager[962]: <info>  (wlp2s0): Activation: starting connection 'Somewhere 
Sep 14 10:14:05 moose NetworkManager[962]: <info>  (wlp2s0): device state change: disconnected -> prepar
Sep 14 10:14:05 moose NetworkManager[962]: <info>  NetworkManager state is now CONNECTING
Sep 14 10:14:05 moose NetworkManager[962]: <info>  (wlp2s0): device state change: prepare -> config (rea
Sep 14 10:14:05 moose NetworkManager[962]: <info>  (wlp2s0): Activation: (wifi) access point 'Somewhere 
Sep 14 10:14:05 moose NetworkManager[962]: <info>  (wlp2s0): device state change: config -> need-auth (r
Sep 14 10:14:05 moose NetworkManager[962]: <info>  (wlp2s0): device state change: need-auth -> prepare (
Sep 14 10:14:05 moose NetworkManager[962]: <info>  (wlp2s0): device state change: prepare -> config (rea
Sep 14 10:14:05 moose NetworkManager[962]: <info>  (wlp2s0): Activation: (wifi) connection 'Somewhere Th
Sep 14 10:14:05 moose NetworkManager[962]: <info>  Config: added 'ssid' value 'Somewhere There'
Sep 14 10:14:05 moose NetworkManager[962]: <info>  Config: added 'scan_ssid' value '1'
Sep 14 10:14:05 moose NetworkManager[962]: <info>  Config: added 'key_mgmt' value 'WPA-PSK'
Sep 14 10:14:05 moose NetworkManager[962]: <info>  Config: added 'psk' value '<omitted>'
Sep 14 10:14:05 moose NetworkManager[962]: <info>  Config: added 'proto' value 'WPA RSN'
Sep 14 10:14:05 moose NetworkManager[962]: <info>  Config: set interface ap_scan to 1
Sep 14 10:14:05 moose NetworkManager[962]: <info>  (wlp2s0): supplicant interface state: inactive -> ass
Sep 14 10:14:05 moose NetworkManager[962]: <info>  (wlp2s0): supplicant interface state: associating -> 
Sep 14 10:14:05 moose NetworkManager[962]: <info>  (wlp2s0): supplicant interface state: 4-way handshake
Sep 14 10:14:05 moose NetworkManager[962]: <info>  (wlp2s0): Activation: (wifi) Stage 2 of 5 (Device Con
Sep 14 10:14:05 moose NetworkManager[962]: <info>  (wlp2s0): device state change: config -> ip-config (r
Sep 14 10:14:05 moose NetworkManager[962]: <info>  Activation (wlp2s0) Beginning DHCPv4 transaction (tim
Sep 14 10:14:05 moose NetworkManager[962]: <info>  dhclient started with pid 10768
Sep 14 10:14:05 moose dhclient[10768]: DHCPREQUEST on wlp2s0 to 255.255.255.255 port 67 (xid=0x132df714)
Sep 14 10:14:05 moose dhclient[10768]: DHCPACK from 192.168.100.254 (xid=0x132df714)
Sep 14 10:14:05 moose NetworkManager[962]: <info>    address 192.168.100.100
Sep 14 10:14:05 moose NetworkManager[962]: <info>    plen 24 (255.255.255.0)
Sep 14 10:14:05 moose NetworkManager[962]: <info>    gateway 192.168.100.1
Sep 14 10:14:05 moose NetworkManager[962]: <info>    server identifier 192.168.100.254
Sep 14 10:14:05 moose NetworkManager[962]: <info>    lease time 600
Sep 14 10:14:05 moose NetworkManager[962]: <info>    hostname 'moose.home.clarkson.id.au'
Sep 14 10:14:05 moose NetworkManager[962]: <info>    nameserver '192.168.100.254'
Sep 14 10:14:05 moose NetworkManager[962]: <info>    domain name 'home.clarkson.id.au'
Sep 14 10:14:05 moose NetworkManager[962]: <info>    domain search 'home.clarkson.id.au.'
Sep 14 10:14:05 moose NetworkManager[962]: <info>  (wlp2s0): DHCPv4 state changed unknown -> bound
Sep 14 10:14:05 moose NetworkManager[962]: <info>  (wlp2s0): device state change: ip-config -> ip-check 
Sep 14 10:14:05 moose dhclient[10768]: bound to 192.168.100.100 -- renewal in 283 seconds.
Sep 14 10:14:05 moose NetworkManager[962]: <info>  (wlp2s0): device state change: ip-check -> secondarie
Sep 14 10:14:05 moose NetworkManager[962]: <info>  (wlp2s0): device state change: secondaries -> activat
Sep 14 10:14:05 moose NetworkManager[962]: <info>  NetworkManager state is now CONNECTED_LOCAL
Sep 14 10:14:05 moose NetworkManager[962]: <info>  NetworkManager state is now CONNECTED_SITE
Sep 14 10:14:05 moose NetworkManager[962]: <info>  Policy set 'Somewhere There' (wlp2s0) as default for 
Sep 14 10:14:05 moose NetworkManager[962]: <info>  (wlp2s0): Activation: successful, device activated.
Sep 14 10:14:06 moose NetworkManager[962]: <info>  NetworkManager state is now CONNECTED_GLOBAL
Sep 14 10:14:34 moose NetworkManager[962]: <info>  sleep requested (sleeping: no  enabled: yes)
Sep 14 10:14:34 moose NetworkManager[962]: <info>  sleeping...
Sep 14 10:14:34 moose NetworkManager[962]: <info>  (wlp2s0): device state change: activated -> unmanaged
Sep 14 10:14:34 moose NetworkManager[962]: <info>  (wlp2s0): canceled DHCP transaction, DHCP client pid 
Sep 14 10:14:34 moose NetworkManager[962]: <info>  (wlp2s0): DHCPv4 state changed bound -> done
Sep 14 10:14:34 moose NetworkManager[962]: <info>  NetworkManager state is now ASLEEP
Sep 14 10:14:34 moose NetworkManager[962]: <warn>  Failed to GDBus.Error:fi.w1.wpa_supplicant1.NotConnec
Sep 14 10:14:43 moose NetworkManager[962]: <info>  WiFi now disabled by radio killswitch
Sep 14 10:14:43 moose NetworkManager[962]: <info>  wake requested (sleeping: yes  enabled: yes)
Sep 14 10:14:43 moose NetworkManager[962]: <info>  waking up...
Sep 14 10:14:43 moose NetworkManager[962]: <info>  (wlp2s0): device state change: unmanaged -> unavailab
Sep 14 10:14:43 moose NetworkManager[962]: <info>  NetworkManager state is now CONNECTED_LOCAL
Sep 14 10:14:43 moose NetworkManager[962]: <info>  connectivity: check for uri 'http://fedoraproject.org
Comment 8 Vinicius Reis 2015-10-29 11:25 EDT
Created attachment 1087602 [details]
Output from "journalctl -u NetworkManager"

Output from "journalctl -u NetworkManager" after a suspend/resume cycle. May contain old log data.
Comment 9 Vinicius Reis 2015-10-29 11:26:52 EDT
I'm experiencing this very same issue on fedora 23 (4.2.3-300.fc23.x86_64), using a dualband Intel Corporation Wireless 7265.

These are the requested info:

$ nmcli con show "droid 2.0" | grep autoconnect
connection.autoconnect:                 yes
connection.autoconnect-priority:        0
connection.autoconnect-slaves:          -1 (default)

$ nmcli radio #BEFORE RESUME
HW-WIFI     WIFI        HW-WWAN     WWAN       
habilitado  habilitado  habilitado  habilitado 

$ rfkill list #BEFORE RESUME
0: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no
1: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no

$ nmcli radio #AFTER RESUME 
HW-WIFI     WIFI          HW-WWAN     WWAN       
habilitado  desabilitado  habilitado  habilitado 


$ rfkill list #AFTER RESUME
1: phy0: Wireless LAN
	Soft blocked: yes
	Hard blocked: no
2: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no

$ lspci
00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09)
00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09)
00:04.0 Signal processing controller: Intel Corporation Broadwell-U Camarillo Device (rev 09)
00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03)
00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI Controller #1 (rev 03)
00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #3 (rev e3)
00:1d.0 USB controller: Intel Corporation Wildcat Point-LP USB EHCI Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation Wildcat Point-LP LPC Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation Wildcat Point-LP SATA Controller [AHCI Mode] (rev 03)
00:1f.3 SMBus: Intel Corporation Wildcat Point-LP SMBus Controller (rev 03)
00:1f.6 Signal processing controller: Intel Corporation Wildcat Point-LP Thermal Management Controller (rev 03)
01:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)

$ journalctl -u NetworkManager
<< PLEASE SEE THE ATTACHED FILE (Output from "journalctl -u NetworkManager") >>
Comment 10 Vinicius Reis 2015-10-29 17:51:58 EDT
I've noticed  after a "resume and turn manually wifi on", everything works fine if the computer suspend/resume an arbitrary number of times (I've tested it with 3 suspend/resume cycles). 
But if I reboot the system and suspend/resume again, wifi will not turn on automatically, as reported on this bug.
Comment 11 Jirka Klimes 2015-10-30 08:19:33 EDT
The rfkill outputs show that after resume the device is soft blocked. Let's see if it unblocks on resume again.

1. enable debug logging in NM
 $ sudo nmcli gen log level debug
2. in a second terminal run
 $ udevadm monitor
3. suspend/resume computer
4. restore original NM log level
 $ sudo nmcli gen log level info
5. attach NM logs and the output of the udevadm command

There could be an issue with platform driver. What laptop is it again?
Comment 12 Vinicius Reis 2015-10-30 11:55:20 EDT
Hello, I've done those steps, the outputs are attached.

These were the steps I've done:
1. Turn on computer;
2. enabled debug log level, as described above;
3. suspend/resume computer
4. attached the logs to this message.
Do you want me to do an aditional step 3? (two suspend/resume cycles in a row).

The exact model of my computer is Dell Inspiron 7348 (2-in-1 laptop).
Thanks!
Comment 13 Vinicius Reis 2015-10-30 11:56 EDT
Created attachment 1087972 [details]
journalctl -u NetworkManager (with debug level)

A more verbose output for NetworkManager log.
Comment 14 Vinicius Reis 2015-10-30 11:58 EDT
Created attachment 1087973 [details]
udevadm monitor output (for a suspend/resume cycle on lid close)
Comment 15 Dan Williams 2015-10-30 17:53:45 EDT
If NM changes the rfkill state, it will log the message "WiFi hardware radio set [dis]enabled".  In the logs you attached, NM enables the rfkill switch a number of times, but never disables it.

Instead, the logs show that something is changing the rfkill state while NetworkManager is asleep:

<debug> [1446219870.901324] [nm-rfkill-manager.c:354] handle_uevent(): udev rfkill event: action 'change' device 'rfkill1'
<debug> [1446219870.901960] [nm-rfkill-manager.c:210] recheck_killswitches(): WiFi rfkill switch rfkill1 state now 0/1
<debug> [1446219870.901983] [nm-rfkill-manager.c:237] recheck_killswitches(): WiFi rfkill state now 'soft-blocked'
<debug> [1446219870.901997] [nm-manager.c:1355] manager_rfkill_update_one_type(): WiFi hw-enabled 1 sw-enabled 0
<info>  WiFi now disabled by radio killswitch
<debug> [1446219870.902111] [nm-rfkill-manager.c:354] handle_uevent(): udev rfkill event: action 'remove' device 'rfkill0'
<debug> [1446219870.914974] [nm-rfkill-manager.c:210] recheck_killswitches(): WiFi rfkill switch rfkill1 state now 0/1
<debug> [1446219870.922485] [nm-sleep-monitor-systemd.c:139] signal_cb(): Received PrepareForSleep signal: 0
<debug> [1446219870.922515] [nm-sleep-monitor-systemd.c:109] take_inhibitor(): Taking systemd sleep inhibitor
<debug> [1446219870.922590] [nm-manager.c:3817] resuming_cb(): Received resuming signal
<info>  wake requested (sleeping: yes  enabled: yes)
<info>  waking up...
<debug> [1446219870.923476] [nm-manager.c:1355] manager_rfkill_update_one_type(): WiFi hw-enabled 1 sw-enabled 0
<debug> [1446219870.927512] [nm-manager.c:1355] manager_rfkill_update_one_type(): WWAN hw-enabled 1 sw-enabled 1
<debug> [1446219870.932467] [nm-manager.c:1355] manager_rfkill_update_one_type(): WiMAX hw-enabled 1 sw-enabled 1
<debug> [1446219872.542940] [nm-manager.c:3677] do_sleep_wake(): disabling WiFi devices (hw_enabled 1, sw_enabled 0, user_enabled 1)
<debug> [1446219872.562969] [nm-device-wifi.c:3112] set_enabled(): [0x5564e49a9bf0] (wlp1s0): device now disabled
<debug> [1446219872.568755] [nm-device-wifi.c:3117] set_enabled(): [0x5564e49a9bf0] (wlp1s0): (disable): device blocked by UNMANAGED state
<debug> [1446219872.568774] [nm-manager.c:3677] do_sleep_wake(): enabling WWAN devices (hw_enabled 1, sw_enabled 1, user_enabled 1)
<debug> [1446219872.568782] [nm-manager.c:3677] do_sleep_wake(): enabling WiMAX devices (hw_enabled 1, sw_enabled 1, user_enabled 1)
<debug> [1446219872.607485] [devices/nm-device.c:7547] nm_device_set_unmanaged(): [0x5564e49a9bf0] (wlp1s0): now managed
<info>  (wlp1s0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]

I also notice that there's really only one rfkill driver on your system, and its name sometimes bounces around.  Systemd has rfkill save/restore functionality, and there may well be stale value stored in /var/lib/systemd/rfkill/ for the name the kernel picks for the device on resume, so it gets disabled.

Try this:

1) mv /usr/lib/systemd/systemd-rfkill /
2) try to reproduce the problem with a couple suspend/resume cycles
3) mv /systemd-rfkill /usr/lib/systemd/

if you don't have any problems after moving systemd-rfkill, then this bug should be moved to systemd.
Comment 16 Vinicius Reis 2015-10-30 22:50:39 EDT
Okay, I've followed those steps and wifi turned on only after the second suspend/resume cycle:

1. mv /usr/lib/systemd/systemd-rfkill /
2. suspend / resume  (here, WIFI DID NOT BACK, as previously described);
3. suspend / resume  (surprise, NOW WIFI ADAPTER WOKE UP! It just connected to default SSID as it should do);
4. mv /systemd-rfkill /usr/lib/systemd/


I've attached the log for NetworkManager for these steps in the hope it  be useful.
Also, I can't move this bug to systemd because I'm not the guy that filed it  =)
Comment 17 Vinicius Reis 2015-10-30 22:56 EDT
Created attachment 1088121 [details]
journalctl -u NetworkManager, for the steps on the comment #16

Logs for the steps on the comment #16:

1. mv /usr/lib/systemd/systemd-rfkill /
2. suspend / resume
3. suspend / resume
4. mv /systemd-rfkill /usr/lib/systemd/
Comment 18 Zbigniew Jędrzejewski-Szmek 2015-12-08 19:51:53 EST
*** Bug 1289631 has been marked as a duplicate of this bug. ***
Comment 19 Zbigniew Jędrzejewski-Szmek 2015-12-08 19:59:51 EST
The rfkill service was rewritten in systemd-227, i.e. the change is currently only in rawhide.

Any chance one of the reporters could check how the system behaves with the new systemd from rawhide? I made a scratch build of the rawhide systemd in koji for F23: http://koji.fedoraproject.org/koji/taskinfo?taskID=12116636. This way it doesn't require newer versions of dependencies, and it should be relatively safe to upgrade just the packages from this build, but please don't do this on a production machine.
Comment 20 Vinicius Reis 2015-12-08 20:30:41 EST
Hello, thanks for helping with this issue.

Sure I can test it! but at the momment I can't download the x86_64 (my fedora cpu arch.) package because it's marked with a "build error".

I'm not a experienced user, perhaps I'm missing some detail.
I will try to download it again.
Comment 21 Zbigniew Jędrzejewski-Szmek 2015-12-08 21:14:11 EST
Yeah, that build failed. This one succeeded: http://koji.fedoraproject.org/koji/taskinfo?taskID=12116703.
Comment 22 Vinicius Reis 2015-12-08 22:30:55 EST
I've tested these packages but it did not solve the problem.

I had some SELinux warnings (iptables and systemd), so I've put it on permissive mode and rebooted the system.
After reboot, I did a suspend/resume cycle, but wifi did not back from suspend.

Please let me know if you need some extra information or system log.
Comment 23 Richard Guest 2015-12-19 18:16:47 EST
I want to lob in and add that I am suffering from this issue also on my Dell Latitude E7450.

The original "fresh" install of Fedora 23 did not exhibit this bug.
Happy to provide any further information if required.

$ lspci | grep -i wireless
02:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)

$ rfkill list
0: dell-wifi: Wireless LAN
	Soft blocked: no
	Hard blocked: no
1: dell-bluetooth: Bluetooth
	Soft blocked: no
	Hard blocked: no
2: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
9: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no

suspend/resume

$ rfkill list
0: dell-wifi: Wireless LAN
	Soft blocked: yes
	Hard blocked: no
1: dell-bluetooth: Bluetooth
	Soft blocked: yes
	Hard blocked: no
2: phy0: Wireless LAN
	Soft blocked: yes
	Hard blocked: yes
10: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no

Key-press to toggle wifi:
Dec 20 12:08:51 hawk.gns.cri.nz kernel: atkbd serio0: Unknown key pressed (translated set 2, code 0x88 on isa0060/serio0).
Dec 20 12:08:51 hawk.gns.cri.nz kernel: atkbd serio0: Use 'setkeycodes e008 <keycode>' to make it known.
Dec 20 12:08:51 hawk.gns.cri.nz kernel: iwlwifi 0000:02:00.0: RF_KILL bit toggled to enable radio.
Dec 20 12:08:51 hawk.gns.cri.nz kernel: iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled
Dec 20 12:08:51 hawk.gns.cri.nz kernel: iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled
Dec 20 12:08:51 hawk.gns.cri.nz kernel: dell_wmi: Unknown key 153 pressed
Dec 20 12:08:51 hawk.gns.cri.nz kernel: iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled
Dec 20 12:08:51 hawk.gns.cri.nz kernel: iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled
Dec 20 12:08:51 hawk.gns.cri.nz kernel: IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready

$ rfkill list
0: dell-wifi: Wireless LAN
	Soft blocked: no
	Hard blocked: no
1: dell-bluetooth: Bluetooth
	Soft blocked: no
	Hard blocked: no
2: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
10: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no
Comment 24 Richard Guest 2015-12-19 22:22:24 EST
And FWIW, this is on systemd-228-6.gite35a787.fc24.x86_64
Comment 25 Richard Guest 2015-12-20 02:52:37 EST
There's clearly something getting toggled here, when it shouldn't...
If I suspend/resume everything's blocked, but then another suspend/resume cycle unblocks everything!

$ rfkill list 
0: dell-wifi: Wireless LAN
	Soft blocked: no
	Hard blocked: no
1: dell-bluetooth: Bluetooth
	Soft blocked: no
	Hard blocked: no
2: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
9: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no
$ systemctl suspend 
$ rfkill list
0: dell-wifi: Wireless LAN
	Soft blocked: yes
	Hard blocked: no
1: dell-bluetooth: Bluetooth
	Soft blocked: yes
	Hard blocked: no
2: phy0: Wireless LAN
	Soft blocked: yes
	Hard blocked: yes
10: hci0: Bluetooth
	Soft blocked: yes
	Hard blocked: no
$ systemctl suspend 
$ rfkill list
0: dell-wifi: Wireless LAN
	Soft blocked: no
	Hard blocked: no
1: dell-bluetooth: Bluetooth
	Soft blocked: no
	Hard blocked: no
2: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
11: hci0: Bluetooth
	Soft blocked: yes
	Hard blocked: no




Dec 20 20:44:34 hawk kernel: wlp2s0: deauthenticating from 00:60:64:ec:1e:bb by local choice (Reason: 3=DEAUTH_LEAVING)
Dec 20 20:44:36 hawk kernel: PM: Syncing filesystems ... done.
Dec 20 20:44:36 hawk kernel: PM: Preparing system for sleep (mem)
Dec 20 20:44:40 hawk kernel: Freezing user space processes ... (elapsed 0.002 seconds) done.
Dec 20 20:44:40 hawk kernel: Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done.
Dec 20 20:44:40 hawk kernel: PM: Suspending system (mem)
Dec 20 20:44:40 hawk kernel: Suspending console(s) (use no_console_suspend to debug)
Dec 20 20:44:40 hawk kernel: sd 1:0:0:0: [sda] Synchronizing SCSI cache
Dec 20 20:44:40 hawk kernel: sd 1:0:0:0: [sda] Stopping disk
Dec 20 20:44:40 hawk kernel: e1000e: EEE TX LPI TIMER: 00000011
Dec 20 20:44:40 hawk kernel: PM: suspend of devices complete after 180.756 msecs
Dec 20 20:44:40 hawk kernel: PM: late suspend of devices complete after 17.023 msecs
Dec 20 20:44:40 hawk kernel: ehci-pci 0000:00:1d.0: System wakeup enabled by ACPI
Dec 20 20:44:40 hawk kernel: e1000e 0000:00:19.0: System wakeup enabled by ACPI
Dec 20 20:44:40 hawk kernel: xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
Dec 20 20:44:40 hawk kernel: PM: noirq suspend of devices complete after 87.925 msecs
Dec 20 20:44:40 hawk kernel: ACPI: Preparing to enter system sleep state S3
Dec 20 20:44:40 hawk kernel: ACPI : EC: EC stopped
Dec 20 20:44:40 hawk kernel: PM: Saving platform NVS memory
Dec 20 20:44:40 hawk kernel: Disabling non-boot CPUs ...
Dec 20 20:44:40 hawk kernel: smpboot: CPU 1 is now offline
Dec 20 20:44:40 hawk kernel: smpboot: CPU 2 is now offline
Dec 20 20:44:40 hawk kernel: smpboot: CPU 3 is now offline
Dec 20 20:44:40 hawk kernel: ACPI: Low-level resume complete
Dec 20 20:44:40 hawk kernel: ACPI : EC: EC started
Dec 20 20:44:40 hawk kernel: PM: Restoring platform NVS memory
Dec 20 20:44:40 hawk kernel: Enabling non-boot CPUs ...
Dec 20 20:44:40 hawk kernel: x86: Booting SMP configuration:
Dec 20 20:44:40 hawk kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2
Dec 20 20:44:40 hawk kernel:  cache: parent cpu1 should not be sleeping
Dec 20 20:44:40 hawk kernel: CPU1 is up
Dec 20 20:44:40 hawk kernel: smpboot: Booting Node 0 Processor 2 APIC 0x1
Dec 20 20:44:40 hawk kernel:  cache: parent cpu2 should not be sleeping
Dec 20 20:44:40 hawk kernel: CPU2 is up
Dec 20 20:44:40 hawk kernel: smpboot: Booting Node 0 Processor 3 APIC 0x3
Dec 20 20:44:40 hawk kernel:  cache: parent cpu3 should not be sleeping
Dec 20 20:44:40 hawk kernel: CPU3 is up
Dec 20 20:44:40 hawk kernel: ACPI: Waking up from system sleep state S3
Dec 20 20:44:40 hawk kernel: xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI
Dec 20 20:44:40 hawk kernel: ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI
Dec 20 20:44:40 hawk kernel: PM: noirq resume of devices complete after 101.955 msecs
Dec 20 20:44:40 hawk kernel: PM: early resume of devices complete after 6.154 msecs
Dec 20 20:44:40 hawk kernel: sd 1:0:0:0: [sda] Starting disk
Dec 20 20:44:40 hawk kernel: e1000e 0000:00:19.0: System wakeup disabled by ACPI
Dec 20 20:44:40 hawk kernel: rtc_cmos 00:01: System wakeup disabled by ACPI
Dec 20 20:44:40 hawk kernel: usb 3-1.3: reset full-speed USB device number 3 using ehci-pci
Dec 20 20:44:40 hawk kernel: ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 20 20:44:40 hawk kernel: ata1: SATA link down (SStatus 0 SControl 300)
Dec 20 20:44:40 hawk kernel: Bluetooth: hci0: turning off Intel device LED failed (-19)
Dec 20 20:44:40 hawk kernel: ata2.00: configured for UDMA/133
Dec 20 20:44:40 hawk kernel: usb 3-1.6: reset high-speed USB device number 4 using ehci-pci
Dec 20 20:44:40 hawk kernel: PM: resume of devices complete after 507.997 msecs
Dec 20 20:44:40 hawk kernel: PM: Finishing wakeup.
Dec 20 20:44:40 hawk kernel: Restarting tasks ... done.
Dec 20 20:44:40 hawk kernel: pci_bus 0000:01: Allocating resources
Dec 20 20:44:40 hawk kernel: pci_bus 0000:02: Allocating resources
Dec 20 20:44:40 hawk kernel: pci_bus 0000:03: Allocating resources
Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:40 hawk kernel: Bluetooth: hci0: read Intel version: 370810011003110e00
Dec 20 20:44:40 hawk kernel: Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
Dec 20 20:44:40 hawk kernel: pci_bus 0000:01: Allocating resources
Dec 20 20:44:40 hawk kernel: pci_bus 0000:02: Allocating resources
Dec 20 20:44:40 hawk kernel: pci_bus 0000:03: Allocating resources
Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:40 hawk kernel: pci_bus 0000:01: Allocating resources
Dec 20 20:44:40 hawk kernel: pci_bus 0000:02: Allocating resources
Dec 20 20:44:40 hawk kernel: pci_bus 0000:03: Allocating resources
Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:40 hawk kernel: acpi PNP0401:00: Already enumerated
Dec 20 20:44:40 hawk kernel: acpi PNP0501:00: Still not present
Dec 20 20:44:41 hawk kernel: e1000e: eno1 NIC Link is Down
Dec 20 20:44:41 hawk kernel: IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready
Dec 20 20:44:41 hawk kernel: IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready
Dec 20 20:44:41 hawk kernel: Bluetooth: hci0: Intel Bluetooth firmware patch completed and activated
Dec 20 20:44:41 hawk kernel: IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready
Dec 20 20:44:55 hawk kernel: PM: Syncing filesystems ... done.
Dec 20 20:44:55 hawk kernel: PM: Preparing system for sleep (mem)
Dec 20 20:44:55 hawk kernel: Freezing user space processes ... (elapsed 0.002 seconds) done.
Dec 20 20:44:55 hawk kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Dec 20 20:44:55 hawk kernel: PM: Suspending system (mem)
Dec 20 20:44:55 hawk kernel: Suspending console(s) (use no_console_suspend to debug)
Dec 20 20:44:55 hawk kernel: sd 1:0:0:0: [sda] Synchronizing SCSI cache
Dec 20 20:44:55 hawk kernel: sd 1:0:0:0: [sda] Stopping disk
Dec 20 20:44:55 hawk kernel: e1000e: EEE TX LPI TIMER: 00000011
Dec 20 20:44:55 hawk kernel: PM: suspend of devices complete after 75.960 msecs
Dec 20 20:44:55 hawk kernel: PM: late suspend of devices complete after 16.685 msecs
Dec 20 20:44:55 hawk kernel: ehci-pci 0000:00:1d.0: System wakeup enabled by ACPI
Dec 20 20:44:55 hawk kernel: e1000e 0000:00:19.0: System wakeup enabled by ACPI
Dec 20 20:44:55 hawk kernel: xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
Dec 20 20:44:55 hawk kernel: PM: noirq suspend of devices complete after 80.935 msecs
Dec 20 20:44:55 hawk kernel: ACPI: Preparing to enter system sleep state S3
Dec 20 20:44:55 hawk kernel: ACPI : EC: EC stopped
Dec 20 20:44:55 hawk kernel: PM: Saving platform NVS memory
Dec 20 20:44:55 hawk kernel: Disabling non-boot CPUs ...
Dec 20 20:44:55 hawk kernel: smpboot: CPU 1 is now offline
Dec 20 20:44:55 hawk kernel: smpboot: CPU 2 is now offline
Dec 20 20:44:55 hawk kernel: smpboot: CPU 3 is now offline
Dec 20 20:44:55 hawk kernel: ACPI: Low-level resume complete
Dec 20 20:44:55 hawk kernel: ACPI : EC: EC started
Dec 20 20:44:55 hawk kernel: PM: Restoring platform NVS memory
Dec 20 20:44:55 hawk kernel: Enabling non-boot CPUs ...
Dec 20 20:44:55 hawk kernel: x86: Booting SMP configuration:
Dec 20 20:44:55 hawk kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2
Dec 20 20:44:55 hawk kernel:  cache: parent cpu1 should not be sleeping
Dec 20 20:44:55 hawk kernel: CPU1 is up
Dec 20 20:44:55 hawk kernel: smpboot: Booting Node 0 Processor 2 APIC 0x1
Dec 20 20:44:55 hawk kernel:  cache: parent cpu2 should not be sleeping
Dec 20 20:44:55 hawk kernel: CPU2 is up
Dec 20 20:44:55 hawk kernel: smpboot: Booting Node 0 Processor 3 APIC 0x3
Dec 20 20:44:55 hawk kernel:  cache: parent cpu3 should not be sleeping
Dec 20 20:44:55 hawk kernel: CPU3 is up
Dec 20 20:44:55 hawk kernel: ACPI: Waking up from system sleep state S3
Dec 20 20:44:55 hawk kernel: xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI
Dec 20 20:44:55 hawk kernel: ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI
Dec 20 20:44:55 hawk kernel: PM: noirq resume of devices complete after 105.065 msecs
Dec 20 20:44:55 hawk kernel: PM: early resume of devices complete after 7.489 msecs
Dec 20 20:44:55 hawk kernel: sd 1:0:0:0: [sda] Starting disk
Dec 20 20:44:55 hawk kernel: iwlwifi 0000:02:00.0: RF_KILL bit toggled to enable radio.
Dec 20 20:44:55 hawk kernel: e1000e 0000:00:19.0: System wakeup disabled by ACPI
Dec 20 20:44:55 hawk kernel: rtc_cmos 00:01: System wakeup disabled by ACPI
Dec 20 20:44:55 hawk kernel: usb 3-1.6: reset high-speed USB device number 4 using ehci-pci
Dec 20 20:44:55 hawk kernel: ata1: SATA link down (SStatus 0 SControl 300)
Dec 20 20:44:55 hawk kernel: ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 20 20:44:55 hawk kernel: ata2.00: configured for UDMA/133
Dec 20 20:44:55 hawk kernel: usb 3-1.3: reset full-speed USB device number 3 using ehci-pci
Dec 20 20:44:55 hawk kernel: PM: resume of devices complete after 527.055 msecs
Dec 20 20:44:55 hawk kernel: PM: Finishing wakeup.
Dec 20 20:44:55 hawk kernel: Restarting tasks ... done.
Dec 20 20:44:55 hawk kernel: Bluetooth: hci0: read Intel version: 370810011003110e00
Dec 20 20:44:55 hawk kernel: Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
Dec 20 20:44:55 hawk kernel: pci_bus 0000:01: Allocating resources
Dec 20 20:44:55 hawk kernel: pci_bus 0000:02: Allocating resources
Dec 20 20:44:55 hawk kernel: pci_bus 0000:03: Allocating resources
Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:55 hawk kernel: pci_bus 0000:01: Allocating resources
Dec 20 20:44:55 hawk kernel: pci_bus 0000:02: Allocating resources
Dec 20 20:44:55 hawk kernel: pci_bus 0000:03: Allocating resources
Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:55 hawk kernel: pci_bus 0000:01: Allocating resources
Dec 20 20:44:55 hawk kernel: pci_bus 0000:02: Allocating resources
Dec 20 20:44:55 hawk kernel: pci_bus 0000:03: Allocating resources
Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Dec 20 20:44:55 hawk kernel: acpi PNP0401:00: Already enumerated
Dec 20 20:44:55 hawk kernel: acpi PNP0501:00: Still not present
Dec 20 20:44:55 hawk kernel: e1000e: eno1 NIC Link is Down
Dec 20 20:44:55 hawk kernel: IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready
Dec 20 20:44:55 hawk kernel: iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled
Dec 20 20:44:55 hawk kernel: iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled
Dec 20 20:44:56 hawk kernel: iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled
Dec 20 20:44:56 hawk kernel: iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled
Dec 20 20:44:56 hawk kernel: Bluetooth: hci0: Intel Bluetooth firmware patch completed and activated
Dec 20 20:44:56 hawk kernel: IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready
Dec 20 20:44:56 hawk kernel: IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready
Dec 20 20:44:56 hawk kernel: IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready
Dec 20 20:44:56 hawk kernel: IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready
Dec 20 20:44:59 hawk kernel: wlp2s0: authenticate with 00:60:64:ec:1e:bb
Dec 20 20:44:59 hawk kernel: wlp2s0: send auth to 00:60:64:ec:1e:bb (try 1/3)
Dec 20 20:44:59 hawk kernel: wlp2s0: authenticated
Dec 20 20:44:59 hawk kernel: wlp2s0: associate with 00:60:64:ec:1e:bb (try 1/3)
Dec 20 20:44:59 hawk kernel: wlp2s0: RX AssocResp from 00:60:64:ec:1e:bb (capab=0x431 status=0 aid=9)
Dec 20 20:44:59 hawk kernel: wlp2s0: associated
Dec 20 20:44:59 hawk kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready
Comment 26 Paul Scott 2016-01-10 06:31:36 EST
Also affects Dell XPS13 9333 with same network card as original poster. Can provide additional details if useful.
Comment 27 Pavel Roskin 2016-01-17 00:35:42 EST
I'm experiencing that problem with Fedora 23 (all up to date with updates-testing) and LXQt desktop. After resuming from suspend, right-clicking on NetworkManager shows that "Enable Wi-Fi" is unchecked. I tried adding a USB Wi-Fi device in addition to the internal card, and both are shows as "Soft blocked: yes". Bluetooth is not soft blocked. The problem also existed on the same system with Fedora 22 and LXDE.
Comment 28 Cédric Bellegarde 2016-02-23 11:27:50 EST
Workaround this bug:

$ cat /etc/systemd/system/rfkill.service 
[Unit]
Description=Unlock my wifi
After=suspend.target

[Service]
ExecStart=/usr/sbin/rfkill unblock 1

[Install]
WantedBy=suspend.target


# systemctl enable rfkill
Comment 29 yannik 2016-03-04 07:15:44 EST
I am experiencing the same issues on a Dell XPS 15 (9530) with an Intel Wireless-AC 7260 wireless card on Fedora 23 with the latest available NetworkManager (1.0.10-3.fc23) and systemd (222-14.fc23).

I can confirm the findings already reported by other users:

Before resume:
$ rfkill list
2: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
15: nfc0: NFC
	Soft blocked: no
	Hard blocked: no
16: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no


After resume:
$ rfkill list
2: phy0: Wireless LAN
	Soft blocked: yes
	Hard blocked: no
15: nfc0: NFC
	Soft blocked: no
	Hard blocked: no
16: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no


These is my journalctl --unit Networkmanager output:
13:08:23 NetworkManager[14269]: <info>  sleep requested (sleeping: no  enabled: yes)
13:08:23 NetworkManager[14269]: <info>  sleeping...
13:08:23 NetworkManager[14269]: <info>  (wlp6s0): device state change: activated -> unmanaged (reason 'sleeping') [100 10 37]
13:08:23 NetworkManager[14269]: <info>  (wlp6s0): canceled DHCP transaction, DHCP client pid 19803
13:08:23 NetworkManager[14269]: <info>  (wlp6s0): DHCPv4 state changed bound -> done
13:08:23 NetworkManager[14269]: <info>  (wlp6s0): canceled DHCP transaction, DHCP client pid 19893
13:08:23 NetworkManager[14269]: <info>  (wlp6s0): DHCPv6 state changed unknown -> done
13:08:23 NetworkManager[14269]: <info>  NetworkManager state is now ASLEEP
13:08:23 NetworkManager[14269]: <warn>  Failed to GDBus.Error:fi.w1.wpa_supplicant1.NotConnected: This interface is not connected: disconnect.
13:08:35 NetworkManager[14269]: <info>  WiFi now disabled by radio killswitch
13:08:35 NetworkManager[14269]: <info>  wake requested (sleeping: yes  enabled: yes)
13:08:35 NetworkManager[14269]: <info>  waking up...
13:08:35 NetworkManager[14269]: <info>  (wlp6s0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
13:08:35 NetworkManager[14269]: <info>  NetworkManager state is now CONNECTED_LOCAL

Regarding the workaround by Cedric Bellegarde: My `phy0: Wireless LAN` has another id number (2 instead of 1), so I would suggest using `/usr/sbin/rfkill unblock wlan`, as suggested by the rfkill help:

---
	list [IDENTIFIER]
	block IDENTIFIER
	unblock IDENTIFIER
where IDENTIFIER is the index no. of an rfkill switch or one of:
	<idx> all wifi wlan bluetooth uwb ultrawideband wimax wwan gps fm nfc
---
Comment 30 Mike McCune 2016-03-28 19:38:32 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 31 Andreas 2016-04-13 03:21:49 EDT
Hi 
Running FC23 (4.4.6-301.fc23.x86_64) here - dell latitude e5550 
02:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)

after suspend this still happens:
[andreas@anakin ~]$ rfkill list
0: dell-wifi: Wireless LAN
	Soft blocked: yes
	Hard blocked: no
1: dell-bluetooth: Bluetooth
	Soft blocked: yes
	Hard blocked: no
3: phy0: Wireless LAN
	Soft blocked: yes
	Hard blocked: yes
8: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no
[andreas@anakin ~]$ 

so I have to manually unblock to make it work again: (either rfkill or network manager > "turn on")
Apr 13 09:15:30 anakin kernel: iwlwifi 0000:02:00.0: RF_KILL bit toggled to enable radio.
Apr 13 09:15:38 anakin NetworkManager[1404]: <info>  WiFi now enabled by radio killswitch
Apr 13 09:15:38 anakin kernel: iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled


BUT:


browsing journalcrt I came across this:

Apr 12 07:01:16 anakin systemd[1]: Started Unlock my wifi.
Apr 12 07:01:16 anakin systemd[1]: Starting Unlock my wifi...
Apr 12 07:01:16 anakin systemd[1]: Started Unlock my wifi.
Apr 12 07:01:16 anakin systemd[1]: Starting Unlock my wifi...
Apr 12 07:01:16 anakin systemd[1]: Started Unlock my wifi.
Apr 12 07:01:16 anakin systemd[1]: Starting Unlock my wifi...


is someone busy with this? Can I help?
Comment 32 Cédric Bellegarde 2016-04-18 16:23:47 EDT
It's a kernel issue.

Just happened on ArchLinux while switching from linux-lts-4.1.21 to linux-lts-4.4.7
Comment 33 Jan Včelák 2016-04-24 16:22:07 EDT
The bug is still present in Fedora 24.

systemd-229-7.fc24.x86_64
kernel-4.5.2-300.fc24.x86_64

Dell Latitude E5450
iwlwifi 0000:02:00.0: loaded firmware version 16.242414.0 op_mode iwlmvm
iwlwifi 0000:02:00.0: Detected Intel(R) Dual Band Wireless AC 7265, REV=0x210

Why is this bug in POST? Was it fixed somewhere? Is the bug tracked upstream?
Comment 34 Ari 2016-04-24 21:59:28 EDT
This happens for me as well

Dell Precision 7510, Fedora 24
Comment 35 Jim Perrin 2016-05-08 15:20:58 EDT
I'm seeing this behavior on a Dell e7450 as well.
Comment 36 Dominik 'Rathann' Mierzejewski 2016-05-15 16:59:41 EDT
Same thing on Dell XPS 13 (9333) with AC7260 Intel wireless chip. I think I see a pattern here: except for the first two reporters who didn't mention their laptop manufacturers, only dell laptops with AC726x chips seem to have this issue. It's likely that it's a bug in the platform driver for this hardware rather than in systemd.
Comment 37 Pavel Roskin 2016-05-16 01:05:21 EDT
I did not mention the model of my laptop in my comment, but it's indeed Dell P57G. I tried suspend and resume with up-to-date packages from update-testing. The problem still exists. dmesg shows some ACPI problems, but no problems with the wireless driver. That's what would be expected if the problem is manufacturer related.
Comment 38 Pavel Roskin 2016-05-16 01:07 EDT
Created attachment 1157794 [details]
kernel log on Dell P57G
Comment 39 Pavel Roskin 2016-05-16 01:08 EDT
Created attachment 1157795 [details]
lspci on Dell P57G
Comment 40 tsimecek 2016-08-04 10:43:18 EDT
I happens to me as well.
It is fresh installation of Fedora 24, kernel 4.6.4.
HW is Lenovo C440.

There was no problem on earlier F23 installation (although I do not know which kernel I was using).

Problem description: when I resume computer, wifi won't reconnect, I have to restart NetworkManager to connect.
Comment 41 tsimecek 2016-08-10 13:25:41 EDT
One more note to this:
It does not happen only when computer suspends. It happens also when you leave your computer running, but you let option "Suspend wifi to save power" in Power section of Gnome settings enabled.
Comment 42 Rob Wilkens 2016-11-14 18:58:52 EST
Sorry on last comment / I was just trying to subscribe to updates-- Having this same issue on Fedora 24 fresh install - 1+ year after this bug was reported.

If this helps, i have an Intel Wifi (Wirelesss AC) chip.. 

I would love to contribute, but I'm starting from scratch knowledgewise.
Comment 43 Rob Wilkens 2016-11-14 19:22:46 EST
I'm looking at the Network Manager logs

Pardon me if i'm stating the obvious, but the relevant part seems to be that when it *wakes* it gets a "WiFi Disabled By Network KillSwitch" message.

On way to sleep..

Nov 14 19:13:19 localhost.localdomain NetworkManager[864]: <info>  [1479168799.3317] manager: NetworkManager state is now ASLEEP

--8 seconds later i wake it up--

Nov 14 19:13:27 localhost.localdomain NetworkManager[864]: <info>  [1479168807.1745] manager: WiFi now disabled by radio killswitch
Nov 14 19:13:27 localhost.localdomain NetworkManager[864]: <info>  [1479168807.1950] manager: wake requested (sleeping: yes  enabled: yes)
Nov 14 19:13:27 localhost.localdomain NetworkManager[864]: <info>  [1479168807.1951] manager: waking up...

So the question would be why is the network killswitch being trigerred when it wakes?

Someone mentioned the AC 7260 chip was an issue, but mine only has an AC 3160 chip, which i believe is half the speed but basically the same chip.  Yes, this is a dell laptop.

-Rob
Comment 44 Rob Wilkens 2016-11-15 07:22:43 EST
This seems to be fixed.

I did an update using dandefied yum ("dnf update"), rebooted, and now i've suspended and resumed at least 6 times and every time wifi came back on.
Comment 45 Pavel Roskin 2016-11-19 11:32:52 EST
The issue is not occurring for me on the same system that was having trouble. I'm on the current Fedora 25 now, kernel 4.8.6-300.fc25.x86_64.
Comment 46 Fedora End Of Life 2016-11-24 07:22:54 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 47 Samster 2016-11-30 11:00:55 EST
Equipment
*********
New install of Fedora 25 & KDE Spin with USB wifi card and 1 dormant/unused hard-wire connection: 

Actions:
********
Suspended PC
Restarted PC
NetworkManager icon is RED. No wifi or wired connections shown/listed at task bar display. System did not attempt to re-connect.

Clicked on connections icon (top right): Both potential connections displayed but "Connect" button is grayed-out on both (nothing operational).

Downloaded & installed rfkill (FC24): No good -- displayed/changed nothing.

Good News:
**********
Rebooted PC and wlan connection restored.

PLEASE NOTE -- I had a similar problem immediately after installing FC25 (though I am not clear that "suspend" was involved). I lost the wlan connection and nothing I found on the net helped restore it. I reinstalled the OS from the ground up.  accck!
Comment 48 Fedora End Of Life 2016-12-20 09:28:47 EST
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 49 Dominik 'Rathann' Mierzejewski 2016-12-21 16:01:17 EST
At least a couple of people said it affected F24 as well.
Comment 50 Fedora End Of Life 2017-07-25 15:11:58 EDT
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Comment 51 Fedora End Of Life 2017-08-08 08:10:19 EDT
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.