Hi I have been trying to use the Wake on LAN feature but I have been struggling very much with it. Limitation with my router. My config is The workaround: When I intend to do is send the magic packets to PC2 (always awake). The understanding I got is that the hub will broadcast to both PC1 and PC2. PC1 is sleeping. Is it possible for me to capture that the broadcast is made to both PC1 and PC2? I currently can only see that the packet is sent to PC2. asked 12 Jul '12, 19:49  Pete the cur... edited 13 Jul '12, 02:45  SYN-bit ♦♦ |
6 Answers:
If the packet is truly a broadcast, it's made to all machines on the network segment, i.e. to every machine plugged into the hub except for the machine sending the broadcast (I don't know of any Ethernet adapters that receive their own transmissions - they might listen to their own transmissions for collision detection, but they don't treat it as an incoming packet, eve in promiscuous mode). If the hub truly is a hub, rather than a switch that's called a hub, and if the router and the two PCs (all of which I assume are plugged into the hub) are all running at the same speed (all at 10Mb/s or all at 100Mb/s), then, if you have an unused port on the hub, you should be able to run a sniffer on a machine plugged into that port and see all the traffic going through the hub. You could also try running Wireshark on PC1 and, even though it's awake, try sending it a Wake-on-LAN packet, and see whether it shows up in Wireshark. If it shows up in Wireshark, that would strongly suggest that, if PC1 isn't waking up, the problem isn't that it's not receiving the wakeup packet - perhaps its Ethernet adapter doesn't support Wake-on-LAN, or does but doesn't have its wakeup signal wired to the appropriate support chip (i.e., the adapter supports Wake-on-LAN but the PC as a whole doesn't), or the operating system doesn't support that wakeup signal. answered 12 Jul '12, 20:28  Guy Harris ♦♦ You could also try running Wireshark on PC1 and, even though it's awake, try sending it a Wake-on-LAN packet, and see whether it shows up in Wireshark. If it shows up in Wireshark, that would strongly suggest that, if PC1 isn't waking up, the problem isn't that it's not receiving the wakeup packet - perhaps its Ethernet adapter doesn't support Wake-on-LAN, or does but doesn't have its wakeup signal wired to the appropriate support chip (i.e., the adapter supports Wake-on-LAN but the PC as a whole doesn't), or the operating system doesn't support that wakeup signal.
(12 Jul '12, 20:39) Pete the cur... did you check the link state of PC1 after 1-2 minutes (LEDs on the HUB)? If the link is down (for whatever reason), PC1 will not receive the WOL packet. (12 Jul '12, 20:43) Kurt Knochner ♦ |
If the destination MAC address of the packet, arriving at PC2, is the broadcast address (FF:FF:FF:FF:FF:FF), you can assume that this packet will also arrive at PC1, if the link to that machine is active! Please check LEDs on the HUB/Switch. If you want to be sure, you need to capture in front of PC1 by using a network tap. You cannot capture on PC1, as you have to switch it on to do that, which changes things, like enabling the network link, if it was disabled before.
If you send the magic packet to PC2, you can do this in two ways. Either you send it to the MAC address of PC2 or you send it to the broadcast address, with the MAC address of PC2 as payload. However, neither case will awake PC1, even if PC1 receives the broadcast packet, as the WOL packet is not intended for PC1. See WOL sample capture. Regards answered 12 Jul '12, 20:22  Kurt Knochner ♦ edited 12 Jul '12, 20:52 Kurt You mention that "neither case will awake PC1, even if PC1 receives the broadcast packet, as the WOL packet is not intended for PC1." What I am doing is trying to replicate the following which I read from another forum. I can see the packet and it has the mac address of PC1 but the destination address is the IP address of PC2. So judging from what u said the following does not work? "Why a hub? Hubs are dumb and they do not direct traffic like routers and switches. Hubs and this is the key word here, "broadcast", the data to all devices connected to it. Now there are two ways you can get this to work: 1. Plug the hub in front of your router 2. Plug the hub behind your router (better) If you are going to plug it behind the router, you are going to have to have a device on the hub that is always on so the router won't kill the line, VoIP or something. Plug the hub in one of the routers LAN ports. Plug your PC and the always on device into the hub. Also if you have a setting "WoL & Shutdown Link Speed" for your NIC, you should probably set it to whatever the other device supports just to be safe, usually 100Mbps. You then should create a reserved LAN IP for the always on device so it never changes to a different LAN IP. Then you will need to port forward to the always on device. Some of you may be scratching your head as to why should we port forward to the always on device and not the PC, well that is the beauty of the hub. It will broadcast the packet to it regardless which device you have port forwarded to. The reason you port forward to the always on device is that your router needs a "live" device to keep the ARP entry alive. The router forwards the packet to that LAN IP address to the hub. The hub then broadcasts the packet to all devices because it doesn't know who it is intended for. Thus your PC will wake despite it going to the other device." (12 Jul '12, 23:14) Pete the cur... An AMD paper on Wake-on-LAN says:
which implies that if the body of a Wake-on-LAN packet doesn't have the right MAC address in it - the body, NOT the Ethernet header - the LAN controller may well ignore it. This means that if a Wake-on-LAN packet is broadcast on a network, so that its destination MAC address is FF:FF:FF:FF:FF:FF, it might STILL wake up only one host, even though more than one host's network adapter receives it. Hosts other than the one whose MAC address appears in the body may just ignore it. (12 Jul '12, 23:38) Guy Harris ♦♦ Kurt Regarding the working for 1-2 minutes after shutdown, I believe the ARP cache is involved. There is a status flag that shows off after a while. My 2Wire does not seem to support port fowarding to 182.168.1.255. (13 Jul '12, 01:58) Pete the cur...
Well, I'm not yet convinced. Can you please post a detailed summary what you do when it works (within 1-2 minutes) and what you do when it does not work.
What is off exactly?
Too bad, as that would be the best way to solve your problem. (13 Jul '12, 02:24) Kurt Knochner ♦ |
As Guy Harris already said the problem might be proper "addressing" of the WOL packet. However, as you said it works for 1-2 minutes after you shutdown PC1, I believe that the link of PC1 goes down for whatever reason (maybe power settings in the BIOS) or that the ARP cache of the router is somehow involved. I found this article, which describes pretty much how to configure your router: http://www.dslreports.com/faq/6790 You just forward incoming UDP packets (port will be defined by the WOL tool) to your network broadcast IP. So, if your network is 192.168.1.0/24 you forward the UDP packet to 192.168.1.255. IF, and only IF the router uses the broadcast MAC address (FF:FF:FF:FF:FF:FF) for that broadcast IP address (some routers do, some don't), then it will work. If it does not work for your router, you can try to add a manual ARP entry, if the router supports that (192.168.1.255 -> FF:FF:FF:FF:FF:FF). I tested it with this online WOL tool: http://www.dslreports.com/wakeup If the router forwards the packet, if will go to FF:FF:FF:FF:FF:FF and the payload contains the MAC address of the PC you want to wake (00:01:02:03:04:05). The setup you described, with the "allways on" IP address, is not guaranteed to work. I guess it depends on the WOL implementation of the adapter if it accepts WOL packets solely by the mac address in the payload, ignoring the fact, that the MAC destination of the WOL packet is the one of the "allways on" IP. answered 13 Jul '12, 00:44 Kurt Knochner ♦ edited 13 Jul '12, 01:48
I incline to think the above is more the issue here. Oh yes I cannot forward to the broadcast address, 192.168.1.255. There is the limitation of the 2 wire 5012NV router. regards (13 Jul '12, 02:17) Pete the cur...
I agree. You can test it. Use a local WOL tool that allows to set the payload MAC different from the dst MAC address. (13 Jul '12, 02:49) Kurt Knochner ♦ |
According to the WOL specifications, the magic packet should be a broadcast packet, not a unicast packet for another mac address. However, you seem to have indicated that sending a unicast packet to the mac address of PC2 did indeed wake up PC1, but only if it was sent max 1-2 minutes after shutting PC1 down. You may want to try different scenarios to see whether they do or do not work.
1) and 2) should work, as these magic packets are according to the WOL specification. 3) and 4) might work, but it might be that the NIC stuts down to a state that it only listens to the broadcast address. Maybe this is what happens 1-2 minutes after shutting down the PC. 5) and 6) should not work IMHO, but of course the firmware of the NIC might just be tolerant enough to let it work. If you can add a static ARP entry on your router, then you may be able to add a port forwarder to send packet 4) from a remote location. Otherwise your best bet would be to use a WOL tool on PC2 and make PC2 remotely accessible. answered 13 Jul '12, 02:43 SYN-bit ♦♦ 1.Send magic WOL packet to broadcast address, 1 minute after shutting PC1 down 2.Send magic WOL packet to broadcast address, 5 minutes after shutting PC1 down 3.Send magic WOL packet to mac address of PC1, 1 minute after shutting PC1 down 4.Send magic WOL packet to mac address of PC1, 5 minutes after shutting PC1 down 5.Send magic WOL packet to mac address of PC2, 1 minute after shutting PC1 down 6.Send magic WOL packet to mac address of PC2, 5 minutes after shutting PC1 down 1,2 - I do not think the router allows this. Anything tried. Cannot see any packets. Not working. 3 - only one that works. 4-6 does not work. Kurt The intend is not a PC alive on the network. I used the PC as an experiment. IF the hub broadcast approach work, I was intending to use a printer and leave it on instead. Anyway thanks for all the help. I decided the hub workaround is not working in my case. (13 Jul '12, 21:52) Pete the cur...
The idea was to test this in the local network, not over the router to figure out if your network adapter accepts broadcast packets.
As test 4 does not work, I assume that your adapter shuts down the pysical link after 2 minutes OR just accepts boradcast packtes after that time. Repeat tests 2 locally.
It does not work, as your tests 5-6 have shown. BTW: Short solution. If tests 1-2 do work locally (please test), buy a router that allows forwarding to the IP boradcast address, as I described in my answer. (14 Jul '12, 06:06) Kurt Knochner ♦
Not sure what u had in mind here. Router cannot port forwardto a broadcast address. (14 Jul '12, 06:24) Pete the cur... The idea was to first determine what your NIC accepts as WOL packets and then to find a solution that matches your needs best. As 3 does work, but 4 doesn't, you are stuck with the specs which say you need to send a broadcast WOL packet. So if your current router does not support directed broadcasts, then your out of luck indeed. Not sure what kind of router ou have, but maybe you can flash it with OpenWRT or DD-WRT? You can then SSH into the router and send a WOL packet from the router CLI. (14 Jul '12, 06:35) SYN-bit ♦♦
They can. I'm talking about the network broadcast IP. Read the link in my answer above and my test. If the test with the broadcast MAC works locally, you just need a router that is able to port forward to the network broadcast IP. According to reports from other peopele (see router forums) several cheap DSL routers can do that. Did you actually try with your router? What happens if you port forward to your internal network brodcast IP (e.g. 192.168.1.255)?? (14 Jul '12, 06:39) Kurt Knochner ♦ |
Maybe a Wake on Lan "Proxy" can help as well. If you have one machine that is allways on, you can install desleeper on it in "proxy mode" (windows service). Then just port forward the required proxy ports (HINT: think about the security implications of such a construct!). Regards answered 13 Jul '12, 17:15 Kurt Knochner ♦ edited 13 Jul '12, 17:28 |
FYI, I am the one that wrote the Wake on LAN/WAN guide that pete quoted. I was able to get WoW working with the hub behind the router and it worked even when the PC was off for several hours or days. The equipment I used to get this working is a Netgear WPN-824 router, Netgear DS-104 Hub, and a Sprint Airave 3G version. I used the Airwave as my always on device. I setup in the router to forward port 9 to a static LAN address for the Airwave. I used my Android phone and the free app "WoL Wake On LAN WAN" to send the magic packet while on 3G, 4G, and other outside networks to wake up my PC using the PC's MAC and port 9. It worked every single time no matter how long the PC was off. The app sends 5 packets by default. It has an option to check for "Send as Broadcast" but I never use it. I got this method from a guy on Netgear forums who was helping someone with WoW and the PC being behind the router. I purchased the hub off of ebay on the cheap, $15, and got working rather easy. The reason to do this, is because most consumer grade routers do not support WoW. Also most consumer grade routers will not let you forward to the router's broadcast address. People have gotten by that by either turning off java and inputing the routers braodcast address in the port forward section then turning it back on or they have modified the range value to include the routers broadcast address as a legit entry. Either way, these two methods open you up to smurf attacks or so I have read. If you can install custom firmware, you can get around these limitations but some routers have very low memory available to install custom firmware, i.e. like mine. I can't even assign a static ARP entry, which would help and probably be much easier. So the only options left are to either get a router that supports WoW, have 2 NICs and have 1 NIC in front of router with a Hub , or use a hub behind the router. Lastly, I have no network certification nor any formal networking background. I am just some average joe who read and researched this stuff and got it to work after trying several different methods and weeks worth of troubleshooting. With that said, if you want me to help you, I will try my best to with the knowledge I have gleaned but don't expect miracles. You can find me over at filesharingtalk if you do want help. answered 14 Aug '12, 20:49  Sandman From your description (link in your answer).
Well, that only works, because the WOL implementation of your PC NIC (the one you want to awake) is (apparently) not standard conform and accepts WOL packets, even though it is neither directed to its own MAC address nor to the ethernet broadcast address. See the WOL specs of AMD. That's kind of odd, as that PC will also wake up, if you try to awake another machine on the same network. If you try that with another NIC brand (different vendor), you might discover, that your method does not work. Unfortunately @Pete-the-curious stopped communication on 14. Jul and did not provide the data we asked for. With that information we might have found a solution for him. However, based on the information he provided, I believe your method does not work for his NIC. I conclude this based on some tests results he posted. (16 Aug '12, 07:46) Kurt Knochner ♦ Kurt, I totally agree except for:
The mac-address of the PC to be awakened is also (repeatedly) embedded in the packets payload. So sending the magic packet to mac-address A with mac-address B in the Payload would not wake up a system with mac-address C. The whole point is whether the NIC of the PC that you try to awaken is listening to all packets or just packets destined to the broadcast address (WOL-spec), it's own mac-address and/or any mac-address. That will probably vary! (16 Aug '12, 07:56) SYN-bit ♦♦
You're right, it should not. Based on the description of Sandman, I'm not sure what he used as payload for the WOL packet. As it only makes sense to use the MAC address of the shutdown PC I now assume he did that. In that case you are right. If he used the MAC address of the allways on PC (it does not really make sense, but based on his description this is what I assumed), the WOL implementation is badly broken, and it will awake by every WOL packet on the network, howsoever it recognizes a packet as a WOL packet. Maybe just by the sequence of: 1 * FFFFFFFFFFFF and 16 * "any MAC address" in the payload !??! The method of Sandman works, if the WOL implementation ignores the frame address and only relys on the MAC address (of the shutdown PC) in the payload.
I agree. (16 Aug '12, 08:29) Kurt Knochner ♦ Kurt, I said that I used the MAC address of the WoL PC and not the always on device. I even mentioned the program I used to send the magic packet.
So with the program I use to send the magic packet, I use the MAC address of the WoL PC, port 9, and the WAN address. The router sees that the packet is intended for port 9 and forwards the packet to the always on device but before it can get to the always on device, the packet has to go through the hub. The hub broadcasts the packet to all attached devices regardless because thats what it does. So every device on the hub gets the same packet but the only device that cares about the packet is the WoL PC, which sees that it contains the correct MAC address and sequence. (16 Aug '12, 12:48) Sandman Sandman, I was referring to the link you mentioned (http://filesharingtalk.com/threads/439573-Wake-on-WAN-guide). The description therein is not that clear about the MAC address used. I did not remember that you mentioned that aspect in your answer here. With that information it's pretty clear what's going on. Your NICs WOL implementation just looks at the payload and if it finds its own MAC address therein, it will accept the WOL packet, regardless of the frame mac address. I have no idea if that is common behavior or not, at least it does not adhere to the original AMD definition of WOL(as I read it).
They have also described the situation with a router and the ARP cache timeout. The solution is to send the packet to the network broadcast address (one suggestion in my answer). As you also mentioned the network broadcast method, you could add a hint, that the "hub method" might not work with all NICs, as some WOL implementations might behave differently (according to the WOL specs). But anyway, if your method works in your environment, that's great. What else do you need ;-) (16 Aug '12, 14:04) Kurt Knochner ♦ Ok np. The WoL FAQ says that the AMD WoL whitepaper also states that the payload can anywhere within the payload. http://wiki.wireshark.org/WakeOnLAN I will update the guide to be more specific. Thanks for the suggestions. (16 Aug '12, 16:03) Sandman showing 5 of 6 show 1 more comments |
Hi all,
Just to add to the clarity on my end. I have been reading all the postings so far. I have done what Sandman described. That is the MAC address is for the PC which I intend to wake up and not the always on PC.
regards