Wake On Lan Is Not Waking

[m00tpoint]

I have an HP Z620 workstation I'd like to Wake on LAN only when I need to use it for my GNS3 network simulations. I have set WOL to enabled in the BIOS, and have disabled P5 deep sleep (don't remember exact verbiage on that one). When the machine is off, there is a very slowly blinking link light on enp1s0 (the ethernet interface that I have cabled), and the NIC on the attached machine indicates link in ethtool output, so to all appearances the NIC and the machine are configured properly. I've updated the BIOS to the latest available.

When I run the wakeonlan utility on the attached machine (another Linux host), tcpdump shows packets being sent to the z620. However, it's not waking up. Here are the ethtool output from the non-waking machine, and the tcpdump from the attached machine:

Code: Select all

dennis@apollo:~$ sudo ethtool enp1s0 
Settings for enp1s0:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 1
	Transceiver: internal
	Auto-negotiation: on
	MDI-X: off (auto)
	Supports Wake-on: pumbg
	Wake-on: g
	Current message level: 0x00000007 (7)
			       drv probe link
	Link detected: yes

Code: Select all

dennis@mercury:~$ sudo tcpdump -i eno1 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
01:45:52.378761 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from ec:8e:b5:79:02:27 (oui Unknown), length 363
^C
1 packet captured
1 packet received by filter
0 packets dropped by kernel
dennis@mercury:~$ 

Any help appreciated!

m00tpoint

[m00tpoint]

Found a couple of online images of the BIOS settings I set:



and

[m00tpoint]

I guess I managed to stump the world as well as myself. Still working on it, no resolution found yet.

[rene]

Any local router between apollo and mercury? If no, i.e., if just a switch, immediately out of ideas again...

[m00tpoint]

apollo and mercury are directly cabled, not even a switch in between. Yeah, I'm out of ideas too LOL. Thanks for the note.

[rene]

Directly cabled even. Although these days NICs tend to auto-adapt to cable-type that used to require a so-called cross-over cable --- and I'd not in fact be massively surprised if that were still the case before the NIC is alive and self-configured to not care. Have a switch and a second cable to quickly try with?

[m00tpoint]

Good thought, but didn't help I'm afraid.

I ordered a wifi-controlled power plug today. My backup plan is to completely shut down power to the box (after clean sudo shutdown now of course), and tell the BIOS to power on after power failure. So there's a backup plan in place in case this doesn't end up working, as seems fairly likely right now. :-p

m00t

[rene]

OK. If among the reboot= possibilities as listed at https://www.kernel.org/doc/html/v4.14/a ... eters.html (Ctrl-F, "reboot=") you can find one that does not in fact work you could instruct a reboot and have the machine hang after doing any and all to in fact cleanly shutdown. If you only then cut power you wouldn't need to deal with e.g. fsck on restarting.

Still. Considering that machine supports WoL it should be possible to get things going more cleanly it seems.

[m00tpoint]

I agree. One would surely think this ought to work, but I'm completely out of things to try. I can prove the packets hit the wire, and I can prove the receiving interface has link, and I can prove WOL is enabled on that NIC (ethtool) and in the BIOS. I sure don't know what else to try. Sigh.

[rene]

This post mentions things working only from a (very) cold boot: https://administrator.de/forum/gel%C3%B ... 03331.html

I.e, worked for poster aftef removing power, draining capacitors by keeping power button pressed for a bit and restoring power. FWIW.

[powerwagon75]

Wondering what wakeonlan command you are using. Are you sending it to the MAC address of the requested machine, ie:
User@user~$wakeonlan 7C:2W:39:FG:V0:04? Just a thought. Saw a similar question recently, and they were trying something completely different. This one has always worked with the machines I have.

[m00tpoint]

Wondering what wakeonlan command you are using. Are you sending it to the MAC address of the requested machine, ie:
User@user~$wakeonlan 7C:2W:39:FG:V0:04? Just a thought. Saw a similar question recently, and they were trying something completely different. This one has always worked with the machines I have.

I'm using wakeonlan, with the mac address of the device I want to awaken.

[m00tpoint]

This post mentions things working only from a (very) cold boot: https://administrator.de/forum/gel%C3%B ... 03331.html

I.e, worked for poster aftef removing power, draining capacitors by keeping power button pressed for a bit and restoring power. FWIW.

And .... guess what? It worked! I just woke up the machine. I'll fiddle around with it some to see if it remembers how to wake up and all that, but color me pleasantly surprised! And my High School German actually came in handy looking at your link.

[rene]

I'll fiddle around with it some to see if it remembers how to wake up and all that, but color me pleasantly surprised!

Nice. Something that gets stuck in the NIC's hardware then. The link suggested it needed the procedure every time, and also on Windows, so maybe you'd still need the power-plug as part of the solution (or a different NIC?). But interesting in any case

[m00tpoint]

I'll fiddle around with it some to see if it remembers how to wake up and all that, but color me pleasantly surprised!

Nice. Something that gets stuck in the NIC's hardware then. The link suggested it needed the procedure every time, and also on Windows, so maybe you'd still need the power-plug as part of the solution (or a different NIC?). But interesting in any case

Yes, it seems to need TLC ... and I've discovered the BIOS also doesn't react properly to the power plug shutting down and giving it power back. I think this thing has serious issues deciding what "power down" means.

I do think I'll try the other NIC and see if it acts any differently.

[rene]

I do think I'll try the other NIC and see if it acts any differently.

Would expect it will...

[m00tpoint]

I do think I'll try the other NIC and see if it acts any differently.

Would expect it will...

I'm sorry to say it doesn't. This machine really needs to be better at identifying its own power states. The NIC's are both Intel, the only difference is that one is on the CPU die and one is on a different chip on the motherboard.

[rene]

That's unexpected to me at least. Things working from a very, very cold boot but not a normal one rules out most anything I can personally still think of but in a more general situation I would've advised to look at (the end of) the output of journalctl -b -1 too see if something suspicious was being executed just before shutdown --- some power/energy related thing such as "laptop mode" --- and/or have advised to try your NIC's other WoL possibilities:

Code: Select all

sudo ethtool -s wol p enp1s0 

and same with u, m, b rather than p (g is magic packet). The expectation with p is that the system wakes up basically immediately again after shutting down (at least on a normal network; the direct-cable situation here could supposedly have that be different).

But now I'm spouting generics that are unlikely to be useful. Don't think I can say anything sensible otherwise any more. If again no success I'll withdraw...

[rene]

Oh, by the way, I only read your statement closely enough now but certainly neither NIC is on the CPU die. But do I take from that statement that both are built-in to the machine? If so, with "different NIC" I was sort of aiming for one on an add-in PCI / PCIe card.

[m00tpoint]

Oh, by the way, I only read your statement closely enough now but certainly neither NIC is on the CPU die. But do I take from that statement that both are built-in to the machine? If so, with "different NIC" I was sort of aiming for one on an add-in PCI / PCIe card.

I've ordered a picie nic and a pcie wireless nic, we'll have to wait a bit to see if your theory works out. I hope so!