Problems with Wake On Lan...

[Robin_39]

I have problems with wake on lan. It doesn't work always. When i start the pc and shutdown(whatever i try.. the power of button or the windows power off), then work the wake on lan.

When i have weekend and i try it at monday moning again it doesn't work. Only when i again start the pc and shutdown, then work the wake on lan.

We have Compaq iPAQ desktop PC P866/815e with Bios Version 1.11

[Ron Kinner]

I'm not an expert on WOL and have never looked at a WOL packet to see if the ethernet MAC address is a broadcast or a specific MAC but I assume it would be a specific MAC. In which case: Are you sure the WOL packet is getting to the PC? I'd stick a sniffer on the link to the PC and see if the packet gets there. I've had cases where the LAN connection to a printer worked fine over night but died over the weekend. Turned out the MAC was expiring out of the ARP cache on the switch and there was a static ARP on one of the switches in the network (where the printer used to be) and when the dymamic ARP expired the old one got sent through the network and the packets never got to the printer. Don't know if that could apply to your setup or not. You could check it with a crossover cable between the device that sends the WOL packet and the sleeping PC to see if bypassing the network would help.

Looking at the manual I see that the Link light on the NIC should blink when it receives a packet. Is it lit? Does it blink once in a while?

If we assume the problem is in the PC then you might look at upgrading the software:

http://h18007.www1.hp.com/support/files/DesktopiPAQ/us/locate/64_1241.html

I see there are new
Intel Chipset Support for Windows,
Intel PRO/100/1000 Drivers, and
Intel PRO/100 Management Software

Have you tried them?

Ron

[Antoniov.]

Hi Robin,
when PC goes in energy saving; after some hours it goes into stand-by (HD is stopped, etc) and system need a bit of time to wake-up; I guess when PC is in stand-by is not ready to accept wake-up from network.

@Antoniov

[Antoniov.]

Sorry
read here
http://www.solarwinds.net/Tools/Network_Monitoring/Wake_On_Lan/
http://www.annoyances.org/exec/show/article04-101

@Antoniov

[Ernest Ford]

Ron presents an interesting theory.

Using AMD's Magic Packet, it is theoretically possible (under specific controlled conditions) to send the WOL packet to a specific MAC address, although it really should be broadcast to the entire segment - the MAC address that you're trying to power on is actually coded into the data segment of the packet.

However, even if the packet is sent to a specific MAC and the ARP cache on the switch has expired, the switch should broadcast the packet on all "unused" ports since it doesn't know which port that NIC is attached to.

In my experience (3com NICs) the link led should stay on and the activity led may or may not flash randomly as broadcast packets are received.


Antoniov,

That Solarwinds writeup is incorrect - it has a line reading "You must also identify the IP Address and MAC Address of the remote device".

The IP address of the remote device is NEVER required.

IP addresses are logical, when the host device is powered off that IP address ceases to exist.

If the sending workstation and the remote device are on the same physical network segment only the MAC address of the remote device is needed. The WOL packet is normally a broadcast.

If the sending workstation is on a different network segment to the remote device, the WOL packet needs to be routed to that segment, so the broadcast IP address of the segment should be entered, along with the MAC address of the remote device - the IP address is used only for routing purposes. If the IP address of the remote device was used, and the MAC address corresponding to that IP address was no longer in the ARP cache of the router, the router would send an ARP request to find the MAC address that matches, receive no response (because the device is off) and simply discard the packet.

Incidentally WOL works in a DHCP environment, where the host device doesn't know it's ip address until after it's powered on.

[Robin_39]

On the Cisco Switch is the ARP-Table empty. The Lease Time for ARP-Entries is 1200 seconds, but the ARP-Table is the hole day empty. I think it not my Problem.

An other thing i must say that the computer is in a other subnet, but this isn't realy important.

In the small Compaq Bios i can't find anything about wake on lan or standby mode.

Sorry for my bad english ;)

greets Robin

[Ron Kinner]

Actually on a Cisco switch we are talking about CAM table (sh cam dyn or sh cam agingtime). On routers they call it the arp table. The ARP table on a Cisco switch is just the table that the devices uses for things it talks to directly like a management PC.

How does the packet get from the originating box to the different subnet that the PC is on? Is there a router involved? If cisco what version IOS? If cisco and IOS 12.0 or better did you have to allow directed broadcast to get this to work or did it work with the default condition or did you use IP helper? Cisco's use a default arp aging time of 4 hours which still isn't long enough to explain how it could remember over night but maybe it has been adjusted in the past? Might be worth putting in a static arp on the router so that we could rule it out.

Ron

[Ernest Ford]

Robin,

The fact that the computer you are trying to remotely power on is on a different subnet is VERY important - in fact it is most likely the cause of your problem.

One possible reason that it works after the PC has been turned on and then off, but not after it's been off all weekend (Ron - I don't see anything that says it works if left off overnight) is a combination of the router's default ARP aging time AND the iPaq's IP address being used to send the Magic Packet, instead of the subnet broadcast ip address.

Assuming that the router is being used as a DHCP box, which is fairly common in small branch offices, the router will have the iPaq in it's ARP table after the machine has been powered on and then off.

If a magic packet is now sent to the iPaq's ip address (and not the subnet broadcast address), it will actually be routed correctly and the router will put it on the LAN segment where it will be received by the iPaq - presto WOL works.

Taking this scenario to Monday morning - the router's ARP table is empty because the entries have all timed out - when the router receives the magic packet, it does not find that address in the ARP table so it sends an ARP broadcast, which the iPaq will not respond to, because it's powered off - at which point, the router will simply discard the magic packet.

What WOL tool are you using to send the packets? For it to work across a router (there must be some sort of routing process, given that it's on a different subnet) there has to be a field for you to enter an IP address, which should be the broadcast IP for the subnet the remote PC is attached to.

As Ron has pointed out - directed broadcast must be enabled on the router for WOL to work, this feature is often disabled as a security measure.

[Ron Kinner]

Earnest, Good call on the no overnight. Somehow I assumed since he complained about weekends that it must have worked overnight. I guess because that was the problem we had with one of our printers. We have a distributed system over 5 floors all reporting to a central switch. One of our switch (old 3COM) had a static arp for the printer. This was really easy to do on a 3COM and saved a little time as long as nothing moved. The printer was moved to a different floor (but the static entry was not cleared) where it would work fine until the weekends at which time the correct dynamic arp (I suppose I should say Forwarding Database Entry but I started with routers so usually think of it as an arp table even tho it's not really an IP to mac list but just a mac on this port list)would time out and the obsolete static one would propagate through the system. On mondays someone would have to reset the printer which made the local switch aware of its presence and it would work happily until the next weekend.

Ron