I'm in an environment with subnets and trying to get WOL to work with LDMS 9.0 SP2 using the WAKE UP option available on RIGHT-CLICK within the NETWORK VIEW.
I should preface by saying that my clients are setup to work with WOL and have done so for many years when I had a different management console residing on the same subnet. That is to say that if I use this OLD TOOL now, as it is still present and unchanged from the past, I can wake up my computers. So I know the clients are fine. In fact we retested this just to confirm the clients were all setup and they were.
Regarding the network, the LDMS core is on a different subnet from the client computers but that server has been configured as an IP Helper on the client subnets. Additionally, UDP ports 0 and 7 are set to forward from the LDMS Core to the subnets where the clients live. Yesterday my network admin tested WOL across the subnets using a SolarWinds WOL tool and Wireshark to see the traffic. The SW WOL tool was running on the LDMS core and Wireshark was on a client computer on a subnet. An adjacent computer was the target for WOL and when the WOL command was issued we observed the magic packet traffic via Wireshark and we observed the target machine wake up as it is supposed to do. Using LDMS 9.0 SP2 in that same scenario we were unable to wake up any machines.
It is worth noting that between the old client management software, the Solar Winds WOL tool, and LDMS 9.0, we observed traffic from all three whenever we issued WOL commands, however all three tools generated DIFFERENT packets. Said another way, the packet captures in Wireshark showed 3 distinct packet signatures such that we could do a blind test free of IP address and other external information and simply look at the packtes then be able to identify which tool they came from. And in the end the LDMS WOL packets did not do their job when the other two did.
-does anyone have any information that may help me figure out how to configure WOL to work in LDMS 9.0 SP2?
I thought this was something that just worked with default settings out of the box, but obviously I was wrong.
BTW, we were using UDP port 0 for WOL because that was default, but absent the desired effect we tested port 7 but got the same result...
LANDesk can't wake a machine on another subnet. There used to be a 3rd party plugin (MarXstar) but it is no longer developed. There is an ER for this: http://community.landesk.com/support/ideas/1638
is this statment really true?
"LANDesk can't wake a machine on another subnet"
do you mean to say that Landesk somehow sees that a machine is on a different subnet and it just gives up without even trying?
Our network is configured to allow WOL packets to be sent from the Landesk Core Subnet to our other subnets; of the tests I described the one with the Solar Winds WOL tool was performed from the landesk core. Said another way, the landesk core server successfully woke up machines on other subnets without error...of course it did so WITHOUT the landesk software.
For what its worth, that ER doesn't really address the simple WOL functionality that I need and appears to already be present, which is having the core issue a WOL packet for a local area network. If the core can put out the correct WOL packet then my local area network can route it to the the target machine...right now it appears that the magic packet is not being sent....
I'm not sure about this but I think that if you are running the Management console on your computer and try to wake up a computer the WOL packet is sent from your computer, If the WOL is part of a scheduled task then the core is what sends the packet.
your two statements align with documentation, Kurt...so I believe you are correct.
....but what I am getting at is that the WOL functionality simply doesn't work. While the focus here is on getting it to work from the core side, its also worth pointing out that it doesn't work for a remote console either.
When we ran Wireshark and tried to use the WAKE UP feature in the console we observed ICMP pings from the landesk core but no UDP traffic on either ports 0 or 7. Conversely we DID see such traffic when using the Solarwinds tool on the core server. My best guess is that LDMS 9.0 IS NOT sending the correct traffic.
I referenced this document in hope of getting at the answer:
but I simply don't understand how LDMS can be failing at this when the other tool is working as both tools are supposed to be sending the same INDUSTRY STANDARD magic packets...
Don't know if this method is a feasbile workaround but in our environment we assign a machine as a MDR on that subnet, and use mulicast with wake on lan option checked in the delivery method, which seem to work. The down side with this method is that a MDR is needed for each subnet for WOL to work.
For your problem, i have a idea.
So you tell that 3 tools make 3 differents packets.
I don't know if you know magic packets, it's only the mac adress send 3 time on a network. Each network card receip his own adress 3 times, wake up and go.
So packets can contain other informations (to fill query for network) but only the mac adress is important.
Otherwise, if you make right clic on a device with your remote console, the magic packet is send by your PC.
If you make right clic on a device with console of Core, Core send magic packet.
Knowing that, you have two WOL different :
1/ If you make right clic (explain up)
2/ if you make a task with wake up active.
If you make a task with wake up, default method want to Core send magic packet, always Core, not your remote console.
If you wan't that a MDR send a WOL, you must configure method in 'multicast domain' section, check MDR wake up the device on WOL.
If you do this, WOL with MDR, if you configure a device to be MDR (just drag and drop in MDR in configuration section, on view of device, but i think that you have already know this) Choose one MDR by subnet, for no problem
If you launch task, MDR wake up your device.
A other way, if you wan't Core wake up your device, you must configure with your network admin to active broadcast, come from Core IP, to all subnet (i do this on my enterprise).
And to finish, If you want to wake up device with your remote console (right clic on device), you must do the same : active broadcast from your IP, on all subnet.
One of our customers is having the same problem with LDMS 9.0SP2. Magic Packet send with a third-party tool from the core server works fine. Doing a Wake up using the LDMS Console and nothing happens. Both are using UDP Port 0.
at least this is confirmation that someone else is having the same problem
Unfortunately, Cedric's post doesn't really help -> seems like he couldn't understand my post and so what he put out is generic and not really helpful in this point, which is:
clearly the network is configured correctly to support WOL, yet LDMS isn't playing with WOL.
I say this simply because tests from the core server with a different tool are indeed able to wake up the clients when they are on a different subnet. I have LDMS configured to use UDP PORT ZERO for WOL packets, yet wireshark sees the traffic and it ISN'T DESIGNATED FOR PORT ZERO. Other tools send PORT ZERO traffic and wireshark verifies this.
I need to look more into this MDR thing and see if setting up one of those will help. Why does something so simple have to be way too complicated?
I just tried this on my LDMS 9 SP2 core. I opened the console, right-clicked a machine that was off, and selected Wake up. I was running Wireshark on my Core for the whole thing. I was able to see the WOL packets get sent. For a filter I just put "wol" (apparently lowercase is important). There are two packets there.
Both of them are UDP with a source port of 57611 and a destination port of 0.
Does anything come up in your Wireshark if you use "wol" as the filter?
You also say it isn't designated for port zero. Can you tell what port it is going to?
So it is interesting that you say both of the packets sent from LDMS are UDP?; by applying the filter for WOL are you not implying that those packets are WOL type?
I've just re-run my tests and here are the results
LDMS sent two packets using WOL protocol; each have a source port of 2121 and a destination port of 0
SolarWinds sent two packets using ECHO protocol; each have a source port of 3028 and a destination port of 7
Symantec sent two packets using WOL and UDP; source of 1347 and destination of 1346
from one of our network guys:
"In configuring the network, I configured the LANDesk server as an IP Helper on the client subnets. I also configured the following lines: "ip forward-protocol udp 0" and "ip forward-protocol udp 7". This allows the helper to have it's broadcasts forwarded to a different subnet."
additional testing had us attempt to wake up a client on the same subnet as our landesk server; while we could see the two LDMS packets in wireshark, we did not observe the machine to power on as expected.
When I use the WOL filter in Wireshark, it is actually filtering the packets by examining the actual payload of the traffic. In this case it finds the "Magic Packet" and therefore it is WOL type and I can use that filter. The packet is still transmitted using UDP. UDP is the counterpart to TCP. They compose the transport layer in the Internet Protocol suite and are used for the vast majority of traffic in an IP network. So... UDP is used to transmit the WOL traffic.
This is similar to the HTTP filter in Wireshark. I can use that filter to find only HTTP traffic, but that traffic still uses TCP underneath. In that case TCP is used to trasmit the HTTP traffic.
I'm not a network engineer, so I can't speak to how your network guy has configured stuff :(. As you and I saw in Wireshark, LANDesk is sending the WOL/Magic Packet. That packet is sent to the broadcast address via UDP to port 0.
You can also put Wireshark on any machine on the target subnet and you should see the packets come through from the LANDesk Core there as well.
It sounds like there is something different about the packets from the other products, or the NICs in the devices are expecting something different or extra to wake up. Maybe try changing the port to match the other tools? Maybe some side-to-side comparison of working and non-working magic packets will show a difference.
Just a note - the MarXtar product referenced is wake-on-wan and is now available again via our website.
The One-Stop Shop for LANDesk Enhancements
We are having the exact same problem.
I am sending the WOL packet from the core to a client on the same subnet and it does not work. But if we use a 3rd party tool it works without a problem. I have configured the 3rd party tool and landesk to use the same port. We installed the Marxtar product and it works fine. when i send the WOL from Marxtar it shows that it is using the landesk core server as its WOL rep!
We ran wireshark on this process and also found some strange results. the core has an address on subnet 10.1.100.x and the client is on the same subnet. But according to wireshark the "destination" is 10.1.19.255 which is the top edge of our primary client computer subnet. and Landesk sees the client as on'the 10.1.100.x subnet. Why is it trying to send this to another subnet when all related parties are on one subnet?
thoughts: domain controller lives in the 10.1.19.x subnet, could that be related?
Anyone got any ideas?