Triode Wrote: > 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.
Triode Wrote: > 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. Triode Wrote: > 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 :-) -- Creeky ------------------------------------------------------------------------ Creeky's Profile: http://forums.slimdevices.com/member.php?userid=9566 View this thread: http://forums.slimdevices.com/showthread.php?t=31561 _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
