> > Agree, nothing looks bad. Try running "iw event" while you suspend > > - if > > the NIC thought it woke up the system there will be an event > > indicating > > so. > > > > Indeed, I get: > 1488836432.153465: wlan0 (phy #0): WoWLAN wakeup > * packet (might be truncated): > ac:fd:ce:de:e1:58:b8:27:eb:f4:3b:4c:08:00:45:00:00:31:78:d1:40:00:3f: > 06:3d:55:c0:a8:02:23:c0:a8:02:2d:30:39:30:39:f2:04:6f:88:8b:74:4c:c2: > 50:18:72:10:00:00:00:00:57:41:4b:45:55:50:4e:4f:57 > * TCP connection wakeup received > > Note the trailing "57:41:4b:45:55:50:4e:4f:57" which is your > "WAKEUPNOW". > > Also magic packet "works" this way, i.e. shows up via "iw event". Right. So that means the device did in fact stay powered all the way through, otherwise we wouldn't have been able to retrieve this event data. > I realized I also have a Win10 installation on that machine - and may > as well try WoWLAN with it. > Enabling (in the dreaded device manager) wake via the WiFi device, > magic packet mode, I also cannot wake the machine. Ok. I didn't even know it was easy to actually get this configured on Windows :) > So if it was a driver bug, it would have to be present both in > Windows and Linux drivers - but I guess it's just another case > of broken system firmware *sigh*. Agree, that seems rather unlikely. Unless there's some kind of "magic" setup that the UEFI wants, and the driver knows nothing about ... also seems unlikely though. > And that's even though it's a pretty recent Clevo W230SD-based > machine (which I considered decently widespread) > with unlocked UEFI (so I see almost all options), but of course > nothing related to ACPI wakeup. > But I guess widespread alone does not help ;-). Yeah, too bad. Want to ask the manufacturer for help? ;-) johannes