PDA

View Full Version : Wake on LAN and bridged networks



Creeky
2007-01-11, 15:48
Hi all. New Squeezebox 3 owner here, trying to get Wake-on-LAN to work over a bridged network.

The configuration is as follows:
. Squeezebox connected wirelessly to a Belkin F5D8230-4 wireless router (which works well according to http://wiki.slimdevices.com/index.cgi?RouterStatus).
. Slimserver running on Mac Mini connected via wired ethernet to a Netgear WGPS606 wireless print server. This print server includes a wireless/ethernet bridge and built-in 4 port ethernet hub. The Mac Mini is connected to the 4-port hub and the WGPS606 is connected wirelessly to the Belkin router, acting as a bridge between the two.

Everything works apart from Wake-on-LAN. A quick network trace with Ethereal shows the problem: the Squeezebox is broadcasting an ARP request to find the MAC address on its network segment associated with it's configured IP address for the Slimserver. Because the WGPS606 is bridging the wireless side and its built-in 4 port wired hub where the Slimserver is actually located, it correctly responds back with its own wireless MAC address. The Squeezebox then uses that MAC address to generate the Magic Packet and broadcasts it. The WGPS606 forwards the broadcasted magic packet to its wired hub side, but because it contains the MAC address of the WGPS606 and not the Mac Mini, the Mac Mini does not wake up.

If I use a tool like the Magic Packet generator from www.depicus.com, configure it to broadcast a Magic Packet containing the Mac Mini's ethernet MAC address, and broadcast this from a laptop connected wirelessly to the Belkin router, the Mac Mini wakes up just fine. Similarly if I attach a Squeezebox via wired ethernet to the WPGS606's 4-port hub, it wakes the Mac Mini fine (since there is no bridging in this case, the Squeezebox's ARP request results in the Mac Mini's MAC address as the response).

My question is: can the Squeezebox be configured to use a manually supplied MAC address (or one retrieved by the Slimserver software from its host) to generate the Magic Packet, rather than it using ARP to try and work out the MAC address of the Slimserver host?

Would this require an enhancement to the Squeezebox firmware or Slimserver software?

I'm sure anyone wishing to use a Squeezebox wirelessly and use the Squeezebox's capability to wake up the computer running the Slimserver software by using a wireless/ethernet bridge would greatly value this capability.

peter
2007-01-12, 08:42
Creeky wrote:
> Hi all. New Squeezebox 3 owner here, trying to get Wake-on-LAN to work
> over a bridged network.
>
> The configuration is as follows:
> . Squeezebox connected wirelessly to a Belkin F5D8230-4 wireless router
> (which works well according to
> http://wiki.slimdevices.com/index.cgi?RouterStatus).
> . Slimserver running on Mac Mini connected via wired ethernet to a
> Netgear WGPS606 wireless print server. This print server includes a
> wireless/ethernet bridge and built-in 4 port ethernet hub. The Mac Mini
> is connected to the 4-port hub and the WGPS606 is connected wirelessly
> to the Belkin router, acting as a bridge between the two.
>
> Everything works apart from Wake-on-LAN. A quick network trace with
> Ethereal shows the problem: the Squeezebox is broadcasting an ARP
> request to find the MAC address on its network segment associated with
> it's configured IP address for the Slimserver. Because the WGPS606 is
> bridging the wireless side and its built-in 4 port wired hub where the
> Slimserver is actually located, it correctly responds back with its own
> wireless MAC address. The Squeezebox then uses that MAC address to
> generate the Magic Packet and broadcasts it. The WGPS606 forwards the
> broadcasted magic packet to its wired hub side, but because it contains
> the MAC address of the WGPS606 and not the Mac Mini, the Mac Mini does
> not wake up.
>
> If I use a tool like the Magic Packet generator from www.depicus.com,
> configure it to broadcast a Magic Packet containing the Mac Mini's
> ethernet MAC address, and broadcast this from a laptop connected
> wirelessly to the Belkin router, the Mac Mini wakes up just fine.
> Similarly if I attach a Squeezebox via wired ethernet to the WPGS606's
> 4-port hub, it wakes the Mac Mini fine (since there is no bridging in
> this case, the Squeezebox's ARP request results in the Mac Mini's MAC
> address as the response).
>
> My question is: can the Squeezebox be configured to use a manually
> supplied MAC address (or one retrieved by the Slimserver software from
> its host) to generate the Magic Packet, rather than it using ARP to try
> and work out the MAC address of the Slimserver host?
>
> Would this require an enhancement to the Squeezebox firmware or
> Slimserver software?
>
> I'm sure anyone wishing to use a Squeezebox wirelessly and use the
> Squeezebox's capability to wake up the computer running the Slimserver
> software by using a wireless/ethernet bridge would greatly value this
> capability.
>

That makes sense to me. On a wireless product it should be possible to
set the MAC address manually.

Regards,
Peter

slimpy
2007-01-12, 09:18
That makes sense to me. On a wireless product it should be possible to
set the MAC address manually.
You can already set the SB's MAC address manually.
What Creeky asks for however is to specify the MAC address of the server in the squeezebox rather than using ARP to look up that address.
I don't know if that is feasible (needs to be in firmware) and I wonder how many people actually run into this kind of problem anyway.

-s.

peter
2007-01-12, 10:44
slimpy wrote:
> Peter;169571 Wrote:
>
>> That makes sense to me. On a wireless product it should be possible to
>> set the MAC address manually.
>> You can already set the SB's MAC address manually.
>>
> What Creeky asks for however is to specify the MAC address of the
> server in the squeezebox rather than using ARP to look up that
> address.
>

Yeah, I understand that. I just expressed myself a little vaguely.

> I don't know if that is feasible (needs to be in firmware) and I wonder
> how many people actually run into this kind of problem anyway.
>

It's feasible if you control the firmware. It could even be done
automatically I think. The slimserver knows the MAC address of the PC
it's running on. Slimserver could send it to the device when WOL is
activated. It's kind of strange to offer a wake on lan feature that only
works on the wire if you sell a device that's usually (my estimate,
should make a poll) used wireless.

Regards,
Peter

slimpy
2007-01-12, 11:01
It's feasible if you control the firmware. It could even be done
automatically I think. The slimserver knows the MAC address of the PC
it's running on. Slimserver could send it to the device when WOL is
activated. It's kind of strange to offer a wake on lan feature that only
works on the wire if you sell a device that's usually (my estimate,
should make a poll) used wireless.
It's not a wireless problem as such. Wake on lan works fine over wireless. The bridging on the server side is the culprit. If the server were hardwired to the router or had its own wireless card there wouldn't be a problem.
This kind of setup that's probably very rare (bridged server AND WOL).

