[SOLVED] Help with oddball WoL issue (networking pros apparently)

klepp0906

Distinguished
Apr 29, 2013
150
0
18,710
Well, with my rudimentary networking acumen and a few thorough sessions of google-time, im throwing in the towel.

I have an application that chooses some crazy arbitrary port to send its wake on lan packet. 30564. The developer says this port was chosen as its the same port said software uses for everything else it does. Naturally, everything else works fine. (its a km/kvm software)

Wake on lan is enabled and does work outside of multiplicity (the software). I can use it with several other apps fine, barring the one thats misbehaving. (the other apps use port 7 and/or 9 as i believe that may be pertinent)

I tried a clean boot. i tried with windows firewall disabled. I even tried with the gateways firewall disabled.

The craziest part? It works in the other direction. AKA pc1 cannot wake pc2 or pc3 if using said application/port. It can with all other apps/ports tried.

pc2 can wake 1 and 3 however (on trouble port) and pc3 can wake 1 and 2.

I dont even know where to go from here or what my next step in the process would be? Anyone got anything for me?

I tried a wake-on-lan monitor type software and as expected - registered nothing on pc2 when it was sent from pc1. Its just not getting there for some reason.
 
Solution
So capture the packets with wireshark and see if they are valid. Wireshark can detect the WoL string in a packet.

In many cases the problem is microsoft. Wake on Lan was a OS independent standard. Microsoft got involved with their own proprietary power saving modes. Some bios manufactures started to support things. You now have a mess where the OS can reset things rather than going into the bios to set stuff like this.

Make sure that the Bios is correctly setup. Be very careful how you shut the machine down so microsoft does not change the settings

Most the issues are idiots who have no true networking back ground write apps. You see these apps send packets to the mac address of the machine rather than the broadcast mac...
What are you talking about. Wake on Lan has no concept of port or IP address. The packet format is a packet contain the mac address of the machine to wake in a special format. It is sent to the broadcast mac address. So all machines will receive this and look inside and see if it is their mac address.
 
Apparently myself (and the developer of the app) had no idea. Nor the people that allow you to choose a port within their wake on lan apps. Go figure.

but really though. If i knew, i wouldnt be asking for help.
 
So capture the packets with wireshark and see if they are valid. Wireshark can detect the WoL string in a packet.

In many cases the problem is microsoft. Wake on Lan was a OS independent standard. Microsoft got involved with their own proprietary power saving modes. Some bios manufactures started to support things. You now have a mess where the OS can reset things rather than going into the bios to set stuff like this.

Make sure that the Bios is correctly setup. Be very careful how you shut the machine down so microsoft does not change the settings

Most the issues are idiots who have no true networking back ground write apps. You see these apps send packets to the mac address of the machine rather than the broadcast mac. It all depends on if the BIOS accepts a non standard wol lan packet.

Again a WoL packet is send to the broadcast mac address. It contain 6 bytes of "FF" followed by the 16 copies of the mac address. Anything else is non standard and the bios may or may not support it.
 
Solution
thanks for the information. I did as much cross checking as i could.

I cant really peg it as the app being the problem, as it works from the other pcs.

I cant really peg it as it being a limitation with the bios/config on the pc's as they can all wake one another barring this one pc, in one direction (consequently/naturally my main pc)

I cant peg it as my nic not sending for whatever reason as other apps work to wake the other pc's fine. (albeit sent on a different port)

Im perplexed.

I have heard wireshark mentioned a gazillion times over the years. I never had a need for it so never delved into it. Figured it might have been over my head anyhow. I'll take a look and see if i can figure it out and if it'll provide me something I can go on.

thanks again
 
What you want to do is run wire shark on the machine that does not wakeup. Obviously you have to do it when the machine is running but what you are looking for is does it actually receive the packet. Next you want to look at the packet and see if the mac address is the broadcast mac or is the actual mac of the machine.

Part of the reason WoL specifies it is the broadcast is so the switch/router sends it to all ports. Many times the actual mac addresses may not point to the correct port in the switch. This normally is not a issue for traffic when the machine is active because the remote device wills send a ARP and when the machine responds the mac will again be mapped. Because the machine is not actually active it will not respond to ARP requests.

WoL has always been a bit flakey mostly because of BIOS issues. What tends to work much better is boot on power. This used to be expensive because of the cost of remote power devices. Now days you can get all kinds of electrical outlets you can control with apps. These you can even activate from the internet unlike WoL.
 
I have some thin clients that fall asleep if I forget to shut off their auto-suspend and needed a way to wake them up via wol. I couldn't find anything that worked well except this command line version. It also allows you to choose the port number:
https://www.depicus.com/wake-on-lan/wake-on-lan-cmd

It doesn't always work on the first shot (not sure if it's the thin client or the program or the firewall), but if I repeat the command enough times (usually 3-9x), the thin client does wake up. You might find it useful for your situation as you can change the port number from the default.
 
@bill001g if nothing else, i at least understand the under the hood goings on of WoL better now. I dont doubt given enough time ill get this sorted. Good reason/opportunity to force me into finally looking into wireshark. Given how long its been around and the praise it gets, i dont doubt its quite useful.

@SamirD that actually will be helpful, just to reinforce the process of elimination. Was looking for something like that, and figured it existed :)

thanks again guys. I'll be sure to post back when I find out the crux of the issue - or at least make some headway.