Sometimes when I lift the lid on the L13 and resume working, although my wifi connection is solid, I will time out on all network requests. I have to disable wifi (via software) and then re-enable it. Then the wifi will reconnect and it will all work.
This happens maybe every 1 out of 5 resumes.
Is there a faster way to cycle the wireless adapter? Is this indicative of a failing wifi card, or purely software in nature.
I do have the proprietary bluetooth firmware installed, if that matters.
I suspect software. I see similar results from time to time with Ubuntu even on cold boot, and more frequently on resume from hibernate (NB: hibernate not standby) - and that’s on the wired interface.
I just
sudo ifconfig interface down
wait x seconds
sudo ifconfig interface up
where interface is the name of the interface (which ought to be static once you know what it is and assuming that that kernel option is on).
Maybe you can script that and see whether it helps.
Toggling the kill switch should be even quicker. 
I don’t think I have this problem. It could also be a specific incompatibility with that particular wifi AP. Trying a different one could be worth a try.
You can hook up systemd target transition to execute some stuff. I was doing it for bluetooth on my older lappy.
See https://wiki.archlinux.org/index.php/Power_management#Sleep_hooksg for details
For sure. I’m weird in that I don’t like using physical buttons if I don’t have to. Wear and tear and all. I figure I’ll use the buttons in the situations where I genuinely want to be sure.
The AP in question is my home network, and for almost a year I had no problems, now it manifests occasionally. It might be that the gateway isnt renewing the DHCP lease or something, but I don’t have this priblem with any of the windows machines in the house.
this is precisely the kind of solution I was looking for. Typing two lines in a bash session is much easier than cycling wifi in the GUI. Thanks!
sudo systemctl restart networking
Except I sometimes see similar behaviour on the wired interface (on Ubuntu).
try to reconfigure (-g) or rebind (-n) dhcp - i suspect it does not wake up properly under certain ciscumstances (lease or arp expiration)
I’m wondering if it is because my home network is a mesh. If I wake it in the same place as I slept it, I don’t think I have a problem. If I, however, pick it up and go sit downstairs on the couch, I’ll have the problem. I wonder how the wireless firmware handles mesh networks. Does it always try to connect to the same AP, even when there are other APs broadcasting with the same SSID?
Also this is a recent thing. It didn’t use to happen. I’m wondering if some updates in the kernel are responsible?
Oh, that even makes it more plausible. Wireless mesh has no native means to bridge eth frames, so most of that is done in software relay. And SW relays need to build forwarding topology. Many of those rely on DHCP flooding (broadcast emulation) to build topology. So if topology expired during the sleep you need to refresh it, which dhcp normally does (by broadcasting). Also windows does it always (broadcasting).
Right, ok, well the next time I have the problem I’ll try to do the rebinding.
Anyway to see this in the logs?
Not in the log but could be seen in tcpdump
XYZ spy agency : computer(#jdfkldasj98234092jksadlka) wake UP !!!
computer(#jdfkldasj98234092jksadlka) : yeeeesss master !