HD200 will not wake up server

[brewston]

I filed it too, no doubt I will get the same reponse. I also mentioned the behaviour of the Hd200 when it loses contact with the server (loss of network, been put into standby etc) unlike my PC client which says 'lost connection with server' the hd200 just hangs on the screen you were on (STV behaviour is slightly different, Default STV recovers when the server comes back, SageMC needs the HD200 to be powered off/on on the remote)

Tim

[Djc208]

Good luck with that. The same request/report was made about the HD100 and that hasn't happened either.

[Swagger200]

I am also trying to be greener by not having servers run 24/7. I managed to get down to only one running all the time, and it sends a "magic packet" to another server to wake it up from shutdown state, at a fixed time, everyday.

The server has to support "Wake-on-LAN" - in other words the BIOS has to support it, and the network card on the server has to support it, and you have to tweak control panel settings for the network card to turn it on.

Most modern motheboards / network cards do support this.

On the "sending" PC or device, you have to program in the MAC address of the "target" server's network card.

Seems to me that the extender could do this with a firmware upgrade.

[Djc208]

Originally Posted by Swagger200

Seems to me that the extender could do this with a firmware upgrade.

I think we all agree it should be possible with the extenders. However it apprently hasn't been very high on the to-do list for either extender.

[Madz]

Hi, just had a response from them on mine and they seemed quite responsive on it - were clarifying a couple of things. Hopefully now they know a few of us are interested they'll have a look at it for us. I'm sure these sort of things come down to how much work they are to implement and what the risk/testing requirements are.

On the same topic I think they should make it an option to have the hd200 not go into standalone mode UNLESS no server is found. If you want to disable this mode have an option within the Sage interface to set a flag that the HD200 reads on reboot to go into standalone mode. This would speed up boot time a good bit. While the current boot time is not horrible, it seems very pointless for me to wait every time i turn it on since I have no need for standalone mode. Reason time wait maybe a concern is that if they get standby mode on the server to wake up that will be a delay that would be ADDED to the current turn on delay making 2 short delays into a long delay.

Maybe all we need is the ability to customise the auto-connect cancel time (from 5s down to 1s)? Not a big deal for me, but agree with your point as I only use it as an extender too - not interested in the stand-alone mode.

[m1abrams]

Originally Posted by Swagger200

On the "sending" PC or device, you have to program in the MAC address of the "target" server's network card.

Seems to me that the extender could do this with a firmware upgrade.

The thing is I do not even need that, while that would be more reliable and would work for waking up a server in hibernate mode. You can setup the server to wake on ANY packet sent to its ip. So if they would just modify the auto-connect to first try to connect to the manual entry that would wake the server. However the manual entries are not even used during HD200 auto-connect.

[Madz]

Just wanted to let you know that I've received a very positive response from Sage support. They are considering the possibility of sending out magic packets or traffic during the auto-discovery phase to servers on the list (if we have auto-connect set). No guarantees of course, but here's hoping we'll see something along these lines implemented in a future firmware.

[BlueH2O]

This probably doesn't help too many folks but I have a linux box on the net that's set to listen for the broadcast UDP packets on port 31100 that are sent by extenders at startup, and send a WOL packet to the server.

[m1abrams]

Originally Posted by BlueH2O

This probably doesn't help too many folks but I have a linux box on the net that's set to listen for the broadcast UDP packets on port 31100 that are sent by extenders at startup, and send a WOL packet to the server.

WOW - nice hack!

Course to do this hack one must have a linux server on their network running which if you already have one for something else makes sense, but as you said probably not really a solution for everyone.

[BlueH2O]

Originally Posted by m1abrams

WOW - nice hack!

Course to do this hack one must have a linux server on their network running which if you already have one for something else makes sense, but as you said probably not really a solution for everyone.

Thanks. You're right, I have this box set up as router, dhcp server, etc.. so it's easy to throw this in there. But it wouldn't make sense to set up a box for this alone unless perhaps if it were very small, like an embedded device.

[cheekymonkey]

Originally Posted by BlueH2O

This probably doesn't help too many folks but I have a linux box on the net that's set to listen for the broadcast UDP packets on port 31100 that are sent by extenders at startup, and send a WOL packet to the server.

I have a small embedded device (slug) running debian and would be interested in your script, any chance you could attach it to this thread?

