Richard, it occurs to me there might be a specific reason this doesn't work currently.  Please let me know if this is possible; it seems like a good idea.

heh the specific reason is we don't have any code to do this yet ;).

it should be possible using busybox's ether_wake command. just need to work out the appropriate ui.

Dean to comment on how he thinks this should work

There probably should be no visible UI for this.  

If the server is disconnected AND is on the same subnet AND we're trying to connect because of a user key event, then it should send the WOL packets.

This probably won't make 7.0, moving to 7.0.1.

I'm going to try to fix this for 7.0.1

Added WOL magic packet code in r2162. This needs UI changes to be useful.

Fixed in jive firmware 7.0.1 r2165.

Created attachment 3226 [details]
Wireshark capture File

I did not get any "official" feedback regarding my posts as “Ventus” in the forum (http://forums.slimdevices.com/showthread.php?t=45013  and http://forums.slimdevices.com/showthread.php?t=45643), thus, this should be the right place for my bug report...

WOL using the Controller still seems not to work. I used Wireshark to record all network communication (file attached). 

My test scenario:
Zyxel HW660 WLAN Router: MAC: 00:a0:c5:d5:9e:b4, IP: 192.168.1.1
Nimbus: MAC: 00-16-35-AD-B2-C9, IP: 192.168.1.15	winXP pc running Wireshark
Discus: MAC 00-11-85-7B-DC-96, IP 192.168.1.100, winXP pc running SqueezeCenter Version: 7.0.1 - 18702 @ Sat Apr 12 00:22:25 PDT 2008 - Windows XP - EN - cp1252
SD Receiver: name “Receiver-WZ”, MAX: 00-04-20-16-16-AA, IP: 192.168.1.101, SW ver. 23
SD Controller: MAC:00:04:20:1A:11:93, IP: 192.168.1.102, SW ver. 7.0.1r2223
All devices are manually configured with IP addresses for network 192.168.1.0/24.
WOL is configured on Discus and works without any problem. I always use Nimbus or my wireless connected Notebook to WOL Discus.

Test sequence:
1.	Discus is powered off, Receiver is on, Controller is off
2.	Wireshark started on Nimbus, Capture File enclosed
3.	Controller switched on 
4.	Controller boots (no WOL of Discus)
5.	Controller: Settings->Music Source: no “discus” shown
6.	Controller: Settings->Music Source->Other Server: 192.168.1.100 configured, no WOL of Discus
7.	played around with different menus -> no WOL of Discus 

After having observed that Controller does not WOL Discus 
8.	I used Nimbus to WOL Discus (see No. 269 in capture file). 
9.	That worked, a short time later (see No. 318 in capture file) Controller found Discus, everything worked fine.

As you can see from the attached capture file Controller does not send the magic packet to WOL Discus. Despite the Slimp3 MAC-Broadcasts Controller send loads of other MAC-broadcasts (e.g. No. 200 in capture file) with UDP as transport protocol but none is a magic packet.

Additional questions:
When is Controller supposed to send magic packet (during booting, after having booted, triggered by special menu/option, …)?
Which MAC-Address is used?

I hope these information help finding and fixing this problem.
Kind regards from Aachen, Germany
-Markus

Markus: You might want to try testing with the following scenario:

Everything on and connected (receiver, controller, discus, etc.) 
Power off discus (music source server).
Examine controller: is wifi icon blue?
Try to initiate playback on receiver using controller: does a wol event occur?  Does discus wake up?

If it does, then it may be that the wol code depends on having an active (if disconnected) player and music source...which the controller may not have if it boots up when the music source server is down.  This is just speculation on my part.

For me the wake on lan works fine with the controller.
7.0.1 r2318.

But I have the problem that the controller seems to wake the server in unregular intervalls for no reason. So the WOL feature is actually a step back and not forward.

Hi there, could we reopen this bug, WOL is working sort of, but still needs some fine tuning.

Heres how it work's for me:

If i pause the Receiver and leave it and shutdown the server it works.
I simply press play where i was and the server boot's up and continues to play from where i left it very good.

It also works with my SB3.

Any browsing in artist or albums would also trigger the WOL function.

Good thinking.

Problems:

Nr 1. If i shutdown the server when the Receiver is playing, it boots up again and continue.

Nr 2. If i press "left" button a couple off seconds and go to the root ? menu of my controller, here i cant do much "choose players" of which theres non to choose.
It's also possible to choose "music source" if i choose my server as music source i would expect WOL from here but it does not, from here theres no WOL functionality.

Nr 3. which is the same as nr 2 but you get here by actually turning off the Controller and boot it again, theres no WOL from here.

Nr 4. If i'm connected to SqueezeNetwork while stopping the Server, again if I try to choose my server as source no WOL

This(2 & 3 ) also shows off a bigger functionality problem wich probably needs it's own bug. The Controller is practically orphaned from here you can not choose any player and it's not possible to WOL the server (so you can get a player to choose) and it's not possible to connect to squeezenetwork either, which would not help anyway. SN can not "start" any of your players (they are expecting SqueezeCenter )

Hi there,

did some more testing. Controller is now on firmware 7.0.1 r2287.

1. At least one player (SB3) playing.
Controller is connected to that player.

2. Power off all currently playing players. Using the old remote, Power button directly from playing. Controller displays pop-up Paused for the player it is connected to and then Off in the top status window.
All players are now powered off (showing the clock screen saver). (two SB3s)

3. A script on the server checks if players are still playing via the CLI, if no more players are playing it sends the server into hibernation after 5 minutes (Server is running on a windows home server (Fujitsu Siemens SCALEO).

4. After some time the controller clock screensaver simply stops and does not display the current time. Also the controller displays Conntecting to SERVER and wakes the server via WOL. (I'm not sure if the clock thing is related to this. I'm pretty sure I saw the stopped clock already on 7.0 r2097)

During the whole time the controller is in the cradle.

If I power off the controller completely the server stays in hibernation (as it used to do with the controller powered on in r2097)

Regards,
Michael

My controller is on r2354.

and i WOL from complete shutdown not Hibernation.

And it does WOl on curious occasions, my server waked now ? when fiddling with SqueezeNetwork on the Controller ?

Maybe a dedicated "Wake SqueezeCenter Now" Menu at root level and player ? level.
Instead off a complicated scheme second guessing when the user might want his/her server

I see the target for this bug has been changed. 
Does this mean that WOL will be removed from the controller completely in 7.0.1 release, or will it stay in this 'broken' form?

I am experiencing the same WOL problems as written above. 
I can see that the matter is being processed. But is there any idea about when the 7.1 version will be ready where his matter is resolved. I am not looking for at specific date but are we talking days, weeks or months.  
If this is not the place to ask this question then I am very sorry for haven done so. 

Hi,

I think this bug should get some higher priority. Basically 7.0.1 is unusable as it wakes the server almost every hour.

So will this WOL be removed from 7.0.1 or will it stay in this broken form?

Regards,
Michael

Based on user feedback WOL has been removed from 7.0.1 r2448. Further work will be done in 7.1.

I'd like to see this bumped to P1. For me it is a very serious usability issue. In fact I would NOT HAVE BOUGHT the product had I knew WOL was not available on the Duet.
(My receiver is wired to the server. The controller is in wireless ad-hoc mode.)

(In reply to comment #20)
> I'd like to see this bumped to P1. For me it is a very serious usability issue.
> In fact I would NOT HAVE BOUGHT the product had I knew WOL was not available on
> the Duet.
> (My receiver is wired to the server. The controller is in wireless ad-hoc
> mode.)

I've voted for this bug for the same reason, if the fix for 7.1 is going to take a long time any chance as a quicker work around you could provide a "settings-->" option to send a WOL to a specified MAC Address?

I'm getting way to old and lazy to walk upstairs and wake the PC by hand.

Thanks in advance.

Some kind of WOL is back with the latest 7.1 !
I have not investigated it's functionality but one bug is still there I can still not WOL from the "root" meny of the controller when no player is choosen and none is aviable.
Reason for this, no player is avaible because they where on the server when i turned it off.
You can wol if you don't "step out" of the latest player meny you where using, then the controller wols the server.

I think WOL has always been in 7.1.  I believe Richard removed it from 7.0.x because of complaints of spurious wake-ups.

The only beef I have with WOL as currently implemented in 7.1 is this:

There doesn't seem to be any way to send WOL to the last used local music source if the SBC is cold-started when all local music sources are shut down.  I should say that I'm having some problems with the server I'm testing this against so, if this functionality is in place, it may be just a problem with my setup.

Otherwise, the current WOL in 7.1 seems to work well for me.

In so many words Gordon :) thats exactly what I mean.

This partly depends on bug 6683, which I am working on right now.

I'm unclear as to the proposed mechanism for resolution of this bug.  Is a root menu option for sending a wakeup packet to a user-defined ip/mac address planned?  That's really all I want.

No, the plan is not to provide a menu option to do WOL. The current mechanism should work well once the bugs are sorted.

A fix for spurious WOL packet is in 7.1 r2662. This does not yet address sending WOL while no player is connected.

Hi Richard I've installed the latest nightly (not sure how to find the revision though):-
SqueezeCenter Version: 7.1 - 21543 @ Mon Jul 7 01:05:04 PDT 2008 - Windows XP - EN - cp1252
And my PC is still waking at random.

When I finish listening to music I turn off the receiver via the controller and just put the controller in it's current state into the docking cradle, and let the PC go to sleep on it's own.

Some point later I notice that the receiever has switched itself on and connected (dim white LED).

I can't say exactley when the PC wakes, but I've notice several times the PC is on and this never seems to happen if I've turned the controller completely off.

Latest few log entries (which could possibly be around the same time it's woken) are:-
[08-07-08 04:11:30.9691] Slim::Networking::Async::DNS::resolve (208) DNS server 194.168.4.100 couldn't resolve IP address for www.squeezenetwork.com: Send: Unknown error
[08-07-08 04:11:30.9867] Slim::Networking::Async::DNS::resolve (208) DNS server 194.168.8.100 couldn't resolve IP address for www.squeezenetwork.com: Send: Unknown error
[08-07-08 05:51:32.9691] Slim::Networking::Async::DNS::resolve (208) DNS server 194.168.4.100 couldn't resolve IP address for www.squeezenetwork.com: Send: Unknown error
[08-07-08 07:31:34.9222] Slim::Networking::Async::DNS::resolve (208) DNS server 194.168.4.100 couldn't resolve IP address for www.squeezenetwork.com: Send: Unknown error
[08-07-08 07:31:34.9736] Slim::Networking::Async::DNS::resolve (208) DNS server 194.168.8.100 couldn't resolve IP address for www.squeezenetwork.com: Send: Unknown error
[08-07-08 07:31:35.1292] Slim::Networking::Async::DNS::resolve (208) DNS server 194.168.4.100 couldn't resolve IP address for www.squeezenetwork.com: Send: Unknown error
[08-07-08 07:31:35.1372] Slim::Networking::Async::DNS::resolve (208) DNS server 194.168.8.100 couldn't resolve IP address for www.squeezenetwork.com: Send: Unknown error
[08-07-08 07:31:35.1455] Slim::Networking::Async::DNS::resolve (208) DNS server 194.168.4.100 couldn't resolve IP address for www.squeezenetwork.com: Send: Unknown error
[08-07-08 07:31:35.1539] Slim::Networking::Async::DNS::resolve (208) DNS server 194.168.8.100 couldn't resolve IP address for www.squeezenetwork.com: Send: Unknown error

Note www.squeezenetwork.com does resolve OK normally i.e.
C:\Documents and Settings\Slingshot>ping www.squeezenetwork.com

Pinging www.squeezenetwork.com [66.151.159.227] with 32 bytes of data:

Reply from 66.151.159.227: bytes=32 time=183ms TTL=81
Reply from 66.151.159.227: bytes=32 time=215ms TTL=81
Reply from 66.151.159.227: bytes=32 time=187ms TTL=81
Reply from 66.151.159.227: bytes=32 time=177ms TTL=81


Hope that helps

Slingshot

In 7.1 r2673 the Controller now remembers the last Player and Server it was connected to. This allows a WOL packet to be sent to the server when the Controller is turned back on.

(In reply to comment #29)
> In 7.1 r2673 the Controller now remembers the last Player and Server it was
> connected to. This allows a WOL packet to be sent to the server when the
> Controller is turned back on.

I find with jive_7.1_r2681 (and 2679) updates that the Controller tries to connect to my SB3 (as the last player connected) when it is turned on but just times out and the SC is not sent a WOL packet.  

Cliff 

Cliff, it should be sending the WOL packet. If you choose "Try Again" on the "Problem Connecting" screen does it work then?

If not please try pressing and holding left, until your player is not selected. Then go to "Choose Player" and select your player again. Does it work after this?

Thanks,
Richard

(In reply to comment #31)
> Cliff, it should be sending the WOL packet. If you choose "Try Again" on the
> "Problem Connecting" screen does it work then?
> If not please try pressing and holding left, until your player is not selected.
> Then go to "Choose Player" and select your player again. Does it work after
> this?
> Thanks,
> Richard

Hi Richard, The player hangs on the 'connecting to SB' screen and there's no try again option (after 5 min).  On pressing the 'left' button and going to 'choose player' there nothing in the menu to select.

This problem may be peculiar to my set up in which case it's not a major issue since my Controller rarely gets switched off these days.  WOL appears to work fine when the player is woken up from sleep mode. Thanks for this fix

Cliff

This should now be fixed in the latest firmware/SC nightly releases for 7.1. Please reopen if you still find problems with WOL.

(In reply to comment #32)
> Hi Richard, The player hangs on the 'connecting to SB' screen and there's no
> try again option (after 5 min).  On pressing the 'left' button and going to
> 'choose player' there nothing in the menu to select.

I'd like to understand what's gone wrong here. Do you use http auth on SC (if so Ben fixed a bug for that yesterday). Otherwise do you have an SD card to capture the debug logs from the Controller?

This bug has now been fixed in the 7.1 release version of SqueezeCenter!  Please download the new version from http://www.slimdevices.com if you haven't already.  

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.

I'm not sure if the "fix" for this bug included the case when the Controller cold-boots and the music source is off.  With recent controller firmwares, there doesn't seem to be any way to wake the server under these conditions.  As folks become more and more hyper-vigilant about turning stuff off, this might be perceived as a drawback.

A simple enhancement that can cope with this case could be:

..every time the Controller successfully connects to a non-SN music source, it writes the following file to /etc/init.d/rcS.local:

#!/bin/sh
scserver=192.168.0.xxx
scservermac=00:xx:xx:xx:xx:xx
/bin/ping -c 1 $scserver || { /bin/echo "$scserver does not respond to ping" >&2 ; /bin/sleep 5 ; /bin/echo "Waking up $scserver.." ; /usr/bin/ether-wake -b $scservermac ; }	


...fixing up the $scserver ip and $scservermac values, of course.

With this in place, when the Controller cold-boots and it can't ping the $scserver, it performs an ether-wake to attempt to WOL the server.

When the Controller connects to SN, it could erase the rcS.local file to prevent a spurious WOL to the local server on the next cold boot.

A total kludge, but it's simple and it seems to work for me.

Ok is it not so already my controller wakes my server when i cold boot it ? this has worked a long time now ?

Hybrid networking mode, with SC 7.2 (debian/stable)
The Receiver/Controller interaction is a TOTAL MESS.
 - WOL does not work. Period.
 - Putting the Receiver On or Off is tricky. Often the server will get out-of -sync... The only way to put de Receiver on is to restart the server ... 
 - Using the Controller to ask a remote SB3 to WOL the server ends in messing with the SB3's configuration. WOL won't work, and the SB3 will need to see the server back on the network to recover.

Hybrid mode needs some serious attention. Or remove it from the documentation.

Mikel: I'm glad it's working for you.  And WOL when the SBC has remained on while after the server has turned off works just fine for me too.  But the case of: server off, SBC off --> SBC on has never worked for me and, from what I've gathered, hasn't worked for others as well. This is a modest proposal.  If the SBC is supposed to already support this case, then please ignore this.  Having the rcS.local file in place now allows me to turn on my server after turning on my SBCs.  So I'm happy.

Thats a realy intresting difference hopefully Richards sees this ?

Can differences in our network or routers make a difference ?
Different servers ? I have Linux (CC4.2 community ed).
Harware i have this VIA EPIA-EN12000EG,EDEN V4/1200Mhz motherboard with built in NIC ?
I'm on r2873 or r2907 FW on my SBC at the moment (r2907 has another bug you don't want that https://bugs-archive.lyrion.org/show_bug.cgi?id=9427)

I've encountered one other snag with WOL i wrote about it in a tread maybe its relevant i cite myself:

"
Started out with My SB3 SBR and SBC on my local SC playing just fine.
Moved to SN with SBR and SBC listening to some Folk Alley.
Turning of the server with SC, continued listening to radio for a while presses stop on SBC and goes to work. places SBC in cradle it's still on displaying clock.

10hrs later slumps down in my couch getting the SBC try to choose my SB3 it's not in the player menu anymore (it usually is, that's one point where WOL usually kicks in ).
Ok tries to choose my music source but can't find my server in the menu (this is another point where WOL usually wake the server ).
Now i'm powering of the SBC and power it on again, NOW WOL kicks in, the server is booting, yes !"

So this remember last SqueezeCenter function is not always working ?
And it's not always remembering players either ?
To invoke WOL from player menu or server menu, servers or players must be listed in thoose menu's.
If WOL at power up does not work for everyone, I have to agree with the other guys WOL is not working again..

I will test this again with r2873 I listen to SN with duet stop it there, i'm going away for work for 2 weeks, letts see if the SBC cam wol the server when i'm back


Some network details, fixed IP's for everything no dhcp same subnet all ip's in 192.168.1.* range, a WRT54GL running tomato WPA2 security and MAC filtering enabled.
SB3 SBR and SBC wifi, Server and Desktop wired.

Now I'm back I tried the experiment i promised: Switch over the SBR and SBC to SN listening to some radio pressed stop, powered off server went away for work for 8 days.

Result, this time it was not even possible to WOL from power on on the SBC.
So the capability to WOL goes away over time ??

If I do the same thing within a short interval, I can wol but only by restarting the SBC and then choose music source, all other options is not working.

So wol is only reliable if all your players and SBC was attached to you local server at shutdown, I'm going to do a time test next week (i'm going away again for at least a week ) Now I'm plan to have all players and controller connected to my local SC, turn it of and see if can wol when I return.

And please reopen bug, it s is not resolved.

Yep this works if my Controller and my players where tied to my local SC wol worked flawless even if the server has been off for a week.

So my previus comment stand, wol does not work if you where conected to SN and gone away for a long time then the controller forgets all about your server and players.

Please reopen wol is broken in a very irritating manner now.
I can not turn of my server properly.

SBC wols the server as soon as i touches it "motion sensors" or any other random occasion when it should not do it. I don't have to touch any buttons for it to happen.

I have to turn of my server 3 times every nigth before my controller will accept it. or turn of the controller !

Tonigth my controller was just lying around with it's screen blank (was on now playing before that) impossible to turn of server.

Server will not respond to it's off button either have ssh and "shutdown -h now"

if missuse the off button by desperately pressing it to make it not boot it boots anyway but is not able to communicate with anything (not even ssh)

Steven: Can you verify that this bug has been regressed?

Not sure this is the most appropriate bug to file this under, as there are probably a few in here, but they all result in WOL being unreliable and frustrating to use.  

WOL is so fragile in its current form (fw 3993) that my other half is asking for the SB2 back because at least it "works".

The problem is that there are several states the system can get into, such that there is no easy recipe for WOL that works, nor is there much feedback as to what is going on. Examples are:

* controller connects to squeezenetwork by itself, and I then can't select jukebox (my server machine) to wake it up, as controller has forgotten jukebox in the music source menu.

* receiver happens to be off (we power down the receiver with the amplifier etc) when the controller is used, and the controller hangs for ages trying to connect to receiver, even if the receiver is subsequently turned on.

* controller forgets the existence of jukebox, and gets into a weird mode where only settings and choose player are available in the menu. You can't wake jukebox at it is not in the music source menu.

To exacerbate the situation, rebooting the controller usually fixes the problem, but the controller regularly hangs indefinitely on shutdown. Just waiting for the day I have to apologetically ask a neighbor for the little black plastic thing that came flying over their fence...

I'm sure there are other scenarios that get in the road of startup as well. The whole process needs to be more intuitive and robust - I can deal with it, but I also have a PhD in computer science.

Hmmm, this will turn into an enhancement request, but I can't resist...

1. Can we have a player selection menu that clearly indicates ON, OFF, and UNAVAILABLE (i.e. unreachable, really off, you need to do something) for each player in the list - i.e. display the current state in the menu, and prevent selection of UNAVAILABLE players. 

2. If the controller looses the currently selected player, then this menu appears forcing you to choose, and the menu needs to be responsive!!!! Better to update the state to UNAVAILABLE if unreachable, than hang trying to connect, controller menu also needs to react quickly if receiver comes out of the UNAVAILABLE state. All this needs to happen without a dependency on squeezecenter either, as the player or squeezecenter or both may be powered off.

3. Controller needs a similar menu for music sources that indicates AVAILABLE/UNAVAILABLE - and  it should not forget the servers unless explicitly ask to. 

4. If the controller looses the currently selected server (and we have a player connected), then the server menu appears - selecting unavailable server sends WOL and sets the "default server", but the menu still remains responsive in this menu - i.e. I could select another server and it would become the default. The idea would be the default server would be the thing the controller is trying to connect to in the background, but still with some in-your-face indication on the screen/menu as to what is happening - to avoid the current hanging when the connection fails due to slow bootup, and whatever else. This would indirectly also gracefully handle selecting dead servers etc, just select another and the controller starts trying the new default.

5. Can we play an indication/tune/beep when the server connection is established - so one does not have to keep checking the screen to see if the server is finally up.

I think this would go a long way to a robust, intuitive, idiot proof, startup sequence, that would clearly lead the user to a running system. The current system of hanging "connecting to server" in seemingly random locations in the menu structure is painful to the less technically inclined - especially if there is no place in the menu that you can navigate to to cause the connection attempt.

I don't have detailed knowledge of your low-level protocols, so maybe it makes sense to select a server, then a player. But either way, you see my point - simple, obvious, intuitive, responsive, robust. Such a scheme would also help even if WOL was not involved (e.g. server or players that happen to be off accidently). Startup for the SB2 is just so much better in this regard - press the red button, "connecting", and when the display appears (which you can see from anywhere in the room), you're ready to go. The controller needs to be this simple.

cheers

   - Kevin

Moving to the product SqueezePlay because this bug appears to apply to any player based on that application code.  Feel free to move it back if it's specific to the original product.

Reset priority before triage.

*** This bug has been marked as a duplicate of bug 10804 ***