-s.

Triode
2007-01-12, 11:39
Well if the print server is really bridging then it should forward the arp rather than respond to it...

It sounds like this is likely to be quite a rare configuration. Is there any way to turn off proxy arp on the print server?

peter
2007-01-12, 14:49
slimpy wrote:
> Peter;169632 Wrote:
>
>> It's feasible if you control the firmware. It could even be done
>> automatically I think. The slimserver knows the MAC address of the PC
>> it's running on. Slimserver could send it to the device when WOL is
>> activated. It's kind of strange to offer a wake on lan feature that
>> only
>> works on the wire if you sell a device that's usually (my estimate,
>> should make a poll) used wireless.
>> It's not a wireless problem as such. Wake on lan works fine over
>>
> wireless. The bridging on the server side is the culprit. If the server
> were hardwired to the router or had its own wireless card there wouldn't
> be a problem.
> This kind of setup that's probably very rare (bridged server AND WOL).
>

I thought most wireless access points were really wireless bridges.but I
must be wrong because my wireless laptop has the correct MAC for my
server in its ARP cache. Your conclusion would be correct that this is
very rare then. Learned two things today ;)

Regards,
Peter

Creeky
2007-01-12, 14:54
Well if the print server is really bridging then it should forward the arp rather than respond to it...
I don't believe this should be the case. An ARP request is basically the translation between OSI layer 3 (network layer, IP address) and layer 2 (data link layer, mac address). My understanding is that the correct response is for a bridge to provide its layer 2 (mac address) as a response to an ARP request for an IP address located on another segment bridged by it, as it effectively being asked to act as a layer 3 bridge at that point. For example (http://www.microsoft.com/technet/community/columns/cableguy/cg0102.mspx):

For unicast traffic, Layer 3 bridging is based on the Address Resolution Protocol (ARP). ARP is used by TCP/IP nodes to resolve the MAC address that corresponds to the next-hop address of an outbound IP packet. If the destination of the outbound IP packet is on the local subnet, the next-hop address is the destination address and ARP is used to resolve the MAC address of the destination node. If the destination of the outbound IP packet is not on the local subnet, the next-hop address is the default gateway address and ARP is used to resolve the MAC address of the default gateway (assuming that this is a typical host configuration).

