wol wake on directed packet wake on magic packet

#Wol wake on directed packet wake on magic packet driver#
#Wol wake on directed packet wake on magic packet mac#

I don't have that particular brand of Optiplex, and it sounds quasi-new enough not to need it. There is a checkbox under the Power Management tab (in the Properties) for let this device wake up the computer (something like that.) Make sure that's actually checked (by default, it isn't.) And you have to enable this for each device separately, so it might be enabled for the onboard, but not for the addon card. I've also a general WOL.EXE program that I run separately at times too (scripted to WOL.EXE macone WOL.EXE mactwo.)Īs for why the 3C905 card isn't WOL'ing. And it does it for both/all NICs it knows the client has.

#Wol wake on directed packet wake on magic packet mac#

Hope that helps you diagnose what's going on I'd be interested in hearing what you discover from the packet trace.Īs you've found, Ghost sends both the specific MAC for WOL and the general broadcast MAC address for WOL as well. On the other hand, some networks filter all forms of broadcast, making reliable use of WOL completely impossible however during the GSS2 project we got enough feedback that customers did have networks like this that we try both.įurthermore, each WOL packet generally only contains the 'wakeup' signal for one MAC address the configuration server will generally know the MAC addresses of all the adapters in the client machine, and it will generally try and generate one pair (one subnet-broadcast, one unicast) of WOL packets for each MAC address it knows for a client. In a sufficiently dense network, DHCP can have reassigned the IP address used by the client so that the upstream switch will not have the right remembered association to send any unicast packet to the right switch port, so the only reliable method of wrapping WOL packets is to use some form of broadcast. The b) part above is problematic, by the way. The IP addresses the WOL packets are wrapped in matter only insofar as the WOL packet needs to be a) routed to the right subnet, and b) directed to the right switch port. The exact algorithm for the WOL packets is a little complicated, because the WOL packets contain MAC addresses (and are processed by the NIC hardware) and therefore don't care about IP addresses.

#Wol wake on directed packet wake on magic packet driver#

Instead that's about other parts of the system, mainly wrangling the components relating to the console's 'Configuration' system - unfortunately designed to only apply settings to one NIC - and to help guess which NIC hardware to build support for in the virtual partition since the DOS TCP/IP code can only load a driver for one NIC.

There is specific code in the GSS2 clients now to handle multiple NICs better, but that's not actually to deal with the client/server communications. Indeed, the actual client code has always supported multiple network interfaces in the machine, back to the very first version. We don't specifically do anything to control that in my experience generally the TCP/IP stack in the client machine will use the IP address of the interface it is using to communicate with the server, and so it should all work out just fine. The address the Configuration Server uses for the WOL packet is generally the last IP address used as a source address in UDP packets sent by the client machine to communicate with the server that's been the case since we added WOL support (which was a long time ago, possibly Ghost Enterprise 6.5).