Bugzilla – Bug 4664
Squeezebox 3 uses incorrect MAC address in WoL Magic Packet to wake Slimserver behind a bridge using proxy arp
Last modified: 2009-08-23 08:35:23 UTC
-- Problem Summary A network trace using Ethereal shows that Squeezebox 3 appears to use ARP to determine the MAC address of the Slimserver. This works for Wake-on-LAN (WoL) on single segment networks, but fails if there is for example a wireless/ethernet bridge or mains/ethernet brdige (Homeplug) between the Slimserver and the Squeezebox, and the bridge implements proxy arp. In this case the bridge provides its own MAC address in response to the ARP request rather than the Slimserver's. The Magic Packet broadcast by the Squeezebox to wake up the Slimserver using WoL therefore contains the wrong MAC address and the Slimserver doesn't wake up, even though the bridge passes on the broadcast magic packet to the Slimserver. This issue was found when using a wireless Squeezebox 3 running firmware version 64, connected via 802.11g/WPAPersonal-TKIP to a Belkin F5D8230-4 wireless router, with another wireless hop to a Netgear WGPS606 wireless print server (which includes a wireless/ethernet bridge and built-in 4 port ethernet switch). An Intel Mac Mini running Slimserver software version 6.5.0 on OS X 10.4.8 was connected to the WGPS606 via ethernet cable. All other tested Squeezebox/Slimserver functionality appears to work fine in this configuration. Just the Wake-on-LAN fails because the bridge proxies ARPs. Using a tool like the Magic Packet generator from www.depicus.com, configured to broadcast a Magic Packet containing the Mac Mini's ethernet MAC address, and broadcasting it from a laptop connected wirelessly to the Belkin router will wake the Mac Mini OK. Attaching a Squeezebox via wired ethernet to the WPGS606's 4-port switch also wakes up the Mac Mini (the bridge does not proxy ARPs in this case, only over the wireless<->wired interface). -- Extent of the Problem Squeezebox users unable to connect the computer running the Slimserver software directly to their wireless router via wired ethernet, but instead using a wireless/ethernet bridge or Homeplug bridge to wire up their desktop remotely, will be impacted by this problem if the bridge they are using proxies ARPs. Users are most likely to need this type of bridged configuration when the broadband access point to their house is in a different room to their computer running the Slimserver software. Whilst researching this issue on the Slimdevices forums a number of other users had tried this type of configuration without success in using WoL, so there is some level demand for this type of configuration, although this is hard to quantify. The stock answer to users wishing to use WoL over anything other than ethernet has generally been not to bother as it doesn't work, so there may be quite a number of users who would like to use this feature but are currently unable to. In this UK for example, the cost of running a Slimserver 24x7 may be anything from $40-$200 per year at current energy prices depending on how power efficient there computer is (20W-100W respectively), so the impact of not being able to use WoL can be significant both financially and environmentally. -- Further Information See the following thread: http://forums.slimdevices.com/showthread.php?t=31561 -- Suggested solution/workaround Provide a way for the user to configure the Squeezebox to use a user-supplied MAC address when creating the Magic Packet, rather than automatically using the MAC address returned by an ARP of the Slimserver's IP address. This could be done on the Squeezebox settings menu using the remote, and/or via the Slimserver web UI.
I have my SlimServer behind a NetGear WGPS606 bridge and have exactly this problem. The Squeezebox assumes the MAC address of the bridge is that of the slimserver, when of course it's not. (It's just like IP addresses hiding behind a NAT firewall, but at the MAC addres level instead.) The MAC address needs to be set explicitly in the Squeezebox. Easiest from the SlimServer web interface, since at that point the SlimServer could have a pretty good guess at the correct address.
Have that problem too with my AVM (most buyed here in germany) WLAN DSL Router. WOL from my laptop works, but not from the transporter or squeezebox.
I too have a squeezebox 3 (firmware v72) wirelessly connected to a router and on to a pc in my garage. The garage pc connects wirelessly to the router too, via a client bridge (Buffalo WBR-G54 running DD-WRT). Everything works fine, except for Wake On Lan. A bit of packet sniffing with ethereal shows that the SB is sending its magic packet to the MAC of the bridge rather than the MAC of the pc. WOL is fully enabled on the pc, and I can wake it up using my wireless laptop and a magic packet generator pointing at the correct MAC. Interestingly, windows gets the MAC correct if you do a "nbtstat -a <garage>", whereas a simple "arp -a <garage>" returns the bridge's MAC. I agree that the best solution is probably to allow a 'hardwired' MAC to be sent in the magic packet, set through the slimserver interface.
The best solution would be for it to just work without the user having to enter a a MAC address at all. :) Two ideas: 1. Find out how to get that address the same way that windows does in the example given. 2. Have the server send the right MAC address to the player to use for WOL. Obviously, the first would be preferred.
(In reply to comment #4) > The best solution would be for it to just work without the user having to enter a MAC address at all. :) It would indeed, but may not be that simple to get working in all situations. For example: > 1. Find out how to get that address the same way that windows does in the example given. I've tried this out and, whilst it works correctly when the remote host is running Windows, nbstat -a just returns a MAC address of 00-00-00-00-00-00 when the remote host is running OS X. I guess this is not surprising given that NetBIOS is a Windows protocol. > 2. Have the server send the right MAC address to the player to use for WOL. Finding the right MAC address to use on the host machine may not be that easy. My Mac Mini has two network adapters (wireless and ethernet), each with its own MAC address. Furthermore, software installed on an OS, such as VPN or virtualisation software, will generally create its own network adapter devices in the OS. Whilst i don't want to discourage you from exploring a no-touch solutions, I would request that you also include the ability for the user to supply a MAC address manually. That way if there are any issues with the automated solution, the user can still get WoL working in their environment. Thanks for looking into this: i look forward to not having to go to the office and turning the computer on every time i want to listen to some music :)
(In reply to comment #5) > > 2. Have the server send the right MAC address to the player to use for WOL. > Finding the right MAC address to use on the host machine may not be that easy. > My Mac Mini has two network adapters (wireless and ethernet), each with its own > MAC address. Furthermore, software installed on an OS, such as VPN or > virtualisation software, will generally create its own network adapter devices > in the OS. Thinking about this further, there could be quite a reliable and simple way of determining which network adapter device in the OS hosting the slimserver is the correct one to use the MAC address for: the Squeezebox is configured with the IP address of the Slimserver host, so perhaps it could communicate it to the Slimserver, which could look up the MAC address for the Network Adapter with that IP address on the local host and send the correct MAC address back to the Squeezebox.
Although it's been a few months since the last comment, I thought I would add a Vote to resolve this problem in some way. I use a pair of Netgear XE103 HomeLink adapters between my wireless SB3 and my SlimServer. Wake-On-LAN "magic packets" to the RedHat Linux SlimServerwork fine when on the same switched LAN segment, but not across the "bridge" formed by the XE103's.
Felix has checked in a fix for this which will be put into the 7.0.1 release.
Fix included in SB FW 86 and TR FW 36. If the SC MAC address automatically learned is not correct, you can set it manually in Setup - Current settings - SqueezeCenter MAC address. Please give it a try, thanks.
Upgraded to SqueezeCenter_trunk_v2008-01-19.dmg (FW v.86) to verify the fix and it works fine. Thanks! Mac Mini (OSX 10.4.11) will now wake from sleep within a second. To stop a Mac going to sleep when playing music see here: http://forums.slimdevices.com/archive/index.php/t-40906.html. Shame it's not built into SC7 by default, but I guess you can't have everything :) -------- A few notes for anyone else wanting to try this out, who hasn't yet made the move to SqueezeCenter 7.0: . Latest builds are kept here: http://www.slimdevices.com/downloads/nightly/latest/7.0/ . Upgrading from SlimServer 6.5.4 to SqueezeCenter 7.0.0 on OSX 10.4 did not work correctly (SqueezeSenter does not start). See here for the fix: http://forums.slimdevices.com/showthread.php?t=41407&highlight=graley. . Configuration of the proper SqueezeCentre system MAC address is done, as Felix says, in the SqueezeBox setup menu. To get to this you have to power cycle the SqueezeBox (took me a couple of minutes to work this out: maybe I'm just slow :) . New versions of plug-ins are needed for SqueezeCenter 7.0. I use SqueezeScrobbler and AlienBBC. SC7 versions of these plug-ins can be found here: AlienBBC: http://www.x2systems.com/AlienBBC/installation.html. I used the OSX version: see bottom of page. I suggested in the instructions, I downloaded the new version of Mplayer) SqueezeScrobbler 1.1: http://sourceforge.net/project/showfiles.php?group_id=105780. SC7 has a built-in plug-in to submit tracks to Last.FM (called Audioscrobbler), but I use SqueezeScrobbler instead as it also enables you to play Last.FM radio streams. Stop AudioScrobbler submitting tracks if you want to use SqueezeScrobbler (SqueezeCenter web pages->Settings->Advanced->Last.FM AudioScrobbler->No, do not report tracks to Last.FM) Everything works very well. SC7 is much more user-friendly and stable than 6.5. Great job!
Verified Fixed Version: 7.0.1 - 19422 with updated Player firmware versions. If you still see an issue, please reopen the bug with added details.
This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1 Please try that version, if you still see the error, then reopen this bug. To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html
The option 'Squeezecenter Mac Address' in the Squeezebox 3 'Current Settings' appears to have disappeared in FW Version 112 (from SqueezeCentre 7.2). Has this functionality been removed, or moved somewhere else? (In reply to comment #12) > This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1 > > Please try that version, if you still see the error, then reopen this bug. > > To download this version, please navigate to: > http://www.slimdevices.com/su_downloads.html >
This functionality has been removed, please see bug 7594 comments 3 and 4.
Hi Felix, I appreciate that you don't wish to make life hard for the typical user in order to support the minority. However, would it not be possible to make everyone happy by having a toggle to enable/disable Squeecenter MAC address manual override? By default the override would not enabled and the product would always determine MAC address via arp as you do now, but users who need an override could explicitly enable it. For myself, and I guess others using bridges which mis-report mac address, removing this feature is a major step backwards, forcing me to downgrade to SC7.1.
Hi Felix, I would also like to echo Creeky's comments because as a voter for this fix I was very happy when the ability to change the MAC address was added to SlimServer. To remove it again in the latest version is rather frustrating to say the least! Thankfully I received this e-mail before I upgraded... I'm sure there are many SqueezeCenter users out there with HomePlug devices and other bridging technologies that benefitted, and with the ongoing increase in home network demands such as high-definition video etc., I can imagine more and more HomePlug users who would want the WoL functionality. There are of course environmental benefits too; only having a server switched on when required, rather than left on just in case, will use less energy. Please can I ask that some sort of workaround is put back in place so that those users that need it at least have a choice to modify the MAC address setting on their players. It's fair enough making this the non-default option, but the choice should be there. Thanks for listening...
Just thought I'd add another voice to the chorus of those in favour of the ability to specify the MAC address. By all means hide the option away in a sub-menu, remove it as the default setting, but please please keep it as an option. Otherwise I'll be stuck with the 7.1 release for the foreseeable future. Thanks! Matthew
Another voice to say this should be fixed properly, it's a poor call (IMHO) to mark this as a WONTFIX.