[BlueH2O]

Originally Posted by cheekymonkey

I have a small embedded device (slug) running debian and would be interested in your script, any chance you could attach it to this thread?

Two files:

1. /etc/xinetd.d/sagewake:

service sagewake
{
	port = 31100
	socket_type = dgram
	protocol = udp
	user = root
	server = /usr/bin/sagewake
	type = UNLISTED
	wait = yes
	only_from = 192.168.1.0
	instances = 1
	log_on_success -= EXIT DURATION
}

2. /usr/bin/sagewake:

#!/bin/bash
/sbin/ether-wake <MAC address of server>

My box is Fedora 10, YMMV.

[cheekymonkey]

Brilliant.
Here I was thinking that it would be a script that would have to run listening to a port, then I would have to monitor somehow it was still running, but your solution is not only the right way to do it's simple as well.

thanks heaps it works a treat

For debian it needs to be slightly changed

its /usr/sbin/etherwake availiable by running "apt-get install etherwake'

and if you dont want to load xinetd you can just add to /etc/services something like

# Local services
sage 31100/udp # sage extenders broadcast on bootup

and then add to /etc/inetd.conf

#:OTHER: Other services
sage dgram udp wait root /usr/bin/sagewake

[ellweber]

Originally Posted by cheekymonkey

Brilliant.
and if you dont want to load xinetd you can just add to /etc/services something like

# Local services
sage 31100/udp # sage extenders broadcast on bootup

and then add to /etc/inetd.conf

#:OTHER: Other services
sage dgram udp wait root /usr/bin/sagewake

Thanks for the pioneer work on this workaround for Sage's missing element. I was able to get my DNS-323 NAS to wake up my Sage server by following your and BlueH2O's tips.

Unfortunately, now that the server is waking up a few seconds after the extender sends out its poll to port 31100 I still end up in the extender's stand-alone UI.

How should I set up the HD 200 to see the server automatically?

- I have tried 1, 5 and 15 seconds delay
- I have tried setting up the server by static IP address.
- I have tried with and without the AutoConnect setting

None of these combinations seem to result in the server connecting without my manually setting it. Very low WAF!

Any suggestions on the way to set up the extender to see the server automatically would be greatly appreciated.

Thanks,

Lynn

[BlueH2O]

Originally Posted by ellweber

Unfortunately, now that the server is waking up a few seconds after the extender sends out its poll to port 31100 I still end up in the extender's stand-alone UI.

How should I set up the HD 200 to see the server automatically?

- I have tried 1, 5 and 15 seconds delay
- I have tried setting up the server by static IP address.
- I have tried with and without the AutoConnect setting

I only have HD100's so I can't test this scenario.. Note that my server takes about a minute to fully 'wake up' so the client keeps polling during that time. but as long as power has not been removed from the extender in the interim it will still go looking for the server in the same place as before rather than doing a 'search'

[Dingdul]

Originally Posted by ellweber

I was able to get my DNS-323 NAS to wake up my Sage server

Wow that's terrific - my one outstanding issue with Sage. Unfortunately though I have no experience of Linux so would be extremely grateful if you could post some instructions for my DNS-323.

Plus have you got it waking correctly into extender mode yet?

Jonathan

[ellweber]

Originally Posted by Dingdul

Wow that's terrific - my one outstanding issue with Sage. Unfortunately though I have no experience of Linux so would be extremely grateful if you could post some instructions for my DNS-323.

Plus have you got it waking correctly into extender mode yet?

Jonathan

I am not experienced with Linux either but I have pieced together a solution that almost works. Unfortunately, Sage has left us with a Catch 22 situation. They have a server that is designed to sleep until it needs to wake up for a scheduled recording, they sell an extender that does not know how to wake up its own sleeping server to watch what the server has recorded (no provision to send a WOL magic packet) and, finally, if an external WOL is provided, the extender never does a retry to see if the server has become available.

So, I have to turn the HD 200 on to wake the Server, then turn it off again so it will retry finding the Server when I turn it back on a second time. This rates a zero-plus on my WAF scale! I hope they add a real WOL capability to the HD 200 in a firmware upgrade SOON.

