Port 30564

ah, well that could be where the hang up is.  we shall see.  I know most use 7 or 9 right?  why the deviation from the norm?

I still havent gotten to testing, but i will soon and report back with the results of course.  

Once thats working all salt will have left the table

Delted my one post by accident but yes, I stand corrected, the port is 30564.

I used this on my Secondary:

https://apreltech.com/Blog/Wake_on_lan_Sniffer

Had it running and used this to send a WOL packet:

https://www.microsoft.com/en-us/p/wake-on-lan-magic-packet/9nblggh51pb3?ocid=9nblggh51pb3_ORSEARCH_Bing&rtc=1&activetab=pivot:overviewtab

As well as MP:

This was the result for MP:

The tool to troubleshoot Wake-on-LAN. www.apreltech.com
(C) 2016, AprelTech
Sniffing is started!

The tool to troubleshoot Wake-on-LAN. www.apreltech.com
(C) 2016, AprelTech
Sniffing is started!
---------------------------Wake-On-LAN Magic Packet---------------------------

Time received:
03/10/20 15:46:28
UDP Header:
|-Source IP : 10.9.15.55
|-Destination IP : 255.255.255.255
|-Source Port : 53035
|-Destination Port : 30564
|-UDP Length : 110
|-UDP Checksum : 37158
MAC Address:
5C F9 DD 98 86 4F
Raw Data (102 bytes):
FF FF FF FF FF FF 5C F9 DD 98 86 4F 5C F9 DD 98
86 4F 5C F9 DD 98 86 4F 5C F9 DD 98 86 4F 5C F9
DD 98 86 4F 5C F9 DD 98 86 4F 5C F9 DD 98 86 4F
5C F9 DD 98 86 4F 5C F9 DD 98 86 4F 5C F9 DD 98
86 4F 5C F9 DD 98 86 4F 5C F9 DD 98 86 4F 5C F9
DD 98 86 4F 5C F9 DD 98 86 4F 5C F9 DD 98 86 4F
5C F9 DD 98 86 4F

I had to shut off my firewall to have the sniffer see it, however - I dont suspect that will need to be the case for the NIC / Motherboard to respond but it will show you if the packet is being received..

Sean Drohan
Stardock Support Manager

 

 

thanks for that ^ 

should be plenty to run with!

well, at least i know the issue now.  

its not getting the packets.  nada. zilch.

I disabled firewall on the primary and secondary just in case.

tested using the same two apps as you, gets them over port 7 from Magic Packet (hence it working).   Does not get them from multiplicity (hence the not working part apparently ;p)

what would you suggest?

adding an option to choose your port might not be a bad idear for future iterations /shrug

 

this is one of those scenarios id then assume it was port related, yet it works fine if i swap roles between primary/secondary.

So i am at a complete loss as why its not working from 1 specific app over 1 specific port in 1 direction.

im at your mercy.

Modify the port in the registry to one you know is working. 

hmm if this is possible, it sounds like its worth a fair shot.

Do you know if a string actually exists to do so or?

the only part that still troubles me is that it works over the crazy 305xx port if i swap roles and send from my secondary to my primary.  

if something was filtering that packet it wouldnt be doing so in one direction.

makes 0 sense to me. 

As I understand it, the OS / port is not involved on the receiving end, the MAC/NIC/motherboard are, for WOL to work.  The port's only relevance here is for these tests when the OS is active - to see if they are indeed being sent/received.

And that is his dilemma - one cannot say for certain what end is failing, the sending or receiving.  

klepp, you are absolutely certain this is checked (re un-checked - checked), yes?

Sean Drohan
Stardock Support Manager

It's been two years since I have dug into MP. I yeild to Sean's knowledge. 

yes, i re-toggled them just to be sure.  ive tried to wake via the tray button, and the gui button.  tried against both secondaries.

I can wake them fine/see the packet with anything but multiplicity. (of course they operate on different ports)

Im not sure which end the port itself affects between send and receive but i know changing the sniffer from say 7 to 9, when I have magic packet set to 7, results in not getting the packet (or at least not seeing the packet) via the sniffer.

So i gotta assume that would be the next test is changing the port, if there were a means to do so.

