Author
Topic: MD wake on Lan not working (Read 3171 times)

After sorting out the shutdown on my other two MDs, I'm now trying to sort out the wake-on-lan for my HP compaq 6710b notebook. It has definitely worked before and definitely has the capability (hardware) but at the moment is not working.

What I've done so far-

* Tried the "power on" from other orbiters and that doesn't work.* Tried running /sbin/WakeMD.sh (or something similar) with --dev and --mac options, no dice.* Tried using ethtool -g to check that wake-on-lan is configured when the MD is up and that looks correct.

Hmmm... will probably have to do a bit more digging to find how wake-on-lan works at a lower level and see if I can do it with a crescent wrench... then if that works I will try to figure out how/why that is not happening via the normal channels! Any suggsetions/troubleshooting tips welcome.

From memory, this is what is required for wake-on-lan to work:* It must be enabled in the BIOS* The network card must have been enabled (by ethtool)* The system must have wake-up enabled - This is done in /proc/acpi/wakeup iirc, see if there is some entries there that match your network card, or a generic PCI entry. Some googling may be required to figure this one out (I don't recall the exact command at the moment)* The driver must support wake-on-lan. What LMCE version are you using 810 or 1004? In 810 there was some network drivers that did not set the wake-up flag correctly, and wouldn't wake-on-lan. I think it is fixed in the kernel used in 1004 but still...

* It must be enabled in the BIOS [TICK]* The network card must have been enabled (by ethtool) [TICK]* The system must have wake-up enabled - This is done in /proc/acpi/wakeup iirc, see if there is some entries there that match your network card, or a generic PCI entry. Some googling may be required to figure this one out (I don't recall the exact command at the moment)* The driver must support wake-on-lan. What LMCE version are you using 810 or 1004? In 810 there was some network drivers that did not set the wake-up flag correctly, and wouldn't wake-on-lan. I think it is fixed in the kernel used in 1004 but still...

Ta, that sounds right. I think the first two are OK. I will have a look at the third (/proc/acpi/wakeup iirc or whatever) and then the fact that the driver supports it... I'm using 1004.My one thought is that I have deleted and recreated this media director device out of webadmin and, obviously, the same MAC address would be used as the previous (now deleted) device so I thought there might have been some config somewhere that wasn't properly purged and the system is still trying to wake the "old" device or something...

If you use /usr/pluto/bin/WakeMD.sh --mac xxxx then it should work anyway. You could also play around with /usr/sbin/etherwake which is used in WakeMD.sh to try and wake the MD.Using WakeMD.sh --dev will look up the MAC address from the web-admin for the MD.

I haven't heard of any problems with the drivers in 1004, but one time have to be the first

One more thing that occurred to me. It seems that there are a slight difference between when you suspend a MD and when you shut it down. When shutting it down, it needs to set NETDOWN=no in /etc/default/halt to keep the network alive. Afaict, this is not required when doing suspend.

Has anyone tried this on an MD when the bios is set to wake after a power loss? Some bios-es support this function. I'd actually like to use the wake on LAN to conserve power at some point in the future.

Second, semi-related question... I have an APC UPS,... Does LinuxMCE have a routine for controlled shutdown when it catches a signal from an UPS?

Logged

See my User page on the LinuxMCE Wiki for a description of my system configuration (click the little globe under my profile pic).

Just to add to this... I haven't got to the bottom of it yet but I have certainly tried many things - confirmed bios is enabled, confirmed via ethtool that WOL is setup for NIC. Where I am at the moment is possibly at a bug in ubuntu somewhere.... because here's what is possible-

If mains power is removed for a few seconds after shutdown and then re-connected, after *that* I can wake on lan the MD. I got that from a bug report somewhere... I think some people had some success removing networkmanager or some similar package but I made a mess of my MD trying some stuff and had to rebuild the image.

Some more tinkering last night. The problem certainly seems related to how the machine is shutdown - it seems the NIC needs to be left in a state that allows WOL to work. This can be forcecd by physically removing power from the machine but obviously I don't want to do that every time... I may as well power it on manually.

The "halt" (/etc/init.d/halt) script which is the last that is called in the shutdown sequence, as I understand it, has a setting at the beginning "NETDOWN=yes" which then, if "yes" passes a "-i" parameter the /sbin/halt executable to, presumably, shut down the network device.

Now there doesn't seem to be clarity as to whether the NIC must be shutdown (similar to

I tried hacking the halt script to include this code prior to the /sbin/halt command but the system then moaned about something being active. I presume this is to do with the NFS being mounted. Of course that is going to be a problem. It makes sense that you can't bring down a network card that is still being used for the filesystem....

Here's what I'm thinking at the moment. The problem is either due toa) My NIC driver which is not allowing the NIC to be moved to a state that will accept WOL when the /sbin/halt command is executed with the "-i" parameter.ORb) Some other problem in the shutdown of this particular MD that is causing other things (NFS, NBD?) not to be stopped properly which is preventing the network being brought down properly.

I'll start with b) because there are definitely a few "faileds" being thrown on shoutdown of this MD. I'll compare to the working ones and see if I'm having a problem somewhere that doesn't exist on the others and try to fix. Otherwise I'll tinker wtih the NIC driver. Maybe.