Comment 6 for bug 1361646

I have been struggling with very frequent wifi drops. In my regular quest for a solution I stumbled upon this post.

My kernel version is 4.2.0-16-generic
Linux 4.2.0-16-generic #19-Ubuntu SMP Thu Oct 8 15:35:06 UTC 2015

Most recent kern.log entries indicate
Nov 7 05:37:28 watsonit-150411 kernel: [419299.308586] ath: phy41: Chip reset failed
Nov 7 05:37:28 watsonit-150411 kernel: [419299.308590] ath: phy41: Unable to reset channel (2457 Mhz) reset status -22
Nov 7 05:37:28 watsonit-150411 kernel: [419299.308592] ath: phy41: Unable to set channel
Nov 7 05:37:28 watsonit-150411 kernel: [419299.408415] ath: phy41: RX failed to go idle in 10 ms RXSM=0x0
Nov 7 05:37:28 watsonit-150411 kernel: [419299.418500] ath: phy41: Failed to wakeup in 500us
Nov 7 05:37:28 watsonit-150411 kernel: [419299.428492] ath: phy41: Failed to wakeup in 500us
Nov 7 05:37:28 watsonit-150411 kernel: [419299.727544] ath: phy41: RX failed to go idle in 10 ms RXSM=0x306e82a7

Based on the above I came across a post @ http://ubuntuforums.org/showthread.php?2239557 and implemented the proposed script in /etc/pm/sleep.d/

case "{$1}" in
    hibernate|suspend)
        # disable wlan0
        ifdown wlan0 --force
        ;;
    resume|thaw)
        # enable wlan0
        ## service networking restart
        ifup wlan0
        ;;
esac

The belief is that for some reason wpa_supplicant does not stop before going to sleep, but then tries to start again upon resume in order to negotiate keys. Let's see if stopping wpa_supplicate before sleep (assuming this code achieves that and that the system really is suspending) solves this issue.

Worth noting here that I am not using network-manager since the problem was even greater with that additional service running.

It is yet to be determined whether or not this resolves, or improves things. What I have noticed since making this last change this morning is that the workstation eventually became unreachable from other LAN locations; however, upon returning to the workstation and unlocking the screen ifconfig and ping proved that connectivity was good.... perhaps the suspend/resume script did help. Ultimately, I still need to avoid having the connection drop at all -- no suspend, no bringing the interface down.

Hopefully some of this information sounds familiar to others and helps. If anyone has further suggestions on permanently resolving this issue, would love to hear them.