Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mazman]

I having an issue using WOL with the DIR655. It seems that sending the magic packet will only wake the pc if it has been asleep just a few minutes. If it's been asleep for 10+ minutes or so, the pc won't wake. I'm running the 1.21 firmware version. Any thoughts on what's up?

[Fatman]

Yes, you can only forward a port to a unicast address.  That address can not be resolved if it has fallen out of the ARP table.  Your only solution is to have to set up some sort of WOL forwarder on your LAN that can send the traffic to a broadcast address, or to manually publish that address on your network.  Neither of which D-Link can really help you with.

[mazman]

Yes, you can only forward a port to a unicast address.  That address can not be resolved if it has fallen out of the ARP table.  Your only solution is to have to set up some sort of WOL forwarder on your LAN that can send the traffic to a broadcast address, or to manually publish that address on your network.  Neither of which D-Link can really help you with.

You explanation is a bit over my head. I am forwarding the WOL packet to a specific pc/ip address. Are you saying that this won't work at with this router?

[Fatman]

Correct, it won't work without at least 1 PC on the LAN with some software designed to get around this problem.

Sorry if I nerded it up a bit much the first time.

[mazman]

Correct, it won't work without at least 1 PC on the LAN with some software designed to get around this problem.

What kind of software is needed?

[Fatman]

Something like a script that takes all incoming traffic on port x and redistributes it as Ethernet traffic to broadcast.  That would be a massive security hole though, a better bet would be searching around online for dedicated remote WOL suites.

[hackztor]

go back to firmware 1.11. Works in there. Under virtual server   port foward  to ip address 192.168.0.255  port 7 or 9 udp depending which one u want to use

[mazman]

go back to firmware 1.11. Works in there. Under virtual server   port forward  to ip address 192.168.0.255  port 7 or 9 udp depending which one u want to use

Thanks for the info but I have a few questions:
1) where to I find firmware 1.11
2) shouldn't I forward to the IP address of the pc I want to wake? What does forwarding to 192.168.0.255 do?
3) Is Dlink going to fix this issue in an upcoming firmware release?

[funchords]

Thanks for the info but I have a few questions:
1) where to I find firmware 1.11
2) shouldn't I forward to the IP address of the pc I want to wake? What does forwarding to 192.168.0.255 do?
3) Is Dlink going to fix this issue in an upcoming firmware release?

#1 ftp://ftp.dlink.com/Gateway/dir655/Firmware/

#2 With 1.21, I tried this 3 ways.  Using the pre-coded entry in Virtual Server, I tried forwarding to a unicast address, which failed after a few minutes (the DIR-655 sent ARP "WHO HAS" messages which is not answered and so the packet dies unforwarded and unlogged!).  Broadcast to 192.168.0.255, which worked every time.  And Broadcast to 255.255.255.255 which failed like unicast did.  (The setting was accepted, even though Javascript complained about the range.)

If you're sticking with 1.21, I would try it using your subnet's broadcast address of 192.168.0.255.  This way the WOL packet is broadcast to MAC FF:FF:FF:FF:FF:FF without any previous ARP "WHO HAS" stuff, so it won't matter if the IP address answers or not or has dropped from the DIR-655's ARP table.   

I didn't try it with 1.11.

#3 I don't work for D-Link, so I can't answer that. 

[Fatman]

It is important that you understand funchords answer to number 2 if you do not please ask for clarification because my answer to number 3 is going to rely on it.

#3 Well my understanding was that we did not currently allow forwarding traffic to a network broadcast address, now I am hearing differently from funchords (who I would bet uses a DIR-655 more than me).  Will this functionality change in the future, probably, the global D-Link trend has been to limit the number of products with this functionality.  Could I give you a definitive answer either way on its future, nope!

If you insist on taking advantage of a security flaw do me a favour though and don't use a well known port for it.  Pick something in the 49152-65535 range.  I don't want to be one of the jerks who sits in forums and tells you people are out to get you, but in this case I would be acting as ill council if I did not tell you this is a bad idea.

[mazman]

But if I use firmware version 1.11, there are no security issues?

[Fatman]

Any time you forward external traffic to a network broadcast address it is a security concern.

[mazman]

Is there still a security concern if I forward to a specific PC's IP address?

[Fatman]

No, but that won't work because that PC will fall our of the ARP table after a specified period (usually like 10 minutes)

[funchords]

Is there still a security concern if I forward to a specific PC's IP address?

The security concern is that a WAN attacker can use WOL to brute-force wake up your LAN machines simply by running through some easily guessed ranges of modern NICs.  On a wireless network, the attacker doesn't need to guess -- they can just sniff (MAC addresses are never encrypted).  Otherwise, the broadcast is simply sent and ignored by the hosts on your machine who aren't listening to the port or who have a different MAC address.  This will take bandwidth, and there might be undiscovered ways to abuse that opening by sending malformed packets. 

If those risks are important to you, then you can mitigate risks like these by knowing what your computer will and won't do when it wakes up in response to a WOL packet (will it require you to log in using a password, will it shut down if you fail to log in, for examples).  You can set the Schedule and Inbound Filter for your virtual server to restrict the acceptance of the magic packet (but be advised that it's UDP and so it's easily spoofed). 

It would probably help people give you advice if we knew what your planned use of WOL is going to be.  For example, if you always keep one machine on in your office or home, it might be more secure to carefully expose a Remote Desktop or SSH port on that machine to the WAN to which you can securely log in and then run WOL software to wake up other machines on the premise from the inside.