Wake on LAN and bridged networks

[Creeky]

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]

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]

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]

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]

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]

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]

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]

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/com...uy/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/showth...hlight=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/showth...s606#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/showth...light=manually)...

[Triode]

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]

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