Im no developer so I honestly have no clue, but why was the industry standard which is 7/9  (not necessarily required apparently but still the standard as talked about here https://superuser.com/questions/889942/does-a-magic-packet-need-to-be-sent-on-a-specific-port-for-it-to-work) tossed to the wind? 

for all i know with a choice of thousands of ports, for some reason this obscure choice is being blocked by the gateway, the isp, who knows at this point, not I.

With acumen bordering on rudimentary, changing it is the only "next" test I can think of. 

of all features to have a problem with lol.  I'd argue WoL is one of the simpler ones.  Sigh. 

reading here, depending on which method it uses - i might have to forward a port it sounds like.

https://superuser.com/questions/889249/does-wake-on-lan-via-wan-needs-port-forwarding

next version totally should allow choice of port, or use the standard (unless theres a reason it doesnt) 

of course, that could have zero to do with my issue, but its all i got.

actually, i have one more idea.  If i can find a wol app that doesnt use 7 or 9, and allows you to choose - i can choose the port multiplicity uses and see if its received by my secondary. 

so im still working on this.  if i run a 

telnet 192.168.1.2 30564    on my primary computer 

i get back MULTIPLICIT5CexxepjO

if i run it on my secondary computer to my main pc's ip address, i get nada.

does this signify anything?

is the random letters following MULTIPLICIT some kind of hash?  Is the secondary not communicating over the port due to it being non-primary and the port only being open from the primary in one direction? 

must...get..this..working

also noticed on the apps that DO send wake on lan packets that are properly received, that app is set to send on 7 (or 9) and its always received on what seems to be a random port > 50000

each time i send another packet, the port seems to go up by 1. 

so given that information, do i have a means to find out if its the receiving port, or the sending port thats causing the struggle?

I assume 30564 is the port its sent from, and it leaves my pc - hits my switch - and comes in through some other port randomly assigned by my switch?

my networking is preeeeetty non existent

hmmm.  more maybe relevant stuff? 

i did a netstat -a and its showing  TCP    192.168.1.2:30564      MY-PRIMARY:24439    ESTABLISHED

on the secondary.

does that mean something?  

 err after reading your reply, thats what it "would" show as that port its what multiplicity uses for everything it sounds like.  and since everything BUT wake on lan works.....

#grumble

You will get nothing from connecting to the primary from the secondary because it is not listening on that port.  Only secondaries will do so.

It sounds like something on your setup is assuming WOL packets are port 7 or 9 but this is not a requirement.  We used 30564 because that's the port in use by Multiplicity so for consistency it was used.

any way to change the port it uses for WoL via registry or something?

or perhaps ill look for a WoL app that allows me to select a port apart from 7 or 9.

What would it be that has the ability to only watch on those ports for magic packets?  That doesnt even hold up as if i switch pc2 to the primary, it can wake 1 and 3 with multiplicity.   but 1 cant wake 2 or 3 except for with other apps.

 

ty for the reply btw

 

little more info in case its helpful and im zzzz for the evening.  sadface.

So netstat -ano | findstr :30564 on primary returns

TCP    0.0.0.0:30564          0.0.0.0:0              LISTENING       4288

  TCP    192.168.1.1:33696      192.168.1.2:30564      ESTABLISHED     8944

  TCP    192.168.1.1:33697      192.168.1.2:30564      ESTABLISHED     10360


on the secondary it returns

  TCP    0.0.0.0:30564          0.0.0.0:0              LISTENING       4344

  TCP    192.168.1.2:30564      192.168.1.1:33696      ESTABLISHED     4344

  TCP    192.168.1.2:30564      192.168.1.1:33697      ESTABLISHED     4344


PID on primary are as follows

MultiSrv.exe

MP2Control.exe

Multipl2.exe

PID on secondary are 

MultiSrv.exe


I imagine thats all proper but JIC

 

i ask on another forum.  this is what i get.  I got nothin.   People have pointed me to wireshark but im close to tossing in the towel.  mac address is the first thing i looked at, and its the same as it is in the other apps and via ipconfig on the secondary.

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.

worth noting.  did a windows in-place upgrade today.   as close as ill ever get to a brand new windows.   Still no bueno.

and the initial consensus was proper.   Finally figured it out.   Using a command line WoL applet i was able to ascertain the pc was getting packets over that port.   Still couldnt figure out why it was then, not waking.

So did an arp -a which showed some IP not assigned by me as first, then my IP.   I thought that was odd so re-did a Get-NetIPInterface in powershell.

Now remember, my networking is almost nonexistent, so someone please enlighten me on this (even now that i know its NOT the case, i'd like to understand why).

My initial confusion derived from the fact that my Virtualbox Network Adapter was given a metric of 25.   My Local Area Connection was given a metric of 5.

I checked that off the list as having highest priority and moved on.

Turns out I have Local Area Connection at 5.  I have Ethernet at 25.   Well evidently local area connection is not my physical adapter and ethernet is.   A conflict between ethernet and virtualbox both at 25 seems the crux of the issue.  for some reason even though its lower alphabetically, its putting it first.

After this post im going to pump up the vbox adapter and be done with it.

I'd like someone to explain to me the difference between local area connection and ethernet in this context though.  Just so i better understand what im looking at. 

Occam's razor once again more or less.  Sigh.  Weeks...  weeeks for something that could have been resolved in day 1.  Its nobodies responsibility but my own, but had someone in the know asked for a screenshot of Get-NetIPInterface, id imagine much embarassment could have been saved.

Best and worst day ever

oh, and here.   https://www.virtualbox.org/ticket/8698#comment:4

 

this has been an issue with them for almost a decade.   Newest post was from January 2020 i believe.  #boggle

So WOL with MP is now working for you?

Sean Drohan
Stardock Support Manager

yep, just tested it on both secondaries.  just inflated the vbox adapter to 45 and flushed the arp cache.  all is well.

though arp is still populating with the vbox adapter first, it seems to be inconsequential.  Though im poised to remove virtualbox alltogether at ths point.   I rarely use it in lieu of vmware and the latter has never caused me any issue and doesnt have a conflicting interface metric.

Either way,  solved.  at long last.   Was more painful than it should have been but the sliver of "bright side" apart from it now working of course, is the darned frustration and misery made the glory and relief that much more profound lol.

very few gripes left with multiplicity now.    thanks for dealing with my abrasiveness over getting broken in with it.