I am using Ubuntu Kinetic (22.10) on my Framework 12th Gen. I have it configured to do wake on WLAN responding only to the “magic packet” as follows:
802-11-wireless.wake-on-wlan is set to “0x8 (magic)” in NetworkManager for my home WiFi connection.
WOL_DISABLE is set to N in /etc/tlp.conf.
With these two settings in place I am able to use the etherwake tool to send a magic packet to my laptop from another Linux machine on my network, and it wakes up… sometimes. And then sometimes it just doesn’t. For example:
My laptop, on battery power, put itself to sleep at 10:13pm last night after it was idle for 20 minutes, as I have it configured to do.
I sent it a magic packet today at around 2:00pm and it didn’t wake up.
I woke it by hand by opening the lid, then suspended it by explicitly selecting the Suspend GNOME menu command, then sent it a magic packet and it woke back up.
I waited a half hour for it to pit itself to sleep and then sent it a magic packet and it woke itself up.
I am not sure why the magic packet worked the second and third time today but didn’t work the first time.
The only possibility I can think of is that there may be some sort of deep sleep state that gets entered after a long period of being asleep, such that it was in that deep sleep state after being suspended all night but never entered it in the shorter periods it was suspended today. If so, is there anyway to disable that deep sleep, and if I do that then will that have a significant impact on battery life?
Or is there some other reason I’m missing for why wake on WLAN might work only intermittently?
Hi @Jonathan_Kamens, I appreciate you reaching out to me directly on Mastodon - I’ve alerted tier 1 that I would be helping them to help you.
I will reply here as well because my findings may be useful to others, but I will also parrot my findings in the ticket as well. So if that seems, well, dumb, there is method to the madness.
You’ve provided outstanding notes that I will work to replicate the environment to better get a feel for what is falling off here. I think you’ve touched on some of my early suspicions, but I’ll be working to replicate your experience.
I have your configuration as:
Ubuntu 22.10 (assuming all the updates are current).
Going to test this with TLP enabled (defaults, then again with WOL_DISABLE is set to N, then again with TLP removed).
I’ll update once I have some findings to report back with. This will take place tomorrow. You will absolutely hear back from me here personally.
One other note: I have nvme.noacpi=1 in GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub for reasons others have explained elsewhere (greatly improves battery life during sleep). That may be either directly or indirectly relevant here, by which I mean that while I don’t think it’s the direct cause of this issue, I think it’s possible that you may not be able to reproduce this issue without that setting, because I suspect that without that setting the laptop never goes into deep enough sleep to cause the problem I’ve described. This is all just guessing though.
Okay, I appreciate this, thanks. I haven’t done anything with Wake on LAN or WAN in a dog’s age, so I did a bit of digging before I dive into this tomorrow morning. Happened upon additional details on WOL with TLP.
unfortunately the setting’s doc is misleading here. In fact WOL_DISABLE=N means that TLP doesn’t touch the state of WOL at all.
I suspect a problem in the kernel driver of the LAN adapter or some other TLP power saving setting that makes the driver activate WOL. Check the troubleshooting guide.
The issue itself appears to be closed without a resolution. But you’ve given me a place from which to test from tomorrow with noacpi=1 and testing various kernels themselves.
Ideally, emphasis on ideally, the sleep state shouldn’t matter…but suspend is a tricky beast. Tomorrow I should have been able to determine if this is a sleep level issue or simply a kernel being a pill.
Appreciate your notes, I will be working through this tomorrow.
from 3 to 2, so I can disable power savings for the WiFi card.
Reboot, testing now. If this fails, I will then test changing s2idle from deep to shallow.
Reboot, test again.
I opted for wakeonlan vs ethtool in these tests. Seems ethtool wasn’t wanting to cooperate with me, so that’s an issue for another time.
This will also be on my testing list. I “suspect” 3 into 2 will make this functional. I’ll know for sure later today after it sits suspended a bit longer.
This is what I am going to test tonight. In passing, it hasn’t “felt” worse. But I will do my typical full charge, 11 hour suspend to verify. Difference being I will wake it with a magic packet vs the lid/keys.
Power states with WiFi has always been an ulcer for me personally, so I am hopeful the battery “tax” is minimal in testing.
