Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
My issue: I need to remotely wake up PCs on my internal network from afar.
My problem: My router (Netgear WNDR3700) doesn't support the WOL feature and actively blocks requests from the internet attempting to do so.
So I was thinking that since I can telnet into my NAS, which is always on, perhaps I could send the magic packet from there since it's on the same subnet as the PCs.
Any way to do this? Would I need a special application compiled for the DNS-321 or is there some other way to go about this?
Offline
When you installed ffp you can use the commandline progam ether-wake.
Offline
Tried that one. I get the following error when I run it:
SIOCGIFHWADDR on eth0 failed: No such device
The command I ran was simply:
busybox ether-wake XX:XX:XX:XX:XX:XX
Last edited by Headcase_Fargone (2009-11-16 00:04:10)
Offline
In that case your network interface isn't eth0. Try
busybox ether-wake -i egiga0 macaddress
If that doesn't work, use ifconfig to find which networkinterface your box is using.
Offline
That worked beautifully on one PC. Now to figure out why the other one isn't responding to the packet now that I know it's being sent.
Thanks much.
Offline
Not all PCs support WOL, and not all PCs that support WOL truly support WOL.
Assuming that the PC that doesn't respond does support WOL AND does have it enabled in the BIOS settings, depending on the age, if it uses an "add-in" ethernet card (as compared to an ethernet port integrated into the system board), it may need a WOL cable between the system board and the ethernet card.
The next area to watch for - some PCs do not truly support WOL and will not wake from an off (S5) state, but only from hibernate (S4) or sleep (S1~3) states
Offline
Interestingly enough, I've tried ether-wake on three PCs so far. Two of them have built-in NICs on the motherboard and those are the ones I can't get to work. The one PC that will wake up has an add-in PCI NIC. Both PCs with the built-in NICs have Wake-on-LAN options in the BIOS as well as the driver software. Very strange.
Offline
Yes, Windows. And that's where I was referring to when I mentioned they have options in the driver software. Device Manager -> Advanced -> Wake-On-Lan/Magic Packet, etc.
It's all turned on.
Offline
Check your documentation - do they support a TRUE wake from an S5 or OFF state - or only from hibernate? Put the PC in to standby and/or hibernate and see if it wakes from those.
I've never used "etherwake", but I have found that quite a few of the WOL utilities out there (written for Windows), were not properly written and do not always send the magic packet as a broadcast - if this is not done, you will find that WOL only works for short periods of time
Depicus offers a WOL "monitor" utility, download it from their website and run it on a PC and make sure that the "magic packet" is being sent as a broadcast
Offline
Good suggestion. I just put one of the PCs that wasn't responding into Sleep mode and sure enough. Ether-Wake woke it right up. Interesting.
Offline
Odd, it only seems to work if the PC was very recently put to sleep. I just tried to wake it up after having set it to sleep last night and nada.
Offline
Headcase_Fargone - you mentioned that you have a Netgear router - can I assume that you've been through the WOL threads on the Netgear forum? If you haven't, it might be an idea to do so - I've explained in some detail the hows & the whys of WOL and they include the scenario you are facing now - I'm reluctant to get into another long, detailed explanation here.
Briefly - and you'll see it mentioned in my earlier responses in this thread - it is important to make sure the WOL magic packet is sent as a broadcast packet otherwise it will only work for a short period after the host is switched off, or in your case, put to sleep.
Offline
ether_wake has a -b option for broadcast. I looked at the source and found that *with* this option the SO_BROADCAST option is set to the socket, and the MAC address is put in the first 6 bytes of the packet. Without the option the first six bytes are 0xff, and the SO_BROADCAST flag is not set.
But I don't get it. I understand that broadcasting is important when you try to send a magic packet through a router, since MAC addresses are not routered. But the OP is sending to a MAC address within it LAN, so it should always arrive.
On the other hand 'the very recently put to sleep' observation looks like an ARP table which refreshes. But there are no ip addresses involved. Maybe a MAC address lookup table in a switch?
fordem, can you give a link to the thread you referred to?
Offline
Oh yes, that was the first thread that I went through on the Netgear forum. I have my IP range set to 128 as suggested.
At this point I've tried some Windows-based WOL solutions and none of them will wake up these PCs with built-in NICs. All of them work fine on the PC with the add-in, though, regardless of how long it's been shut down.
I've tried both with and without the -b switch in Etherwake.
Offline
Mijzelf - you are right - it is the arp table or arp cache on the source computer. It is not the MAC table in the switch, if the switch receives a data packet with an unknown destination MAC, it is required to flood that packet to all ports, and then look to see where the response comes from so that it can add it to the MAC table.
Briefly - when data is sent across a LAN, the ip addresses are not used to determine souce & destination, it's the MAC addresses that are used, so, the network stack must translate the destination ip address to a destination MAC address, which it does using arp.
The process (for a unicast packet) goes something like this - the source computer checks it's arp cache for a cached ip/MAC address pair with the required ip address, if it finds the required ip address, it uses the corresponding MAC address, if it doesn't an arp request will be issued, essentially a broadcast asking "who has ip address a.b.c.d?" at which point the destination computer, recognizing it's ip address, responds, and the source now has a MAC address to use.
It is important to note - arp caches are periodically flushed to remove stale & unused entries - typically at 30 minute intervals
The problem with WOL as a unicast packet is that with arp if the computer is off, it cannot respond, so once that arp entry is cleared from the arp cache, the source computer never gets a response and the unicast WOL packets are simply discarded.
Broadcast packets - on the other hand - being intended for all hosts will never be sent to a specific MAC address, but rather use the hardware broadcast address (FF-FF-FF-FF-FF-FF) bypassing the arp process completely.
Last edited by fordem (2009-11-19 15:36:41)
Offline