Comments (3)
Further debugging info:
By looking at sol.exe's output and sending magic packets from MikroTik and UDP packets from another machine, I have discovered that magic packets from MikroTik are not received at all.
On the other hand, if I try to send an ordinary UDP packet from my other windows machine to this machine's IP, then I can see that the packet is received.
But this sounds wrong.
My LAN's broadcast IP address should be 192.168.173.255, right (192.168.173.0/24)?
Then, why is sol.exe listening on my machine's IP 192.168.173.18?
This looks to me like sol.exe is listening on unicast IP address, not broadcast IP address.
Furthermore, judging by the XML output from REST interface, sol.exe's network calculation is wrong. It shows:
<host ip="192.168.173.18/16" mac="fc:aa:14:2b:58:ea:00:00"/>
But, my network is not /16 but /24.
Hope this helps.
from sleep-on-lan.
Have to investigate this further, but the "hosts" list in the REST dump (or in logs on start) is just what the go program is reading from the default network interfaces on the host (in order to easily retrieve the MAC address), nothing is computed / changed, and the program is just supposed to listen to everything broadcasted through UDP on :7 (or any other configured port).
from sleep-on-lan.
I think I know the solution to this issue, or at least why it doesn't work. I was just troubleshooting why I wasn't able to use etherwake to sleep a Windows using SleepOnLan.. After a while of troubleshooting I sent the same backwards-mac from an Android app, from which it worked. I then opened Wireshark and sent the same wol packets from both etherwake and the android app. What I noticed was that etherwake doesn't seem to send the wol to the actual broadcast address of 192.168.1.255.. Even if explicitly told to send to 192.168.1.255, the wol packet is only sent to the MAC? broadcast adress, but not the IP of .255? At least this is how it is displayed in Wireshark. In summary:
Using etherwake xx:xx:xx:cc:cc:cc:
- Wireshark lists destination as only being cc:cc:cc:xx:xx:xx
- Regular WOL works without issues
- SleepOnLan doesn't work
Using etherwake with -b 192.168.1.255
- Wireshark lists destination as "Broadcast"
- Regular WOL works without issues
- SleepOnLan doesn't work
Using Android-app:
- Wireshark lists destination as 192.168.1.255
- Regular WOL works without issues
- SleepOnLan also works
Using http://hostname:8009/wol/cc:cc:cc:xx:xx:xx
- Not displayed in Wireshark on another machine, and not on destination machine (Interface is shutdown before WOL packet is received by Wireshark).. Don't know if this should be the expected behaviour? The other machine with Wireshark was monitoring a wlan interface, which does receive regular WOL packets as normal.
- Regular WOL works as expected
- SleepOnLan also works
This leads me to think that sleep-on-lan isn't actually monitoring in, or at least not properly reacting to all of these cases, especially where the WOL packet seemingly isn't sent to broadcast at all, but only to the destination backwards MAC cc:cc:cc:xx:xx:xx.
from sleep-on-lan.
Related Issues (20)
- Switch logging framework to logrus
- Add missing target platform
- add commands doesn't work HOT 12
- Only allow expected command types in custom commands definition
- Log file or event log on Windows? HOT 2
- Incorrect example for Commands? HOT 3
- Have better "default configuration" generated
- Split the ZIP distribution into one archive per platform
- Split README.md into separated pages
- New --verbose parameter
- Extra default filenames
- Logs where not displaying timestamps in line with system's timezone
- No response for HTTP sleep HOT 2
- Have extra delay before executing command HOT 3
- PC sleeps immediately after Wake on Lan after having used sleep on lan HOT 5
- Wake on LAN works strange when service work HOT 1
- Create non-console version, so conhost.exe doesn't also need to run HOT 3
- VirusTotal scan results HOT 1
- Build binaries for x86 architecture HOT 1
- Commands cannot execute. I think the Execute function in SR-G/sleep-on-lan/src/utils_system.go is bugged.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sleep-on-lan.