On the other hand the magic packet is a layer 2 broadcast, which just contains target mac address repeated many times, and the bridge correctly forwards this to the wired network segment using layer 2 bridging.


Is there any way to turn off proxy arp on the print server?
Unfortunately not, and AFAIK that would not be correct behaviour for it to operate in that manner (see above). The Squeezebox is basically making a simplifying assumption that there is only one network segment by using a layer 3 query (ARP request) to determine the contents of a layer 2 message (Magic Packet). This works ok on a single segment, but fails in a multi-segment network.

The Belkin wireless router (as with most domestic wireless routers i guess) treats its wired and wireless sides as a single segment (effectively acting as a wireless+wired combined hub rather than a bridge), i guess to simplify things for home users. Hence if you do an ARP request on the router's IP address it will give the same MAC address as an answer from either the wired or wireless side. The WGPS606 on the other hand acts as a bridge rather than a hub, and has a wireless side MAC address and a wired side MAC address (two different segments).

Thus a Slimserver connected directly to the wireless router's wired hub will wake up as it is on the same segment as the wireless squeezebox, whereas in my configuration the Squeezebox and Slimserver are on different segments and the Squeezebox's simplifying assumption breaks down.


It sounds like this is likely to be quite a rare configuration.
Probably. However, I'm presuming the way the Squeezebox implements its wake on lan functionality will fail for anyone using a wireless/ethernet bridge or Homeplug bridges to extend their networks. I haven't tested any Homeplugs to confim they operate in this manner, but i'm assuming each homeplug will have a unique mains-side MAC address and ethernet side MAC, so will operate as a bridge rather than a hub.

The reason why i have this network setup is that my wireless router is in the hallway, as that's where the broadband connection is, whereas the Mac Mini hosting the Slimserver software is also used as a desktop machine in the 'office'. Since the Mac Mini (and pretty much every system i know of) only supports WoL on the ethernet port, i was hoping using a wireless/ethernet bridge would allow me to use the WoL feature. My guess is that whatever proportion of Slimbox users have their wireless router in a different room to their desktop running the Slimserver software (and the two not connected via ethernet) have probably given up on getting wake-on-lan to work.

I could of course leave the computer on all the time, but I'm trying to do my bit to save the planet. I could also go upstairs and turn the Mac Mini on when i want to listen to music, but it's not exactly the most convenient way of doing things even if it is good exercise ;-)

Before creating this thread I did a search of the forum, and there have been a few people trying to get a configuration similar to mine to work (e.g. do a search on "wake-on-lan wireless"), including http://forums.slimdevices.com/showthread.php?t=29110&highlight=wgps606, where someone claimed to have had success with a WGPS606 and WoL (i don't see how...), and another where someone else tried with the WGPS606 (http://forums.slimdevices.com/showthread.php?p=89317&highlight=wgps606#post89317) and failed.

