Superhub Wake on WAN help!

[*sloman*]

Hi All

Has anyone managed to wake on WAN their PC with a superhub?

I can WOW within 5-10mins of the PC shutting down, but after this the PC disappears from the trusted devices.

I have port forwarding on UDP 9 with the PC's IP (192.168.0.25) and have been using subnet 255.255.255.255 from this site with the PC's MAC but nothing: http://www.depicus.com/wake-on-lan/woli.aspx

Anyone manged to get this to work and if so how.

PS i am asking about Wake-On-WAN (NOT LAN that works fine thanks)

[kwikbreaks]

It worked for me using LogMeIn and the Superhub only by forwarding UDP 9 to the fixed IP of the PC. I can't remember if that was a hard coded IP on the PC or a Superhub reserved one - I think the former as I got very annoyed with the Superhub reboots reserving IPs and livid when it somehow corrupted the table and I had to start over - I'm sure that's when I changed over to using a range of hard coded IPs outside the DHCP range for anything I wanted on a fixed IP. I couldn't get it to work when using a double NAT'ed additional router.

[*sloman*]

ok after a lot of faffing it seems Wake-On-Wake is not possible after 10mins or so of the pc shutting down. i think this is due to the superhub clearing the arp cache.

The way i got this to work now is ssh to my NAS (from the outside world) (forwarding port 22 to NAS in Superhub) and running a shell to WOL the PC ./wol.sh

[sniper007]

Any news on this issue? I saw it talked about on another forum and thought I would check here and this came up in a search. I can get wake on lan working locally, but only if the client I wan to wake up appears on the trusted devices list under IP filtering and/or MAC Filtering menu off the superhub. Sometimes it seems to drop off of there and sometimes it stays despite being powered down.

[kwikbreaks]

I'm pretty much certain that you can't make it work across the WAN with the Superhub now - that may be down to a change or it could be (as I've seen suggested) that it will work but only for a very limited time after the device sleeps and when I tried it I hadn't let the device sit sleeping long enough for the failure to be obvious to me.

It works just fine from the LAN or WAN with a VMNG300 and my router running the Tomato firmware (no port forwarding etc. required) - you could probably put the Superhub in modem mode and use a router which supports it as I don't see the modem section of the Superhub blocking the magic packet in any way.

[sniper007]

I just want to use the superhub and have WOL work locally. Do not even care for wake on wan events. I personally find that I can get WOL to work locally but my client I want to wake drops off the trusted devices list sometimes which prevents me from waking it. I do not find I need to port forward or anything. It just works...only when it is on trusted device list. If I use a static IP set manually on the client it drops off the trusted device list instantly when turned off. Atleast with superhub reserved IP it stays on there for sometime after being turned off. Would a longer DHCP lease help this do you think or should it be nothing to do with appearing on trusted device list?

Thanks kiwi

---------- Post added at 23:14 ---------- Previous post was at 22:51 ----------


EDIT:

Ok I am confused.

The tool I was using I think I was using it wrongly. I had been using a windows magic packet sending tool called "WOL - Magic Packet Sender" to wake my client LOCALLY on my LAN which gives the following options:

HOSTNAME
SUBNET MASK
MAC ADRESS
PROTOCOL
PORT

I had been using:

HOSTNAME: <my client hostname>
SUBNET MASK: 255.255.255.0
MAC ADRESS: <my client mac address>
PROTOCOL: UDP
PORT: 9

And this had failed each time the client hostname did not show up in trusted devices on superhub IP/MAC filter with it's reserved IP address. I changed to using the actual IP instead of the hostname in the hostname field and it started working. I thought magic packet was only dependent on the MAC used and IP was irrelevant given that when offline it won't be contactable via an IP. I'm confused.

---------- Post added 30-12-2011 at 00:09 ---------- Previous post was 29-12-2011 at 23:14 ----------

I think I had been over complicating it. Anyway... locally it works ok now, but over internet it only works when device is still cached in the trusted device list. So does appear to be when the arp cache is cleared as discussed on community forums.

---------- Post added at 01:35 ---------- Previous post was at 00:09 ----------

I tested some more tonight and even changed my subnet mask to 255.255.255.128 so I could have a broadcast address of 192.168.0.127. The reason is so that the superhub can be told to forward port 9 UDP to the broadcast address on the local network. It does not let you add 192.168.0.255 when you have a subnet of 255.255.255.0 as gives an invalid IP error. With a subnet of 255.255.255.128 you can add 192.168.0.127 and it will let you do this. This is the broadcast address so should give it every chance of working. It still does not.

The only way I can get it working over the internet is by having port 9 UDP forwarded AND the destination client machine to be woken up to appear in the trusted device list on the superhub.

[kwikbreaks]

From the little I remember reading about this from when I was miffed because I'd been using it and it stopped working with the SH the IP is indeed not important but the SH routing drops the packet if it doesn't recognise the MAC because it's been dropped from the ARP table.

If you have some local device powered up and accessible from the WAN then you only actually need it to work LAN side anyway because you can have that device send the magic packet. I only ever use it via Logmein and I have a 24x7 client so it may be logmein routes the wakeup via that although technically it shouldn't be doing that unless it asks for that machines access code and it doesn't do that.

I don't have the Superhub now (or at least I'm not using it) so I can't experiment. I do recall it working when I fiddled about with the port forwarding on the SH but can't swear that it worked a long time after the target had been powered down.

[sniper007]

I think this may have worked on the superhub but since firmware updates somewhere along the way the feature has stopped working.