In any case my DNS-323 is modified to allow a more user-configurable Linux environment. There is an active community of users that have developed a suite of tools that make this possible. Go to: http://forum.dsmg600.info/f3-DNS323-...iscussion.html to get started and also to: http://wiki.dns323.info/ for more resources. The key to all of this is the installation of a tool called fun_plug on your DNS-323. I will not try to duplicate all of the install info here, as I have not looked at that for a long time.

I had already added scripts to better manage the disk drive sleep behavior and to control the fan speed.

The main script that sends the WOL to wake the server is “sagewake”:

#!/bin/sh
  PATH=/ffp/bin:/bin:usr/sbin:/sbin:/usr/bin
  /ffp/bin/ether-wake -b -i egiga0 00:1e:8c:86:6b:ed
   
  # Kill inetd so it can be restarted, only works once? 
  PID=$(/bin/pidof inetd)
  if [ -n "$PID" ]
  then
     kill -9 $PID
  fi 
  sleep 1
   
  # restart it for the next time
  /ffp/sbin/inetd

“ether-wake” is the Linux program that generates the WOL message and that line ends with the MAC address of your Sage Server’s LAN device. For reasons that I do not yet understand this only works the first time it runs so I kill and restart the Linux service manager “inetd.”

This line needs to be added to the file “services” which, in my system, is located in ffp/etc:

sage                 31100/udp      # sage extenders broadcast on boot up

This defines a new service that will listen for a udp message on port 31100 which is what the HD 200 sends out when it wakes up.

This line needs to be added to inetd.conf, which, in my system, is also in ffp/etc:

sage                 dgram            udp             wait             root             /ffp/start/sagewake

This sets the action taken upon detection of the port 31100 activity.

I found that because the services and inetd.conf files reside in flash I needed to copy them to RAM so that my edits would stick. Also, I found that inetd wasn’t even running by default so I needed to start it for the first use then it would be restarted by sagewake for subsequent use. I added these files to the master fun_plug script but I suspect that there is a more appropriate place for them.

# copy modified "services" and inetd.conf file to RAM 
   
  cp -p -f /ffp/etc/services /etc/services
  echo "++++++++copy services to RAM++++++++++++"
   
  cp -p -f /ffp/etc/inetd.conf /etc/inetd.conf
  echo "++++++++copy inetd.conf to RAM++++++++++++"
   
  # start inetd 
   
  /ffp/sbin/inetd
  echo "+++++starting inetd+++++"

This seems like a lot of hassle and band-aid for such a basic problem but the part that works does work for me. Credit to BlueH2O and cheekymonkey for the ideas and the development. Note that the file locations and other details may not apply to different versions of the underlying DNS-323 software and the fun_plug tools. I am running 1.03 DNS-323 S/W and funPlug3.

Good luck!

Lynn

ps: I don't see any reason why the HD 200 couldn't do this same thing, without much effort. As far as I can see it too is running some form of Linux.

[bshiek]

Hmm. Thanks for the sharing the scripts. Do you think I could run a similar WOL script from an HD100 extender to DD-WRT router to SageTV server? I have some reading to do on DD-WRT...

[BlueH2O]

Originally Posted by bshiek

Hmm. Thanks for the sharing the scripts. Do you think I could run a similar WOL script from an HD100 extender to DD-WRT router to SageTV server? I have some reading to do on DD-WRT...

DD-WRT supports WOL and xinetd, so this should be no problem.

[fac13]

I've just been down the same path and my DNS-323 now wakes up my Sage server when it sees the 31100 UDP broadcast.

Unless I've missed something, this doesn't leave us much better off though, does it? The problem is that the extender only broadcasts to 31100 when it is first powered on, or forced to simulate a power-on by pressing the Home key or the Menu button while on standby. Is that correct?

Usually an extender is resumed from standby, not started from cold, at least in my house, but this does not generate a 31100 broadcast, even if repeated attempts to reach the last-used server fail. I've traced it and it just sends packets to port 31099 at the last-used server IP address, over and over, forever.

I can see the point of it retrying a few times, but FOREVER? Surely better to give up, tell the user the last-used server is unavailable and broadcast on 31100 to see if there are any alternative servers available?

It's much quicker to go and resume the server myself than force the extender to cold-start just to get it to generate a 31100 packet. Or have I missed something?

Edit: I should mention that I am using HD100s, maybe HD200s behave differently?