Interestingly, one of the original threads asking about WoL support in the Squeezebox before it was implemented did mention a possible implementation where the MAC address of the Slimserver could be manually entered (http://forums.slimdevices.com/showthread.php?t=4231&highlight=manually)...

Triode
2007-01-12, 15:20
I don't believe this should be the case. An ARP request is basically the translation between OSI layer 3 (network layer, IP address) and layer 2 (data link layer, mac address). My understanding is that the correct response is for a bridge to provide its layer 2 (mac address) as a response to an ARP request for an IP address located on another segment bridged by it, as it effectively being asked to act as a layer 3 bridge at that point.

I was getting picky about the terminology. A _bridge_ forwards at OSI layer 2 and so should not particpate in any layers above this. A _router_ forwards at layer 3 and hence processes IP and ARP. Many of the home networking devices these days are actually routers.

So is it routing - are the IP subnets difference each side of the device and does it decrement the IP TTL for packets that pass through it?

me3
2007-01-12, 16:39
I have had the same problem, I have a Netgear DG834G ADSL modem router (again next to the BT telephone socket in the house...) with a wired SB3 connected directly to this, and this is wirelessly bridged to the upstairs "study" using a Netgear WGPS606 where the PC (hope to get a Mac Mini soon though......) is currently connected.

This works a treat, apart from Wake On LAN.

I gave up and just leave it on 24/7, but with electricity prices rocketing in the UK and much much more importantly environmental changes happening all around us, I am VERY keen to have this working to start saving energy.

I for one, vote for this feature.

Maybe our configuration is not so rare after all?

There may be many more readers of this forum (like me) who post rarely but read a lot for research into issues.

Stephen

Creeky
2007-01-12, 16:44
I was getting picky about the terminology. A _bridge_ forwards at OSI layer 2 and so should not particpate in any layers above this. A _router_ forwards at layer 3 and hence processes IP and ARP. Many of the home networking devices these days are actually routers.

So is it routing - are the IP subnets difference each side of the device and does it decrement the IP TTL for packets that pass through it?
Both sides belong to the same subnet, and the TTL is not decremented. Broadcast packets pass through it. On closer examination, the wired side is a switch not a hub.

Triode
2007-01-12, 17:32
So if the server is on the same subnet it is ligitimate to assume you can arp for it and get the mac address of the device. [Bridges should not respond to arps for devices.] However you shouldn't arp at the time of the wake up operation as the server is off and hence probably doesn't respond [you need to arp when the server is working and store the mac address].

For routers there is definately a problem and I'm not sure it is easly solved. From http://www.liebsoft.com/index.cfm/whitepapers/Wake_On_LAN WOL requires a magic pattern based on the devices mac address within the protocol payload. So assuming:

Squeezebox [Subnet 1] -> Router -> Server [Subnet 2]

If the squeezebox knew both the IP address and MAC of the Server it could send the magic packet to the router's mac which is its default gateway, but assuming the server has been off for a while, the router would have lost the arp entry for the server and hence would not be able to forward the packet. It would send out arps onto the server subnet for the server, but these do not contain any data from the packet which triggered them and hence would not wake up the server as the server does not receive the magic bit pattern.

To wake up the server in this case would probably require a static arp entry in the router [i.e. static config for this in the router], or something more esoteric such as sending out directed broadcasts for the target subnet and having the router support this (which would not be common or need explicit configuration).

In short making it work for routed networks is definately going to be harder and is likely to require specific support/configuration in the router as well as the squeezebox knowing both the IP address and mac of the server.

Creeky
2007-01-12, 18:41
Bridges should not respond to arps for devices.
If you take a strict definition of a bridge or switch as a layer 2 device, then yes. There are however many 'layer 2' devices out there though which also implment some layer 3 functionality, but are not strict layer 3 routers either. As you point out it's not really in the spirit of a pure OSI model, but then given we live in an imperfect world, it's generally best to work around the imperfections i think.


However you shouldn't arp at the time of the wake up operation as the server is off and hence probably doesn't respond [you need to arp when the server is working and store the mac address].
Interestingly the Squeezebox appears to issue ARP broadcasts almost every second, even when it has been put into standy with the power button on the remote. Running an 802.11 radio when you're in standby seems rather a waste - i haven't checked yet if there is a way to disable that.


For routers there is definately a problem and I'm not sure it is easly solved. From http://www.liebsoft.com/index.cfm/whitepapers/Wake_On_LAN WOL requires a magic pattern based on the devices mac address within the protocol payload. So assuming:

Squeezebox [Subnet 1] -> Router -> Server [Subnet 2]

If the squeezebox knew both the IP address and MAC of the Server it could send the magic packet to the router's mac which is its default gateway, but assuming the server has been off for a while, the router would have lost the arp entry for the server and hence would not be able to forward the packet. It would send out arps onto the server subnet for the server, but these do not contain any data from the packet which triggered them and hence would not wake up the server as the server does not receive the magic bit pattern.

To wake up the server in this case would probably require a static arp entry in the router [i.e. static config for this in the router], or something more esoteric such as sending out directed broadcasts for the target subnet and having the router support this (which would not be common or need explicit configuration).

In short making it work for routed networks is definately going to be harder and is likely to require specific support/configuration in the router as well as the squeezebox knowing both the IP address and mac of the server.
Sure, but I'm not asking for a super-duper Squeezebox routable WoL implementation. All i'm asking is that the user be able to supply the Squeezebox with a Mac Address to use for the Magic Packet, to cover the vaguaries of domestic layer 2 kit which implements some layer 3 functionality. This could be done entirely in firmware, via the Squeezebox settings and remote, or via the Slimserver web, or both. I don't really mind which. I'd have thought this should be a fairly simple thing to add, and should provide a viable solution for those users wishing to add a wireless/wired or homeplug bridge to support WoL but finding their bridging kit doesn't work as planned because it proxies arps.

Having spent quite some time researching others' comments on this subject in the forums, my gut feeling is that there is a reasonable minority who wish to use WoL but can't at the moment because they can't plug their Slimserver into their wireless router's ethernet ports and find bridging does not work or have been put off from trying because of the lack of success reported in the forums. I can't quantify this of course, but i do appreciate me3's vote of support :-)

slimpy
2007-01-12, 19:29
Interestingly the Squeezebox appears to issue ARP broadcasts almost every second, even when it has been put into standy with the power button on the remote. Running an 802.11 radio when you're in standby seems rather a waste - i haven't checked yet if there is a way to disable that.
There's no standby mode in the squeezebox. It is always on. The "off" state is just another mode of operation.
Anyway, to make sure you get slimdevice's attention and for easier tracking I suggest you file an enhancement request at http://bugs.slimdevices.com

-s.

Creeky
2007-01-13, 12:47
There's no standby mode in the squeezebox. It is always on. The "off" state is just another mode of operation.
That's a shame considering I measured the Squeezebox power consumption at 5-6 Watts without the display lit. The two squeezeboxes i've just bought will now constitute 10% of our household's base (24x7) electrical load, unless i unplug them after use.


Anyway, to make sure you get slimdevice's attention and for easier tracking I suggest you file an enhancement request at http://bugs.slimdevices.com
Thanks for the tip. I've logged it as http://bugs.slimdevices.com/show_bug.cgi?id=4664, for anyone that wishes to vote for it.

me3
2007-01-13, 14:46
Vote added......Thanks for raising that bug.

I had a suspicion that the Netgear WGPS606 (wireless bridge) was the problem as if I go to "attached devices" on the Netgear ADSL modem router DG834G it shows hostnames attached to the WGPS606 with MAC addresses of the WGPS606, ie the MAC of the wireless bridge.

I really think it would be of great help to have the WoL MAC address configurable via the remote or via web interface and implemented in firmware.

Stephen

jtuliani
2007-02-12, 04:43
I also have a bridged network using a Netgear WGPS606. Other than this WOL issue, it's a fantastic setup.

I support the comment that what is required is for the server MAC address to be configurable in the squeezebox--enhance the squeezebox firmware to support this and the slimserver interface to support the administration side.

If I connect a laptop with a WOL client to the same network segment as my SqueezeBox, by default it picks up the bridge MAC address. If I manually configure the server MAC address in the WOL client, WOL works just fine.

It's not a routing problem--the WOL packet is passed on properly by the bridge. The problem is that the WOL 'magic packet' actually contains 16 copies of the MAC address in its body, and without these the server doesn't respond.

Jonathan

oreillymj
2007-02-13, 04:56
Not sure if I fully understand your exact setup, but have you tried the following.

Use a static I.P. on your Squeezebox and set the Mac Mini as the Def Gateway. I would expect the magic packets to be sent to the Def. Gateway for routing and since that's what you're trying to wake, should work.

...or if you're print server server port forwarding,setup a virtual server redirecting all UDP port 9 traffic to the static I.P. of the Mac Mini. That would guearentee that any WOL packets broadcast on the network get redirected by the router to the Mac Mini's I.P.

AFAIK, the lan card is still kept active (it has to be to "hear" the WOL packets) when the system is asleep, so a router with a machine in standby attached still "see's" that port as active and will not forget the routing information associated with that port.

jtuliani
2007-02-13, 09:21
It's not a routing problem. The magic packets get through the bridge to my server (a PC, not a Mac) just fine.

The problem is the CONTENTS of those packets. WOL Magic Packets must *contain* the MAC address of the machine they're trying to wake up (see http://en.wikipedia.org/wiki/Wake-on-LAN#How_it_works).

The SqueezeBox only 'sees' the MAC address of the bridge, and *assumes* this is the MAC address of the server, so that's the address that goes into the Magic Packet. I need to be able to override that assumption. (It's a bit like the way NAT hides your IP address, but with MAC addresses instead.)

Jonathan

alter_sack
2007-02-16, 11:05
I voted too, because i have the same problem with my Wlan-Router.

Black Pearl
2008-06-23, 13:43
I agree with the cost of running a pc 24/7 a WoL feature on the Sqeezebox would be fantastic. At present I have to either go upstairs, open a cupboard and prod the desktop into life (no real problem but hardly in keeping with SB spontaneity) or fire up the laptop and use Magic Packet Sender to get things running.